About Face 2.0(c) The Essentials of Interaction Design

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 varieties of dialog box: property, function, process, and bulletin.

Property dialog boxes

A property dialog box presents the user with the settings or attributes of a selected object and enables the user to make changes to them. Sometimes the attributes may relate to the entire application or document, rather than just one object.

The Font dialog box in Word, shown in Figure 30-3, is a good example. The user selects some text in the main window and then requests the dialog box from the Format menu. The dialog enables the user to change font-related attributes of the selected characters. You can think of property dialogs as a control panel with exposed configuration controls for the selected object. Property dialog boxes can be either modal or modeless.

Figure 30-3: The Font dialog box in Word is a properties dialog. It reflects all the typographic characteristics of the current selection. When the user manipulates controls in this dialog, the typographic qualities of the selection change in the preview area, but not in the document until the OK button is clicked. The operation is essentially one of configuration. The preview box is great, but why can't the font field in the upper-left corner use the actual fonts, too?

A properties dialog box generally controls the current selection. This follows the object-verb form: The user selects the object, then, via the property dialog, selects new settings for the selection.

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, inserting objects, or spell checking.

Function dialog boxes not only allow the user to start an action, but they often also enable the user to configure the details of the action's behavior. In many programs, for example, when the user requests printing, she uses the Print dialog to specify which 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 initiates 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.

Many functions available from modern software are quite complicated and have many configurable options. Their controlling dialog boxes are thus correspondingly complicated.

In the example shown in Figure 30-4, the user first configures the operation by choosing a file and then executes the configured command by clicking the terminating command button. It is very tempting to make that terminating button say Insert instead of OK, as the designers have done in this case. You should fight this urge. It may seem more logical, but the loss of a consistently labeled terminating command button is too great a price to pay. If the dialog's title bar text is appropriate, it will read like an English phrase, telling the user exactly what will happen: Insert the Picture….

Figure 30-4: The Insert Picture dialog box from Word is a function dialog box. It is quintessentially modal, allowing the user to first configure the function by choosing a file. Nothing happens, however, until the OK button is clicked. The dialog does not have an effect on an object, but rather performs an operation.

Note also that the Insert button in this picture has a drop-down menu associated with it. Although the intent was to hide complexity (and probably to save space), the last thing you want in a terminating control on a dialog is for it to be non-standard and confusing. The designers should have taken a different approach.

Process dialog boxes

Process dialog boxes are launched at the program's discretion rather than at the user's request. They indicate to the user that the program is busy with some internal function and that performance in other areas is likely to degrade.

The process dialog box alerts the user to the program's inability to respond normally. It also warns the user not to be overcome with impatience and to resist banging on the keyboard to get the program's attention.

When a program begins a process that will take perceptible quantities of time, as measured by a human user, it must make clear that it is busy, but that everything is otherwise normal. If the program does not indicate this, the user will interpret it as rudeness at best; at worst, he will assume the program has crashed and that drastic action must be taken.

As we discussed in Chapter 21, 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 tasks:

1. Make clear to the user that a time-consuming process is happening.

2. Make clear to the user that things are completely normal.

3. Make clear to the user how much more time the process will take.

4. Provide a way for the user to cancel the operation and regain control of the program.

The mere presence of the process dialog box satisfies the first requirement, alerting the user 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 program 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 than 50 percent of the next process.

The 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 the user 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 on 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 30-5). The effect is remarkable: The user gets 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.

Figure 30-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. The user's mental model is one 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.

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.

Notice that the copy dialog in Figure 30-5 also has a Cancel button. Ostensibly, this satisfies requirement number four, that there be a way to cancel the operation. The 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 trace of the operation to be obliterated.

If the 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 pushing 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 the 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 Halt Move or Halt 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. The user could then choose the one he really wants.

Eliminating process dialogs

The need for process dialog boxes is unclear. They are as common as weeds in contemporary software, and about as useful, too. But what can we do to replace them?

The answer to that question is found by asking who is doing the processing. 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 shown in Figure 30-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.

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 issuing program'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 30-6.

Figure 30-6: 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 the 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 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, the 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 the 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.

Property and function dialog boxes are intentionally requested by the user—they serve the user. The program, however, issues bulletin dialogs—they serve the program, at the user's expense. Error, notification (alert), and confirmation messages are blocking bulletin dialogs. As we shall see, even these can and should be avoided in most circumstances. We will discuss this in detail in Chapters 33 and 34.