acm - an acm publication

Articles

The humane interface (book excerpt)

Ubiquity, Volume 2000 Issue May, May 1 - May 31 2000 | BY Jef Raskin 

|

Full citation in the ACM Digital Library



On a clear disk you can seek forever. -- Source unknown

Whether a product is a handheld two-way radio or a computer's desktop, it is not always clear what functions are available, what they do, or how they are accessed. You should be able to use your senses to easily discover both what abilities are available and how they are to be operated.

An interface feature is visible if it either is currently accessible to a human sense organ -- usually the eyes, although this discussion applies also to other sensory modalities -- or was so recently perceived that it has not yet faded from short-term memory. If a feature is not visible, we say that it is invisible. For an interface to work well, as Donald A. Norman states in his classic book The Psychology of Everyday Things (New York: Basic Books, 1988) "[j]ust the right things have to be visible: to indicate what parts operate and how, to indicate how the user is to interact with the device. Visibility indicates the mapping between intended actions and actual operations." If an interface forces you to memorize the fact that a feature exists, that feature is invisible. If you are forced to root around in the interface until, by luck and perseverance, you reach a sequence of actions that activates a feature, such a feature is not visible. If you have to use a help system to discover how to perform an operation, the methods for invoking that operation are invisible. Many computer games are, essentially, undocumented interfaces in which the controls, or their mapping to desired effects, are invisible. Add documentation and these games become trivial. Most people do not want to play games when they are trying to get work done. It is up to the designer of an interface to make every feature of a product visible.

In designing to accommodate visibility, each function and the method of operating it would be apparent -- to most people in the culture for which it is intended -- by merely looking at it. A control that has this attribute has come to be called an affordance (Norman 1998, p. 123). "Affordances provide strong clues to the operations of things. . . . Knobs are for turning. Slots are for inserting things into. Balls are for throwing or bouncing" (Norman 1988, p. 9). If you, as a designer, put a knob such as is used in volume controls on a product, people will attempt to turn that knob. Put on something that looks like a pushbutton, and people will push it. Whether a feature is or is not an affordance depends on the experience and the background of the people who will be using the product and the context in which the feature appears.

In analyzing interfaces, we should always ask how the user knows that an action is possible, and we should always require that each visible feature provide a recognizable affordance. Icons are often considered the epitome of visible affordances, but they do not always serve this function.

Visibility is more than just detectable existence. An object may be visible in the sense that it is there, but it might be too small to be noticed, or it may have too little contrast to be readily distinguished from the background. Optimizing the perceptual qualities of an interface is an important ergonomic consideration, but the concern here is with the cognitive properties of interfaces.

Affordance Avoidance: BART

It is the interface to its ticket machines that brings Bay Area Rapid Transit (BART) into this book. The machines at a local station are the result of the transit authority's ignorance of 25 years of experience with the old ticket-dispensing robots. As I stand in line at one of the two machines not presently out of service, I watch person after person baffled by the machine's layout. Although experienced with the machines myself, I still fumble at the unnatural sequence of operations that they require. The obvious way to start the interaction, and what nearly everybody whom I've observed tries at first, is to put in money or an old ticket, which is a money-equivalent. That's how vending machines work: Put in money, make choice, get stuff. It is a cultural paradigm.

The BART ticket-vending machines must have been designed on another planet. First, you choose between BART and BART-MUNI buttons. (A pamphlet, available nowhere in the vicinity, explains the subtle difference.) These buttons are at the top of the wall of the machine face: a reasonable place to start but an unreasonable transaction with which to start. The slots into which you then put your ticket (to the left), coins (in the middle), or bills (lower right) are widely separated instead of being clustered. The LCD display is up high at top center, where short people cannot easily read it; in any case, it is far enough from the rest of the interface that many people do not notice it at all. Maybe it's good they do not see it, in that its response time is so slow that people who do watch it either repeat their actions in hope of forcing a response or stand there wondering whether the machine is broken, which it often is. Then there's the "correction" button, labeled as though it is to be used in case you've made a mistake that has to be corrected. In fact, you do not use this button for correcting a mistake: You use it if you want the ticket to be issued for less than the total amount of money that you have put in. That is, it simply tells the machine you want some change back.

