Man is an over-complicated organism. If he is doomed to extinction he will die out for want of simplicity. ?span>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 (see Section 3-6). 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,[8] 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. [8] I usually suggest that if the word compatibility is eliminated from this phrase, its true meaning becomes apparent.
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 Appendix B; Alzofon and Raskin 1985, p. 95). 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, discussed in more detail in Section 3-6, 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, Moran, and Newell 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. |
