Kortum P. (ed.) HCI Beyond the GUI. Design for Haptic, Speech, Olfactory, and Other Nontraditional Interfaces

Подождите немного. Документ загружается.

in the book. While the chapter on MIMM interfaces is not meant to be a primer

on system human factors, it will discuss how to determine which interface modes

to use (interface allocation) and how and when to overcode the interfaces (inter-

face redundancy), and it will deal with issues surrounding the presentation of

information using non-native interfaces (i.e., using tactile displays to represent

sound).

1.3

DESIGN PRINCIPLES FOR NONTRADITIONAL

INTERFACES

Each chapter describes certain human factors principles and design considera-

tions that should be taken into account when working with a particular interface

modality. However, the fundamental principles for designing nontraditional inter-

faces are the same as those for designing traditional GUIs. Schneiderman and

Plaisant (2004), Nielsen (1999), Raskin (2000), Norman (2002), Mayhew (1997),

and others have described these principles in great detail. The key is to remember

that the traditional, fundamental principles still apply, even if the interface you

are designing is anything but traditional.

Most users do not care about the interface technology—they simply have a

task they want to accomplish and they want the interface to support them in com-

pleting that task. Too often, however, the designer is led by other goals (corporate

needs, fascination with technology, “cool” factor, etc.), and the human factors of

the design suffer. The bottom line is this: Good designs do not just happen! They

are the result of careful application of numerous design methodologies that enable

you, as the designer, to understand the user, the environment, and how they

interact. ISO 9241:11 (ISO, 1998) specifies that usable designs should have three

important attributes.

First, they should be

effective

, meaning that the user can successfully use the

interface to accomplish a given goal. Second, the interface should be

efficient

This means that the user not only can accomplish the goal, but can do so quickly

and easily with a minimum of error or inconvenience. Finally, the interface

should leave the user

satisfied

with the experience. This does not mean the user

has to be happy, but it does mean that the user should have high confidence

that the task was accomplished according to his intentions. For example, using

a bank’s automated telephone system to transfer money should be easy to do

(effective), quick (efficient), and leave users with the certainty that they really accom-

plished the task and that the bank has their correct instructions (satisfaction).

The next section summarizes the fundamental human factors design guide-

lines to keep in mind when pursuing general usability goals, regardless of the

interface mode(s) you eventually decide to use in your interface.

1 Introduction to the Human Factors of Nontraditional Interfaces

1.3.1 Design to Support the User’s Goals

Whenever you start a design, you certainly have the user in mind. Unfortunately,

somewhere along the way, designers often forget that they should be trying to

serve the user rather than another master, such as the corporation, vendor, or

technology. Think about what the user wants or needs to do and focus on that.

A great example of a violation of this principle can be found in the butterfly ballot

debacle in the 2000 Florida elections. Although not maliciously conceived (unless

you are a conspiracy buff), the ballot was designed to support a more modest

goal: space efficiency. The results, as we all know, were significant questions

about voters’ intent in the seemingly simple task of selecting their preferred can-

didate. Each time you are tempted to add, delete, change, prettify, or otherwise

alter a good design, ask yourself if this helps the user accomplish the goal. If it

does not, think twice!

1.3.2 Design to Support the User’s

Conceptual Model

Whenever people use a system, they bring with them an idea of how that system

works. If your system’s design does not match this idea (the user’s conceptual

model), then the way that the person will use the system can be unpredictable.

The classic example of this is how many people interact with the thermostat

in their home. For instance, a person comes home from a long day at work, and

the house is

hot

. He goes to the thermostat and turns the dial all the way to the

left to quickly cool the house down. Why does he turn it all the way to the left,

rather than carefully select the exact temperature that he wants the house to

be? Does turning the dial all the way to the left make it cooler faster? No! The cool-

ing system in the home is a two-state device—it is either on or off. It cools until it

reaches the temperature set on the thermostat. However, the model that many of

us have is that the farther you turn the dial to the left, the cooler it gets. In one

respect, that is true—left is cooler—but the rate of change is independent of the

setting. Why is this a problem?

Invariably, after making this “make-it-as-cold-as-fast-as-possible” adjustment,

one gets called away from the house and returns to meat-locker–like tempera-

tures. The interface failed to support what the user thought the system would

do (and what the user wanted it to do). Newer electronic thermostats seem to

have prevented this problem, since a specific temperature setting is required

and so a quick “cold-as-you-can-make-it” command is harder and slower to exe-

cute. Figuring out what the user’s model is can be difficult (and models may vary

from person to person). However, mapping the way the system

really

works to

the way people

think

it works makes for superior usability.

1.3 Design Principles for Nontraditional Interfaces

1.3.3 Design for the User’s Knowledge