Another indication that the new machines are badly designed is the bright, colorful, large numbers "1, 2, 3, 4" and the big arrows presumably placed to guide you. If the front of the machine were well laid out, you wouldn't need crutches. The numbers do not help tremendously anyway, because you must remember what step you are executing (say, step 2) while you put in your money ($5), knowing that you only want to get a $3 ticket so you must hit the correction button in the next step (step 3), keeping in mind that you'll want to count your change ($2) that will come in the form of quarters (eight of them). Hurry! You can hear the 7:06 train coming! What step did you say you were on? When you find a computer interface that requires bright colors and myriad explanatory legends to guide you, you can guess that the design has gone astray.

Here is one way in which the BART machines could work. Remember, however, that were you consulting to BART, you would request user testing of your proposed design to verify that people will use it as you have predicted. On the left -- because English and Spanish are written from left to right -- is the slot for old tickets, a horizontal slot for bills, and a small vertical slot for coins, grouped together and well labeled. The display -- located at average eye level -- reads: "Put in money OR your old BART ticket OR both." As you put in each, the total value accrued appears immediately in the LCD display with this message:

You now have put in $4.55.

If you want a ticket for more than $4.55, put in more money or another old ticket

If you want a ticket for less than $4.55 press: Change Ticket Amount

If you want a ticket for $4.55, press one of these buttons:

Issue BART Ticket

Issue MUNI-BART Ticket

If the user selects "Change Ticket Amount," he is asked to type in the amount for which he wants the ticket issued and to press the large ENTER button that is under the numeric key pad. The user is returned to the display that shows the current total and asks him to increase it, decrease it, or OK it. When the ticket is issued, any change due the user is returned. For the experienced traveler with the right amount of money in hand, this interface reduces six actions to these two: put in money and then press an Issue-Ticket button.

Monotony

Man is an over-complicated organism. If he is doomed to extinction he will die out for want of simplicity.
-- Ezra Pound

Designers of interfaces often present users with a choice of methods. For example, both a menu item and a keyboard shortcut may execute the same command. In most word processors, you can move a contiguous portion of the text by either (1) the three steps of selecting, cutting, and pasting or (2) the two steps of selecting and dragging. Also, the selection process itself can be invoked in more than one way. The user has a smorgasbord of methods.

One justification for having multiple methods to do a given task is that some users prefer one method and other users prefer a different method. For example, a novice user might find menus easier to learn, although an expert user might rather keep her hands on the keyboard and issue commands by typing them. Another justification is that one method -- for example, selecting, cutting, and pasting -- is useful between distant portions of a document, and the other method -- selecting and dragging -- is effective only when the source and destination are both visible on the display. Another reason for a plurality of methods is that each of them is sanctioned by custom, and the developers felt it wise to accommodate as many previously developed skills as possible.

This last reason, called backward compatibility (if the word compatibility is eliminated from this phrase, its true meaning becomes apparent), is the weakest and can lead to absurd interfaces that are an accumulation of incompatible methods. When I was grounded and waiting for the weather to improve during a long flight by commercial jet, I went to the cockpit, where I studied an autopilot that had no fewer than five ways of entering coordinates and similar numbers of methods for performing most of its other functions. When I asked the pilot for the rationale, she said that it had been built to functionally resemble, as closely as possible, autopilots from other aircraft that pilots might have trained on and thus avoid the need for expensive retraining. The question was whether the tactic was successful and whether the old units had been duplicated exactly. As she explained, the pilots not only had to learn the small but annoying differences between their old system and the emulation of their old system on the new autopilot but also were required to learn the four other ways of using the autopilot. A pilot must be familiar with every aspect of every piece of equipment in the cockpit; besides, many of the newer features of the autopilot were available in only some of the emulations; those of the earlier autopilots did not have those features because the autopilots being copied had not had them.

The tactic of portmanteau interface design, or just toss every method you can think of into the bag, increased training time, produced a harder-to-use autopilot, and, as the pilot noted, increased cockpit confusion and opportunities for errors. She did not say so, but it also probably increased the cost and complexity of the product, the manuals, and the cost of maintenance. The same is true for any interface that is a conglomeration of disparate design philosophies, accumulated over time; this includes the Macintosh and Windows.

