Since humans are more pliable than computers, it can be easier to make a human fit the computer's limitations than to design the computer to fit the human's needs. When that happens, the human becomes a prisoner trapped by the computer rather than liberated by it. ?span>Karla Jennings Modes are a significant source of errors, confusion, unnecessary restrictions, and complexity in interfaces. Many of the problems modes cause have been widely recognized; nonetheless, making systems truly mode less is an underused tactic in interface design. Before we can discuss methods for eliminating modes, we must understand them in detail, especially because even interface professionals have disagreed about what constitutes a mode (Johnson and Englebeck 1989). To understand modes, we must first define a gesture. A gesture is a sequence of human actions completed automatically once set in motion. For example, typing a common word, such as the, is a single gesture for an experienced typist, whereas the typing of each letter would be a separate gesture for a beginning typist. Combining a sequence of actions into a gesture related to the psychological process is called chunking: the combining of separate items of cognition into a single mental unit, a process that allows us to deal with many items as though they were one (Buxton 1986, pp. 475?80; Miller 1956). Most interfaces have multiple interpretations of a given gesture. For example, at one moment, tapping Return inserts a return character into the text, whereas at another time, tapping Return causes the text typed immediately prior to that tap to be executed as a command. Modes are manifested by how an interface responds to gestures. For any given gesture, the interface is in a particular mode if the interpretation of that gesture is constant. When that gesture has a different interpretation, the interface is in a different mode. This definition gives us a useful initial view of what constitutes a mode; we will refine the definition later. A flashlight that is operated via a push-button toggle can be either on or off, assuming that it is in good operating condition. Pressing the button turns the light on if the present state is off, and turns the light off if the present state is on. The two states of the flashlight correspond to two modes in the interface: In one mode, tapping the button turns the light on; in the other mode, tapping the button turns the light off. If you do not know the present state of the flashlight, you cannot predict what a press of the flashlight's button will do. If your flashlight is deep in a duffel bag where you cannot see it, you cannot check by feel whether the light is off or on, assuming that it does not get detectably warm; if your intent is to make sure that it is off, you will have to take it out. Your inability to determine the state of the flashlight is a classic problem caused by an interface that has modes; you cannot tell by inspecting the controlling mechanism what operation you need to perform to accomplish your goal. If you operate the controlling mechanism without separately verifying the state of the system, you cannot predict the effect that the operation will have. Toggles are difficult to label. For example, in an interface I was shown, an on-screen button was labeled Lock. When users first encountered the button, they understood that they had to click on it to lock the data in that window. When they did so, the button's label changed to Unlock, to indicate that operating that button would unlock the data. Later, most of the users wondered why the data was unlocked, a conclusion they came to because the button said Unlock. As often happens when toggles are used on buttons or in menus, users read the label as an indicator of state. And they are justifiably confused: The button said Lock when the data was unlocked and Unlock when the data was locked. Obviously, you cannot solve the problem by interchanging the labels and having the button say Unlock when the data is unlocked and Lock when it is locked. What can help is to use a check box rather than a button and to use the word Locked rather than Lock on it. This is usually understood correctly: When the box is checked, the data is locked. When the box is not checked, the data is not locked. The labels do not change. You can make more complete labels, such as "Click this button to unlock the data" or even "The data is currently locked; click this button to unlock the data." But it is difficult to put full explanations on a button, alongside a check box, or in a menu, unless a zooming interface is available, as discussed in Section 6-2. Check boxes can leave the user guessing what the alternative is. For example, if a check box labeled "Save to archive on closing" is checked, the data will be saved to an archive when the window is closed, but the label gives little clue as to what will happen if the box is not checked. Will the data be saved somewhere else, not saved at all, or will another option appear when you close the window? Often, the best solution is to use a set of radio buttons (Figure 3.1); they are not modal, and the user can clearly see not only the current state but also the alternative(s). Whether check boxes or radio buttons are used, it is important to label them with adjectives, which describe the state of the object affected, rather than verbs, which describe an action, in which case the user does not know whether the action has taken place or is yet to take place. Figure 3.1. A pair of radio buttons labeled with adjectives. The option chosen has the dot in the circle; the left image reflects the locked state and the right image the unlocked state. Confusion is unlikely, and the user is aware of the available options. 
For one-of-many choices, radio buttons are already the standard, and there is rarely reason to use other mechanisms. Use radio buttons rather than toggles; toggles work reliably only when the value of the state controlled by the toggle is your locus of attention and is visible, or is in short-term memory. Except when the state is the locus of attention and it is usually not toggles will at times cause users errors. The kinds of errors caused by toggles are usually transient, and recovery is easy, but this is no reason to overlook them in interface design. To work in interface design without attending to details at this level is like trying to play a violin concerto, only occasionally forgetting to play a sharp or a flat given in the key signature. The errors annoy by pulling the listener's attention away from the continuity of the music. Similarly, occasional little "gotchas" in an interface impede the user's work flow. Another troublesome aspect of modes one that causes computer users considerable exasperation is exemplified by the way that the Caps Lock key, found on most keyboards, functions. Often, your first indication that this key has become engaged accidentally is that you notice that the sentence you have typed is set in all uppercase letters, and only then do you also notice that the Caps Lock key's light is on, if it has such a light. "It is no accident that swearing is denoted by #&%!#$&," writes my colleague, Dr. James Winter; it is "what a typewriter used to do when you typed numbers when the Caps Lock was engaged" (personal communication 1998). Decades ago, Larry Clark observed that modes cause problems because they make habitual actions have unexpected effects (Clark 1979).[1] The most commonly prescribed remedy for mode errors is to indicate prominently to a user the state of the system. Dr. Donald Norman characterized mode errors as resulting from inadequate feedback, the feedback being provided by an indicator of system state (Norman 1983). The real culprit, however, is not inadequate feedback but that the provided indicator is not the user's locus of attention. [1] I am not sure for how long the term mode has been used in describing interfaces. An internal Xerox report on the Gypsy Typescript System boasted, "There are no 'modes' in Gypsy" (Tesler and Mott 1975). There were, in fact, modes in Gypsy, but some of the more problematical ones of contemporary word processors had been eliminated. The term mode was new enough in 1975 that the authors felt it necessary to put it in quotes.
An especially clear example of the failure of using an indicator to provide feedback of system state to the user occurs in the generally excellent interface to the computer-aided design (CAD) package Vellum (Ashlar 1995). To anybody who is designing a drawing package, I strongly recommend a study of Ashlar's Drafting Assistant; it represents an extraordinarily good interface, one that is more productive and pleasant than that of the better-known AutoCAD.[2] One of Vellum's time-saving functions is a tracer that can follow the inside or the outside of a geometrical figure, selecting the border as it travels. To enable the tracer, you click on a palette item that turns the standard cursor  into a distinct shape, the tracer cursor  After you finish tracing, you often forget to switch back to the standard cursor. As I click to select an object after I have executed a trace operation selecting by clicking being an action that I do so often that it long ago became automatic instead of succeeding in making the selection, I sit surprised as the tracer goes off on its rounds. I have been making this mistake for years, as have other users with whom I have spoken. Although I sometimes catch myself in time, I never will learn I never can learn to always catch that I am in tracer mode because clicking to make a selection is, for me, automatic. My locus of attention is the object I am selecting, not the cursor shape. Vellum's changing cursor shape is one example of many that confirm that feedback and indicators of system state are not sufficient to guarantee the elimination of mode errors, even if the indicators are physically colocated with your locus of attention. They may be in your high-resolution foveal field, and, in this case, you are even using the indicator as your cursor, yet because it is not your locus of attention, you are not aware of the message it is trying to convey. Essential topics for future research include quantifying the frequency of mode errors and understanding the conditions that affect the frequency with which these errors occur. [2] In fact, AutoCAD licensed this technology while this book was being written.
Expertise is no protection against modes; an expert has developed firm habits. Naiveté is also no protection. In the example of Vellum's cursors, the beginner has not yet established in his mind that it is necessary to change the cursor back after tracing. By the time a beginner has learned to do this step without having to think about it explicitly, he is an expert with respect to this feature and is subject to the habituation problem. If the current state of the interface is not the user's locus of attention and if an interface has modes, the user will sometimes make errors because his locus of attention is not the current mode. Here is another example: On some popular computers, many programs give you a new, clean form when you type Command 
The n stands for new. In the America Online electronic mail package, in contrast, you obtain a new, blank e-mail form by typing Command
I presume that m stands for mail. The error that is repeatedly made when a user wants to start a new electronic mail message is to use Command
The interface state that gives rise to a mode in this example consists of having a particular application active. The problem occurs when users employ the Command command habitually. A beginner would probably make this same error for a different reason; he would assume that operates identically across applications and thus would make the error from excusable ignorance. Norman (1983) lists three ways to minimize mode errors. Do not have modes. Make sure that the modes are distinctively marked. Make sure that the commands required by different modes are not the same, so that a command issued in the wrong mode will not lead to difficulty.
Of these three, only the first always prevents mode errors. As we have seen, the second works sporadically. The third does not decrease the number of errors, but it does reduce the penalty for erring. Extreme techniques will usually draw a user's attention to a mode indicator, but by their intrusive strength, they redirect the user's locus of attention to the current state of the system and not on what he is trying to accomplish a result that is as undesirable as the mode error that the indicators might prevent. Norman defined mode errors as mistakes that occur when a user misclassifies, or when the user makes an erroneous analysis of a situation (Norman 1981). The terms misclassifies and analysis hint at active, conscious participation on the part of the user and therefore apply while she is unfamiliar with a command but do not apply after her use of it has become automatic. 3-2-1 Definition of Modes If the definition of a mode is based exclusively on the design of the interface, as our definition has been up to now, all users would make the same errors, albeit with different frequencies. They do not. A given interface feature can be modal for one user and not modal for another. A more complete definition of modes must incorporate how the user views the interface: A human-machine interface is modal with respect to a given gesture when (1) the current state of the interface is not the user's locus of attention and (2) the interface will execute one among several different possible responses to the gesture, depending on the system's current state. An interface can be modal with respect to one gesture and not modal with respect to a second gesture. For an interface as a whole to be classified as not modal, it must not be modal for any gesture. A measure, Q, of how modal a particular interface is can be given by classifying each of the gestures in an interface as modal or not modal. Then, given the probability, p(Ni), that a particular nonmodal gesture, Ni, is used, measured for a given user or averaged over a population of users,  . Q ranges from 0, completely modal, to 1, completely nonmodal. Both parts of the definition of a modal gesture are necessary to decide whether, for example, the gesture of pressing the Backspace key is modal. In most computer interfaces, assuming you are in the process of entering text, the Backspace command erases the most recently typed character. If that character was an e, the key erases an e. If that character was an x, the key erases an x. That is, sometimes Backspace is an e eraser, and sometimes it is an x eraser. Considering only the second part of the definition, the use of Backspace is modal because what it erases depends on the character most recently typed; content is part of system state. However, when you realize that your locus of attention is the object that you are erasing, it is the first part of the definition that explains why the operation is not modal and why you do not make mode errors when you use the Backspace key to erase characters in text or any other kind of object that you can select and delete in the same way.[3] [3] On the Macintosh, the key is, more accurately, labeled Delete.
A command that sets whether the Backspace key operates as a forward or a reverse erase, on the other hand, does make the interface modal. The setting of erase direction, made earlier, is usually not your locus of attention when, subsequently, you use Backspace, so sometimes you will erase in the unexpected direction. Preventing (Aircraft) Crashes by Eliminating a Mode Due to simple interface design error, both remote-piloted vehicles (RPVs), as used by the military, and civilian radio-controlled model aircraft are occasionally destroyed. To understand the error and a method of solving it, you must first know something about how these devices work. To fly an RPV, the operator, who stays safely on the ground, moves a small joystick embedded in a control box (Figure 3.2). Typically, you push the stick to pitch down the nose of the RPV, pull on the stick to pitch the nose temporarily upward, and move the stick to the left or right to cause the RPV to roll to the left or right, respectively. Moving the stick causes a proportional motion of a device called a servo in the RPV. The servo is linked mechanically to a control surface, such as the elevator in the rear of the RPV, that controls pitch. Figure 3.2. A commercial RPV controller. Note the many controls scattered across the face and the top of the device. 
A servo has no standard direction of motion with respect to a stick motion, so it is convenient and conventional to have a switch, located on the controller, that allows the user to choose which direction of stick motion corresponds to which direction of servo motion. This clearly modal convention runs into conflict, as modes usually do, with a habituated reaction on the part of the user. Often, one controller is used with multiple different RPVs. Each may have different servo directions corresponding to the actions of the aircraft. When changing between different RPVs, the user must operate the switches that choose servo direction so that a given stick motion corresponds to the appropriate RPV action. It is nearly impossible to train a pilot to operate the control sticks in reverse fashion when a servo reversal is unexpected. For example, consider that the pilot about to perform a takeoff with the RPV is unaware that the switch that controls the direction of the roll is in the wrong position. Taking off is a critical maneuver that requires rapt attention. It is common for the RPV to spontaneously roll slightly to the left or the right just after leaving the ground, and the expert pilot will automatically apply a small opposite control input to compensate for the roll; the reaction is so fast that, with a good pilot, a nonpilot observer will not detect the incipient roll. With a reversed-direction control switch, the roll, of course, will get worse, because the servo is moving in the wrong direction. On seeing this, a well-trained pilot will apply a stronger compensating stick motion that, because of the servo reversal, exacerbates the roll, and the RPV will, at this point in the flight, usually be demolished as soon as the wingtip contacts the ground or the RPV rolls entirely on its back. (This entire sequence can take a fraction of a second.) I have never seen a pilot successfully figure out the problem and reverse reactions in time to complete the takeoff. This kind of crash has happened to me on two occasions, in spite of a well-trained ritual of checking that control surface motion is in the correct direction before each takeoff. Checking control direction, after its having been done dozens of times, also becomes a habit, to the point that you don't always verify that the directions in which the control surfaces move are correct. (If they don't move at all, that is sufficiently surprising to alert you to the presence of a problem.) During these checks, I have more often than not caught reversed servos on RPVs I was going to fly. However, when under pressure or with other things on my mind, I, like hundreds of other pilots, have missed the reversal. Interestingly, this error does not usually occur on a new aircraft's first flight, during which you are especially alert for potential problems. It is only after flying the particular craft has become "second nature," or habitual, that the problem strikes. This is an example of a mode that cannot be removed from the world. Modes are inherent in the nature of servos and control sticks. Yet the problem can be greatly ameliorated. The solution: Put the servo reversal switch in the aircraft, perhaps as part of the servos, and have no servo reversal switches on the controller. The interiors of RPVs are not normally accessible: The switches would be set during assembly of the RPV. Correct direction of operation would be checked by the assemblers, rechecked by inspectors, and checked again (usually) by the pilot prior to the first flight. This method does not eliminate the possibility of a crash, but once the first flight is completed, servo reversal on that RPV will not be a problem, no matter how many different RPVs the controller is used with in the interim. To the operator of the RPV, the mode is gone. Nearly all model aircraft controllers have servo reversal switches. Crashes due to having the controller in the wrong mode are not uncommon. Worse still is the "feature" of many controllers to have other modes set by long-handled paddle switches, easily knocked to the wrong position by accident. On the controller I designed for my own use, all such switches are of a design such that the switch levers have to be pulled away from the controller against spring tension before they can be moved (Figure 3.3) I have never had an accident due to a switch being unknowingly pushed to the wrong position. Sometimes, the solution to a mode problem is mechanical. Figure 3.3. These switches on an RPV controller cannot be operated accidentally; the handle must be pulled out before the switch can be operated. 
|
Modes also restrict your scope of activity. If a gesture g invokes action a in mode A and action b in mode B, you must, if you are in mode B and want to invoke action a, first leave mode B and reset the interface into mode A. Only then can you use the gesture g to invoke a. The division of an interface into bounded areas is a necessary consequence of modes; the set of states in which the gesture g has a particular interpretation can be called the range of g. Software sold as an application for example, a spreadsheet usually consists of one or more overlapping ranges. Certain ranges are relatively large. For example, the following sequence performs a cut in nearly all applications on both the Macintosh and Windows platforms: Command
Other ranges are tiny. The following sequence in a certain computer game opens a treasure chest only when the chest is visible: Command
Grouping commands into separate ranges, or what we usually call applications, can be an aid to understanding and using a complex interface, but there are ways to organize an interface that are less restrictive than are modes. A fully humane interface would consist of exactly one range. When an interface is controlled by another machine, you might think that modelessness is of no importance, because machines have no problem remembering state; they just model it internally with a state of their own. However, if an interface is modal and the program operating it does not initially know the current state of the interface for example, if it connects to the system after the system is already running the program, prior to operating any modal control, must be provided with a means for testing that state. Interface toggles are particularly troublesome in this regard, where consecutive invocations of the toggling mechanism cycle the control through a number of states before returning to the initial state (the cycle then repeats). This discussion of programs that operate interfaces is relevant to human-machine interface design because you might want to construct a set of stored commands that can be played back with a single gesture, a macro, which is a rudimentary form of computer program. A macro cannot set a toggle into a specific state unless the macro first interrogates the system to determine the system's current state. We saw this problem in the example of the flashlight in the duffel bag. One solution is to have any multiple-option switch always reset to a specified initial state immediately after it is operated. Then, counting the number of invocations of the switch always informs the operator of the switch's current state. More than about five states is excessive if the switching is to be done by a person. As mentioned earlier, another solution is to use radio buttons. We have not yet exhausted what harm modes do. Modes can put the computer, instead of the user, in charge of an interaction. This aspect is especially noticeable when you are forced to stop what you are doing to reply to a message box. Certain designers consider forcing the user to stop and to work in lockstep with a planned sequence to be an interface advantage, in that the system is "guiding" the user. There may be circumstances under which it is imperative that the user make a particular decision if there is no user decision, there is no need for a dialogue at all by a certain time or before doing another step in the sequence. In the first case, put up a count-down clock, but do not restrict the user from doing other operations with the system. In the second case, have a message stating that the decision must be made before the next step will be presented, but the system should not prevent the user from performing other operations that are not part of the programmed sequence. For example, what if the user needs to look up something in a file or do a calculation in order to answer the question? Guidance should be offered modelessly, so that the user remains in control of as much as possible of the system. 3-2-2 Modes, User-Preference Settings, and Temporary Modes Facilities for setting user preferences constitute an example of modes and are a major source of user frustration. Ironically, these features are usually touted as a user benefit. Present interfaces are often so difficult to use that a user may feel an urge to rearrange them. Microsoft (1995, p. 4) specifically recommends that such facilities be provided: "Users, because of their widely varying skills and preferences, must be able to personalize aspects of the interface...such as color, fonts, or other options." On the other hand, a user of Microsoft Word described the effect of setting a preference as being like dropping a time bomb into the word processor. She needed to build a list in a format different from the one she usually used, so she looked up how to make the changes and chose new settings. The next time she wanted to build a list, she used the familiar List command and, of course, unexpectedly obtained the one she had reset Word to give her rather than the one she was used to. It took her more than an hour to figure out what had happened and to fix it. (Her first impulse was to believe that there was something wrong with the program or in her use of the command, and she repeated the command many times before she remembered that she had reset the preferences.) Bob Fowles, of the Pennsylvania State University Computer Center, observed: People not aware of the complexity of Word can really get into trouble when they accidentally press Command, Option, or Control plus another key while they are typing rapidly. My wife got into a problem yesterday that took me quite a few minutes to figure out. Every time she pressed Return, she got a bullet. Looking at the Edit pull-down menu, I saw "undo Autoformat." After several minutes of searching and using Help, I found where Autoformat could be turned on or off and turned it off. Somehow, she had typed a keyboard shortcut that had turned it on. (personal communication 1998) This user was injured by a customization, a mode, an invisible keyboard shortcut, and excessive design complexity all at once. Customizations are software design changes that are not reflected in the documentation. For example, when I was using Word, I tried to turn off a feature that was unfamiliar to me. The Help facility instructed me simply to click a certain button on the standard toolbar; however, a previous user had modified this toolbar using a user-preference setting, so that the button was not there. It took me a long time to figure out how to make the program behave. More important, the incident pointed out another fundamental problem of having user preferences: How do you test for interface quality or even succeed at documenting a system whose configuration the designers and writers cannot know in advance? In my case, the previous user's mode change rendered the documentation wrong. Allowing the user to change the interface design often results in choices that are not optimal, because the user will, usually, not be a knowledgeable interface designer. Typically, a user will choose the method closest to one with which he is already familiar or a customization needed only temporarily. Some designers have argued that applications for high-level users should have many preference settings so that a user can tailor the system as much as possible. However, high-level users have no special claim to being good interface designers and, being habituated to their software, have an especially strong need for a stable system so that their habits will not be rendered useless by changes, even changes they themselves make. By providing preferences, we burden users with a task extraneous to their job function. A user of, say, a spreadsheet has to learn how to use not only the spreadsheet but also the customizing facilities. Time spent in learning and operating the personalization features is time mostly wasted from the task at hand. Managers complain about the time workers waste "playing with" the system preferences. Most users just want to get their jobs done and care not whether the numbers in the spreadsheet default to Palatino in purple, Garamond in green, or Bodoni Semibold Extended Italic in bellwether blue. Personalizing an interface in a shared environment is an invitation to disaster, as it means that the interface can change without notice. The right action yesterday say, clicking the red button is clicking the blue button today, because someone thought it looked better in blue. Your training and habits are undermined. Especially over the telephone or via e-mail, it is also more difficult to help the user of a system that has preferences. Customization sounds nice, democratic, open-ended, and full of freedom and joy for the user, but I am unaware of any studies that show that it increases productivity or improves objective measures of usability or learnability. Adding customization certainly makes a system more complex and more difficult to learn. I suspect that if you were to take a user survey, more people than not would be in favor of lots of personalizable features. But then, when GUIs were first coming in, a majority of users said that they'd never want to use one. It is also important to recognize that users will customize an interface in such a way that it appeals to their subjective judgment. As has been observed in a number of experiments, an interface that optimizes productivity is not necessarily an interface that optimizes subjective ratings. (For an example, see Tullis 1984, p. 137.) The central point of this issue is that if we are competent user interface designers and can make our interfaces nearly optimal, personalizations can only make the interface worse. Therefore, we must be sparing and deliberate in offering user customizations. If a user can, by a few judicious choices, really improve the interface, we probably have done a poor job. On the other hand, if a program's interface is as dismal to voice an opinion as that of Microsoft Word 97/98, the situation is reversed. Almost any change the user makes is an improvement, to exaggerate only slightly. However, Word's interface is not the kind of goal toward which we should be striving. Modes that vanish after a single use cause fewer errors than do those that persist, if for no other reason than that they have less time to cause havoc. In the Vellum cursor example, fewer user errors would result if the cursor, after performing its trace function, reverted in form and function to its normal state. If you use a temporary mode immediately after setting it, the fact that you set the mode may not have evaporated from your short-term memory, and you will not make a mode error; you may even incorporate setting the mode as part of the gesture that carries out the command, which makes the situation completely nonmodal for you. However, if you set the interface mode for a command, and, prior to using the command, are delayed or distracted, you are likely to make a mode error. To avoid a mode, the Canon Cat was designed without a power switch.[4] The reason was that products react to gestures differently, depending on whether they are on or off, and a power switch therefore introduces a mode. To save energy, the Cat went into a low-powered sleep state if it was not used for five minutes. To make sure that sleep was not a mode, any user action or incoming message turned on the Cat without perceptible delay; furthermore, the user action that turned it on was not lost but took effect just as if the machine had not been in the sleep state. [4] I was startled to find a power switch on the back of the Cat when the first units came back from Japan. I pointed out that the design specifications said that there was to be no power switch, and I had gone over the rationale for this repeatedly with the engineers. "We thought the specifications had an error," I was told.
In many systems, computers come out of sleep mode at the touch of a key, but the keystroke that turns them on and any keystrokes made subsequently but before the system is fully awake are lost. Not losing any keystrokes turned out to be an elegant feature. For example, if you had a sudden inspiration or had to take a note during a telephone call, you could just start typing without worrying about the state of the Cat or even looking at the display. It is a characteristic of modelessness that, once you become habituated, you do not have to think or plan before you act; your attention stays on the content of your work. (If you happened to put your note in the midst of something else, you'd just select the note and move it after you were done memorializing your inspiration or finishing your telephone call.) Occasionally, designers claim that modes are necessary because the number of desired software functions exceeds the number of gestures that a user can make with a keyboard and a graphical input device, making gesture reuse necessary. However, display-based commands, such as menus, and typed multiple-character commands, as in command line driven systems, offer an unlimited number of commands and thus avoid that difficulty. (How you make sure that the various commands in a command line system are visible, rather than having to be memorized, will be discussed later.) The bottom line on modes is this: If you design a modal interface, users will make mode errors except when the value of the state that is controlled by the mode is the user's locus of attention and is visible to the user or is in the user's short-term memory. The burden is on the designer to demonstrate that a mode is being used under the appropriate condition or that the advantages of a particular modal design outweigh its unavoidable disadvantages. It is always safe to avoid interface designs that have modes. Buttons that Change in the Night Some aircraft have pushbuttons that contain a dot-matrix display used to change the legend that appears on the button. This change is done under the aircraft's computer's control so that the buttons can be relabeled on the fly. The advertising copy for one brand of these buttons made some human factors claims. For one thing, fewer buttons would be needed in the limited cockpit area. For another, avionics and other system changes could be effected without having to rewire the cockpit. From the perspective of cognitive science, good labels enhance visibility. Assuming that the person choosing the labels bothers to test the wording, to make sure that the chosen labels are effective and unconfusing, it is, on the face of it, a good idea. But more careful thinking reveals a number of potential pitfalls to the product: All legended buttons get obscured by the very finger you are using just as you are about to press them, obviating a last-second check that you are pressing the right button. But this is a minor problem, for normally you have looked at the legend before you press the button if you have looked at all. (I am certainly not looking at the legends on the keycaps of my keyboard as I type this.) Then there is the deeper problem of the disappearing button. You want to enable, say, the manual controls on the cabin air conditioner. There is, you recall, a button labeled MANUAL AIR, but it is nowhere to be found. The reason is that it now says COMM BACKUP. You have to figure out how to get that button to light up the way it did before. Perhaps a switch or a button somewhere else changes the legends on the buttons. Or perhaps the legends are context-sensitive and won't allow you to change the air conditioning right now. Whatever the cause, when a button has variable legends, the button you want will perhaps have vanished because the system is in a different mode. But the gravest problem has to do with habituation. Imagine the experienced pilot reaching up and pressing a button. The radio's not working; something's wrong. A communications problem: Time to enable COMM BACKUP. She jabs out expertly at the COMM BACKUP button. Click! Too bad. The copilot was adjusting the cabin temperature in response to a passenger complaint, and the buttons are now in climate-control mode. The pilot has just achieved complete manual control over the air conditioning system. Variable-legend buttons could be useful, for instance, if several people use the same console, each using it in such a way that the buttons do not change meaning for any one user. But this is a situation seldom encountered. Soft keys, whereby a display has changable legends that affect on-screen buttons or buttons adjacent to the display, have the same liability as do variable-legend buttons. A similar problem exists with the use of function buttons, labeled F1 through F12 on many computers. If their functions are unchanging, the labeling is unmnemonic. If their functions change, you cannot use them automatically. In either case, they are a poor design. |
Are Fewer Buttons Better? A portable Fluke[5] oscilloscope I recently tested (Figure 3.4) is incredibly sturdy and capable. Its 35 buttons control a bounteous multitude of modes and functions. The device was difficult to learn and has proved impossible to operate quickly when trying to work with many of its features. Figure 3.4. Fluke scopemeter: powerful and rugged, zillions of functions, a paucity of keys, but difficult to learn and sometimes slow to get to the function you need. On the other hand, its color-coded leads eliminate a traditional source of confusion about which lead does what. 
A Tektronix oscilloscope (see Figure 3.5) with its myriad settings that seem so daunting at first glance, is easier both to teach and to use. The number of switches and knobs is about the same as on the digital scope, but many of the knobs have multiple settings that you can access immediately, and the settings are marked on the face of the product, so that they are visible rather than hidden in a menu that must be summoned to be seen. Fluke's product offers much greater functionality but at the cost of making some tasks that were previously easy more difficult. The rotating knobs are each far more powerful than each of the Fluke's buttons. Fluke also went further than necessary in creating submenus of excessive depth. Figure 3.5. The Tektronix oscilloscope has a myriad of settings, but although initially intimidating, it is quick and easy to operate. All knobs that can uncalibrate the unit are in red. 
Operation of the oscilloscopes parallels the relative ease of use of two radios I own. My truck radio (Figure 3.6) has 18 preset stations, arranged in three groups of six. One button cycles through the three groups, and a linear arrangement of six buttons chooses the station within each group. An LCD panel shows the group number (1 through 3). Seven buttons suffice to select among 24 stations. Figure 3.6. The radio in my truck is difficult enough to use as a radio, and I find it impossible to remember how to set the clock. 
My other radio is the electronically superb Sony 2010 (see Figure 3.7), which has 32 presets on 32 identical buttons in four rows of eight buttons each. At first sight, this radio looks more complex, but as interviews with owners and long personal use have proved to me, this design makes it easier to find a preset station, especially in the dark; just count down and over to the button you want and tap it. The Sony 2010 stores all parameters of the station, such as whether the station is AM, short-wave, FM, or aircraft band, and any other settings you have chosen. Tap one of the 32 buttons, and everything needed to play that station is set automatically and at once. I put the most frequently accessed stations near the upper-left corner of the array. Figure 3.7. The Sony 2010 short-wave radio has many buttons but a fast, readily learned operation. 
The truck radio sacrifices usability to obtaining a low button count and small panel size. The worst part of the design is that you are forced to take your eyes from the road to know which set of presets you are using, or you can be distracted fishing for the station you want. (If you are switching from AM to FM or vice versa, you must find and tap two buttons; with the Sony, it is always one tap to select any preset.) It is only slightly hyperbolic to suggest that it should be illegal to have a toggling, modal interface in a motor vehicle. Clearly, my truck radio has an unsatisfactory interface for selecting stations; even less satisfactory is its invisible method for setting the clock. I have to look it up every time: Press and hold the DISP button for 2 seconds; let it go. Turn the tuning knob counterclockwise to advance hours; turn it clockwise to advance minutes; press the DISP button to finish setting the clock. (The DISP button is the volume-control knob.) On the plus side, at least my radios have real volume-control knobs, unlike the pair of volume-control buttons on some more modern equipment. Volume-control buttons suffer from making it take too long to get to the desired loudness and from the fact that the current setting is neither visible to the eye nor accessible to the sense of touch. In a recent user survey that I conducted, every subject (n = 55) preferred a knob in this role. Fewer buttons and simpler-looking controls are not always better. The lesson applies to screen design as well as to instruments and appliances. |
[5] I am grateful to John Fluke Manufacturing Co. for providing the sample unit.
3-2-3 Modes and Quasimodes Using the Caps Lock key to type uppercase letters and holding the Shift key to the same effect are significantly different. The first case establishes a mode; the second case does not. A set of experiments at the University of Toronto confirmed that the act of holding down a key, pressing a foot pedal, and any other form of physically holding an interface in a certain state does not induce mode errors (Sellen, Kurtenbach, and Buxton 1992). Other studies revealed the neurophysiological roots of this phenomenon: Most of our nervous system operates such that a constant stimulus yields signals that, in time, decrease in their ability to capture our attention. This decrease continues until our cognitive system receives no signal at all. However, the signals that report back to us whether our muscles are actively producing a force do not fade. Activating and holding a control while performing another user action has been referred to as a spring-loaded mode and a spring-locked mode (Johnson and Engelbeck 1989). But this terminology is inappropriate because no physical spring may be involved, the key or button is not locked, and holding a control does not cause mode errors. The phrase user-maintained mode (Sellen, Kurtenbach, and Buxton 1992) for this action is accurate but makes it difficult to frame a corresponding adjective. I have come to use the term quasimode and its adjectival form, quasimodal, to denote modes that are maintained kinesthetically. (See Figure 3.8.) Figure 3.8. The hunchback of Notre Dame. 
Quasimodes are very effective in eliminating modes (Raskin 1989); however, excessive use of quasimodes can lead to absurd interface conventions that require the user to remember dozens of commands, such as Control . The limit for the number of effective quasimodes is probably between four and seven. But one quasimode can solve a multitude of varied problems (see Section 5-4). A typical problem that is readily solved by the use of quasimodes occurs when an interface presents you with a set of choices, such as the Macintosh's pull-down menus. In this application of quasimodes, you press and hold down the graphical input device button when, on the name of the menu, the other choices appear for as long as you are holding down the button. You move the cursor to the desired item and release on that item to make your menu choice. Another use of quasimodes is to cycle through a set of options. So long as the cycle starts on the same element in the set and proceeds in the same order, and so long as there are not too many elements, a fixed number of taps chooses the option. For example, in the design of the Canon Cat, the user could change a selection to any of four paragraph styles: left-aligned, centered, right-aligned, and justified. Paragraph styles were chosen by repeatedly tapping the key that had on its front the legend ¶ STYLE
To access a key with a front legend on the Cat, you held down a special Shift key that was marked on its top Use Front (Figure 3.9). In general, the Use Front key allowed you to execute the function indicated by the legend on the front of a key. Because paragraph style was a quasimode (you had to hold down Use Front while tapping the Paragraph Style key), the Cat knew how many times you had tapped it. As a consequence, you soon learned that one tap left-aligned the selection, two taps right-aligned the selection, and so forth. Had the software cycled from wherever you left off, as many interfaces do, there would have been no way of making your use of the paragraph style command habitual; you always would have had to look at the display to know what was happening. Note that a paragraph style button that did not require holding down Use Front would not have worked as well; it was the establishment of the quasimode, when you pressed the Use Front key, that allowed the system to know when to start counting. Figure 3.9. Canon Cat's Use Front key and some of the command keys. The words USE FRONT are light blue, as are the legends on the fronts of the keys that are enabled by the Use Front key. 
A habituating feature is often one that can be operated successfully by a blind user. Following the principles in this book will often result in interface methods that can be used by the blind. We are all blind in a very real sense to the world outside of our locus of attention. Some menus or palettes take the most-used or the most recently used item and position it at the top of the menu or in the palette: a simple example of an adaptive menu or an adaptive palette. A menu or a palette is made adaptive on the assumption that having the favored item available, without having to pull it down, will speed your use of the system. It is useful to compare two approaches: The first approach is to remove the chosen item from the list that has been pulled out and place that item in the main palette or menu; the second approach is to duplicate the chosen item into the main palette or menu (Figure 3.10). Figure 3.10. Ashlar pull-out palette. Note the duplication of the first icon on the pulled-out group, so that the pullouts are always in the same order; their use can, therefore, become automatic. 
It might seem that the first strategy is better. For one thing, there is one less choice in the list that has been pulled out. It also takes less screen space. But you also have to stop and check whether the tool you want is in the main palette or in the pulldown, especially if it has been more than a few seconds since you last used the tool. But it is the second alternative, whereby you can adopt the simple strategy of always using the nth pulldown for a desired task, that is usually faster. It is certainly easier from a cognitive standpoint. If you remember that a certain option is now in the main menu, you save having to pull down the complete list. But if you don't remember, you can use the pulldown as you always do. Vellum (Ashlar 1995) is an example of a product interface with adaptive palettes done correctly (Figure 3.10). In Vellum, the palette is adaptive, and each tool can also be found in its accustomed place. However, an experienced user might ignore the adaptive feature, going automatically to the accustomed tool position. An additional aspect of providing multiple ways of invoking a feature will be discussed in Section 3-5. It has been suggested that interfaces should adapt to accommodate the user's emotional state, and some products, such as Microsoft's Bob, attempt to tailor the interface to the personality of the user. It is not clear how an interface can adapt to the user in these ways without upsetting habituation. But even if we can, someday, reliably detect a user's emotional needs and use that information to improve the performance of an interface without interfering with our learned and automatic responses, our interfaces must still first satisfy the user's unchanging cognetic needs. The principles outlined in this book will still apply and will probably need to be applied prior to any adjustment for emotional needs. Fundamentally, there are only two kinds of inputs you make to your computer or information appliance: creating content or controlling the system. The rule of thumb adopted here is this: Quasimodes are reserved for control functions. Operations you perform when no quasimode is engaged create content. It is this way rather than the other way around because it is more difficult to operate a system while a quasimode-establishing button is being held, and it is hoped that users will spend more time creating and working with content than in using commands. |