Each user of your interface will bring a specific set of knowledge and experience

to the table. If your interface requires knowledge that the user does not have, then

it will likely fail (unless you can train the user on the spot). For instance, as illu-

strated in Figure 1.4, the designer took great care to ensure that the interface

would support users with multiple language skills (good for the designer!). How-

ever, he failed to follow through in his execution of the design. What is wrong with

this selection menu? The user must read English in order to select the desired lan-

guage! Determine what your users know, and then design the interface to require

no more knowledge than that.

1.3.4 Design for the User’s Skills and Capabilities

In addition to specific knowledge sets, users of your interface will also have

specific sets of skills and capabilities that limit how they can use your interface.

For example, humans have specific limits on what they can hear, so when you

are designing an auditory warning, you want to make sure that you select a

frequency that can be easily heard by the human ear. Think of the dog whistle as a

dog’s basic auditory display—it says “Attention!” to the dog. The interface

is worthless for use with humans (like your children) because the whistle operates

outside of the human ear’s capability to detect sound. It is, however, a perfect inter-

face for the dog. By thinking of what your users can and cannot do, you can design

the interface in the most effective fashion.

Figure 1.5 shows an example of a poorly designed interface in that it ignored

the specific skills and capabilities of its intended users. While the intent of the

designers was noble, the execution of the design resulted in an interface that

did not serve its intended purpose.

FIGURE

1.4

Example of a clear violation of designing for the user’s knowledge.

Users must read English in order to select the language in which they would like

to use the interface. (Courtesy of the Interface Hall of Shame.)

1 Introduction to the Human Factors of Nontraditional Interfaces

1.3.5 Be Consistent—But Not at the Expense

of Usability

Consistency is often the hallmark of a usable design. Once you learn to use one

interface, then other similar interfaces are easier to learn and use. This consis-

tency can manifest itself as standardization among interfaces made by different

designers or can show up as good internal consistency within a given interface.

In both cases the usability of the interface is increased because users have to learn

and remember less as they become familiar with the interface. Unfortunately,

blind adherence to the consistency principle can actually lead to less usable inter-

faces. Sometimes the existing standard does not lend itself well to a new problem

or situation. If the designer makes the decision that consistency is of the utmost

importance, then the entire interaction may be “force-fit” into the standard inter-

face. While the end user may enjoy some of the benefits of a consistent interface,

the forced fit may actually decrease the overall usability of the system. Small-

screen implementations of the Microsoft Windows operating system are a good

example in which consistency may not have been the right choice.

FIGURE

1.5

Example of an interface that does not take into account the skills and

capabilities of the users for whom it was intended.

The intercom system is supposed to be used by individuals who are mobility

impaired and cannot pump their own gas. The problem here is that its placement

precludes its use by this very population. Further, the instructions that explain

what the user is supposed to do are too small to be easily read from the most likely

location of a user in a wheelchair.

1.3 Design Principles for Nontraditional Interfaces

Clearly, the users of these devices had the potential advantage of being able to

seamlessly transition between desktop and handheld applications. However,

many of the GUI elements that Windows uses do not scale well to very small

screens and so the consistency begins to degrade. Now, the interface is only partially

consistent, so many of the benefits derived from consistency are lost (“I know

I can do this in Windows! Where is the icon!?!”). Other manufactures of small-

screen devices have determined that there are better interface methods and have

designed their own specialized interfaces (Chapter 10 addresses these in much

more detail). While the learning consistency has been forfeited, the interface

is not being asked to do things that it was not originally designed to do, and so

overall usability is enhanced. In the end, you should seriously consider whether

consistency enhances or detracts from the overall usability of the interface, and

then make the appropriate implementation decision.

1.3.6 Give Useful, Informative Feedback

When I first began giving lectures that included these eight design principles, this

guideline simply read “Give Feedback.” However, after seeing too many examples

of useless feedback messages filled with cryptic error codes or worthless state

information (Figure 1.6), the guideline was changed to include the words “useful”

and “informative.” Users of an interface need to know where they are in the inter-

face, what they are doing, and what state the system is in. By providing feedback,

the system aids the user in making correct, efficient decisions about what actions

to take next.

The feedback may be explicit and require direct action (e.g., a pop-up dialog

box that states, “Clicking yes will erase all the data. Proceed anyway?”), or it

FIGURE

1.6

Interface providing feedback that is not useful or informative.

Why can’t I do this? What should I do to make it so that I can? Is there a

workaround? This is the kind of feedback that gives interface designers a bad

name. (Courtesy of the Interface Hall of Shame.)

1 Introduction to the Human Factors of Nontraditional Interfaces

may be more subtle in nature and provide the user with cues that the state of the

