Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf)
Page 68
Two solutions for better modeless dialogs
We offer two design strategies for improving modeless dialogs. The first one is easy to swallow, a stopgap for common predicaments. The second one is more radical; an evolutionary step forward. The first solution is less thorough and effective than the second one. As you might guess, we prefer the evolutionary step. (Luckily, as you will see, in recent years, many other designers have already generated some momentum in this direction.)
30_084113 ch24.qxp 4/3/07 6:11 PM Page 511
Chapter 24: Dialogs
511
A stopgap solution
If you have limited time and resources to deal with interaction design issues, we recommend leaving modeless dialog boxes pretty much the way they are, but adopting two guiding principles and applying them consistently to all modeless dialog boxes.
DESIGN
Visually differentiate modeless dialogs from modal dialogs.
principle
If a programmer uses the standard modeless dialog box facility in the Windows API, the resultant dialog is visually indistinguishable from a modal one. We must break this habit. The designer must assure that all modeless dialog boxes are rendered with a clearly noticeable visual difference. Possible methods include using a different background, making the controls visually distinct, or using a different color title bar or icon. Whatever method you choose, you must consistently stick with it.
The second principle says that we must adopt consistent and correct conventions for the terminating commands. It seems that each vendor, sometimes each programmer, uses a different technique on each individual dialog box. There isn’t any reason for this cacophony of methods. Some dialogs say Close, some say Apply, some use Done, while others use Dismiss, Accept, Yes, and even OK. The variety is endless. Still others dispense with terminating buttons altogether and rely only upon the Close box in the title bar. Terminating a modeless dialog box should be a simple, easy, consistent idiom, very similar — if not exactly the same — from program to program.
DESIGN
Use consistent terminating commands for modeless dialog boxes.
principle
One particularly obnoxious construction is the use of terminating buttons that change their legends from Cancel to Apply, or from Cancel to Close, depending on whether a user has taken an action within the modeless dialog box. This dynamic change is, at best, disconcerting and hard to interpret and, at worst, frightening and inscrutable. These legends should never change. If a user hasn’t selected a valid option but clicks OK anyway, the dialog box should assume the user means, “Dismiss the box without taking any action,” for the simple reason that that is what the user actually did. Modal dialog boxes offer us the ability to cancel our actions directly, with the Cancel button. Modeless dialogs don’t usually allow this direct idiom — we must resort to Undo — so changing the legends to warn users just confuses things.
30_084113 ch24.qxp 4/3/07 6:11 PM Page 512
512
Part III: Designing Interaction Details
DESIGN
Don’t dynamically change the labels of terminating buttons.
principle
The cognitive strength of modal dialog boxes is in their rigidly consistent OK and Cancel buttons. In modal dialogs, the OK button means, “Accept my input and close the dialog.” The problem is that there is no equivalent for modeless dialog boxes. Because the controls on a modeless dialog box are always live, the equivalent concept is clouded in confusion. A user doesn’t conditionally configure changes in anticipation of a terminal Execute command as he does for a modal dialog box. In modal dialogs, the Cancel button means, “Abandon my input and close the dialog.”
But because the changes made from a modeless dialog box are immediate —
occurring as soon as an activating button is clicked — there is no concept of
“Cancel all of my actions.” There may have been dozens of separate actions on a number of selections. The proper idiom for this is the Undo function, which resides on the toolbar or Edit menu and is active application-wide for all modeless dialog boxes. This all fits together logically, because the Undo function is unavailable if a modal dialog box is up, but is still usable with modeless ones.
The only consistent terminating action for modeless dialog boxes is Close. Every modeless dialog box should have a Close button placed in a consistent location such as the lower-right corner. It must be consistent from dialog to dialog, in the exact same place and with the exact same caption. This button should never be disabled. Further, if the Close button actuates a function in addition to shutting the dialog, you have created a modal dialog box that should follow the conventions for the modal idiom instead.
Modeless dialog boxes frequently have several buttons that immediately invoke various functions. The dialog box should not close when one of these function buttons is clicked. It is modeless because it stays around for repetitive use and should close only when the single, consistently placed Close button is clicked.
Modeless dialog boxes must also be incredibly conservative of pixels. They will be staying around on the screen, occupying the front and center location, so they must be extra careful not to waste pixels on anything unnecessary. For this reason, especially in the context of floating palettes, the Close box in the title bar may be the best solution for a sole terminating control.
Taking an evolutionary step
The previous recommendations add up to a modest solution. Following them will surely improve some otherwise rough interactions, but the results will still leave something to be desired. There is a more radical solution that delivers us from modeless dialog maladies.
30_084113 ch24.qxp 4/3/07 6:11 PM Page 513
Chapter 24: Dialogs
513
There have traditionally been two modeless tool idioms in common use. The modeless dialog box is the older of the two. The other modeless idiom is a relative newcomer on the user-interface scene but has been largely successful: namely, the toolbar. The toolbar idiom has been demonstrably effective and convenient.
Most importantly, users really seem to understand that the toolbar state reflects what is selected, and that interactions with the widgets in a toolbar have a direct and immediate impact on the selection or application.
Here’s where we see an opening for a new approach to modeless interactivity.
Toolbars are modeless, but they don’t introduce the conundrums that modeless dialogs do. They also offer two characteristics that modeless dialog boxes don’t: They are visually different from dialog boxes, and there is no need to worry about dismissing them because they are omnipresent — thus there is no need for terminating controls. They solve other problems, too. Toolbars are incredibly efficient in screen space, particularly compared to dialog boxes, and they don’t cover up what they are operating on!
Modeless dialogs are conventionally free-floating windows, which allows users to position them on the screen wherever they like, but it also results in window-management excise. It is no user’s goal to reposition windows — all work done in the service of this is excise. Docking toolbars point us in the direction of a good solution (see Chapter 23 for more about them). You can click and drag on a docking toolbar, pull it away from the edge of the program, and it will instantly convert into a floating palette (also called a palette window). You can leave it this way or drag it to any edge of the program’s main window, where it will convert back to a toolbar and become docked against the edge.
The palette takes the idea of the docking toolbar and extends to allow for even more interactivity. In fact, modern toolbars commonly contain all the control widgets that you might need for a highly interactive palette. The minor leap from a toolbar to a palette is really mostly one of changing the layout and allocation of vertical space.
Palettes are popular in graphics applications, where modeless access to tools is absolutely critical for users to maintain a productive flow. Adobe Photoshop was among the first to
provide a good deal of functionality modelessly through palettes.
With a growing number of palettes, it has become necessary to give them a more permanent home. Adobe Fireworks MX and other applications originally developed by Macromedia were among the first to provide a more robust docking structure to minimize screen management excise (see Figure 24-1). Recent versions of Photoshop have taken up the idiom.
30_084113 ch24.qxp 4/3/07 6:11 PM Page 514
514
Part III: Designing Interaction Details
Figure 24-1 The docked palettes in Adobe Fireworks MX provide similar interactivity as modeless dialog boxes, but don’t require users to spend as much effort and attention invoking, moving, and dismissing dialogs. It doesn’t take a lot of imagination to see that these are really quite similar to toolbars in the sense that they use standard controls and widgets to provide application functionality directly, visibly, and persistently in the user interface.
The final step in the evolution of this new modeless command idiom has been the introduction of the sidebar or task pane — a pane in the application window dedicated to providing the kind of functions that were formerly delivered through dialog boxes. One of the first applications to do this was Autodesk’s 3ds Max, a 3D
modeling application that provides the ability to adjust object parameters modelessly through a sidebar. Mainstream applications that feature sidebars include Microsoft Windows Explorer and Internet Explorer, with their Explorer Bars, Mozilla Firefox with its Side Bar, Apple’s uLife applications with their Inspectors, and Microsoft Office through its Task Pane. Adobe Lightroom has perhaps adopted this approach the most wholeheartedly — almost all of the application’s functionality is provided modelessly through sidebars (see Figure 24-2).
30_084113 ch24.qxp 4/3/07 6:11 PM Page 515
Chapter 24: Dialogs
515
Figure 24-2 Sidebars in Adobe Lightroom replace the need for dozens of dialog boxes. This approach is similar to the palette approach shown in Figure 24-1, but unlike palettes, the sidebar doesn’t require users to position it on the screen and doesn’t allow users to undock or dismiss it individually (though the entire sidebar may be hidden). This further reduces screen management excise and represents a significant improvement over using dialog boxes to present application functions.
Sidebars holds a lot of promise as an interaction idiom — they are featured prominently in many Cooper designs, and they need not be limited to the sides of the screen. A commonly employed pattern is the dedicated properties area below a document pane or “workspace.” This modelessly provides the ability to modify a selected domain object while minimizing confusion and screen management excise (see Figure 24-3). This idiom may even be usefully employed for functions that must be submitted. Among other applications, we’ve used inline dialogs as mechanisms for defining orders for financial markets.
30_084113 ch24.qxp 4/3/07 6:11 PM Page 516
516
Part III: Designing Interaction Details
Figure 24-3 This design by Cooper for a customer-relationship management (CRM) application features dedicated properties. When a user selects an object in the workspace (top half of the screen, on the left), its properties are displayed below, thereby retaining the users context and minimizing screen management excise.
Four Different Purposes for Dialogs
The concepts of modal and modeless dialogs are derived from programmers’ terms.
They affect our design, but we must also examine dialogs from a goal-directed point of view. In that light, there are four fundamental types of information that are useful to convey with a dialog box: property, function, process, and bulletin.
Property dialog boxes
A property dialog box allows users to view and change settings or attributes of a selected object. Sometimes the attributes may relate to the entire application or document, rather than just one object.
30_084113 ch24.qxp 4/3/07 6:11 PM Page 517
Chapter 24: Dialogs
517
The Font dialog box in Word, shown in Figure 24-4, is a good example. A user selects some text in the main window and then requests the dialog box from the Format menu. The dialog enables users to change font-related attributes of the selected characters. You can think of property dialogs as control panels with exposed configuration controls for the selected object. Property dialog boxes can be either modal or modeless. A properties dialog box generally controls the current selection. This follows the object-verb form: A user selects the object, then, via the property dialog, picks new settings for the selection.
Figure 24-4 The Font dialog box in Microsoft Word 2003 is a classic example of a properties dialog. A user selects text in a document, invokes the dialog with a menu command, and is then presented with a tabbed modal dialog containing all of the Font settings relevant to that text. This is one of the most common operations in a word processor. Why should a user have to go to another room to do this?
Function dialog boxes
Function dialog boxes are usually summoned from a menu. They are most frequently modal dialog boxes, and they control a single function such as printing, modifying large numbers of database records, inserting objects, or spell checking.
Function dialog boxes not only allow users to initiate an action, but they often also enable users to configure the details of the action’s behavior. In many applications, for example, when a user wants to print, she uses the Print dialog to specify which
30_084113 ch24.qxp 4/3/07 6:11 PM Page 518
518
Part III: Designing Interaction Details
pages to print, the number of copies to print, which printer to output to, and other settings directly relating to the print function. The terminating OK button on the dialog not only confirms the settings and closes the dialog but also executes the print operation.
This technique, though common, combines two functions into one: Configuring the function and invoking it. Just because a function can be configured, however, doesn’t necessarily mean that a user will want to configure it before every invocation. It’s often better to make these two functions separately accessible (though clearly they should also be seamlessly linked).
Many functions available from modern software are quite flexible and have a number of options. If you don’t segregate configuration and actuation, users can be forced to confront considerable complexity, even if they want to perform a routine task in a simple manner.
Process dialog boxes
Process dialog boxes are launched at an application’s discretion rather than at a user’s request. They indicate that the application is busy with some internal function and that performance in other areas is likely to degrade.
When an application begins a process that will take perceptible quantities of time, it must make clear that it is busy, but that everything is otherwise normal. If the program does not indicate this, a user will interpret it as rudeness at best; at worst, he will assume the program has crashed and that drastic action must be taken.
DESIGN
Inform the user when the application is unresponsive.
principle
As we discussed in Chapter 19, many programs currently rely on active wait-cursor hinting, turning the cursor into an hourglass. A better, more informative solution is a process dialog box (we’ll discuss an even better solution later in this chapter).
Each process dialog box has four requirements:
Make clear to users that a time-consuming process is happening
Make clear to users that things are completely normal
Make clear to users how much more time the process will take
Provide a way for users to cancel the operation and regain control of the program
30_084113 ch24.qxp 4/3/07 6:11 PM Page 519
Chapter 24: Dialogs
519
The mere presence of the process dialog box satisfies the first requirement, alerting users to the fact that some process is occurring
. Satisfying the third requirement can be accomplished with a progress meter of some sort, showing the relative percentage of work performed and how much is yet to go. Satisfying the second requirement is the tough one. The application can crash and leave the dialog box up, lying mutely to the user about the status of the operation. The process dialog box must continually show, via time-related movement, that things are progressing normally. The meter should show the progress relative to the total time the process will consume rather than the total size of the process. Fifty percent of one process may be radically different in time from 50% of the next process.
A user’s mental model of the computer executing a time-consuming process will quite reasonably be that of a machine cranking along. A static dialog box that merely announces that the computer is Reading Disk may tell users that a time-consuming process is happening, but it doesn’t show that this is true. The best way to show the process is by using animation in the dialog box. In Windows, when files are moved, copied, or deleted, a process dialog box shows a small animated cartoon of papers flying from one folder to another folder or the wastebasket (see Figure 24-5). The effect is remarkable: Users get the sense that the computer is really doing something. The sensation that things are working normally is visceral rather than cerebral, and users — even expert users — are reassured.
Microsoft’s progress meter satisfies — barely — the third requirement by hinting at the amount of time remaining in the process. There is one dialog box per operation, but the operation can affect many files. The dialog should also show an animated countdown of the number of files in the operation (for example, “12 out of 37 files remaining”). Right now, the meter shows only the progress of the single file currently being transferred (interestingly, the standard Windows install process does use a meter that indicates how many documents there are to go).