I use the term monotonous, tongue partially in cheek, to describe an interface having only one way to accomplish a task (See Alzofon, David and Jef Raskin. Swyftcard, 2d ed. (Menlo park, CA: Information Appliance, 1985). Monotony is the dual of modelessness in an interface. In a modeless interface, a given user gesture has one and only one result: Gesture g always results in action a. However, there is nothing to prevent a second gesture, h, from also resulting in action a. A monotonous interface is one in which any desired result has only one means by which it may be invoked: Action a is invoked by gesture g and in no other way. An interface that is completely modeless and monotonous has a one-to-one correspondence between cause (commands) and effect (actions). The more monotony an interface has for a given task space, the easier it is for the user to develop automaticity, which, after all, is fostered by not having to make decisions about what method to use.

Another cause of nonmonotonous design is managerial indecision. Given two or more choices of interface methods and no rational method of choosing one above the others, I have seen the problem "solved" by expediently putting in all of the proposed methods. This is rationalized as giving the user a choice, as if the user were an interface expert and will make the most productive choice.

A common myth is that beginners and expert users of a system require radically different interfaces. Designers speak in terms of "the tradeoffs between ease of learning and speed of execution in a system" (Card, Stuart K., Thomas P. Moran, and Allen Newell. The Psychology of Human-Computer Interaction (Hillsdale, NJ: Lawrence Erlbaum Associates, 1983, p. 419). This may be true of particular interface designs, but I have seen no demonstration that it is necessarily a property of all interface designs; in particular, it is not a property of the kinds of designs discussed in this book. Present desktop GUIs are a compound of at least two distinct interfaces, a relatively visible and learnable but time-consuming menu-based system and an incomplete keyboard-based collection of hard-to-learn and unmemorable shortcuts. Two wrongs do not make a right.

When you have to choose among methods, your locus of attention is drawn from the task and temporarily becomes the decision itself. This is a primary reason for choosing to design a monotonous system. If the conditions for making the decision are sufficiently clear and distinct, the path you take in each case can become habitual, and you have monotonized the situation. It still behooves the designer to seek an efficient monotonous solution to gain benefits, including ease of learning, simplicity of implementation, minimization of documentation, and lowered maintenance costs. These benefits are either free to the implementers or can be had for the relatively small one-time cost of careful design and testing. Monotony does not mean that the same content cannot be arrived at in many ways but that there should not be multiple gestures to invoke the same command.

Monotony happens spontaneously. Many users monotonize the interfaces they use by choosing one method and sticking to it, ignoring alternatives whatever the situation. Computer gurus who pride themselves on knowing every wrinkle of a system often decry such users as amateurs; nonetheless, the "amateurs" may be using the interface more efficiently than the gurus do. From the point of view of an implementer, such users are wasting features; from the point of view of the users, it is the implementers who are wasting resources.

I believe that an interface that is both modeless and, insofar as possible, monotonous -- all other design features being of at least normal quality for a modern interface -- would be extraordinarily pleasant to use. A user would be able to develop an unusually high degree of trust in his habits. The interface would, from these two properties alone, tend to fade from the user's consciousness, allowing him to give his full attention to the task at hand. The psychological effects of totally (or near totally) modeless and monotonous systems is an area of interface design ripe for experimental study.

If I am correct, the use of a product based on modelessness and monotony would soon become so habitual as to be nearly addictive, leading to a user population devoted to and loyal to the product. Its users would find moving to a competitor's product psychologically difficult. Unlike selling illicit drugs, marketing an addictive interface is legal, and the product is beneficial to its users; in another way, it is just like selling illicit drugs: extremely profitable.

Myth of the Beginner-Expert Dichotomy

We're humans first, beginners or experts second.
-- Clifford Nass, CBC "Quirks and Quarks" radio program, 23 January 1994

Psychologist Clifford Nass's point is similar to one that this book makes: Our interface designs must begin by accommodating universal human frailties and exploiting universal human strengths. We must make sure that every detail of an interface matches both our cognitive capabilities and the demands of the task (not that those two objectives exhaust our concerns). His comment also reflects the common assumption that users can be grouped into two classes: beginners and experts, perhaps with a few temporarily in transition. This dichotomy is invalid. As a user of a complex system, you are neither a beginner nor an expert, and you cannot be placed on a single continuum between these two poles. You independently know or do not know each feature or each related set of features that work similarly to one another. You may know how to use many commands and features of a software package; you may even work with the package professionally, and people may seek your advice on using it. Yet you may not know how to use or even know about the existence of certain other commands or even whole categories of commands in that same package. For example, a user of a photo-processing application who produces only online images may never need, or even learn of, that same application's facility for doing color separations, a feature needed primarily by commercial printers.

Interface designers have tried various approaches to accommodate the premise that users can be separated into beginners and experts. Because this premise is false, the approaches have failed. Adaptive systems that shift automatically from beginner mode to expert mode when they judge that your competence has reached a certain level are a good example. If you are using such a system in beginner mode and it suddenly shifts into expert mode, you will find yourself on unfamiliar ground, at least with regard to a portion of the system. A system that shifts piecemeal, feature by feature, is no better. It will feel unstable and unsettling, because the habits that you were developing as a novice yesterday become useless when the feature shifts into expert mode today.

One web-based program I studied promoted you to expert status after you had used it once successfully. The program put you back into beginner mode when you had not used it for six months. Any such arbitrary schedule may not accord with a user's personal rate of learning and memory decay. If a program that promoted you switches to beginner mode after too short a time, you will feel annoyed at being forced to use the tedious beginner method. If the program does not switch back to beginner mode in time, you will be faced with features that you have forgotten how to use. Given present technology, a system cannot know when you have forgotten how to use a given feature, so it cannot know when it should shift back to beginner mode. A program that quizzed you from time to time to assess your level of expertise would be obnoxious.

Most attempts to make interfaces adaptive are ill-advised; whenever a system changes automatically, even if the change is as small as, say, a reordered set of items on a menu, your expectations are upset and your habituation is frustrated. (Microsoft features adaptive menus in its Windows 2000 operating system. Windows 2000 was a new product as this section was being written, and I was able to interview only a few users. A typical remark was, "Adaptive menus seemed like a cool idea, but the first time a menu changed on me, I found it upsetting. I don't like the idea any more.") On the other hand, there is no theory that tells us that the same fixed interface cannot work well over the full span of a person's experience with it, from novice to old timer. It seems best not to have to shift paradigms during your use of a product, and no elaborate analysis is needed to reveal the advantage in having to learn only one interface to a task.

It is easy to fall into the trap of designing different interfaces for different classes of users, because by doing so, you can make sweeping assumptions that simplify the design process. Few such assumptions are likely to be true of every user in any reasonably large class of users that you specify. The antidote is to view an interface not from the perspective of a class of users but rather through the eyes of an individual. Every person who uses software over a long period goes through a relatively brief period of learning for each feature or command and a far longer period of routine (and, we hope, automatic) use. We do need to design systems that are easy to learn and understand, but it is more important that we make sure that these systems can be efficiently used in the long run. The exceptions are applications that will be used only briefly, so that every user is a novice, and habituation is not an issue. One example of such an interface is that for a computer-driven kiosk at an exhibition. The learning phase of working with a feature involves your conscious attention. Therefore, simplicity, clarity of function, and visibility are of great importance. The expert phase is predominantly characterized by unconscious use of the feature; such use is enhanced by such qualities as aptness to the task, modelessness, and monotony. These sets of requirements are not in conflict; therefore, a well-designed and humane interface does not have to be split into beginner and expert subsystems. This is not to say that an interface must not be split on these lines. However, if you find yourself designing an interface and are tempted to provide "expert" shortcuts, consider whether you should instead redesign the existing method so that it satisfies the needs of all users with one mechanism.


********

Reprinted with permission from The Humane Interface (C) 2000, Addison-Wesley, an ACM Press book. All rights reserved. For more information see: http://cseng.aw.com/bookpage.taf?ISBN=0-201-37937-6.

COMMENTS

POST A COMMENT
Leave this field empty