Dialog Box Basics

Most dialogs have buttons, comboboxes, and other controls on their surface; and although there are some rudimentary conventions, generally the designer places them as she sees fit and not according to any conventional plan. The dialog's window may or may not have a title/caption bar or frame.

All dialog boxes have an owner. Normally this owner is an application program—usually the one that created it—but it can also be the window system itself. Dialog boxes are always placed visually in a layer on top of their parent program, although the windows of other programs may obscure them.

Every dialog box has at least one terminating command, a control that, when activated, causes the dialog box to shut down and go away. Most dialogs will offer at least two push-buttons as terminating commands, OK and Cancel, although the Close box in the upper-right corner (upper-left corner in Windows 3.x and Mac OS 9) is also a terminating command idiom.

It is technically possible for dialogs not to have terminating commands. Some dialogs are unilaterally erected and removed by the program—for reporting on the progress of a time-consuming function, for example—so their designers may have omitted terminating commands. This is poor design for a variety of reasons, as we will see.

Modal dialog boxes

There are two types of dialog boxes: modal and modeless. Modal dialogs boxes are, by far, the most common variety. After a modal dialog opens, the owning program cannot continue until the dialog box is closed. It stops all proceedings in their tracks. Clicking on any other window belonging to the program will only get the user a rude "beep" for his trouble. All the controls and objects on the surface of the owning application are deactivated for the duration of the modal dialog box. Of course, the user can activate other programs while a modal dialog box is up, but the dialog box will stay there indefinitely. When the user goes back to the program, the modal dialog box will still be there waiting.

In general, modal dialogs are the easiest for users (and designers) to understand. The operation of a modal dialog is quite clear, saying to the user, "Stop what you are doing and deal with me now. When you are done, you can return to what you were doing." The rigidly defined behavior of the modal dialog means that, although it may be abused, it will rarely be misunderstood. There may be too many modal dialog boxes and they may be weak or stupid, but their purpose and scope will usually be clear to the user. Like death and taxes, you may not like modal dialog boxes, but you grasp their meaning.

If a modal dialog box is function-oriented, it usually operates on the entire program or on the entire active document. If the modal dialog box is process- or property-oriented, it usually operates on the current selection. In any case, you can't change the selection after you've summoned the dialog. This is the most important difference between modal and modeless dialogs.

Actually, because modal dialog boxes only stop their owning application, they are more precisely named application modal. It is also possible to create a dialog box, called system modal, that brings every program in the system to a halt. No application program should ever create one of these. Their only purpose is to report truly catastrophic occurrences (such as the hard disk melting) that affect the entire system.

DESIGN TIP 

Never create a system modal dialog.

Modeless dialog boxes

The other variety of dialog box is called modeless. They are less common than their modal siblings (although they are becoming more common with the widespread use of floating palettes in applications from Adobe and Macromedia). They are also less understood.

After the modeless dialog opens, the parent program continues without interruption. It does not stop the proceedings, and the application does not freeze. The various facilities and controls, menus, and toolbars of the main program remain active and functional. Modeless dialogs have terminating commands, too, although the conventions for them are far weaker and more confusing than for modal dialogs.

A modeless dialog box is a much more difficult beast to use and understand, mostly because the scope of its operation is unclear. It appears when you summon it, but you can go back to operating the main program while it stays around. This means that you can change the selection while the modeless dialog box is still visible. If the dialog acts on the current selection, you can select, change, select, change, select, and change all you want. For example, Microsoft Word's Find and Replace dialog allows you to find a word in text (which is automatically selected), make edits to that word, and then pop back to the dialog, which has remained open during the edit.

In some cases, you can also drag objects between the main window and a modeless dialog box. This characteristic makes them really effective as tool or object palettes in drawing-type programs.

Modeless dialog issues

Most modeless dialogs are implemented awkwardly. Their behavior is inconsistent and confusing. They are visually very close to modal dialog boxes, but they are functionally very different. There are few established behavioral conventions for them, particularly with respect to terminating commands. Microsoft is setting a disturbing precedent with terminating buttons that change legends contextually, a poor construct.

Most of the confusion arises because we are more familiar with the modal form and because of inconsistencies that arise in the way we use dialogs. When we see a dialog box, we assume that it is modal and has modal behavior. If it is modeless, users must tentatively poke and prod at it to determine how it behaves. There is just no clear archetype for it.

More confusion creeps into the situation because users are so familiar with the behavior of modal dialogs. A modal dialog can adjust itself for the current selection at the instant it was summoned. It can do this with assurance that the selection won't change during its lifetime. Conversely, the selection is quite likely to change during the lifetime of a modeless dialog box. Then what should the dialog do? For example, if the modeless dialog box modifies text, what should it do if we now select some non-text object on the main window? Should gizmos on the dialog box gray out? Freeze up? Disappear? Should the dialog box just stay there with all its controls "active" but having no effect if they are manipulated? All these options have been tried, and although each one has advantages, it is not clear which help and which hinder us. We'll take a closer look in the next few pages.

Modeless dialog boxes also lead us into complex situations. For example, in Word, request the modeless Find dialog box from the Edit menu. Now, from the Format menu request the modal Font dialog. The Find dialog vanishes. This is a good thing, sort of—it would be bizarre to have a modal dialog stuck on top of an unrelated modeless dialog—but where did the Find dialog go? If you close the Font dialog, the modeless Find dialog reappears—it was hiding behind your document window the whole time! This shuffling of windows makes logical sense: Keep the modal dialog and the window it is operating on as close together as possible visually. However, the disappearance of the modeless dialog could be a bit disturbing to inexperienced users. The simple answer would be to eliminate modeless dialog boxes entirely, but that would be cutting off our nose to spite our face.

