“lost” the program and must start over. Problems like these prompted Microsoft to
26_084113 ch20.qxp 4/3/07 6:09 PM Page 427
Chapter 20: Window Behaviors
427
introduce the taskbar and Apple to invent Expose, which is an attractive and usable way to keep track of open windows (though its lack of integration with applications minimized to the Dock is more than a bit problematic).
Another part of the confusion regarding overlapping windows comes from several other idioms that are also implemented using an overlapping window. The familiar dialog box is one, as are menus and floating tool palettes. Such overlapping within a single application is completely natural and a well-formed idiom. It even has a faint but resonant metaphoric trace: that of someone handing you an important note.
Microsoft and Tiled Windows
In the grand tradition of focusing on the most visible aspect of the new PARC GUI, Bill Gates hastily cobbled together a response to the Macintosh’s success and named it “Windows.”
The first version of Microsoft Windows diverged somewhat from the pattern established by Xerox and Apple. Instead of using overlapping rectangular windows to represent the overlapping sheets of paper on one’s desktop, Windows 1.0 relied on what was called tiling to allow users to have more than one application onscreen at a time. Tiling meant that applications would divide up the available pixels in a uniform, rectilinear tessellation, evenly parsing out the available space to running programs. Tiling was invented as an idealistic means to solve the orientation and navigation problems caused by overlapping windows. Navigation between tiled windows is much easier than between overlapped windows, but the cost in pixels is horrendous. And besides, as soon as the user moves neatly tiled windows, he is thrust right back into overlapping window excise (see Chapter 11). Tiling died as a mainstream idiom, although it can still be found in the most interesting places: Try right-clicking on the current Windows taskbar.
Full-Screen Applications
Overlapping windows fail to make it easy to navigate between multiple, running programs; so other vendors continue to search for new ways to achieve this. The virtual desktop of session managers on some Unix-based platforms extends the desktop to six times the size of the visible window. (Apple has recently introduced something similar in Mac OS X.) In a corner of the screen are small, superimposed, thumbnail images of all six desktop spaces, all of which can be running different things simultaneously and each of which can have many open windows. You switch between these virtual desktops by clicking on the one you want to make active. In
26_084113 ch20.qxp 4/3/07 6:09 PM Page 428
428
Part III: Designing Interaction Details
some versions, you can even drag tiny window thumbnails from one desktop to another.
Microsoft braved a double-barreled, breach-of-contract and patent-infringement lawsuit from Apple in order to add overlapping to Windows 2.0. In all this contro-versy, the basic problem seemed to have been forgotten: How can a user easily navigate from one program to another? Multiple windows sharing a small screen —
whether overlapping or tiled — is not a good general solution (although it certainly may have its occasional uses). We are moving rapidly to a world of full-screen programs. Each application occupies the entire screen when it is “at bat.” A tool like the taskbar borrows the minimum quantity of pixels from the running application to provide a visual method of changing the lineup. (Amusingly, this concept is similar to the early days of the Mac with its Switcher, which would toggle the Mac display between one full-screen application and another.) This solution is much more pixel-friendly, less confusing to users, and highly appropriate when an application is being used for an extended period of time. In Mac OS X and Windows XP and Vista, users have the choice of making their applications full-screen or overlapping.
Contemporary software design often begins with the assumption that the user interface will consist of a series of overlapping windows, without modes, informed by a global metaphor. The PARC legacy is a strong one. Most of what we know about modern graphical user interface design came from these origins, whether right or wrong. But the well-tempered designer will push the myths aside and approach software design from a fresh viewpoint, using history as a guide, not as a mandate.
Multipaned Applications
It turns out that there is an idiom that takes the best elements of tiled windows and provides them within a sovereign, full-screen application — the idiom of multipaned windows. Multipaned windows consist of independent views or panes that share a single window. Adjacent panes are separated by fixed or movable dividers or splitters. (We discuss splitters more in Chapter 21.) The classic example of a multipaned application is Microsoft Outlook, where separate panes are used to display the list of mailboxes, contents of the selected mailbox, a selected message, and upcoming appointments and tasks, all on one screen (see Figure 20-1).
26_084113 ch20.qxp 4/3/07 6:09 PM Page 429
Chapter 20: Window Behaviors
429
Figure 20-1 Microsoft Outlook 2007 is a classic example of a multipaned application. The far-left pane includes a list of mailboxes, as well as providing the ability to switch between views such as Mail and Calendar. The top-center pane shows all the messages in the selected mailbox, while the pane below it shows the contents of the selected message. The pane on the right shows the next three appointments and upcoming tasks.
The advantage of multipaned windows is that independent but related information can be easily displayed in a single, sovereign screen in a manner that reduces navigation and window management excise to almost nil. For a sovereign application of any complexity, adjacent pane designs are practically a requirement. Specifically, designs that provide navigation and/or building blocks in one pane and allow viewing or construction of data in an adjacent pane seem to represent an efficient pattern that bears repeating.
The concept of adjacent panes was also adopted on the Web in the form of frames, but thanks to a poorly designed implementation out of the gate and a standards war between then preeminent Netscape and Microsoft, frames have been tainted as awkward and complex. Hopefully, as Web technologies progress and highly interactive Web applications become more prevalent, the concept behind frames will reemerge inside the browser (the browsers themselves already make use of multiple
26_084113 ch20.qxp 4/3/07 6:09 PM Page 430
430
Part III: Designing Interaction Details
panes). To some extent, current client-side technology approaches (such as AJAX
and Flash) and can already deliver pane-like behaviors.
Another form of multiple panes are stacked panes or tabs. Although these are seen most frequently in dialogs (see Chapter 24), they are also sometimes useful in sovereign windows. A good example of this is Microsoft Excel, which allows related spreadsheets to be accessible via inverted tabs at the bottom of the screen. Excel makes use of stacked panes with its “Sheets.”
Designing with Windows
Our programs are constructed of two kinds of windows: main windows and subordinate windows (like documents and dialog boxes). Determining how to use windows in an application is an important aspect of defining a Design Framework (see Chapter 7).
Unnecessary rooms
If we imagine our application as a house, each window is a separate room. The house itself is represented by the application’s main window, and each room is a pane, document window, or dialog box. 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 application unless they have a purposes that can’t or shouldn’t be served by existing windows.
It’s important to think through this question of purpose from prospective users’
goals and mental models. The way we think about it, saying that a room has a purpose implies that using it is associated with a goal, but not necessarily with a particular task or fun
ction.
DESIGN
A dialog box is another room; have a good reason to go there.
principle
For example, in Adobe Photoshop, if you’d like to change the brightness and contrast of a photo, you must go to the Image menu, select the Adjustments submenu, and then select the Brightness/Contrast command. This triggers a dialog box, where you can make your adjustments (see Figure 20-2). This sequence is so commonplace that it is completely unremarkable, and yet it is undeniably poor design.
Adjusting the image is the primary task in a photo editing program. The image is in the main window, so that’s where the tools that affect it should be also. Changing
26_084113 ch20.qxp 4/3/07 6:09 PM Page 431
Chapter 20: Window Behaviors
431
the brightness and contrast isn’t a tangential task but one quite integral to the purpose of the application.
Putting functions in a dialog box emphasizes their separateness from the main task.
Putting the brightness and contrast adjustment in a dialog box works just fine, but it creates an awkward interaction. From a programmer’s point of view, adjusting brightness and contrast is a single function, independent of many other functions, so it seems natural to segregate it into its own container. From a user’s point of view, however, it is integral to the job at hand and should be obvious in the main window.
Things have improved considerably in Adobe Lightroom. The application is divided into views or “rooms,” each concerned with a specific purpose: Library, Develop, Slideshow, Print, and Web. In Develop, brightness and contrast adjustment are presented in a pane on the right side of the main window, along with every other imaginable way of adjusting an image (see Figure 20-3).
Figure 20-2 One of Adobe Photoshop’s many rooms: Brightness & Contrast.
We’re all used to the fact that we have to invoke a dialog to perform a basic function, so we hardly notice it. But this creates unnecessary work for users, and of course the dialog obscures the most important thing on the screen — the image.
26_084113 ch20.qxp 4/3/07 6:09 PM Page 432
432
Part III: Designing Interaction Details
Figure 20-3 Adobe Lightroom shows vast improvements over Photoshop. Critical tools are grouped by purpose and presented directly in the main window, adjacent to the image being adjusted.
DESIGN
Provide functions in the window where they are used.
principle
This is one of the most frequently violated principles in user-interface design. Programmers often work by breaking down the application into discrete functions, and the user interface is often constructed in close parallel. Combine this with the incredible ease with which programmers can implement a dialog box, and the obvious 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.
26_084113 ch20.qxp 4/3/07 6:09 PM Page 433
Chapter 20: Window Behaviors
433
Necessary rooms
When you want to go swimming, it would be odd if you were offered a living room full of people 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 outside their normal sequence of events, it’s usually desirable to 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 application 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 a 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 arranges his tools on his drawing board, close at hand. They 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. Users shouldn’t have to go to the menu or to dialog boxes to access these tools.
For example, Corel Painter 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, you decide 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 immediately related to drawing. The clip art directory is clearly not congruent with the
26_084113 ch20.qxp 4/3/07 6:09 PM Page 434
434
Part III: Designing Interaction Details
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 drawing application, 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 you’re done creating the artwork, you’ve achieved your initial goal of creating an effective image. At this point, your goals change. Your 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, so he stores them in a closet. In the software equivalent of this process, you end the drawing program, put away your drawing tools, find an appropriate place on the hard drive to store the image, and send it to someone else via electronic mail. These functions are clearly separated from the drawing process by goals and motivations.
By examining users’ goals, we are naturally guided to an appropriate form for the application. 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.
Achievi
ng 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. CompuServe Navigator, shown in Figure 20-4, is the case in point.
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.
26_084113 ch20.qxp 4/3/07 6:09 PM Page 435
Chapter 20: Window Behaviors
435
Figure 20-4 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: Users had to put every window away individually, in the reverse order of opening them.
DESIGN
The utility of any interaction idiom is context-dependent.
principle
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 ex post facto: the 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.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 58