Chapter 30: Using Dialogs

Dialog boxes, or dialogs, are not part of the main program. If the program is the kitchen, the dialog box is its pantry. The pantry plays a secondary role, as does the dialog box. They are supporting actors rather than lead players, and although they may ratchet the action forward, they are not the engines of motion.

Dialogs Suspend Normal Interaction

Dialogs are superimposed over the main window of the parent program. The dialog engages the user in a conversation by offering information and requesting some input. When the user has finished viewing or changing the information presented, he has the option of accepting or rejecting his changes. The dialog then disappears and returns the user to the main program.

Many users and programmers think of dialog boxes as the primary user-interface idiom of the GUI. Many applications use dialogs to provide the main method of interaction with the program (we're not speaking of simple applications that are composed of just a single dialog box; in those cases, the dialog assumes the role of a main window). In most applications, the user is forced to bounce back and forth between the program's main window and its dialog boxes, inevitably leading to his fatigue and frustration.

AXIOM 

Put primary interactions in the primary window.

When the application presents a dialog box, it temporarily moves the action out of the mainstream, abandoning the user's main focus of attention to develop a secondary issue. This understanding that dialogs are suspensions of normal processing is key to their proper design. The main interaction of the program should be contained in the main window of the program, whereas dialog boxes should be used only for secondary, and usually brief, interactions.

If you asked your dinner party guests to temporarily abandon their soup and step into the pantry, the smooth flow of conversation and warm friendship would be broken. In the same way, a dialog box breaks the smooth flow of rapport between a user and the program. Dialogs, for good or ill, interrupt the interaction and make the user react to the program instead of driving it.

AXIOM 

Dialogs break flow.

Dialogs are appropriate for functions or features that are out of the mainstream of interaction. Anything that is confusing, dangerous, or rarely used can profitably be placed on a dialog box. Dislocating actions make immediate and gross changes to the screen image. Such changes can be visually disturbing to the user and should be cordoned off from users unfamiliar with them. For this reason, dialogs are tools well suited to managing dislocating actions.

Dialog boxes are good for presenting infrequently used functions and settings. The dialog box serves to isolate these operations from more frequently used functions and settings. The dialog box is generally a roomier setting to present controls than other primary control venues; you have more space for explanatory labels than you do in a toolbar, for example.

Dialog boxes are also well suited for concentrating information related to a single subject, such as the properties of an object in an application—an invoice or a customer, for example. They can also gather together all information relevant to a function performed by a program—printing reports, for example. The dialog box, when used in this way, becomes an encapsulation tool, enabling you to box up and remove functions and settings that might have a dislocating or dangerous effect on the program's normal flow of events. For example, a dialog box that allows wholesale reformatting of a document should be considered a dislocating action. The dialog helps prevent this feature from being invoked accidentally by assuring that a big, friendly Cancel button is always present, and also by providing the space to show more protective and explanatory information along with the risky controls. The dialog can graphically show the user the potential effects of the function with a thumbnail picture of what the changes will look like.

Most dialogs are invoked from a menu, so there is a natural kinship between menus and dialogs. As discussed in Chapter 27, menus provide the pedagogic command vector—their primary purpose is to teach users about the program. By extension, dialog boxes also frequently play a part in the pedagogic vector.

Dialog boxes serve two masters: the frequent user who is familiar with the program and uses them to control its more advanced or dangerous facilities; and the infrequent user who is unfamiliar with the scope and use of the program and who is using dialogs to learn the basics. This dual nature means that dialog boxes must be compact and powerful, speedy and smooth, and yet be clear and self-explanatory in use. These two goals may seem to contradict each other, but they can actually be useful complements. A dialog's speedy and powerful nature can contribute directly to its power of self-explanation.