“smart” phones (such as Treos and BlackBerries), I think most would agree that the depth of functionality included on these devices does somewhat compromise their efficacy as telephones.
14_084113 ch09.qxp 4/3/07 6:04 PM Page 187
Chapter 9: Platform and Posture
187
Figure 9-8 The Palm Treo 650 provides hardware buttons for switching between modes (notice the calendar and e-mail buttons on either side of the four-way rocker).
Many devices share information with desktop systems. It makes sense to approach the design of such systems from a desktop-centric point of view: The device is an extension or satellite of the desktop, providing key information and functions in contexts where the desktop system isn’t available. Scenarios can help you determine what functions are truly useful for such satellite systems.
Balance navigation with display density
Many devices are constrained by limited display real estate. Whether limited by hardware cost, form factor, portability, or power requirements, designers must make the best use of the display technology available while meeting the information needs of users. Every pixel, segment, and square millimeter of display are significant in the design of display-constrained embedded systems. Such limitations in display real estate almost always result in a trade-off between clarity of information displayed and complexity of navigation. By appropriately limiting the scope of functions, you can ameliorate this situation somewhat, but the tension between display and navigation almost always exists to some degree.
You must carefully map out embedded systems’ displays, developing a hierarchy of information. Determine what is the most important information to get across, and make that feature the most prominent. Then, look to see what ancillary information
14_084113 ch09.qxp 4/3/07 6:04 PM Page 188
188
Part II: Designing Behavior and Form
can still fit on the screen. Try to avoid flashing between different sets of information by blinking the screen. For example, an oven with a digital control might display both the temperature you set it to reach and how close it is to reaching that temperature by flashing between the two numerical values. However, this solution easily leads to confusion about which number is which. A better solution is to display the temperature that the oven has been set to reach and next to that, to show a small bar graph that registers how close to the desired temperature the oven currently is. You must also leave room in the display to show the state of associated hardware controls, or better yet, use controls that can display their own state, such as hardware buttons with lamps or hardware that maintains a physical state (for example, toggles, switches, sliders, and knobs).
Minimize input complexity
Almost all embedded systems have a simplified input system rather than a keyboard or desktop-style pointing device. This means that any input to the system —
especially textual input — is awkward, slow, and difficult for users. Even the most sophisticated of these input systems, such as touch screens, voice recognition, handwriting recognition, and thumb-boards, are cumbersome in comparison to full-sized keyboards and mice. Thus, it’s important that input be limited and simplified as much as possible.
Devices such as RIM’s BlackBerry make effective use of a thumbwheel as their primary selection mechanism: Spinning the wheel very rapidly scrolls through possible choices, and pressing the wheel (or a nearby button) selects a given item. Both of these devices also make use of thumb-boards when text data entry is necessary.
In contrast, the Palm Treo makes use of a touch screen and a thumb-board. This would be effective if you could adequately activate everything on the Treo screen by the touch of a finger. However, most Palm screen widgets are too small and require users to rely on a stylus for accurate interactions. This means that users must switch between stylus and thumb-board, making for considerably awkward input interactions. Palm has attempted to compensate for this in recent models by adding a five-way (left, right, up, down, and center) D-pad between the touch screen and thumb-board, which allows users to navigate to and activate screen widgets without actually touching the screen (see Figure 9-8).
Kiosks, whose screens are usually larger, should nonetheless avoid complex text input whenever possible. Touch screens can display soft keyboards if they are large enough; each virtual key should be large enough to make it difficult for the user to accidentally mistype. Touch screens should also avoid idioms that involve dragging; single-tap idioms are easier to control and more obvious (when given proper affordance) to novice users.
14_084113 ch09.qxp 4/3/07 6:04 PM Page 189
Chapter 9: Platform and Posture
189
Designing for handhelds
Handheld devices present special challenges for interaction designers. Because they are designed specifically for mobile use, these devices must be small, lightweight, economical in power consumption, ruggedly built, and easy to hold and manipulate in busy, distracting situations. Especially for handhelds, close collaboration among interaction designers, industrial designers, programmers, and mechanical engineers is a real necessity. Of particular concern are size and clarity of display, ease of input and control, and sensitivity to context. This section discusses, in more detail, these concerns and useful approaches to address them. The following are the most useful interaction and interface principles for designing handheld devices:
Strive for integration of functionality to minimize navigation. Handheld devices are used in a variety of specific contexts. By exploring context scenarios, you can get a good idea of what functions need to be integrated to provide a seamless, goal-directed experience.
Most convergence devices run the risk of pleasing nobody by attempting to do too much. Communicators such as the Treo are at their best when they integrate functionality for a more seamless experience of communication-related functions. These devices currently do a reasonable job of integrating the phone and address book: When a call arrives, you can see the full name from the address book and, by tapping on a name in the address book, you can dial it. However, this integration could be taken a step further. Clicking on a name in an address book could show you all documents known to the communicator that are associated with that person: appointments, e-mails, phone calls from the log, memos including the caller’s name, Web sites associated with him, and so on. Likewise, clicking on the e-mail address in the address book could launch the mail application. Some recent applications for communicators, such as iambic Inc.’s Agen-dus, are beginning to take this approach to integrating what were once different applications into a more seamless flow that matches users’ goals.
Think about how the device will be held and carried. Physical models are essential to understanding how a device will be manipulated. The models should at least reflect the size, shape, and articulation (flip covers and so on) of the device, and they are more effective when weight is also taken into account. These models should be employed by designers in context and key path scenarios to validate proposed form factors. Labels on buttons have very different contextual needs depending on where and when they will be used. For example, the labels on a package-delivery tracking tool don’t need to be backlit like those on a cell phone or TV remote control.
Determine early on whether the device or application will support one-handed or two-handed operations. Again, scenarios should make it clear which modes are acceptable to users in various contexts. It’s okay for a device that is intended
14_084113 ch09.qxp 4/3/07 6:04 PM Page 190
190
Part II: Designing Behavior and Form
primarily for one-handed use to support some advanced functions that require two-handed use, as long as they are needed infrequently. A handheld inventory tool, for example, that allows all counting to be done single-handedly, but then requires two hands to submit the entered data confers no advantage because the submit function is part of a frequent-use scenario.
Consider whether the device
will be a satellite or a standalone. Most handheld data devices are best designed as satellites of desktop data systems. Palm and Windows Mobile devices both succeed best as portable systems that communicate with desktop systems or servers. Rather than replicate all desktop functions, they are geared primarily towards accessing and viewing information and provide only lightweight input and editing features. The latest handheld models extend the idea of a tethered satellite into the realm of wireless connectivity, making the idea of the satellite device even more powerful and appropriate.
On the other hand, some devices, such as standard cell phones, are truly designed to be standalone. It’s possible to upload phone numbers from PCs to many cell phones, but most users never try to do so because of the interaction complexity. Such standalone devices are most successful when they focus on a narrow set of functions, but provide world-class behaviors for those functions.
Avoid use of pluralized and pop-up windows. On small, low-resolution screens, floating windows typically have no place. Interfaces, in this regard, should resemble sovereign posture applications, taking the full-screen real estate. Modeless dialogs should be avoided at all cost, and modal dialogs and errors should, whenever possible, be replaced using the techniques discussed in Chapters 24 and 25.
Postures for handheld devices
Designing for handheld devices is an exercise in hardware limitations: input mechanisms, screen size and resolution, and power consumption, to name a few. One of the most important insights that many designers have now realized with regard to some handheld devices is that handhelds are often not standalone systems. They are, as in the case of personal information managers like Palm and Windows Mobile devices, satellites of a desktop system, used more to view information than perform heavy input on their own. (Despite the fact that many handhelds have thumb-boards or detachable fold-up keyboards, they are still hardly fit for input-intense interactions.) These satellite devices usually take a transient posture. In a typical interaction, a user quickly refers to his daily calendar or adds an item to his to-do list while sitting at a stop light.
Cellular telephones are an interesting type of handheld device. Phones are not satellite devices; they are primary communication devices. However, from an interface posture standpoint, phones are also transient. A user places a call as quickly as
14_084113 ch09.qxp 4/3/07 6:04 PM Page 191
Chapter 9: Platform and Posture
191
possible and then abandons the interface in favor of the conversation. The best interface for a phone is arguably nonvisual. Voice activation is perfect for placing a call; opening the flip lid on a phone is probably the most effective way of answering it (or again using voice activation for hands-free use). The more transient the phone’s interface is, the better.
In our work we routinely hear about ideas to create sovereign applications for handheld devices, such as a product that allows radiologists to review medical imaging such as x-rays and MRIs while at the golf course. Clearly portable display technology has a long time to go before these products are ready for the market, and it remains to be seen how appropriate handhelds can be for sovereign applications (aside from for entertainment products like portable game devices and portable DVD players).
Designing for kiosks
On the surface, kiosks may appear to have much in common with desktop interfaces: large, colorful screens and reasonably beefy processors behind them. But as far as user interactions are concerned, the similarity ends there. Kiosk users, in comparison with sovereign desktop application users, are at best infrequent users of kiosks and, most typically, use any given kiosk once. Furthermore, kiosk users will either have one very specific goal in mind when approaching a kiosk or no readily definable goal at all. Kiosk users typically don’t have access to keyboards or pointing devices, and often wouldn’t be able to use either effectively if they did.
Finally, kiosk users are typically in a public environment, full of noise and distractions, and may be accompanied by others who will be using the kiosk in tandem with them. Each of these environmental issues has a bearing on kiosk design (see Figure 9-9).
Transaction versus exploration
Kiosks generally fall into two categorical types: transactional and explorational.
Transactional kiosks are those that provide some tightly scoped transaction or service. These include bank machines (ATMs) and ticketing machines such as those used in airports, train and bus depots, and some movie theaters. Even gaso-line pumps and vending machines can be considered a simple type of transactional kiosk. Users of transactional kiosks have very specific goals in mind: to get cash, a ticket, a Tootsie Roll, or some specific piece of information. These users have no interest in anything but accomplishing their goals as quickly and painlessly as possible.
14_084113 ch09.qxp 4/3/07 6:04 PM Page 192
192
Part II: Designing Behavior and Form
Figure 9-9 The GettyGuide, a system of informational kiosks at the J. Getty Center and Villa in Los Angeles, designed by Cooper in collaboration with the Getty and Triplecode.
Explorational kiosks are most often found in museums. Educational and entertainment-oriented kiosks are typically not a main attraction, but provide additional information and a richer experience for users who have come to see the main exhibits (though there are certainly a few museums, such as the Experience Music Project in Seattle, where interactive kiosks form the basis for some exhibits).
Explorational kiosks are somewhat different from transactional kiosks in that users typically have open-ended expectations when approaching them. They may be curious, or have the desire to be entertained or enlightened, but may not have any specific end goals in mind. (On the other hand, they may also be interested in finding the café or nearest restroom, which are goals that can be supported alongside the more open-ended experience goals.) For explorational kiosks, it is the act of exploring that must engage the user. Therefore, the kiosk’s interface must not only be clear and easy to master in terms of navigation, but it must also be aesthetically pleasing and visually (and possibly audibly) exciting to users. Each screen must be interesting in itself, but should also encourage users to further explore other content in the system.
14_084113 ch09.qxp 4/3/07 6:04 PM Page 193
Chapter 9: Platform and Posture
193
Interaction in a public environment
Transactional kiosks, as a rule, require no special enticements to attract users. However, they do need to be placed in an optimal location to both be obviously visible and to handle the flow of user traffic they will generate. Use wayfinding and sign systems in conjunction with these kiosks for the most effectiveness. Some transactional kiosks, especially ATMs, need to take into account security issues: If their location seems insecure, users will avoid them or use them at their own risk. Architectural planning for transactional kiosks should occur at the same time as the interaction and industrial design planning.
As with transactional kiosks, place explorational kiosks carefully and use wayfinding systems in conjunction with them. They must not obstruct any main attractions and yet must be close enough to the attractions to be perceived as connected to them. There must be adequate room for people to gather: Exploration kiosks are more likely to be used by groups (such as family members). A particular challenge lies in choosing the right number of kiosks to install at a location — companies employing transactional kiosks often engage in user flow research at a site to determine optimum numbers. People don’t linger long at transactional kiosks, and they are usually more willing to wait in line because they have a concrete end goal in mind. Explorational kiosks, on the other hand, encourage lingering, which makes them unattractive to onlookers. Because potential users have few expectations of the contents of an explorational kiosk, it becomes difficult for them to justify waiting in line to use one. It is safe to assume that most people will only approach an explorational kiosk when it is vacant.
When de
signing kiosk interfaces, carefully consider the use of sound. Explorational kiosks seem naturals for use of rich, audible feedback and content, but volume levels should be chosen so as not to encroach on the experience of the main attraction such kiosks often support. Audible feedback should be used sparingly for transactional kiosks, but it can be useful, for example, to help remind users to take back their bankcard or the change from their purchases.
Also, because kiosks are in public spaces, designing to account for the needs of differently-abled users is especially important. For more about designing for accessibility, see Chapter 26.
Managing input
Most kiosks make use either of touch screens or hardware buttons and keypads that are mapped to objects and functions on the screen. In the case of touch screens, the same principles apply here as for other touch screen interfaces:
14_084113 ch09.qxp 4/3/07 6:04 PM Page 194
194
Part II: Designing Behavior and Form
Make sure that your click targets are large enough. Touchable objects should be large enough to be manipulated with a finger, high contrast, colorful, and well separated on the screen to avoid accidental selection. A 20mm click target is a typical minimum if users will be close to the screen and not in a hurry — this size should be increased for use at arm’s length or when in a rush. A good low-tech trick to make sure that your click targets are large enough is to print the screens at actual size, ink the end of your finger with a stamp pad, and run through your scenarios at a realistic speed. If your fingerprints are overlapping the edges of your click targets, you probably should increase their size.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 28