Two solutions for better modeless dialogs

A solution must be found for the modeless dialog box problem. We offer two. The first one is easy to swallow, an evolutionary step forward from our present predicament. The second one is more radical; a revolutionary leap. As you might suspect, the first solution is less thorough and effective than the second one. You might also guess—correctly—that we're fonder of the revolutionary leap.

THE EVOLUTIONARY SOLUTION

In the evolutionary solution, we leave modeless dialog boxes pretty much the way they are, but we adopt two guiding principles and apply them consistently to all modeless dialog boxes. The first principle says that we must visually differentiate modeless dialog boxes from modal ones.

DESIGN TIP 

Visually differentiate modeless dialogs from model dialogs.

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. One possible method might be to use a distinctive hue for the dialog's background, or perhaps provide a colored border around the window, or insert a colored stripe across its corner, or make the controls visually distinct, using a different color or labeling them in, say, italics. You can also try setting apart the title/caption bar visually, by making it thinner, for example, or adding a distinctive icon to it.

Whatever method you choose, you must stick with it consistently. It would be nice if vendors agreed on a standard common to all, but that is wishful thinking. It will still be a significant improvement if each vendor adheres to his own company-wide standards for modeless dialog boxes.

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 some Dismiss, Accept, Yes, and some even use 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 TIP 

Give modeless dialog boxes consistent terminating commands.

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 the 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 the 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 the user just confuses things.

DESIGN TIP 

Never dynamically change the labels of terminating buttons.

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. The 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 like the lower-right corner. It would have to be consistent from dialog to dialog: in the exact same place and with the exact same caption. Not to put too fine a point on this, but the word Close is the one to use, and the dialog should never deactivate or change this label.

If the Close button activates 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.

Don't forget that modeless dialog boxes will 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 only close 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.

A MORE RADICAL SOLUTION

The previous is but an interim solution. There is a more radical solution that delivers us from modeless-dialog maladies.

We currently have 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 achieved unprecedented success: toolbars and butcons. The toolbar idiom has by now achieved a widespread success because of its demonstrable quality and convenience. It is also nothing more than a modeless dialog box permanently attached to the top (or side) of the program's main window.

The modelessness of toolbar butcons is perfectly acceptable because they are not delivered to us in the visual form of a dialog. Instead, they are presented as omnipresent tools surrounding the workspace. Without the usual trappings of dialog boxes, it's a sure bet that they won't be confused with dialog boxes. We have no trouble understanding their use, even though identical controls often confound us when placed on a modeless dialog box.

Toolbar butcons can, and should (as discussed in Chapter 29) gray out when they have no effect in the context of the current selection. This behavior is easily understood by users and solves yet another modeless dialog issue.

In summary, 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 free-floating windows, allowing users to position them on the screen wherever they like. The downside is the windows-management excise this entails. Docking toolbars (discussed in the previous chapter; see Figure 29-4) are the perfect solution. 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)—in other words, a modeless dialog. 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.

Elimination of windows-management excise becomes quite important, especially when we are talking about a large suite of floating palettes such as those in Adobe Photoshop and other drawing programs. Back in the days of 640x480 screen resolutions, there was a good reason to leave these floating—the user could slide them out of the way and still get access to the tools. But as screen resolutions creep higher and the numbers of these floating controls multiply, there is a point of diminishing returns where floating palettes simply get in the way. Adobe has partially acknowledged the issue by allowing palettes to snap to the edges of the main window, but they have not gone the final step of allowing them to dock in the main window so that nothing is hidden beneath them. Macromedia, on the other hand, has embraced the idea of dockable palettes in Fireworks MX and other recent application versions. Docking palettes and toolbars eliminate excise, but still give users the flexibility to float individual tools when they are needed.

Look at Figure 30-1, a toolbar from Microsoft Word that has been undocked. It is normally docked in a horizontal row at the top of the main window, just below the menu bar.

Figure 30-1: Here's a floating toolbar from Microsoft Word. It is also a modeless dialog box! The smaller title bar gives it a visual appearance distinct from modal dialog boxes, and the apparent conundrum of contextually inactive butcons is bothersome to nobody. If all modeless dialog boxes were rendered this way, much of the confusion surrounding them would disappear. What's more, if you drag this floating toolbar to an edge of the application, it docks on that edge as a familiar, fixed toolbar. Imagine if you could do that with any modeless dialog box—the Find dialog, for example?

Now let's imagine Word's Find dialog, shown in Figure 30-2, rendered as a floating toolbar. It would have a smaller-title bar instead of its normal one. It would lack a terminating button, relying instead on the Close box in the minicaption bar. What would happen if we were to drag this new Find dialog to the upper edge of the main window? If its behavior were consistent, it would dock: The controls on the surface of the Find dialog would distribute themselves in a horizontal toolbar the way the Format toolbar does. If it works for all those Format butcons and comboboxes, why can't it work for the Find dialog? Why can't we have a toolbar with a butcon for Find Next and with check boxes for the various options (if not for every bit of functionality, then at least for the most often-used functions)? A great example of this is the Google Toolbar, a downloadable toolbar control for Internet Explorer that implements Google's search functions along with a surprising amount of additional functionality.

Figure 30-2: Here's a typical, modeless dialog box, from Microsoft Word. What a mess! It's big, it obscures the text it needs to search within (Word disconcertingly nudges it out of the way if a found word is underneath it), and its button labels are unclear. The Cancel button, for example: What does it cancel? Why can't functions like Find be built into the main window interface? The answer is, they can.

Microsoft has made the floating/docking toolbar idiom a standard in its Office suite. The programs all include a facility for customizing the toolbars to the user's taste. This is a fine step in developing the user interface and should be used whenever possible as a new idiom for replacing modeless dialog boxes.