inf 4260 Vnal report
One-click Information Kiosk
Ola Bauge, Kjell Briseid, Hugo Østerberg
{olasba,kjelbr,hugobo}@ifi.uio.no
November 27, 2009
Contents
1 Introduction 3
1.1 Target audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Problem space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Problem speciVcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Method 3
2.1 Data gathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Interface options 4
3.1 Windowed interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Touch screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.1 Multi-touch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4 Robots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5 Cellphone interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.6 Accessibility considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.7 Appliance interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Related work 7
4.1 Taking advantage of physical location: À la carte vs. table d’hôte . . . . . . 8
4.2 Situated software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 Digesting facts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 inf 4260: One-click Information Kiosk
5 Design iterations 12
5.1 Initial interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.1 Informant stats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.2 Suggestions for content . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.3 Suggestions for interface . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.4 Sample user story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.5 Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6 Prototypes 13
6.1 Prototype testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2 Brief description, prototype Ⅴ . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3 Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.4 Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7 Brief evaluation 16
7.1 Issues with phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1.1 First scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1.2 Second scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2 Issues with phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.2.1 Communicating the design . . . . . . . . . . . . . . . . . . . . . . . . 17
8 Second round of interviews 17
8.1 Informant stats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9 Conclusion 19
November 27, 2009 3
1 Introduction
1.1 Target audience
The intended users of our projected application are primarily students at—and, possibly, visitors to—the
University of Oslo informatics department’s new building “ifi-2”.
1.2 Problem space
With time to spare between lectures, a student usually has several options open when it comes to how
to spend it: However, making any sort of an informed decision between them can be diXcult. Within a
time frame of ten minutes to an hour, you can easily waste most of that time just gathering information
about the alternatives available to you — which means this is a pressed situation where having rapid
access to particular kinds of information is especially valuable.
Since this is speciVcally for situations where the total time available for both decision and action can
run as low as ten minutes, a user who is in a hurry should typically not have to spend more than one
minute with the kiosk, performing as few actions as possible to discover the salient facts.
1.3 Problem speciVcation
• What facts are our prospective users interested in?
• How do desires diUer between groups of users, e.g. students vs. employees?
• What is the most eXcient mode of presenting these facts?
• How may users most easily navigate the information?
Originally, the system was intended for both current and prospective students: However, to the degree
that the needs of students and visitors diUer signiVcantly, it’s likely that they’ll beneVt from having
mostly disparate systems serving their separate needs; and a system for visitors would be outside the
scope of this project.
2 Method
For initial ideas, we relied on our personal experience of the types of information that we would have
liked to have in the past, such as: The occupancy rate of login terminals in the computer labs, today’s
lunch specials in the various cafeterias, and upcoming lectures of interest.
To get unbiased opinions from representative potential users, we tried to assemble a focus group, but this
turned out to be unfeasibly diXcult given our limited resources and time frame: Instead, we conducted
interviews with fellow students. These were primarily intended to elicit two things:
• The kind of information they would want quickly available, and
• Opinions as to what kind of form factor the information kiosk should be borne into
(touchscreen, monitor and keyboard, PDA browser app, robots, . . . )
4 inf 4260: One-click Information Kiosk
2.1 Data gathering
A list of six questions was prepared; interviews were carried out in a semi-structured fashion.1One
interview subject was unable to attend in person and instead answered the questions by e-mail — this
could be regarded as a structured interview. Although this was somewhat less helpful than the inter-
views that were conducted face-to-face, it did contribute some useful clues.
3 Interface options
3.1 Windowed interfaces
The GUI “windowing” metaphor provides a visual representation of multitasking: In common usage,
“having an application open” and “having a window open” mean one and the same thing. InteractionDesign mentions (in §6.3.1, p. 226) that «One of the disadvantages of having multiple windows open is
that it can be diXcult to Vnd speciVc ones» or, as Fred Brooks puts it:
. . . the screens of today are too small, in pixels, to show both the scope and the resolution
of any seriously detailed software diagram. The so-called “desktop metaphor” of today’s
workstation is instead an “airplane-seat” metaphor. Anyone who has shuYed a lap full of
papers while seated between two portly passengers will recognize the diUerence — one can
see only a very few things at once.2
Brooks was writing this as early as 1986. However, his “crowded airplane-seat” metaphor still holds
today, because, whereas processing power has tended to double every two years, display resolution has
not followed suit:3Although they’ve gotten larger, most of today’s monitors still operate at no more
than 100 dpi, which is impoverished by several orders of magnitude compared to the 600+ dpi of paper.
Windowing tends to be used as a workaround for this sorry state of aUairs; however, manipulating
windows will usually be Vddly until the particular windowing system becomes familiar.
Our system may safely assume that its users are familiar with windowing systems in general. But to
meet our goal of eXciently serving quick facts we require that users do not have to spend more than
a few seconds to familiarize themselves with the system, as this is for walk-up, not sit-down use:
Basically, we do not have the luxury of presuming any kind of learning curve at all. To realize this we
may have to abandon the usual windowing metaphors outright, as Web browsers like Internet Explorer
and Firefox do in their dedicated “fullscreen” — or, precisely, “information kiosk” modes.
3.2 Menus
Menus give users a choice, usually hierarchical, after an à la carte model: Where the restaurant patron
may pick and choose from appetizers, main courses and desserts, the GUI user picks from «File», «Edit»
and «Help». It is with this as it is with windowing: Familiarity tends to disguise just how counterintu-
itive the usual Windows menus are, when there’s really no particularly logical reason why «Exit» should
be under the File drop-down menu, or what «Check for Updates» is doing in the Help menu of Adobe
1Sharp/Rogers/Preece, Interaction Design (2
nded.) §7.4.3, p. 299
2Frederick P. Brooks, Jr., “No Silver Bullet: Essence and Accidents of Software Engineering” in Kugler, H.-J. (ed.), Informa-
tion Processing ’86, Elsevier Science Publishers B.V. (North-Holland), 1986.3http://en.wikipedia.org/wiki/Moore’s_Law
November 27, 2009 5
Reader. In a walk-up system where we cannot assume familiarity with idiosyncratic conventions like
these, any menus that come into play would have to be arranged in such a way that the user can know
what to expect without having to Vddle around playing with the submenus.
3.3 Touch screens
Mice are notoriously hard to draw with; mostly, they just enable simple pointing. Touch screens advance
the pointing metaphor to one of Vnger-painting, which is in many ways more expressive. Note, however,
several important cases, such as virtual on-screen “buttons”, where touch screens cannot provide the
expected tactile feedback: This lack has obvious implications for accessibility, cf. §3.6.
Figure 1: JeU Han demonstrating a lava
lamp “interactive screensaver”.
When displaying “buttons” on a touch screen there’s also the
problem that people tend to behave as if they’re analog sen-
sors, pressing down harder to get a stronger reaction: If the
interface is unresponsive or otherwise frustrates the user, this
may easily lead to screen damage. Additionally, most touch
screens tend to register temperature better than pressure; the
demo application to which touch screens seem best suited is
the virtual lava lamp.
When UI designers treat the touch screen as simply a mouse-
pointer interface without any rodent in it, this leads to awk-
ward designs where a particular button on one screen ap-
pears, obliviously, in the exact same position as the button you
just activated on the previous screen, which incurs two major
headaches:1)Your Vnger is still hovering in the same position,
obscuring the label far more than a mouse pointer would, and2)Lingering heat from your Vngertip may
activate an unintended option even though you’re no longer touching the screen. This is particularly
egregious with touchscreen applications where mistakes may actually cost you money, as is the case
with ticket vending machines: Though ftir4looks set to improve on this, with today’s technology these
factors still need to be taken into consideration.
3.3.1 Multi-touch
Although multi-touch displays necessarily have to be more sensitive than current-generation touch
screens, the basic problem still remains that placing your hand on the screen obscures valuable screen
space. Also, since there cannot yet be any cemented conventions for multi-touch gestures as there is for
the point & click GUI, multi-touch proper might conceivably get in the way of speedy operation.
3.3.2 Terminology
When discussing touch screen functionality, ‘click’ and ‘button’ will often be used whenever the result
of touching the screen corresponds to a click in a mouse-driven interface.
4Han, J. Y. 2005. Low-Cost Multi-Touch Sensing through Frustrated Total Internal ReWection. In Proceedings of the 18th
Annual ACM Symposium on User Interface Software and Technology
6 inf 4260: One-click Information Kiosk
3.4 Robots
One possible use of robots could combine “attentive environments” with “software agents”.5Especially
for the task of providing information to visitors, roving robots could act as greeters at the door, oUering
to show the way to common points of interest. If the robots happened to be built at iV, they would
simultaneously advertise the technologies developed at the institute.
However, with the enormous complications (and security considerations) incurred by designing any
sort of autonomously moving device, the robotic form factor seems far-fetched at the present time.
3.5 Cellphone interface
Given that modern cell phones are rapidly converging with PDA’s and that many visitors to the institute
of informatics will almost certainly be interested in emerging technologies, relevant information might
simply be oUered to the user through a Web-based «portal» application which would be autodiscovered
by the user’s cell phone when she approached the building’s local wireless network.
3.6 Accessibility considerations
The coupling of machine-readable information with speech synthesizers can be a great help for the sight-
impaired, as in the case of barcode scanners that speak the price of items. However, as our projected
system is primarily an interactive information graphic that assumes little familiarity with its conven-
tions, it becomes more diXcult to construct a separate tactile/speech interface to the facts it provides.6
One accessibility measure which is relatively easy to implement is to oUer a high-contrast colour scheme
with large fonts.7
The other major guideline suggested for making signs available to the partially-sighted — that it should
be possible to stand directly in front of them in order to examine them up close8— will be “built into”
most of the conventional form factors; e.g., it’s a necessity for touch screens.
3.7 Appliance interfaces
This word is used in Interaction Design in a very speciVc sense, taken from the book About Face :
Appliance interfaces... should primarily be considered transient posture interfaces. . . . users ofappliances are trying to get something very speciVc done. Like the users of transactional kiosks,
they are not interested in exploring the interface or getting additional information; they simply
want to put the washer on normal cycle or cook their frozen dinners.9
By “posture” Cooper and Reiman seem to mean, more or less, look-and-feel:
The look and behavior of your program should reWect how it is used, rather than an arbitrary
standard. A program’s behavioral stance—the way it presents itself to the user—is its posture. The
5Interaction Design, p. 270 & 202
6Blindeforbundet, “Et inkluderende samfunn” §2.10.3 —
https://www.blindeforbundet.no/internett/tilrettelegging-i-samfunnet/bygg
7ibid., §2.19
8ibid., §2.10
9Cooper & Reiman 2003, About Face 2.0: The essentials of interaction design, p. 118
November 27, 2009 7
look and feel of your program from the perspective of posture is not an aesthetic choice: It is a
behavioral choice. Your program’s posture is its behavioral foundation...
The “transient posture” seems highly relevant to our ideal of a one-click, one-minute information kiosk,
although in our case the interaction may be slightly less goal-driven: Where someone walking up to a
washing machine usually has a fairly clear idea of what they want to achieve, a listless or hungry student
considering ways to spend his time may not focus quite as much on a single objective in particular.
4 Related work
The 2008 inf4260 project Animated trains is especially interesting for our project since it also amounts
to an interactive information graphic whose primary purpose is to facilitate the rapid dispensing of facts
rather than involved exploration of cascading menus, data entry etc. In particular, we may quote from
page 13 of their Vnal report:
In general people were skeptical to modes, mainly because they didn’t want to interactwith the system. Their only goal was to receive the information they need.
10
This ties directly into Bret Victor’s essayMagic Ink which, as it happens, was inspired by his work on a
MacOS Dashboard widget for planning subway trips.11
His experience with designing the interface for
this widget lead him to consider interactivity itself as harmful and unnecessary:
In this paper, I suggest that the long-standing focus on “interaction” may be misguided. For a
majority subset of software, called “information software,” I argue that interactivity is actually a
curse for users and a crutch for designers...12
Where some designers may argue vaguely in favor of reducing the amount of clicking required for a
given task, Victor argues for an ideal of zero clicking, which he aims to realize through software that is
more acutely context-sensitive — a concept he may have picked up from (again) About Face :
Another distinct diUerence between embedded systems and desktop applications is the importanceof environmental context. ... Even embedded systems that are mostly stationary and secluded
(like household appliances) have a strong contextual element: A host juggling plates of hot food
for a dinner party is going to be distracted, not in a state of mind to navigate a cumbersome set of
controls for a smart oven. ... For kiosks, the contextual concerns focus more on the environment in
which the kiosk is being placed and also on social concerns: What role does the kiosk play in the
environment? Is the kiosk in the main Wow of public traXc? Does it provide ancillary information,
or is it the main attraction itself? Does the architecture of the environment guide people to the
kiosks when appropriate? How many people are likely to use the kiosk at a time?13
In Magic Ink, Victor takes this one step further, declaring that all software should be like embedded
software, discovering their location through GPS and embedding themselves in it.14
Although testing
an actual mobile application would be diXcult for us, the principle of paying attention to the context of
location is easily applied to a stationary kiosk.
10Marthinsen/Fredriksen/Nielsen 2008, “Animated trains” –
http://www.uio.no/studier/emner/matnat/iV/INF4260/h08/student%20projects/interactive-train-maps/
11http://worrydream.com/MagicInk/#case_study_train_schedules
12Bret Victor 2006, Magic Ink: Information Software and the Graphical Interface. http://worrydream.com/MagicInk/
13Cooper & Reiman 2003, About Face 2.0: The essentials of interaction design, p. 491
14“I believe that location is such vital context, Powerbooks should come with GPS receivers pre-installed... Someday, a
computer without GPS might seem as silly as a computer without a clock.”
8 inf 4260: One-click Information Kiosk
4.1 Taking advantage of physical location: À la carte vs. table d’hôte
Clicking items on a screen may be compared to choosing courses from a menu; but à la carte is not theonly way to run a restaurant. Its antonym, table d’hôte, describes serving dishes not to speciVc guests
based on their orders but to speciVc tables at a set time; that is, instead of waiting for the guest to state his
choice, the type of meal is inferred from physical location — as in a fast food chain serving hamburgers
exclusively on the left and veggieburgers on the right. We can also Vnd more information-technological
examples of function being tied to speciVc physical locations, resulting in fewer clicks.
For instance, at UiO’s central Georg Sverdrup library, there are separate stations for delivering and
checking out books; all transactions are initiated by physical actions such as inserting your library card
or placing a book on a conveyor belt. Attendant touchscreens serve mostly to instruct the user.
Figure 2: Location. Time tables for subway lines are
displayed facing the rails those lines run on.
At the somewhat smaller Sophus Bugge library,
however, there is only one station which handles
both incoming and outgoing books; and to signal
your intent of delivering books, you have to stroke
a virtual «button» on a touchscreen, with greater
potential for confusion accordingly.
To resume the dining metaphor, the more compact
multitasking station in Sophus Bugge tries to
make up for having fewer tables by providing more
options on its menu: Instead of simply performing
the self-explanatory, eUortless action of walking up
to a delivery slot, you have to disambiguate your
purpose by pointing. Awkward virtual “naviga-
tion” takes the place of the intuitive physical navi-
gation.
In the language of About Face, the awkward
virtual “preparation” for being allowed to deliver
your books is called excise:
Excise is the extra work that satisVes either the needs of our tools or those of outside agentsas we try to achieve our objectives. The distinction is sometimes hard to see because we get
so used to the excise being part of our tasks. Most of us drive so frequently that diUeren-
tiating the act of opening the garage door from the act of driving towards the destination
is diXcult. Manipulating the garage door is something we do for the car, not for us,and it doesn’t move us towards our destination the way the accelerator pedal and steering
wheel do.
4.2 Situated software
The widespread design of software tied to very speciVc circumstances is a relatively new trend, noted
by Clay Shirky:
Part of the future I believe I’m seeing is a change in the software ecosystem which, for the
moment, I’m calling situated software. This is software designed in and for a particular
November 27, 2009 9
social situation or context. ...the physicalization of the interface, using the gutted BetaMax
deck, provides a communal aUordance that it is impossible to replicate over the web.15
“Communal aUordance” might be a good way to describe our goal of providing bulletins that tie the
campus together to a greater degree, using the increased Wexibility of digital information graphics to
provide campus-wide information which is technically available to everyone, but cumbersome to get
at — e.g., the campus bookstore only posts information about in-store presentations outside their own
building, which can be a ten minute walk from iV.
Although Shirky’s essay touches on issues that are highly relevant for our project, he does not say
anything about situated testing — he seems to assume implicitly that this will simply work out.
4.3 Digesting facts
Figure 3: Undigested temporal facts.
Again, fromMagic Ink: «in any data space with a temporal dimension, “now” is almost always the prime
landmark.» As with the posted timetables, the electronic train schedules only show the immediately
relevant information regarding the track they’re placed right next to.
In Fig. 4 & 5, note also that the less pressing information—departures further into the future—is dis-
played in smaller type and in a less-digested form; this eUectively serves to partition user groups into
those who are in a hurry and those who aren’t, serving their diUerent needs through a variation in the
immediacy of presentation.
15Clay Shirky 2004, “Situated Software”. http://www.shirky.com/writings/situated_software.html
10 inf 4260: One-click Information Kiosk
Figure 4: The same facts digested relative to the current time.
Figure 5: For the beneVt of travellers leaving the platform, departures are displayed for the bus and tram
lines above.
November 27, 2009 11
Figure 6: The same information as in Fig. 5, dis-
played less dynamically.
Figure 7: Semi-geographical information.
Figure 8: Preset ordering by location
instead of by time.
Fig.6 shows schedules digested relative to the current time, but
with a preset ordering of the diUerent lines: This means the lines
can’t be sorted according to the order in which they’ll arrive, and
accordingly, the line numbers and arrival countdowns tend to come
oU visually as just a jumble of random numbers. If you want to
travel in the direction of Majorstuen, you have to keep in mind that
there are two lines you can take.
Static displays are best suited to information that rarely changes;
old maps do not suddenly become useless overnight. However, even
for information that is online, where both client and server have
ready access to a clock, the ordering tends to be preset.
12 inf 4260: One-click Information Kiosk
5 Design iterations
5.1 Initial interviews
5.1.1 Informant stats
Age range 25–33
Years on campus 1/2–7
Percentage male 100%
n = 3
5.1.2 Suggestions for content
Every single person we interviewed requested maps of the campus, including those who had been at the
university for more than Vve years. SpeciVcally:
• Interactive maps with a search function
• Visual description of the route with dots and arrow
• Pictures of the destination building
• Search function for the name and location of employees
Everyone also requested information about the events of the day and upcoming lectures; one speciVcally
mentioned notiVcation for events which had been cancelled or moved. One subject requested menus for
the cafeterias.
5.1.3 Suggestions for interface
• One person mentioned having the information accessible by PDA/phone, all of them thought in
terms of multitouch.
• Everyone thought the dispersal of information to students could be made less cumbersome.
5.1.4 Sample user story
Applications of computer science cross over into a variety of diUerent Velds, and it would be far from
uncommon to have an appointment with someone from a diUerent department. It would therefore be
helpful if the terminal would accept the name of a person as a search word, and then provide a (visual)
description of the route to the building containing that person’s oXce, display the Woor and room number
of said oXce, as well as a picture of the building itself.
5.1.5 Considerations
Having a general-purpose search function would necessitate a virtual or physical keyboard for entering
search terms. This immediately makes using the kiosk more involved than we originally envisioned,
although it may simply be seen as an alternate mode for advanced users. Testing this function would
probably be outside our current scope.
November 27, 2009 13
The suggestion for listing urgent messages is potentially problematic, as what is immediately urgent will
vary widely depending on the courses the individual is enrolled in — however, identifying individual
users also makes things rather more involved. We have been toying with the idea of identifying students
by having them swipe their electronic ID card but, again, testing this is likely to be outside the current
scope of our project.
Information about lectures that have been moved might be oUered by displaying message boxes taken
from the Web pages of courses whose lectures are, or were, scheduled to begin shortly. This could
remove the need for identifying users by paying closer attention to the temporal dimension — i.e.,
coarsely targeting the application at groups of users rather than individuals.
6 Prototypes
6.1 Prototype testing
Since there wasn’t much time for developing and testing the prototypes, we decided to focus on the map
as this was likely to be the biggest design challenge and the component most likely to be reused, e.g.
providing directions to events and cafeterias. After coming up with our candidate concept, it became
clear that we would need to use paper sketches for the Vrst round of testing as even a simple mock-up
would require a lot of work.
Figure 9: Prototypes Ⅰ–Ⅲ.
We developed 3 diUerent screen solutions (prototypes Ⅰ—Ⅲ), to give the user a feel of the design of the
end product. The circles stand for icons that the user may press to achieve the desired action.
Further prototyping focused on the design of the main interior screen of the map application itself. The
less complex prototype Ⅳ was given less attention than the fancier prototype Ⅴ.
6.2 Brief description, prototype Ⅴ
The main screen consists of a conventional 2D top-down map of the campus area, a textual list of the
names of the buildings, and a labeled “button” that will take the user to a reVning search function.
From a system design perspective, the map function can be divided into two states: phase one, in which
the user identiVes the destination; and phase two, in which she explores the route to it.
14 inf 4260: One-click Information Kiosk
Figure 10: Prototype Ⅳ, a less complex version of the map component.
6.3 Phase 1
There are two main scenarios for the use of prototype Ⅴ:
1) If a building is chosen from the textual list, both the list item and the corresponding building will
be illuminated. Further, the route to the building will be plotted into the map, and the entire map
area will Wash temporarily to communicate to the user that changes have occured. Next, the user
may deselect the building by clicking the list item again, or simply choose a diUerent item.
2) If the reVning search—for the sake of this discussion, presume it to be labelled «Find person»—is
chosen, the map area will fade into the background and a search window will appear “on top”
of it. (The idea here is that the overlay will make the process more intuitive by providing an
immediate context for the search.) After a person has been chosen, the window will fade out and
the map brought into the foreground again, now showing data16about said person and a route to
her building. Both of these items will Wash temporarily to indicate that they’ve changed.
6.4 Phase 2
The route to the destination will be plotted onto the map using dots. Clicking a dot or a building will
bring up a 360-degree photo of the corresponding area. This picture can be rotated by dragging one
Vnger over it in the intended direction, and it can be resized with two Vngers by stretching or shrinking
it. It can be removed by clicking a familiar «X» in its right upper corner or by clicking anywhere outside
of it.
16Name, picture, building, oXce and telephone number.
November 27, 2009 15
Figure 11: Prototype Ⅴ.
16 inf 4260: One-click Information Kiosk
7 Brief evaluation
7.1 Issues with phase 1
7.1.1 First scenario
While selecting a building from the textual list does what one expects it to do, the result of clicking a
building in the map area could potentially leave the user confused. The system should convey what the
diUerent items do, but if there is any elegant way of encoding this message into the graphics themselves,
we have yet to Vnd it. So for now, both areas will have a textual label describing proper use.
7.1.2 Second scenario
There are many bad designs for the search function. The one we tried for the prototype, consists of a
virtual keyboard for inputting the name of the person to be located, a text Veld displaying the current
input, and an index of the persons whose names match the current input.
Said index will show both names and portrait photographs to allow for quick identiVcation. But it is
far from obvious how this index should be presented visually. If the name is to be emphasized, then a
scrollable list might be a good option. If the photo is to be emphasized, some sort of carousel might be
a good option. For this prototype, we chose the latter on the grounds that a conical or circular carousel
would be more interesting to the eye than the traditional list view. There are, however, many remaining
issues:
• Whenever the index is large, the carousel must be truncated so that only a portion of it is shown.
The original idea was that the user could “spin” the carousel to navigate the index; but on reWec-
tion, this turned out to be less than ideal.
Firstly, the question arises how exactly this spinning is to be performed. One could click one of the
currently shown items and drag it left or right, but then it becomes unclear what should happen
when said item is rotated out of view. Alternatively, there could be a slider to move back and
forth in the index, but if the list is large it will require very precise movement. One could also
consider having “back” and “forward” buttons, but having to tap the screen repeatedly might very
well serve to aggravate the user.
Secondly, if the search needs to be reVned because the person in question was not identiVed in the
search, the user must repeatedly move her hands between the virtual keyboard and the carousel.
This simply does not feel like good design.
• Since we cannot presuppose that the user can identify the person she needs to Vnd by appearance
only, the name must be legible at all times. For longer names, this might mean that the carousel
will be sparsely populated and thus less useful.
While it could be argued that the above objections represent marginal cases—after all, most name
searches will yield only a handful of matches—they do underline the fact that there is something inher-
ently inelegant about the design. We suspect, however, that a truly elegant solution would be diXcult to
come by, and that the task itself may not be readily adapted to our platform.
November 27, 2009 17
7.2 Issues with phase 2
7.2.1 Communicating the design
As noted earlier, we’re not sure how to let the user know that she can click the dot in order to view the
area in photographic detail. The dots can be made to pulsate gently to make them stand out more, but
there would still need to be some sort of design convention that pulsating objects can be interacted with.
For want of such a convention, the best we’ve come up with is a label stating that the user may click
pulsating objects for a detailed view. This solution, of course, goes against the injunctions of several UI
authorities (e.g., Krug17) that interfaces should be self-explanatory.
8 Second round of interviews
8.1 Informant stats
Age range 25–33
Years on campus 1/2–8
Percentage male 100%
n = 2
For this round of interviews, we developed three sets of prototypes. The Vrst set (Ⅰ–Ⅲ) represented
alternative layouts for the main menu. The second set (Ⅳ) represented a minimal map function, while
the third set (Ⅴ) represented the bells and whistles map version as described in chapters 6 and 7.
Suggestions for modeling of screen, prototypes Ⅰ–Ⅲ:
Both persons liked prototypeⅢ. One of them would have preferred having the list of icons on the bottom
of the screen, instead of at the top (as in prototype Ⅱ). The other one thought it was a bit troublesome
that the icons on the drawing could be interpreted as physical buttons.
Feedback on prototype Ⅳ:(Fig. 10)
This prototype was intended as a fallback, for ease of implementation over prototype Ⅴ; however, this
fact may not have been clearly communicated to our interview subjects.
One of our participants thought that the connection between the list of buildings and the suggested
path to follow was less than obvious. He thought that the map could be useful, depending on where one
wanted to go. For maximum usefulness, there would have to be screens located almost everywhere, as
the interviewee claimed.
The other interviewee thought that the map could be useful for people unfamiliar with the diUerent
areas and buildings at Blindern; also, that it would have been nice with directions to particular rooms or
oXces inside the buliding. In addition, he suggested a wheelchair edition of the map.
18 inf 4260: One-click Information Kiosk
Feedback on prototype Ⅴ:(Fig. 11)
One of the interview subjects didn’t quite understand the thing about the «Search» button. He would
have preferred «Søk» instead of «Search». He didn’t understand that the keyboard actually was a key-
board and not all about how to get from Vgure Ⅰ to Vgure Ⅲ. A «3D Model» button would have been
nice, he thought. It would be quite useful, he thought, with a map like this. But that it could be made
more intuitive. He liked the 3D function and thought it was cool. But he would have preferred that it
was a bit more obvious than for this model.
The other interviewee didn’t understand «Search». Did it lead to search functionality for oXces, houses
or lectures? He would have preferred some more information in the search box, so one could understand
a little bit more. He thought the 3D model was both cool and fun, but a little uncertain about how useful
it would be. He missed a description of how to get to a particular oXce in a building.
8.2 Discussion
The preference for having the search button labelled in Norwegian may be because it stood out against
the Norwegian names of the buildings right next to it in Vg. Ⅰ in prototype Ⅴ.
The problem of communicating what exactly it is that you’re searching for has been treated in e.g. Krug
2000:
. . . in sites that oUered options many people were left puzzled when their search failed
because they had misinterpreted their options. ... After all, why should I have to think
about how I want to search? And even worse, why should I have to think about how the
site’s search engine wants me to phrase the question, as though it were some ornery troll
guarding a bridge?18
In this case, it may be that the lack of speciVcity in the early prototype made things more confusing by
not providing enough subtle cues as to what exactly was being searched; or it may be a simple question
of not being in the expected place.
17Steve Krug 2000, Don’t Make Me Think: A Common Sense Approach to Web Usability, p. 46
18Steve Krug 2000, Don’t Make Me Think: A Common Sense Approach to Web Usability, p.17
November 27, 2009 19
9 Conclusion
On the face of it, “number of clicks to get anywhere” seems like a useful criteria. But over time I’ve
come to think that what really counts is not the number of clicks it takes me to get to what I want
(although there are limits), but rather how hard each click is—the amount of thought required, and
the amount of uncertainty about whether I’m making the right choice.19
For this project, we decided to use «lo-V» prototyping, following the recommendation of Rettig that this
is a great help early in the design of a project:
Reviewers and testers tend to comment on “Vt and Vnish” issues. You are trying to get feed-
back on the big things: the Wow of the conversation, the general layout of the controls,
the terminology, the expressiveness and power of the basic metaphor. With a slick soft-
ware prototype, you are just as likely to hear criticisms about your choice of fonts, color
combinations, and button sizes.20
Both Nielsen, Rettig and Krug recommend videotaping the users’ reaction to prototypes for later analysis,
but this was sadly not within our means. Also, taking clear photographs of destination buildings to give
map users an idea of what to look for was diXcult due to a dearth of available light in November.
A more thorough study would most likely have to include fresh participants in each round, to avoid
designing for the idiosyncracies of individual participants. For a balanced impression, at least one round
would have had to include users who were not male and/or students.
Through the design iterations, we learned that all our test users wanted maps, even though there were
already reasonably well-designed ones printed on the signposts throughout campus. We did make some
headway on the map component.
Our initial vision for the kiosk had a stronger focus on temporally relevant information (today’s lunch
specials, lectures, concerts etc.), hence the focus on information graphics that change with time in the
theory sections.
19ibid., p.41
20Marc Rettig, “Prototyping for Tiny Fingers”. Comm. ACM Vol. 37, No. 4 (April 1994), p. 21–27