Almost all error message boxes can be eliminated. If you examine the situation from the point of view that the error message box must be eliminated and that everything else is subject to change in search of this objective, you will see the truth of this assertion. You will also be surprised by how little else needs to be changed in order to achieve it. In those rare cases where the rest of the program must be altered too much, that is the time to compromise with the real world and go ahead and use an error message box. But programmers need to start thinking of this compromise as an admission of failure on their part, as a solution of last resort.
All this said, there are certainly some time-critical situations where users must be notified in an obtrusive, attention-demanding manner. For example, if during market hours, an investment manager sets up some trades to be executed by the end of the day, and then sends them down to the trading desk after market close, she should be interrupted from whatever else she’s working on to be warned that the trades can’t be executed until the market opens tomorrow, at which point she may no longer want to make the trades.
Improving error messages: The last resort
In the case that it is truly infeasible to redesign your application to eliminate the need for error dialogs, we offer you some ways to improve the quality of error message boxes. Use these recommendations only as a last resort, when you run out of other reasonable options for actually eliminating the error dialog.
An error dialog should always be polite, illuminating, and helpful. Never forget that an error dialog is the application’s way of reporting on its failure to do its job, and that it is interrupting the user to do this. The error message box must be unfailingly polite. It must never even hint that the user caused this problem, because that is simply not true from the user’s perspective.
31_084113 ch25.qxp 4/3/07 6:12 PM Page 538
538
Part III: Designing Interaction Details
The error message box must illuminate the problem for the user. This means that it must give him the information he needs to make an appropriate plan to solve the program’s problem. It needs to make clear the scope of the problem, what the alternatives are, what the program will do as a default, and what information was lost, if any.
It is wrong, however, for the program to just dump the problem on a user’s lap and wipe its hands of the matter. It should directly offer to implement at least one suggested solution right there on the error message box. It should offer buttons that will take care of the problem in various ways. If a printer is missing, the message box should offer options for deferring the printout or selecting another printer. If the database is hopelessly trashed and useless, it should offer to rebuild it to a working state, including telling the user how long that process will take and what side effects it will cause.
Figure 25-3 shows an example of a reasonable error message. Notice that it is polite, illuminating, and helpful. It doesn’t even hint that the user’s behavior is anything but impeccable.
Figure 25-3 In the case that you must use an error dialog, it should look something like this. It politely and clearly illuminates the problem and proposes a good solution. The action buttons and resulting effects are also clearly described.
31_084113 ch25.qxp 4/3/07 6:12 PM Page 539
Chapter 25: Errors, Alerts, and Confirmations
539
Alert Dialogs: Announcing
the Obvious
Like error dialogs, alerts and confirmations stop the proceedings, often with idiocy.
Alerts and confirmations do not report malfunctions. An alert notifies a user of the program’s action, whereas a confirmation also gives a user the authority to override that action. These dialogs pop up like weeds in most programs and should, like error dialogs, be eliminated in favor of more useful idioms.
Alerts usually violate one of our basic design principles: A dialog box is another room; you should have a good reason to go there (see Chapter 20). Even if a user must be informed about an action taken by the application, why go into another room to do it?
When it comes down to it, an application should either have the courage of its convictions or it should not take action without a user’s direct instruction. If the application, for example, saves a user’s file to disk automatically, it should have the confidence to know that it is doing the right thing. It should provide a means for users to find out what the application did, but it doesn’t have to stop the proceedings to do so. If the application really isn’t sure that it should save the file, it shouldn’t save the file but should leave that operation up to the user.
Conversely, if a user directs the program to do something — dragging a file to the trash can, for example — it doesn’t need to stop the proceedings with idiocy to announce that the user just dragged a file to the trashcan. The program should ensure that there is adequate visual feedback regarding the action, and if the user has actually made the gesture in error, the program should unobtrusively offer him a robust Undo facility so he can backtrack.
The rationale for alerts is to keep users informed. This is a great objective, but it need not come at the expense of smooth interaction flow.
The alert shown in Figure 25-4 is an example of how alerts are more trouble than help. The Find dialog (the one underneath) already forces a user to click Cancel when the search is completed, but the superimposed alert box adds another flow-breaking button. To return to his work, a user must first click the OK button on the alert, then the Cancel button on the Find dialog. If the information provided by the alert were built into the main Find dialog, the user’s burden would be reduced by half.
31_084113 ch25.qxp 4/3/07 6:12 PM Page 540
540
Part III: Designing Interaction Details
Figure 25-4 A typical alert dialog box. It is unnecessary, inappropriate, and stops the proceedings with idiocy. Word has finished searching the document. Should reporting that fact be a different facility than the search mechanism itself? If not, why does it use a different dialog?
Alerts are so numerous because they are so easy to create. Most programming languages offer some form of message box facility in a single line of code. Conversely, building an animated status display into the face of a program might require a thousand or more lines of code. Programmers cannot be expected to make the right choice in this situation. They have a conflict of interest, so designers must be sure to specify precisely where information is reported on the surface of an application. The designers must then follow up to be sure that the design wasn’t compromised for the sake of rapid coding. Imagine if the contractor on a building site decided unilaterally not to add a bathroom because it was just too much trouble to deal with the plumbing. There would be consequences.
Of course, software must keep users informed of its actions. It should have visual indicators built into its main screens to make such status information immediately available to users, should they desire it. Launching an alert to announce an unrequested action is bad enough. Putting up an alert to announce a requested action is pathological.
Software should be flexible and forgiving, but it doesn’t need to be fawning and obsequious. The dialog box shown in Figure 25-5 is a classic example of an alert that should be put out of our misery. It announces that the application successfully completed a synchronization — its sole reason for existence. This occurs a few seconds after we told it to synchronize. It stops the proceedings to announce the obvious. It’s as though the application wants approval for how hard it worked. If a person interacted with us like this, we’d find it uncomfortable and him overbearing. Of course some feedback is appropriate, but is another dialog that must be dismissed really necessary?
31_084113 ch25.qxp 4/3/07 6:12 PM Page 541
Chapter 25: Errors, Alerts, and Confirmations
541
Figure 25-5 This dialog, from AirSet Desktop Sync, is unnecessarily obsequious.
We tell it to synchronize and are promptly stopped in our tracks by th
is important message. Do we really need the program to waste our time demanding recognition that it managed to do its job?
Confirmation Dialog
When an application does not feel confident about its actions, it often asks a user for approval with a dialog box, like the one shown in Figure 25-6. This is called a confirmation. Sometimes a confirmation is offered because the application second-guesses one of the user’s actions. Sometimes the program feels that is not competent to make a decision it faces and uses a confirmation to give the user the choice instead. Confirmations always come from the program and never from the user.
This means that they are often a reflection of the implementation model and are not representative of user goals.
Figure 25-6 Every time we delete a file in Windows, we get this confirmation dialog box asking if we’re sure. Yes, we’re sure. We’re always sure. And if we’re wrong, we expect Windows to be able to recover the file for us. Windows lives up to that expectation with its Recycle Bin. So, why does it still issue the confirmation message? When a confirmation box is issued routinely, users get used to approving it routinely. So, when it eventually reports an impending disaster to the user, he goes ahead and approves it anyway, because it is routine. Do your users a favor and never create another confirmation dialog box.
31_084113 ch25.qxp 4/3/07 6:12 PM Page 542
542
Part III: Designing Interaction Details
Revealing the implementation model to users is a surefire way to create an unpleasant and inferior product. This means that confirmation messages are inappropriate. Confirmations get written into software when a programmer arrives at an impasse in her coding. Typically, she realizes that she is about to direct the program to take some bold action and feels unsure about taking responsibility for it. Sometimes the bold action is based on some condition the program detects, but more often it is based on a command the user issues. Typically, the confirmation will be launched after the user issues a command that is either irrecoverable or whose results might cause undue alarm.
Confirmations pass the buck to users. Users trust the application to do its job, and the application should both do it and ensure that it does it right. The proper solution is to make the action easily reversible and provide enough modeless feedback so that users are not taken off-guard.
As a program’s code grows during development, programmers detect numerous situations where they don’t feel that they can resolve issues adequately. Programmers will unilaterally insert buck-passing code in these places, almost without noticing it. This tendency needs to be closely watched, because programmers have been known to insert dialog boxes into the code even after the user-interface specification has been agreed upon. Programmers often don’t consider confirmation dialogs to be part of the user interface, but they are.
The dialog that cried “Wolf!”
Confirmations illustrate an interesting quirk of human behavior: They only work when they are unexpected. That doesn’t sound remarkable until you examine it in context. If confirmations are offered in routine places, users quickly become inured to them and routinely dismiss them without a glance. Dismissing confirmations thus becomes as routine as issuing them. If, at some point, a truly unexpected and dangerous situation arises — one that should be brought to a user’s attention — he will, by rote, dismiss the confirmation, exactly because it has become routine. Like the fable of the boy who cried “Wolf,” when there is finally real danger, the confirmation box won’t work because it cried too many times when there was no danger.
For confirmation dialog boxes to work, they must only appear when a user will almost definitely click the No or Cancel button, and they should never appear when a user is likely to click the Yes or OK button. Seen from this perspective, they look rather pointless, don’t they?
31_084113 ch25.qxp 4/3/07 6:12 PM Page 543
Chapter 25: Errors, Alerts, and Confirmations
543
Eliminating confirmations
Three design principles provide a way to eliminate confirmation dialog boxes. The best way is to obey the simple dictum: Do, don’t ask. When you design your software, go ahead and give it the force of its convictions (backed up, of course, by user research, as discussed in Chapter 4). Users will respect its brevity and its confidence.
DESIGN
Do, don’t ask.
principle
Of course, if an application confidently does something that a user doesn’t like, it must have the capability to reverse the operation. Every aspect of the program’s action must be undoable. Instead of asking in advance with a confirmation dialog box, on those rare occasions when the program’s actions were out of turn, let the user issue the Stop-and-Undo command.
Most situations that we currently consider unprotectable by Undo can actually be protected fairly well. Deleting or overwriting a file is a good example. The file can be moved to a directory where it is kept for a month or so before it is physically deleted. The Recycle Bin in Windows uses this strategy, except for the part about automatically erasing files after a month: Users still have to take out the garbage.
DESIGN
Make all actions reversible.
principle
Even better than acting in haste and forcing users to rescue the program with Undo, you can make sure that applications offer users adequate information so that they never issue a command (or omit a command) that leads to an undesirable result.
Applications should use rich visual feedback so that users are constantly kept informed, the same way the instruments on dashboards keep us informed of the state of our cars.
DESIGN
Provide modeless feedback to help users avoid mistakes.
principle
Occasionally, a situation arises that really can’t be protected by Undo. Is this a legit-imate case for a confirmation dialog box? Not necessarily. A better approach is to provide users with protection the way we give them protection on the freeway: with consistent and clear markings. You can often build excellent, modeless warnings right into the interface. For instance, look at the dialog from Adobe Photoshop in
31_084113 ch25.qxp 4/3/07 6:12 PM Page 544
544
Part III: Designing Interaction Details
Figure 25-7, telling us that our document is larger than the available print area.
Why has the program waited until now to inform us of this fact? What if guides were visible on the page at all times (unless a user hid them) showing the actual printable region? What if those parts of the picture outside the printable area were highlighted when a user moused over the Print butcon in the toolbar? Clear, modeless feedback (see the next section) is the best way to address these problems.
Figure 25-7 This dialog provides too little help too late. What if the program could display the printable region right in the main interface as dotted guides?
There’s no reason for users to be subjected to dialogs like these.
Much more common than honestly irreversible actions are those actions that are easily reversible but still uselessly protected by routine confirmation boxes. The confirmation in Figure 25-6 is an excellent specimen of this species. There is no reason whatsoever to ask for confirmation of a move to the Recycle Bin. The sole reason the Recycle Bin exists is to implement an undo facility for deleted files.
Replacing Dialogs: Rich
Modeless Feedback
Most computers (and many devices) come with high-resolution displays and high-quality audio systems. Yet, very few applications (outside of games) even scratch the surface of using these facilities to provide useful information about the status of the program, the users’ tasks, and the system and its peripherals in general. An entire toolbox is available to express information to users, but designers and programmers have stuck to using the same blunt instrument — the dialog — to communicate information. Needless to say, this means that subtle status information is simply never communicated to users at all, because even the most cluele
ss designers know that you don’t want dialogs to pop up constantly. But constant feedback is exactly what users need. It’s simply the channel of communication that needs to be different.
31_084113 ch25.qxp 4/3/07 6:12 PM Page 545
Chapter 25: Errors, Alerts, and Confirmations
545
In this section, we’ll discuss rich modeless feedback, information that can be provided to users in the main displays of your application, which doesn’t stop the flow and can all but eliminate pesky dialogs.
Rich visual modeless feedback
Perhaps the most important type of modeless feedback is rich visual modeless feedback (RVMF). This type of feedback is rich in terms of giving in-depth information about the status or attributes of a process or object in the current application. It is visual in that it makes idiomatic use of pixels on the screen (often dynamically), and it is modeless in that this information is always readily displayed, requiring no special action or mode shift on the part of a user to view and make sense of the feedback.
For example, in Microsoft Outlook 2007, a small icon next to an e-mail sender’s name visually indicates whether that person is available for a chat session or a phone call, if it turns out that a real-time conversation is preferable to an e-mail exchange. This small icon (as well as the ability to start a chat session from a right-click menu), means that users don’t have to open their chat client and find the sender’s name to see if that person happens to be available. This is so easy and convenient that a user literally does not have to think about it. Another example of the strategy, as designed for a Cooper client, can be seen in Figure 25-8.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 71