Microsoft’s printing solution is a reasonable rule of thumb. Put immediate access to functions on buttons in the toolbar and put access to function-configuration dialog boxes on menu items. The configuration dialogs are better pedagogic tools, whereas the buttons provide immediate action.
DESIGN
Provide choices, don’t ask questions.
principle
Asking questions is quite different from providing choices. The difference between them is the same as that between browsing in a store and conducting a job interview. The individual asking the questions is understood to be in a position superior to the individual being asked. Those with authority ask questions; subordinates respond. Asking users questions makes them feel irritated or inferior.
Dialog boxes (confirmation dialogs in particular) ask questions. Toolbars offer choices. The confirmation dialog stops the proceedings, demands an answer, and it won’t leave until it gets what it wants. Toolbars, on the other hand, are always there, quietly and politely offering up their wares like a well-appointed store, giving you the luxury of selecting what you would like with just a flick of your finger.
15_084113 ch10.qxp 4/3/07 6:05 PM Page 218
218
Part II: Designing Behavior and Form
Contrary to what many software developers think, questions and choices don’t necessarily make users feel empowered. More commonly, they make people feel badgered and harassed. Would you like soup or salad? Salad. Would you like cabbage or spinach? Spinach. Would you like French, Thousand Island, or Italian? French.
Would you like lo-cal or regular? Stop! Just bring me the soup! Would you like chow-der or chicken noodle?
Users don’t like to be asked questions. It cues a user that the application is:
Ignorant
Forgetful
Weak
Lacking initiative
Unable to fend for itself
Fretful
Overly demanding
These are qualities that we typically dislike in people. Why should we desire them in software? The application is not asking us our opinion out of intellectual curios-ity or desire to make conversation, the way a friend might over dinner. Rather, it is behaving ignorantly or presenting itself with false authority. The application isn’t interested in our opinions; it requires information — often information it didn’t really need to ask us in the first place (for more discussion on how to avoid questions, see Chapter 12).
Worse than a single question is a question that is asked repeatedly and unnecessarily. Many ATMs continually ask users what language they prefer: “Spanish, English, or Chinese?” This is not an answer that is likely to change after a person’s first use.
Interactive products that ask fewer questions appear smarter to users, and more polite and considerate.
In The Media Equation (Cambridge University Press, 1996), Stanford sociologists Clifford Nass and Byron Reeves make a compelling case that humans treat and respond to computers and other interactive products as if they were people. We should thus pay real attention to the “personality” projected by our software. Is it quietly competent and helpful, or does it whine, nag, badger, and make excuses?
We’ll discuss more about how to make software more polite and considerate in Chapter 12.
Choices are important, but there is a difference between being free to make choices based on presented information and being interrogated by the application in
15_084113 ch10.qxp 4/3/07 6:05 PM Page 219
Chapter 10: Orchestration and Flow
219
modal fashion. Users would much rather direct their software the way they direct their automobiles down the street. Automobiles offer drivers sophisticated choices without once issuing a dialog box. Imagine the situation in Figure 10-7.
Figure 10-7 Imagine if you had to steer your car by clicking buttons on a dialog box! This will give you some idea of how normal people feel about the dialog boxes on your software. Humbling, isn’t it?
Directly manipulating a steering wheel is not only a more appropriate idiom for communicating with your car, but it also puts you in the superior position, directing your car where it should go. No one likes to be questioned like a suspect in a lineup, yet that is exactly what our software often does.
DESIGN
Hide the ejector seat levers.
principle
In the cockpit of every jet fighter is a brightly painted lever that, when pulled, fires a small rocket engine underneath the pilot’s seat, blowing the pilot, still in his seat, out of the aircraft to parachute safely to earth. Ejector seat levers can only be used once, and their consequences are significant and irreversible.
Just as a jet fighter needs an ejector seat lever, complex desktop applications need configuration facilities. The vagaries of business and the demands placed on the software force it to adapt to specific situations, and it had better be able to do so.
Companies that pay millions of dollars for custom software or site licenses for thousands of copies of shrink-wrapped products will not take kindly to a program’s inability to adapt to the way things are done in that particular company. The application must adapt, but such adaptation can be considered a one-time procedure, or something done only by the corporate IT staff on rare occasion. In other words, ejector seat levers may need to be used, but they won’t be used very often.
Applications must have ejector seat levers so that users can — occasionally — move persistent objects (see Chapter 11) in the interface, or dramatically (sometimes irreversibly) alter the function or behavior of the application. The one thing that must never happen is accidental deployment of the ejector seat (see Figure 10-8). The interface design must assure that a user can never inadvertently fire the ejector seat when all he wants to do is make some minor adjustment to the program.
15_084113 ch10.qxp 4/3/07 6:05 PM Page 220
220
Part II: Designing Behavior and Form
Windshield
FM
Ejector
Cabin
Washer
Radio
Seat
Lights
Figure 10-8 Ejector seat levers have catastrophic results. One minute, the pilot is safely ensconced in her jet, and the next she is tumbling end over end in the wild blue yonder, while her jet goes on without her. The ejector seat is necessary for the pilot’s safety, but a lot of design work has gone into ensuring that it never gets fired inadvertently. Allowing an unsuspecting user to configure an application by changing permanent objects is comparable to firing the ejection seat by accident. Hide those ejector seat levers!
Ejector seat levers come in two basic varieties: those that cause a significant visual dislocation (large changes in the layout of tools and work areas) in the program and those that perform some irreversible action. Both of these functions should be hidden from inexperienced users. Of the two, the latter variety is by far the more dangerous. In the former, a user may be surprised and dismayed at what happens next, but she can at least back out of it with some work. In the latter case, she and her colleagues are likely to be stuck with the consequences.
By keeping in mind principles of flow and orchestration, your software can keep users engaged at maximum productivity for extended periods of time. Productive users are happy users, and customers with productive, happy users are the goal of any digital product manufacturer. In the next chapter, we further discuss ways to enhance user productivity by eliminating unnecessary barriers to use that arise as a result of implementation-model thinking.
DESIGN
Optimize for responsiveness; accommodate latency.
principle
An application can become slow or unresponsive when it performs a large amount of data processing or when it talks to remote devices like servers, printers, and networks. There isn’t much that is more disturbing to a user’s sense of flow than staring at a screen waiting for the computer to respond. It’s absolutely critical to design your inte
rfaces so that they are sufficiently responsive — all the lush visual style in
15_084113 ch10.qxp 4/3/07 6:05 PM Page 221
Chapter 10: Orchestration and Flow
221
the world isn’t going to impress anyone if the interface moves like molasses because the device is maxed out redrawing the screen.
This is one arena where collaboration with developers is quite important. Depending on the platform and technical environment, different interactions can be quite
“expensive” from a latency perspective. You should both advocate for implementation choices that provide the user with appropriately rich interactions with as little latency as possible, and design solutions to accommodate choices that have been made and cannot be revisited. When latency is unavoidable, it’s important to clearly communicate the situation to users and provide them the ability to cancel the operation causing the latency and ideally perform other work while they are waiting.
If your application executes potentially time-consuming tasks, make sure that it occasionally checks to see if a person is still out there, banging away on the keyboard or madly clicking on the mouse, whimpering “No, no, I didn’t mean to reorganize the entire database. That will take 4.3 million years!”
In a number of studies dating back to the late 1960s, it’s generally been found that users’ perception of response times can be roughly categorized into several buckets.1
Up to 0.1 seconds, users perceive the system’s response to be instantaneous.
Here, they feel that they are directly manipulating the user interface and data.
Up to about 1 second, users feel that the system is responsive. Users will likely notice a delay, but it is small enough for their thought processes to stay uninterrupted.
Up to about 10 seconds, users clearly notice that the system is slow, and their mind is likely to wander, but they are capable of maintaining some amount of attention on the application. Providing a progress bar is critical here.
After about 10 seconds, you will lose your users’ attention. They will wander off and get a cup of coffee or switch to a different application. Ideally, processes that take this long should be conducted offline or in the background, allowing users to continue with other work. In any case, status and progress should be clearly communicated, including estimated time remaining, and a cancel mechanism is absolutely critical.
In summary, creating a successful product requires more than delivering useful functionality. You must also consider how different functional elements are orchestrated to enable users to achieve a sense of flow as they go about their business. The best user interfaces often don’t leave users in awe of their beauty, but rather are hardly even noticed because they can be used effortlessly.
Notes
1. Miller, 1968
15_084113 ch10.qxp 4/3/07 6:05 PM Page 222
16_084113 ch11.qxp 4/3/07 6:05 PM Page 223
11
Eliminating Excise
Software too often contains interactions that are top-heavy, requiring extra work for users. Programmers typically focus so intently on the enabling technology that they don’t carefully consider the human actions required to operate the technology from a goal-directed point of view. The result is software that charges its users a tax, or excise, of cognitive and physical effort every time it is used.
When we decide to drive to the office, we must open the garage door, get in the car, start the motor, back out, and close the garage door before we even begin the forward motion that will take us to our destination. All these actions support the automobile rather than getting to the destination. If we had Star Trek transporters instead, we’d dial up our destination coordinates and appear there instantaneously — no garages, no motors, no traffic lights. Our point is not to complain about the intricacies of driving, but rather to distinguish between two types of actions we take to accomplish our daily tasks.
Any large task, such as driving to the office, involves many smaller tasks. Some of these tasks work directly towards achieving the goal; these are tasks like steering down the road towards your office. Excise tasks, on the other hand, don’t contribute directly to reaching the goal, but are necessary to accomplishing it just the same. Such tasks include opening and closing the garage door, starting the engine, and stopping at traffic lights, in addition to putting oil and gas in the car and performing periodic maintenance.
16_084113 ch11.qxp 4/3/07 6:05 PM Page 224
224
Part II: Designing Behavior and Form
Excise is the extra work that satisfies either the needs of our tools or those of outside agents as we try to achieve our objectives. The distinction is sometimes hard to see because we get so used to the excise being part of our tasks. Most of us drive so frequently that differentiating between the act of opening the garage door and the act of driving towards the destination is difficult. Manipulating the garage door is something we do for the car, not for us, and it doesn’t move us towards our destination the way the accelerator pedal and steering wheel do. Stopping at red lights is something imposed on us by our society that, again, doesn’t help us achieve our true goal. (In this case, it does help us achieve a related goal of arriving safely at our offices.)
Software, too, has a pretty clear dividing line between goal-directed tasks and excise tasks. Like automobiles, some software excise tasks are trivial and performing them is no great hardship. On the other hand, some software excise tasks are as obnoxious as fixing a flat tire. Installation leaps to mind here, as do such excise tasks as configuring networks and backing up our files.
The problem with excise tasks is that the effort we expend in doing them doesn’t go directly towards accomplishing our goals. Where we can eliminate the need for excise tasks, we make people more effective and productive and improve the usability of a product, ultimately creating a better user experience. As an interaction designer, you should become sensitive to the presence of excise and take steps to eradicate it with the same enthusiasm a doctor would apply to curing an infection.
The existence of excise in user interfaces is a primary cause of user dissatisfaction with software-enabled products. It behooves every designer and product manager to be on the lookout for interaction excise in all its forms and to take the time and energy to see that it is excised from their products.
DESIGN
Eliminate excise wherever possible.
principle
GUI Excise
One of the main criticisms leveled at graphical user interfaces by computer users who are accustomed to command-line systems is that users must expend extra effort manipulating windows and menus to accomplish something. With a command line, users can just type in a command and the computer executes it immediately. With windowing systems, they must open various folders to find the desired file or application before they can launch it. Then, after it appears on the screen, they must stretch and drag the window until it is in the desired location and configuration.
16_084113 ch11.qxp 4/3/07 6:05 PM Page 225
Chapter 11: Eliminating Excise
225
These complaints are well founded. Extra window manipulation tasks like these are, indeed, excise. They don’t move a user towards his goal; they are overhead that the applications demand before they deign to assist that person. But everybody knows that GUIs are easier to use than command-line systems. Who is right?
The confusion arises because the real issues are hidden. The command-line interface forces an even more expensive excise budget on users: They must first memorize the commands. Also, a user cannot easily configure his screen to his own personal requirements. The excise of the command-line interface becomes smaller only after a user has invested significant time and effort in learning it.
On the other hand, for a casual or first-time user, the visual explicitness of the GUI helps him navigate and learn what tasks are appropriate and when. The step-by-step nature of the GUI is a great help to users who aren’t yet familiar with
the task or the system. It also benefits those users who have more than one task to perform and who must use more than one application at a time.
Excise and expert users
Any user willing to learn a command-line interface automatically qualifies as a power user. And any power user of a command-line interface will quickly become a power user of any other type of interface, GUI included. These users will easily learn each nuance of the applications they use. They will start up each application with a clear idea of exactly what they want to do and how they want to do it. To this user, the assistance offered to the casual or first-time user is just in the way.
We must be careful when we eliminate excise. We must not remove it just to suit power users. Similarly, however, we must not force power users to pay the full price for our providing help to new or infrequent users.
Training wheels
One of the areas where software designers can inadvertently introduce significant amounts of excise is in support for first-time or casual users. It is easy to justify adding facilities to a product that will make it easy for newer users to learn how to use it. Unfortunately, these facilities quickly become excise as users become familiar with the product — perpetual intermediates, as discussed in Chapter 3. Facilities added to software for the purpose of training beginners, such as step-by-step wizards, must be easily turned off. Training wheels are rarely needed for extended periods of time, and although they are a boon to beginners, they are a hindrance to advanced users when they are left on permanently.
16_084113 ch11.qxp 4/3/07 6:05 PM Page 226
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 32