system has changed and requires the attention of the user (e.g., antilock-brake

feedback systems). As the designer, you should make sure that you provide both

kinds of feedback, and test the effectiveness of the feedback with actual users

who encounter the cases where it is provided.

1.3.7 Design for Error Recovery

People make mistakes. With that in mind, you should always ensure that the inter-

face is designed to help users by minimizing the mistakes they make (e.g., the auto-

spell feature in a word-processing program) and by helping them recover from

mistakes that they do make. In the strictest definition of error, no adverse conse-

quence is required for the action (or lack thereof ) to be considered as an error.

In practical terms, however, an error that is caught and corrected before any

adverse impact occurs is of far less concern than an action that has an adverse out-

come. Providing users with ways to easily correct their mistakes, even long after

they have happened can be very beneficial. The trash can that is employed in many

desktop computer interfaces is an excellent example. A document may be thrown

away but, just like in the physical world, can be pulled out of the trash and recov-

ered if the user discovers that the deletion was in error. Contrast that with the dia-

log window shown in Figure 1.7. Even if the user recognizes that she has performed

the action in error, the system is offering no recourse. Adding insult to injury, the

poor user has to acknowledge and accept the action that is no longer desired!

1.3.8 Design for Simplicity

As Albert Einstein once noted, “Make everything as simple as possible, but not

simpler.” This axiom is especially true in interface design. Simplicity makes

FIGURE

1.7

Poor error recovery for a critical action.

Imagine what you would do (besides scream) if you knew you had just made a

mistake, and you did not want to overwrite the original file. (Courtesy of the

Interface Hall of Shame.)

1.3 Design Principles for Nontraditional Interfaces

interfaces easy to learn and easy to use—complexity does the opposite. Unfortu-

nately, complexity is sometimes a necessary evil that reflects the nature of the

task. Interfaces for nuclear power plants and sophisticated fighter jets just cannot

be as simple as that for an iPod. In these situations, you must strive to understand

the user’s task to such a degree as to be able to distill the interface down to its

essential components. The result may still be complex, but its functions will rep-

resent what the user (the operator or the pilot) actually needs to do.

In many cases, however, the complexity is due to the inclusion of features,

usually over time, that “enhance” the product. All of us have seen this feature

creep. You only have to look as far as your word processor—features, features,

and more features. If only I could just figure out how to use them, they would

be great. Design simplicity is where the human factors practitioner and the

marketing folks may be at odds, since marketing is often looking for feature

superiority (“My toy has more features than your toy!”). The result can be an

interface that masquerades as simple, but has significant hidden functionality

and complexity behind its beautifully simple exterior. The modern cell phone is

a classic example.

In its most basic form, the cell phone is designed to make and receive calls.

In most current implementations, it is also a camera, an address book, an MP3

player, a game platform, a pager, and so on and so forth. While each feature on

its own may be important, the combination of all these features, particularly on

a small-screen device, can lead to usability nightmares. Sometimes the complexity

is simply a matter of space—too many features and not enough space to imple-

ment them. Figure 1.8 shows an example of a relatively complex design that is

driven by space considerations.

As the designer, it will be up to you to try to determine how to maximize both

feature inclusion and simplicity in a way that supports all of the user’s goals. Any-

one can design a complex interface—it takes real skill to design a simple one.

Designing nontraditional interfaces does not release you from the fundamental

design principles described here. By understanding what your users want, what they

need (which is often different from what they want), what they know, how they do

their work, and what their physical and cognitive limitations are, you, the designer,

can create superior interfaces that support the user in accomplishing his goal.

1.4

THE FUTURE OF NONTRADITIONAL

INTERFACE DESIGN

Undoubtedly, interface design in the future will move toward designs where the

right modality for the job is selected, rather than the modality at hand being forced

to fit the job. There’s an old expression that says that if all you have is a hammer,

then everything looks like a nail, and the same can be said of GUIs. The GUI

1 Introduction to the Human Factors of Nontraditional Interfaces

is a powerful and adaptable interface form, and designers who are trained in the

art and science of creating GUIs have tended to approach any given interface

implementation with a GUI solution. However, careful analysis of the needs of

the user in a given interface environment may suggest that another (nontradi-

tional) form of user interface is required. More likely than not, the interface will

be multimodal, as described in Chapters 11 and 12, and the goal of the designer will

be to ensure that the correct interface modes are assigned to the information

inputs and outputs that provide for the best, most effective experience for the user.

Much of this multimodal interface evolution is bound to move toward more

“natural” interaction techniques. In natural interactions, the user does not need

to make any translation of coded data or determine how to perform a function—

the user simply interacts with the interface as she would in the physical world.

Analogs (like the Windows desktop) will disappear, and the interface will become

