Cascading Dialogs

Cascading dialogs are a diabolical idiom whereby controls, usually push-buttons, on 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 31-6 shows an example taken from Windows XP.

Figure 31-6: 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.

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, comboboxes 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?

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 a too-complex 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 the overall complexity of your interface.

Examples of cascading are common. Most print dialogs allow print-setup dialogs to be called, and most print-setup dialogs allow print-driver-configuration dialogs to be called. Each layer of dialog box is another layer deeper into the process, and as the user terminates the uppermost dialog, the system returns control to the next lower dialog, and so on.

Cascading dialogs exist because they seem natural to programmers and because they mirror the physical processes underneath them. Sometimes they reflect the fact that two different programming teams worked on different parts of the interface, and linking dialogs was the most expedient way to stitch it all together. But this kind of baling-wire and band-aid rationalization is about as backward a motivation as one can have—it ignores the user's goals and the user's mental model of the process. Perhaps cascading dialog boxes can't be entirely avoided, but they represent a very weak idiom and should be scrutinized carefully before they are deployed. Sometimes the situation demands them, as in the print dialog example described above. Even in that case, however, the authors would combine them into a single dialog with three tabs, or at the least combine the first two dialogs and maintain only the printer driver dialog separately from the main print dialog. Three cascading dialogs are excessive for almost any purpose.