Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf)
Page 70
530
Part III: Designing Interaction Details
The idea that an application doesn’t have the right — even the duty — to reject a user’s input is so heretical that many practitioners dismiss it summarily. Yet, we’d like to suggest that if you examine this assertion rationally and from a user’s point of view, it is not only possible, but quite reasonable.
Why we have so many error messages
The first computers were undersized, underpowered, and expensive, and didn’t lend themselves easily to software sensitivity. The operators of these machines were white-lab-coated scientists who were sympathetic to the needs of the CPU and weren’t offended when handed an error message. They knew how hard the computer was working. They didn’t mind getting a core dump, a bomb, an “Abort, Retry, Fail?” or the infamous “FU” message (File Unavailable). This is how the tradition of software treating people like machines began. Ever since the early days of computing, programmers have accepted that the proper way for software to interact with humans was to demand input and to complain when the human failed to achieve the same perfection level as the CPU.
Examples of this approach exist wherever software demands that users do things its way instead of the software adapting to the needs of humans. Nowhere is it more prevalent, though, than in the omnipresence of error messages.
What’s wrong with error messages
Error messages stop the proceedings with a modal dialog box. Many designers and programmers imagine that their error message boxes are alerting users to serious problems. This is a widespread misconception. Most error message boxes are informing users of the inability of the program to work flexibly and are an admission of real stupidity on the application’s part. In other words, to most users, error message boxes are seen not just as the program stopping the proceedings but as stopping the proceedings with idiocy. We can significantly improve the quality of our interfaces by eliminating error message boxes.
Error message boxes stop the proceedings with idiocy and should
DESIGN
principle
be avoided.
31_084113 ch25.qxp 4/3/07 6:11 PM Page 531
Chapter 25: Errors, Alerts, and Confirmations
531
People hate error messages
Humans have emotions and feelings: Computers don’t. When one chunk of code rejects the input of another, the sending code doesn’t care; it doesn’t scowl, get hurt, or seek counseling. Humans, on the other hand, get angry when they are flatly told they are stupid.
When a user sees an error message box, it is as if another person has told her that she is stupid. Users hate this (see Figure 25-1). Despite the inevitable user reaction, most programmers just shrug their shoulders and put error message boxes in anyway. They don’t know how else to create reliable software.
Figure 25-1 No matter how nicely your error messages are phrased, this is how they will be interpreted.
Many programmers and user-interface designers labor under the misconception that people need to be told when they are wrong. This assumption is false in several ways. First of all, it ignores human nature. Very few people wish to hear from a machine that they’re wrong. You may call it denial, but it is true, and users will blame the messenger before they blame themselves.
The assumption that users need to know when they are wrong is similarly false.
How important is it for you to know that you requested an invalid type size? Most programs can make a reasonable substitution.
We consider it very impolite to tell people when they have committed some social faux pas. Telling someone they have a bit of lettuce sticking to their teeth or that their fly is open is equally embarrassing for both parties. Sensitive people look for ways to bring the problem to the attention of the victim without letting others notice. Yet programmers assume that a big, bold box in the middle of the screen that stops all the action and emits a bold “beep” is the appropriate way to behave.
Whose mistake is it, anyway?
Conventional wisdom says that error messages tell users when they have made a mistake. Actually, most error bulletins report when the computer gets confused.
Users make far fewer substantive mistakes than imagined. Typical “errors” consist
31_084113 ch25.qxp 4/3/07 6:11 PM Page 532
532
Part III: Designing Interaction Details
of a user inadvertently entering an out-of-bounds number, or entering a space where the computer doesn’t allow it. When a user enters something unintelligible by the computer’s standards, whose fault is it? Is it a user’s fault for not knowing how to use the program properly, or is it the fault of the program for not making the choices and effects clearer?
Information that is entered in an unfamiliar sequence is usually considered an error by software, but people don’t have this difficulty with unfamiliar sequences.
Humans know how to wait, to bide their time until the story is complete. Software usually jumps to the erroneous conclusion that out-of-sequence input means wrong input, so it issues an evil error message box.
When, for example, a user creates an invoice for a customer without an ID number, most applications reject the entry. They stop the proceedings with the idiocy that the user must enter a valid customer number right now. Alternatively, the application could accept the transaction with the expectation that a customer number will eventually be entered, or that a user may even be trying to create a new customer.
The program could provide a little modeless feedback that the number isn’t recognized, then watch to make sure the user enters the necessary information to make that customer number valid before the end of the session, or even the end of the month book closing. This is the way most humans work. They don’t usually enter
“bad” codes. Rather, they enter codes in a sequence that the software isn’t prepared to accept.
If a person forgets to fully explain things to the computer, the computer can, after some reasonable delay, provide more insistent signals to the user. At day’s or week’s end, the program can make sure that irreconcilable transactions are apparent to the user. The application doesn’t have to bring the proceedings to a halt with an error message. After all, the application will remember the transactions, so they can be tracked down and fixed. This is the way it worked in manual systems, so why can’t computerized systems do at least this much? Why stop the entire process just because something is missing? As long as users remain well informed throughout, there shouldn’t be a problem. The trick is to inform without stopping the proceedings. We’ll discuss this idea more later in the chapter.
If the application were a human assistant and it staged a sit-down strike in the middle of the Accounting Department because we handed it an incomplete form, we’d be pretty upset. If we were the bosses, we’d consider finding a replacement for this uptight, petty, sanctimonious clerk. Just take the form, we’d say, and figure out the missing information. The authors have used Rolodex programs that demand you enter an area code with a phone number even though the person’s address has already been entered. It doesn’t take a lot of intelligence to make a reasonable guess
31_084113 ch25.qxp 4/3/07 6:11 PM Page 533
Chapter 25: Errors, Alerts, and Confirmations
533
at the area code. If you enter a new name with an address in Menlo Park, the program can reliably assume that the area code is 650 by looking at the other 25
people in your database who also live in Menlo Park and have 650 as their area code. Sure, if you enter a new address for, say, Boise, Idaho, the program might be stumped. But how tough is it to access a directory on the Web, or even keep a list of the 1,000 biggest cities in America along with their area codes?
Programmers may now protest: “The program might be wrong. It can’t be sure.
Some cities have more than one area code. It can’t make that assumption without approval of the user!” Not so.
If we asked an assistant to enter a clien
t’s phone contact information into our Rolodex, and neglected to mention the area code, he would accept it anyway, expecting that the area code would arrive before its absence was critical. Alternatively, he could look the address up in a directory. Let’s say that the client is in Los Angeles so the directory is ambiguous: The area code could be either 213 or 310. If our human assistant rushed into the office in a panic shouting “Stop what you’re doing! This client’s area code is ambiguous!” we’d be sorely tempted to fire him and hire somebody with a greater-than-room-temperature IQ. Why should software be any different? A human might write 213/310? into the area code field in this case.
The next time we call that client, we’ll have to determine which area code is correct, but in the meantime, life can go on.
Again, squeals of protest: “But the area code field is only big enough for three digits! I can’t fit 213/310? into it!” Gee, that’s too bad. You mean that rendering the user interface of your program in terms of the underlying implementation model — a rigidly fixed field width — forces you to reject natural human behavior in favor of obnoxious, computer-like inflexibility supplemented with demeaning error messages? Not to put too fine a point on this, but error message boxes come from a failure of applications to behave reasonably, not from any failure of users.
Error messages don’t work
There is a final irony to error messages: They don’t prevent users from making errors.
We imagine that users are staying out of trouble because our trusty error messages keep them straight, but this is a delusion. What error messages really do is prevent the program from getting into trouble. In most software, the error messages stand like sentries where the program is most sensitive, not where users are most vulnerable, setting into concrete the idea that the program is more important than users.
Users get into plenty of trouble with our software, regardless of the quantity or quality of the error messages in it. All an error message can do is keep me from entering letters in a numeric field — it does nothing to protect me from entering the wrong numbers — which is a much more difficult design task.
31_084113 ch25.qxp 4/3/07 6:11 PM Page 534
534
Part III: Designing Interaction Details
Eliminating error messages
We can’t eliminate error messages by simply discarding the code that shows the actual error message dialog box and letting the program crash if a problem arises.
Instead, we need to redesign applications so that they are no longer susceptible to the problem. We must replace the error message with more robust software that prevents error conditions from arising, rather than having the program merely complain when things aren’t going precisely the way it wants. Like vaccinating it against a disease, we make the program immune to the problem, and then we can toss the message that reports it. To eliminate the error message, we must first reduce the possibility of users making errors. Instead of assuming error messages are normal, we need to think of them as abnormal solutions to rare problems — as surgery instead of aspirin. We need to treat them as an idiom of last resort.
Every good programmer knows that if module A hands invalid data to module B, module B should clearly and immediately reject the input with a suitable error indicator. Not doing this would be a great failure in the design of the interface between the modules. But human users are not modules of code. Not only should software not reject the input with an error message, but the software designer must also reevaluate the entire concept of what “invalid data” is. When it comes from a human, the software must assume that the input is correct, simply because the human is more important than the code. Instead of software rejecting input, it must work harder to understand and reconcile confusing input. A program may understand the state of things inside the computer, but only a user understands the state of things in the real world. Remember, the real world is more relevant and important than what the computer thinks.
Making errors impossible
Making it impossible for users to make errors is the best way to eliminate error messages. By using bounded widgets (such as spinners and drop-down list boxes) for data entry, we can prevent users from entering bad numbers. Instead of forcing a user to key in his selection, present him with a list of possible selections from which to choose. Instead of making a user type in a state code, for example, let him choose from a list of valid state codes or even from a picture of a map. In other words, make it impossible for the user to enter a bad state.
DESIGN
Make errors impossible.
principle
31_084113 ch25.qxp 4/3/07 6:11 PM Page 535
Chapter 25: Errors, Alerts, and Confirmations
535
Another excellent way to eliminate error messages is to make the application smart enough that it no longer needs to make unnecessary demands. Many error messages say things like “Invalid input. User must type xxxx.” Why can’t the program, if it knows what the user must type, just enter xxxx by itself and save the user the tongue-lashing? Instead of demanding that a user find a file on a disk, introducing the chance that the user will select the wrong file, the program should remember which files it has accessed in the past and allow a selection from that list. Another example is designing a system that gets the date from the internal clock instead of asking for input from users.
Undoubtedly, all these solutions will cause more work for programmers. However, it is the programmer’s job to satisfy users and not vice versa. If the programmer thinks of the user as just another input device, it is easy to forget the proper peck-ing order in the world of software design.
Users of computers aren’t sympathetic to the difficulties faced by programmers.
They don’t see the technical rationale behind an error message box. All they see is the unwillingness of the program to deal with things in a human way. They see all error messages as some variant of the one shown in Figure 25-2.
Figure 25-2 This is how most users perceive error message dialog boxes. They see them as Kafkaesque interrogations with each successive choice leading to a yet blacker pit of retribution and regret.
One of the problems with error messages is that they are usually ex post facto reports of failure. They say, “Bad things just happened, and all you can do is acknowledge the catastrophe.” Such reports are not helpful. And these dialog boxes always come with an OK button, requiring the user to be an accessory to the crime.
These error message boxes are reminiscent of the scene in old war movies where an ill-fated soldier steps on a landmine while advancing across the rice paddy. He and his buddies clearly hear the click of the mine’s triggering mechanism and the realization comes over the soldier that although he’s safe now, as soon as he removes his foot from the mine, it will explode, taking some large and useful part of his body with it. Users get this feeling when they see most error message boxes, and they wish they were thousands of miles away, back in the real world.
31_084113 ch25.qxp 4/3/07 6:12 PM Page 536
536
Part III: Designing Interaction Details
Positive feedback
One of the reasons why software is so hard to learn is that it so rarely gives positive feedback. People learn better from positive feedback than they do from negative feedback. People want to use their software correctly and effectively, and they are motivated to learn how to make the software work for them. They don’t need to be slapped on the wrist when they fail. They do need to be rewarded, or at least acknowledged, when they succeed. They will feel better about themselves if they get approval, and that good feeling will be reflected back to the product.
Advocates of negative feedback can cite numerous examples of its effectiveness in guiding people’s behavior. This evidence is true, but almost universally, the context of effective punitive feedback is getting people to refrain from doing things they want to do but shouldn’t: things like not driving over 55 mph, not cheating on their spouses, and not fudging their income t
axes. But when it comes to helping people do what they want to do, positive feedback is best. If you’ve ever learned to ski, you know that a ski instructor who yells at you isn’t helping the situation.
DESIGN
Users get humiliated when software tells them they failed.
principle
Keep in mind that we are talking about the drawbacks of negative feedback from a computer. Negative feedback by another person, although unpleasant, can be justified in certain circumstances. One can say that a coach is helping your mental toughness for competition, and the imperious professor is at least preparing you for the vicissitudes of the real world. But to be given negative feedback by a machine is an insult. The drill sergeant and professor are at least human and have bona fide experience and merit. But to be told by software that you have failed is humiliating and degrading. There is nothing that takes place inside a computer that will be helped by humiliating or degrading a human user. We only resort to negative feedback out of habit.
Aren’t there exceptions?
As our technological powers grow, the portability and flexibility of our computer hardware grows, too. Modern computers can be connected to and disconnected from networks and peripherals without having to first power down. This means that it is now normal for hardware to appear and disappear ad hoc. Printers, modems, and file servers can come and go like the tides. With the development of wireless networks such as WiFi and Bluetooth, our computers can frequently connect and disconnect from networks. Is it an error if you move between two wireless
31_084113 ch25.qxp 4/3/07 6:12 PM Page 537
Chapter 25: Errors, Alerts, and Confirmations
537
networks? Is it an error if you print a document, only to find that no printers are connected? Is it an error if the file you are editing normally resides on a drive that is no longer reachable?
None of these occurrences should be considered as errors. If you open a file on the server and begin editing it, then wander out to a restaurant for lunch, taking your notebook with you, the program should see that the normal home of the file is no longer available and do something intelligent. It could use a wireless network and VPN to log on to the server remotely, or it could just save any changes you make locally, synchronizing with the version on the server when you return to the office from lunch. In any case, it is normal behavior, not an error, and you shouldn’t have to tell the computer what it should do every single time it encounters the situation.