indistinguishable from its representative model. Imagine if the Windows desktop

were replaced with an immersive virtual desktop that was indistinguishable from

the real-word analog in form and basic function but had all the benefits that can be

derived in a computer-driven model.

This vision is most certainly

not

a reversion to the much maligned virtual-

world interface proposed by Microsoft in the mid-1990s that was supposed to take

the desktop metaphor to the next level. Microsoft Bob (Figure 1.9) tried to repli-

cate the office and home environment through a rich metaphor that had all the

FIGURE

1.8

Complex interface for multiple features on the turn signal stalk in a

Chevrolet Suburban.

The stalk used to be reserved for a single function—activating the turn signal.

Now it supports the blinker, cruise control, variable front wipers, high-beam

headlights, rear wiper, and window washer system. The result is a system

that is hard to use and contributes to inadvertent activation of undesired

functions.

1.4 The Future of Nontraditional Interface Design

objects that one would expect in these environments. However, the metaphor was

not quite perfect, since there are many things that can (and should) be done on a

computer that just do not fit into the physical metaphor. The implementations of

these nonconforming functions (not the least of which was the talking dog that

was needed to help novice users get their bearings) caused users to have difficulty

in learning and using the interface. This complexity, along with a plethora of

hidden functions, led the interface to an early demise despite its promise as a

research platform into high-performance metaphorical interfaces.

One of the most exciting developments in nontraditional interfaces is the

recent advances that are currently being made in brain–computer interfaces. This

class of interface completely bypasses the human musculoskeletal body as a

mechanism for input/output, and instead interfaces directly with the brain. The

interface that the user is trying to use interprets these raw brain waves and then

performs the appropriate action. These kinds of interfaces represent a very

FIGURE

1.9

Home page for Microsoft Bob.

MS Bob was an extension of the desktop metaphor that was supposed to be

extremely easy to learn and use. Unfortunately, it suffered from many

deficiencies, and Microsoft pulled it from production shortly after its release.

Source:

Mid-1990s screenshot of Microsoft’s Bob Operating System.

1 Introduction to the Human Factors of Nontraditional Interfaces

specialized, newly emerging interface domain, and so they are not addressed in a

separate chapter in this book (just wait for the second edition!), but they hold sig-

nificant promise for the future.

Much of the current brain–computer research is focused on using brain waves

to control screen cursor movements (Friedrich, 2004), although recent advances

have led to limited success in the operation of robotic arms (Donoghue et al.,

2007). Of course, as with many futuristic interfaces, Hollywood has been thinking

about this for some time—recall Clint Eastwood flying the super-secret Russian

plane in the 1980s thriller

Firefox

, in which the aircraft is controlled by the

thoughts of the pilot—but of course those thoughts must be in Russian “Gjvjubnt!

Z yt db;e d heccrbq!”—“Help! I can’t think in Russian!”.

Although the technology is nowhere near this level of sophistication, Tanaka

and his colleagues (Tanaka, Matsunaga, & Wang, 2005) have had tremendous

success with research in which patients could control the navigation of their

powered wheelchairs using brain interfaces, eliminating the need for joysticks

or other input devices. Direct brain interfaces may prove to be a boon for the

physically disabled, allowing them to control computers and other assistive

devices without physical movement.

Holographic interfaces are another technology that may become important in

future applications. One of the biggest problems with current GUIs is that they

demand physical space. If the physical space is restricted, as in a mobile phone

for instance, then the interface must conform to the reduced space. Holography

has the potential to overcome this limitation by using the air as the interface

medium. By using holography, no physical interface would be required. Simple

commercial holographic interfaces are just now becoming available, and research

into more complex holographic interfaces continues (e.g., Bettio et al., 2006;

Kurtenbach, Balakrishnan, & Fitzmaurice, 2007).

When mentioning holographic displays, the ones envisioned by George Lucas

and his team of special effects wizards immediately come to mind. He and his

associates showed us how future holographic interfaces might include games, per-

sonal communications devices, and battlefield tactical displays. Reality has been

less forthcoming—a holographic-like game was introduced in the early 1980s by

Cinematronics that had the illusion of being a projected holographic display

(it was an illusion based on, literally, mirrors). Dragon’s Lair was immensely pop-

ular at the time, but the limitations of the game and its display interface made

it the last commercially available game of its type since then. A more realistic

depiction of what the future might hold is shown in Figure 1.10.

Although not holographic, the new projected keyboards are similar in

concept—keyboards take up space, and so for small devices, a keyboard that could

appear out of thin air might be a useful interface mode (although speech might be

a viable alternative as well). Figure 1.11 shows one of these virtual keyboards

being projected on a flat surface.

1.4 The Future of Nontraditional Interface Design