Choosing Your Windows

Our programs are constructed of two kinds of windows: main windows and subordinate windows (like documents and dialog boxes). Determining which windows to use for a program is a primary step in determining its look and feel. If we expect to create an effective user interface, we cannot simply guess at which windows to use. We must choose them carefully and understand why we make our choices.

Unnecessary rooms

If we imagine our program as a house, we can picture each window as a separate room. The house itself is represented by the program's main window, and each room is a document window or dialog box. In real life, we don't add a room to our house unless it has a purpose that cannot be served by other rooms. Similarly, we shouldn't add windows to our program unless they have a special purposes that can't or shouldn't be served by existing windows.

Purpose is a goal-directed term. It implies that using a room is associated with a goal, but not necessarily with a particular task or function. For example, you might shake someone's hand at your front door, but it will probably have quite different connotations from shaking someone's hand in the kitchen or bedroom.

If someone you just met held out his hand to shake yours, you would think it odd if he suddenly jerked it away and said, "Wait! Let's go into the kitchen." Moving to another room just to shake hands is simply weird. The task can be performed just as well right where you are. It would be especially ridiculous if, after shaking hands in the kitchen, you both then trudged back to the foyer to continue what you were doing.

AXIOM 

A dialog box is another room; have a good reason to go there.

In most drawing programs, for example, the depth of a drop-shadow is usually set by selecting a menu item that triggers a dialog box. A text field or similar control on the dialog then sets the shadow depth. After the setting is made, the program returns to the main screen that contains the drawing. This sequence is so commonplace that it is completely unremarkable, and yet it is undeniably poor design. In a drawing program, changing the image is the primary task. The image is in the main window, so that's where the tools that affect it should be also. Setting the depth of a drop-shadow isn't a tangential task but one quite integral to the drawing process. If the drawing were being done with pencil on paper, the artist might bring a new tool to bear—an eraser—but he would not shift to a different table or sheet of paper just to change the depth of the drop-shadow. The drop-shadow depth could be set with a control right on the toolbar, for example, or—better yet—by letting the user click on the shadow with the mouse and simply drag the shadow to a new position.

Putting functions in a dialog box emphasizes their separateness from the main task. Putting the drop-shadow adjustment in a dialog box works just fine, but it creates an interaction that is awkward. Going into an adjacent room to shake hands works fine as far as the handshake goes, but it is a distracting waste of effort in the context of the larger interaction.

From the programmer's point of view, changing the drop-shadow is a separate function, so it seems natural to treat it like one. From the user's point of view, however, it is an integral function and should be integrated into the main window.

DESIGN TIP 

Build functions into the window where they are used.

This is one of the most frequently violated tips in user interface design. Because the construction of programs is so function-centric, the user interface is often constructed in close parallel. Combine this with the incredible ease with which we can build dialog boxes, and the result is one dialog box per function. Our modern GUI-building tools tend to make dialogs easy to create, but adding controls to the surface of a document window or creating direct-manipulation idioms is generally not supported by these handy tools. The developer who wants to create a better user interface often must build his own without much help from the tool vendors.

Necessary rooms

When you want to go swimming, it would be odd if you were offered a living room full of guests as a place to change your clothes. Decorum and modesty are excellent reasons for you to want a separate room in which to change. It is entirely appropriate to provide a separate room when one is needed.

When users perform a function that is outside of the normal sequence of events for them, that program should provide a special place in which to perform it. For example, purging a database is not a normal activity. It involves setting up and using features and facilities that are not part of the normal operation of the database program. The more prosaic parts of the program will support daily tasks like entering and examining records, but erasing records en masse is not an everyday occurrence. The purge facility correctly belongs in a separate dialog box. It is entirely appropriate for the program to lead the user into a separate room—a window or dialog—to handle that function.

Using goal-directed thinking, we can examine each function to good effect. If someone is using a graphics program to develop a drawing, his goal is to create an appealing and effective image. All the drawing tools are directly related to this goal, but the pencils and paintbrushes and erasers are the most tightly connected functions. These tools should be intimately integrated into the workspace itself in the same way that the conventional artist will arrange his pencils, pens, knives, tweezers, erasers, and other drawing equipment right on his drawing board, close at hand. The tools are ready for immediate use without his having to reach far, let alone having to get up and walk into the next room. In the program, drawing tools should be arrayed on the edges of the drawing space, available with a single click of the mouse. The user shouldn't have to go to the menu or to dialog boxes to accomplish these tasks. Procreate's Painter 7 arranges artists' tools in trays, and lets you move the things that you use frequently to the front of the tray. Although you can hide the various trays and palettes if you want, they appear as the default and are part of the main drawing window. They can be positioned anywhere on the window, as well. And if you create a brush that is, for example, thin charcoal in a particular shade of red that you're going to need again, you simply "tear it off" the palette and place it wherever you want on your workspace—just like laying that charcoal in the tray on your easel. This tool selection design closely mimics the way we manipulate tools while drawing.

