Notice that the copy dialog in Figure 24-5 also has a Cancel button. Ostensibly, this satisfies requirement number four, that there be a way to cancel the operation. A user may have second thoughts about the amount of time the operation will take and decide to postpone it, so the Cancel button enables him to do so. However, if the user realizes that he issued the wrong command and wishes to cancel the operation, he will not only want the operation to stop but will want all traces of the operation to be obliterated.
30_084113 ch24.qxp 4/3/07 6:11 PM Page 520
520
Part III: Designing Interaction Details
Figure 24-5 Microsoft got this one mostly right. For any move, copy, or delete operation in this Explorer, they show this reasonably well-designed process dialog box. It provides a hint of the time remaining in the operation, and the dialog uses animation to show paper documents flying out of the folder on the left into the folder (or wastebasket) on the right. Many users’ mental models are of things moving inside the computer, and this little gem actually shows things moving. It is refreshing to see the outside of the computer reflect the inside of the computer in users’ terms. The one thing missing is a countdown of the number of files left to move, which would provide even better feedback about the process at hand.
If a user drags 25 files from directory Alpha to directory Bravo, and halfway through the move realizes that he really wanted them placed in directory Charlie, he will try clicking the Cancel button. Unfortunately, all that does is stop the move at its current state and abandons the remainder of the moves. In other words, if a user clicks the Cancel button after 10 files have been copied, the remaining 15 files are still in directory Alpha, but the first 10 are now in directory Bravo. This is not what the user wants. If the button says Cancel, it should mean cancel, and that means,“I don’t want any of this to happen.” If the button were to accurately represent its action, it would say Stop Move or Stop Copy. Instead, it says Cancel, so cancel is what it should do.
This may mean some significant buffering is needed, and the cancel operation could easily take more time than the original move, copy, or delete. But isn’t this rare event one when the extra time required is easily justified? In Windows Explorer, the program can completely undo a copy, move, or delete, so there is no reason why the Cancel button can’t also undo the portion that has already been performed.
A good alternative would be to have two buttons on the dialog, one labeled Cancel and other labeled Stop. Users could then choose the one they really want.
Eliminating process dialogs
Because a dialog is a separate room, we must ask whether the process reported by the dialog is a function separate from that on the main window. If the function is an integral part of what is shown on the main window, the status of that function should be shown on the main window. For example, the Windows flying pages dialog that was
30_084113 ch24.qxp 4/3/07 6:11 PM Page 521
Chapter 24: Dialogs
521
shown in Figure 24-5 is attractive and appropriate, but isn’t copying a file fundamental to what the Explorer does? The animation, in this case, could have been built right into the main Explorer window. The little pages could fly across the status bar, or they could fly directly across the main window from directory to directory.
Process dialogs are, of course, much easier to program than building animation right into the main window of a program. They also provide a convenient place for the Cancel button, so it is a very reasonable compromise to fling up a process dialog for the duration of a time-consuming task. But don’t lose sight of the fact that, by doing this, we are still going to another room for a this-room function. It is an easy solution, but not the correct solution. Web browsers such as Mozilla Firefox and Microsoft Internet Explorer provide a much more elegant solution. Because loading Web pages is so intrinsic to their operation, the progress indicator is displayed in the status bar itself (see Figure 24-6).
Figure 24-6 Web browsers such as Internet Explorer don’t throw up a process dialog every time they load a page. Rather, a progress indicator is displayed in the status bar on the bottom of the window. This allows users to easily understand what’s going on without obscuring their view of the partially loaded Web page in front of them (which in this case is quite usable). Consider whether this would be appropriate for your users before you assume that process dialogs are the correct solution.
30_084113 ch24.qxp 4/3/07 6:11 PM Page 522
522
Part III: Designing Interaction Details
Bulletin dialog boxes
The bulletin dialog box is a simple, devilish little artifact that is arguably the most abused element of any graphical user interface. Like the process dialog, it is launched, unrequested, by the program.
The ubiquitous error message box best characterizes the bulletin dialog. Normally, the application’s name is shown in the caption bar, and a very brief text description of the problem is displayed in the body. A graphic icon that indicates the class or severity of the problem, along with an OK button, usually completes the ensemble.
Sometimes a button to summon online help is added. An example from Word is shown in Figure 24-7.
Figure 24-7 Here’s a typical bulletin dialog box. It is never requested by the user but is always issued unilaterally by the program when the program fails to do its job or when it just wants to brag about having survived the procedure. The program decides that it is easier to blame the user than it is to go ahead and solve the problem. Users interpret this as saying, “The measurement must be between -22 inches and 22 inches, and you are an incredible buffoon for not knowing that basic, fundamental fact. You are so stupid, in fact, that I’m not even going to change it for you!”
The familiar message box is normally an application modal dialog that stops all further progress of the program until a user issues a terminating command — like clicking the OK button. This is called a blocking bulletin because the program cannot continue until the user responds.
It is also possible for a program to put up a bulletin dialog and then unilaterally take it down again. This type is a transitory bulletin because the dialog disappears and the program continues without user intervention.
Transitory bulletins are sometimes used for error reporting. A program that launches an error message to report a problem may correct the problem itself or may detect that the problem has disappeared via some other agency. Some
30_084113 ch24.qxp 4/3/07 6:11 PM Page 523
Chapter 24: Dialogs
523
programmers will issue an error or notifier bulletin merely as a warning — Your disk is getting full — and take it down again after it has been up for, say, 10 seconds.
This type of behavior is fraught with usability problems.
An error or confirmation message must stop the program. If it doesn’t, a user may not be able to read it fully, or if he is looking away, he either won’t see it or worse yet, see only a fleeting glimpse out of the corner of his eye. He will be justifiably suspicious that he has missed something important, something that will come back to haunt him later. He will now begin to worry: What did I miss? Was that an important bit of intelligence that I will regret not knowing? Is the system unstable? Is it about to crash? This is true even if the problem has gone away by itself.
If a thing is worth saying with a dialog box, it’s worth ensuring that a user definitely gets the message. A transitory bulletin can’t make that guarantee. It should never be used in the role of error reporting or confirmation gathering.
DESIGN
Never use transitory dialogs as error messages or confirmations.
principle
Property and function dialog boxes are intentionally requested by users — they serve users. The application, however, issues bulletin dialogs — they serve the application, at users’ expense. Error, notification (alert), and confirmation messages are blocking bulletin dialogs. As we shall see, even these can and should be a
voided in most circumstances.
Managing Content in Dialog Boxes
Even if you are conscientious about the use and organization of dialogs, they can easily become quite crowded with properties, options, and the like. There are a couple of common strategies for managing this crowding so your dialogs maintain their usefulness.
Tabbed dialogs
A number of years back, tabbed dialogs quickly became an established standard in the world of commercial software. The idiom, while quite useful at times, has also become an unfortunately convenient way for programmers to jam a whole pile of vaguely related functions into a dialog box.
30_084113 ch24.qxp 4/3/07 6:11 PM Page 524
524
Part III: Designing Interaction Details
On a positive note, many domain or application objects with numerous properties can now have correspondingly rich property dialog boxes without making those boxes excessively large and crowded with controls (see Figure 24-8 for an example).
Many function dialogs that were previously jam-packed with controls now make better use of their space. Before tabbed dialogs, the problem was often clumsily solved with expanding and cascading dialogs, which we’ll discuss shortly.
Figure 24-8 This is a tabbed dialog box from iTunes. Combining the different properties of a song in one dialog box is effective for users because they have a single place to go to find such things. Note that the terminating controls are correctly placed outside the tabbed pane, in the lower right.
A tabbed dialog allows programmers to cram more controls into a single dialog box, but more controls won’t necessarily mean that users will find the interface easier to use or more powerful. The contents of the various tabs must have a meaningful rationale for being together, otherwise this capability is just another way to build a product according to what is easy for programmers, rather than what is good for users.
30_084113 ch24.qxp 4/3/07 6:11 PM Page 525
Chapter 24: Dialogs
525
The tabs in a dialog should be organized to provide either increased depth or increased breadth on a well-defined topic. To organize for breadth, each tab should cover parallel, alternate aspects of the primary topic, the way song properties from iTunes, shown in Figure 24-8, addresses a variety of properties and settings for the song that would be unwieldy in a single pane. In the case of organizing for more depth, each tab should probe the same aspect of one topic in greater depth. The commonly employed Advanced tab is an example of this strategy.
Tabs are successful because the idiom follows many users’ mental model of how things are normally stored. The various controls are grouped in several parallel panes, one level deep. But this idiom is often abused.
Because it’s easy to cram so many controls into a tabbed dialog, the temptation is great to add more and more tabs to a dialog. The Options dialog in Microsoft Word, shown in Figure 24-9, is a clear example of this problem. The 10 tabs are far too numerous to show in a single line, so they are stacked two deep. The problem with this idiom, called stacked tabs, is that a user has to do a fairly significant amount of work to find the single option she wants to change. While the labels of the tabs may give her some help, she is still forced to scan the contents of several tabs while switching between them. And if that isn’t enough, when she clicks on a tab in the back row, the entire row of tabs moves forward, shunting the other two rows to the back. Very few users seem to be happy with this — it’s disconcerting to click on a tab and then have it move out from under the mouse.
DESIGN
All interaction idioms have practical limits.
principle
Stacked tabs illustrate the following axiom of user-interface design: All idioms, regardless of their merits, have practical limits. A group of 5 radio buttons may be excellent, but a group of 50 of them is ridiculous. Five or six tabs in a row are fine, but adding enough tabs to require stacking greatly reduces the usefulness of the idiom.
A better alternative would be to use several separate dialogs with fewer tabs on each. In this example, Options is just too broad a category, and lumping all this functionality in one place isn’t doing users any favors. There is little connection among the 12 panes, so there is little need to move among them. This solution may lack a certain programming elegance, but it is much better for users.
30_084113 ch24.qxp 4/3/07 6:11 PM Page 526
526
Part III: Designing Interaction Details
Figure 24-9 The Options dialog in Word is an abuse of the tabbed dialog idiom.
The problem is that users have to do quite a lot of work to find the option that they’re looking for.
DESIGN
Don’t stack tabs.
principle
Expanding dialogs
Expanding dialog boxes were big around 1990 but have declined in popularity since then, largely due to the ubiquity of toolbars and tabbed dialogs. You can still find them in many mainstream applications, such as the Find dialog in Word.
Expanding dialogs unfold to expose more controls. The dialog shows a button marked More or Expand, and when a user clicks it, the dialog box grows to occupy more screen space. The newly added portion of the dialog box contains added functionality, usually for advanced users or more complex, but related, operations.
The Find dialog in Microsoft Word is a familiar example of this idiom and is shown in Figure 24-10.
30_084113 ch24.qxp 4/3/07 6:11 PM Page 527
Chapter 24: Dialogs
527
Figure 24-10 The Microsoft Word Find dialog is an example of an expanding dialog. The image on the left shows it in its original state; the one on the right is what happens after the More button is pressed.
Expanding dialog boxes allow infrequent or first-time users the luxury of not having to confront the complex facilities that more frequent users don’t find confusing or overwhelming. Think of the dialog as being in either beginner or advanced mode. However, these types of dialogs must be designed with care. When a program has one dialog for beginners and another for experts, it all too often simultaneously insults the beginners and hassles the experts. It’s usually a good idea for the dialog to remember what mode it was used in the last time it was invoked. Of course, this means you should always remember to include a Shrink or Less command to return the dialog to simple beginner mode (as you can see in the Find dialog in Figure 24-10).
Cascading dialogs
Cascading dialogs are a diabolical idiom whereby controls, usually pushbuttons, in one dialog box summon up another dialog box in a hierarchical nesting. The second dialog box usually covers up the first one. Sometimes the second dialog can summon up yet a third one. What a mess! Thankfully, cascading dialogs have been falling from grace, but examples can still be found. Figure 24-11 shows an example taken from Windows Vista.
It is simply hard to understand what is going on with cascading dialogs. Part of the problem is that the second dialog covers up at least part of the first. That isn’t the big issue — after all, combo boxes and pop-up menus do that, and some dialogs can be moved. The real confusion comes from the presence of a second set of terminating buttons. What is the scope of each Cancel? What are we OKing?
30_084113 ch24.qxp 4/3/07 6:11 PM Page 528
528
Part III: Designing Interaction Details
Figure 24-11 You can still find cascading dialogs in Windows. Each dialog box offers a set of terminating buttons. The resulting excise and ambiguity are not helpful.
The strength of tabbed dialogs is handling breadth of complexity, while cascading dialogs are better suited for depth. The problem is that excessive depth is a prime symptom of too much complexity in an interface. If you find your program requiring cascading dialogs for anything other than really obscure stuff that your users won’t generally need, you should take another look at your interaction framework —
you may find some severe structural flaws.
Dialogs can become useful assistants that help yo
ur users accomplish their goals, instead of dreaded roadblocks that confound them at every step. By keeping your dialogs manageable, and invoking them only when their functions are truly those that belong in another room, you will go far towards maintaining your users’ flow and ensuring their success and gratitude.
31_084113 ch25.qxp 4/3/07 6:11 PM Page 529
25
Errors, Alerts, and
Confirmation
In Chapter 24, we discussed the bulletin dialog, commonly issued by applications when they have problems or confront decisions they don’t feel capable of making, or really any time they have something to notify users about. In other words, these dialog boxes are used for error messages, alerts, and confirmations, three of the most abused components of modern GUI design. With proper design, these dialogs can all but be eliminated. In this chapter, we explore how and why.
Error Dialogs
There is probably no user-interface idiom more abused than the error dialog. They are typically poorly written, unhelpful, rude, and worst of all, are never in time to prevent the error in the first place. Users never want error messages. Users want to avoid the consequences of making errors. This is very different from saying that they want error messages — it’s like saying that people want to abstain from skiing when what they really want to do is avoid breaking their legs. As usability heavy-weight Donald Norman points out, users frequently blame themselves for errors in product design. Just because you aren’t getting complaints from your users doesn’t mean that they are happy getting error messages.
31_084113 ch25.qxp 4/3/07 6:11 PM Page 530
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 69