4260 Vnal report One-click Information Kiosk

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, . . . )


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


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.”


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


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.


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.


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.


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.


Figure 11: Prototype Ⅴ.


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.


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.


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


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

Documents

4260 Vnal report One-click Information Kiosk