If, on the other hand, the user decides to import a piece of clip art, although the function is related to the goal of producing a good drawing, the tools used are not related to drawing. The clip art directory is clearly not congruent with the user's goal of drawing—it is only a means to an end. The conventional artist probably does not keep a book of clip art right on his drawing board, but you can expect that it is close by, probably on a bookshelf immediately adjacent to the drawing board and available without even getting up. In the program, the clip art facility should be very easy to access but, because it involves a whole suite of tools that aren't normally needed, it should be placed in a separate facility: a dialog box.

When the user is done creating the artwork, he has achieved his initial goal of creating an effective image. At this point, his goals change. His new goal is to preserve the picture, protect it, and communicate through it. The need for pens and pencils is over. The need for clip art is over. Leaving these tools behind now is no hardship. The conventional artist would now unpin the drawing from his board, take it into the hall and spray it with fixative, then roll it up and put it in a mailing tube. He purposely leaves behind his drawing tools—he doesn't want them affected by fixative overspray and doesn't want accidents with paint or charcoal to mar the finished work. Mailing tubes are used infrequently and are sufficiently unrelated to the drawing process that he stores them in a closet. In the software equivalent of this process, the user ends the drawing program, puts away his drawing tools, finds an appropriate place on the hard disk to store the image, and sends it to someone else via electronic mail. These functions are clearly separated from the drawing process by the goals of the user.

By examining the user's goals, we are naturally guided to an appropriate form for the program. Instead of merely putting every function in a dialog box, we can see that some functions shouldn't be enclosed in a dialog at all. Others should be put into a dialog that is integral to the main body of the interface, and still other functions should be completely removed from the program.

Windows pollution

Some designers take the approach that each dialog box should embody a single function. What they end up with is windows pollution.

Achieving many user goals involves executing a series of functions. If there is a single dialog box for each function things can quickly get visually crowded and navigationally confusing. The CompuServe Navigator (Version 1.0.1), shown in Figure 25-2, is the case in point.

Figure 25-2: Version 1.0 of CompuServe's Navigator suffered from tragic windows pollution. Normal downloading of e-mail required three windows to be opened. To examine a filed message required three more windows. Examining mail is one integral activity and should occupy a single, integrated window. But the worst is yet to come: The user had to put every window away individually, in the reverse order of opening them.

Adding a squirt of oil to a bicycle makes it pedal more easily, but that doesn't mean that dumping a gallon of oil on it will make it pedal itself. The designer of Navigator was on a mission to put more windows in our lives, perhaps in the mistaken belief that windows are inherently good.

AXIOM 

The utility of any interaction idiom is context-dependent.

Another possibility is that Navigator was the result of a large team of programmers working without an integrated framework for the design. Thus each module of functionality is expressed in a window or dialog, simply because it's easier than trying to fit them cleanly together post facto: classic implementation model. This example was presented in the first edition of About Face in 1995, and we wish we could say things have improved. But one need only look at America Online's interface today to see how little things have changed. AOL, despite the disservice it does to its huge user base in terms of excise and confusion, continues to be one of the worst windows polluters on the planet.

Let's look at one example from Navigator: e-mail. From the user's point of view, examining a saved piece of e-mail is not three functions (choosing a mailbox, sorting mail in a mailbox, and reading a message), but rather, a single activity. One window would not only be perfectly sufficient to accomplish this task, it would also more closely correspond to the user's goal and mental model of viewing an e-mail. The programmer has instead faithfully rendered the actual processing to the user, somewhat like forcing the driver to turn two steering wheels, one for each front wheel, instead of combining the two functions into a single, conceptual whole.

A much better solution to the Navigator problem would have been to create a single mailbox with tools strategically positioned along the top row—a toolbar would be perfect—for managing searches. Intermediate results of the search could be shown in the window along with the final message itself. One goal—finding and reading a message—should be implemented as one dialog box. Microsoft Outlook has made strides in this area: Multiple mailboxes, the list of mail in each box, and the e-mail messages themselves can be accessed within a single, multipane, sovereign window that is designed to remain maximized. Replying to a message opens a single additional window.

There is no way to show the connections between lots of windows, so don't create lots of windows. This is a particularly annoying problem with Visual Basic (VB) where it is easy to create forms. Forms are independent, top-level windows. In terms of behavior, they are the same as modeless dialog boxes. Creating applications as collections of several modeless dialog boxes is a questionable strategy that was never very common until VB made it easy to do. Just because it's easy to do doesn't mean it is good design. Modal dialogs always get you immediately back to the point of departure so they don't count against you, but each added window contributes more to the user's burden of window management excise. This overhead can grow to obnoxious proportions if the program is used daily.

A VB programmer once explained that his program was especially difficult to design because it had 57 forms. No program can be used effectively with 57 forms. Each form may be excellent in its own right, but collectively, it's simply too many. It's like saying you're going to taste 57 vintage Chardonnays at a sitting or test drive 57 sedans on Saturday.