List of Figures

Introduction to the Second Edition

Figure 1: Three dimensions of design. Design has traditionally focused on form and, more recently, on meaning and content. The newest dimension of design is behavior, how complex systems interact with humans.

Chapter 1: Goal-Directed Design

Figure 1-1: The evolution of the software development process. Today, design is often an afterthought. It should, instead, happen before any coding or testing begins.

Figure 1-2: Thanks for sharing. Why didn't the program notify the library? What did it want to notify the library about? Why is it telling us? Why do we care? And what are we OKing, anyway? It is not OK that the program failed!

Figure 1-3: Building successful digital products. Expanding on Keeley's triangle (left), the center diagram indicates the three major processes that need to be followed in tandem to create successful technology products. This book addresses the first and foremost issue: how to create a product people will desire.

Figure 1-4: A problematic design process. Traditionally, research and design have been separated, with each activity handled by specialists. Research has, until recently, referred primarily to market research, and design is too often limited to visual design or skin-deep industrial design. More recently, user research has expanded to include qualitative, ethnographic data. Yet, without including designers in the research process, the connection between research data and design solutions remains tenuous at best.

Figure 1-5: Bridging the gap between research and design. Three primary activities close the gap. A process of modeling that synthesizes research results into design tools, a process of synthesizing and defining requirements from these models, and a process of translating the knowledge captured in the models and requirements into a design framework that reflects the goals and needs of users, while also addressing business and technical imperatives.

Figure 1-6: The Goal-Directed Design process

Chapter 2: Implementation Models and Mental Models

Figure 2-1: The way engineers must build software is often a given, dictated by various technical and business constraints. The model for how the software actually works is called the implementation model. The way users perceive the jobs they need to do and how the program helps them do it is their mental model of interaction with the software. It is based on their own ideas of how they do their jobs and how computers might work. The way designers choose to represent the working of the program to the user is called the represented model, which, unlike the other two models, is an aspect of software over which designers have great control. One of the most important goals of the designer should be to make the represented model match the mental model of users as closely as possible. It is therefore critical that designers understand in detail the way their target users think about the work they do with the software.

Figure 2-2: Adobe Photoshop has a great example of software design to match user mental models. The Variations interface shows a set of thumbnail images, varying color balance and brightness by adjustable increments. The user can click on the image that best represents the desired color setting. This image then becomes the new default for more varied thumbnails. The interface follows the mental model of graphic artists who are after a particular look, not a set of abstract numerical values.

Figure 2-3: The ubiquitous calendar is so familiar that we rarely stop to apply information age sensibilities to its design on the screen. Calendars were originally designed to fit on stacked sheets of paper, not interactive digital displays. How would you redesign it? What aspects of the calendar are artifacts of its old, mechanical-age platform?

Figure 2-4: Scrolling is a very familiar idiom to computer users. Why not replace the page-oriented representation of a calendar with a scrolling representation to make it better? This perpetual calendar can do everything the old one can, and it also solves the mechanical-representation problem of scheduling across monthly boundaries. Don't drag old limitations onto new platforms out of habit. What other improvements can you think of?

Chapter 3: Beginners, Experts, and Intermediates

Figure 3-1: The demands that users place on software vary considerably with their experience. The tools presented to the user need to reflect this disparity. Your program won't be appreciated much if its best quality is that it is very easy for first-timers to learn, since most users will quickly become perpetual intermediates. Similarly, if only professional, full-time experts will use the product, the interface needs to cater to their unique needs.

Chapter 5: Modeling Users—Personas and Goals

Figure 5-1: A simplified example of how personas are useful. If you try to design an automobile that pleases every possible driver, you end up with a car with every possible feature, but which pleases nobody. Software today is too often designed to please too many users, resulting in low user satisfaction. Figure 5-2 provides an alternative approach.

Figure 5-2: A simplified example of how personas are useful. By designing different cars for different people with different specific goals, we are able to create designs that other people with similar needs to our target drivers also find satisfying. The same holds true for the design of digital products and software.

Figure 5-3: Personas versus market segments. Market segments can be used in the Research phase to limit the range of personas to target markets. However, there is seldom a one-to-one mapping between market segments and personas.

Figure 5-4: Mapping interview subjects to behavioral variables. This example is from e-commerce. Interview subjects are mapped across each behavioral axis. Precision of the absolute position of an individual subject on an axis is less important than its relative position to other subjects. Clusters of subjects across multiple axes indicate significant behavior patterns.

Chapter 6: Scenarios—Translating Goals into Design

Figure 6-1: Example of an early framework sketch. Framework sketches should be simple, starting with rectangles, names, and simple descriptions of relationships between functional areas. Details can be visually hinted at to give an idea of contents, but don't fall into the trap of designing detail at this stage.

Figure 6-2: Examples of storyboards from Shared Healthcare Systems' Orcas product.

Figure 6-3: Full-resolution bitmap screens for SHS Orcas based on the storyboards from the previous figure. Note that there are minor changes to the layout that naturally result from the realities of pixels and screen resolution. Visual and interaction designers need to work closely together at this stage to ensure that visual changes to the design continue to reinforce appropriate product behaviors and meet the goals of the primary personas.

Chapter 7: Synthesizing Good Design—Principles and Patterns

Figure 7-1: The primary structural pattern used by Microsoft Outlook is widely copied in the industry, across many diverse product domains. The left-vertical pane provides navigation and drives the content of the overview pane in the upper right. A selection in this pane populates the lower-right pane with detail or document content.

Chapter 8: Software Posture

Figure 8-1: Microsoft Outlook is a classic example of a sovereign posture application. It stays on screen interacting with the user for long, uninterrupted periods, and with its multiple adjacent panes for navigation and supporting information, it begs to take up the full screen.

Figure 8-2: Microsoft Word has placed controls at both the top and the bottom of the application. Those at the top are more benign than those at the bottom. The latter are segregated because they can cause significant visual dislocation.

Figure 8-3: The Windows Volume Control is a typical example of a transient application, used briefly and infrequently in the service of some more sovereign activity, and then dismissed. Microsoft could have done a bit more to reinforce this panel's transient stature by conserving white space a bit more, enlarging its controls, and using a more colorful palette to differentiate it from the sovereign application that it is likely launched on top of.

Figure 8-4: The Calculator accessory in Windows and on the Mac is another good example of a transient application, with large, obvious buttons and functions. The program can also be operated using the key-board, which is good, because the hardware-style buttons are somewhat awkward, though acceptable for infrequent use.

Figure 8-5: The status area of the taskbar in Windows XP. The mouse cursor is pointed at an icon representing a daemonic process that monitors the connection to Windows Messenger. The icon provides modeless visual status and also provides a launch-point for the Windows Messenger application. It is a variation on the axiom: Allow input wherever you have output (Chapter 10).

Figure 8-6: Microsoft has recognized the potential auxiliary role of streaming audio to Web browsing, and has integrated its audio player into a collapsible side panel in Internet Explorer. The audio controls themselves can also be popped out of the browser window as a standalone window.

Chapter 9: Orchestration and Flow

Figure 9-1: Just because programmers are accustomed to seeing messages like this, it doesn't mean that people from other walks of life are. Nobody wants his machine to scold him. If we guide our machines in a dunderheaded way, we expect to get a dunderheaded response. Sure, they can protect us from fatal errors, but scolding isn't the same thing as protecting.

Figure 9-2: In Word, if you want to know the number of words in your document, you choose Word Count… from the Tools menu. This opens a dialog box. To get back to work, you must first click the Close button on the Word Count dialog. This behavior is the opposite of modeless feedback, and it hampers flow.

Figure 9-3: This is easily the most unnecessary dialog box in the world of GUI. Of course, we want to save our work! It is the normal course of events. Not saving it would be something out of the ordinary that should be handled by some dusty dialog box. This single dialog box does more to force users into knowing and understanding the useless and confusing facts about RAM and disk storage than anything else in their entire interaction with their computer. This dialog box should never be used.

Figure 9-4: In Excel, Version 4.0, this dialog box popped up every time you pressed the delete key. This is quite reasonable if you are a computer, but if you are a human it means that you have to deal with the remote possibilities of deletion every time you try to do the high-probability clearing of the formula. Using Excel with this dialog was like listening to the symphony pause every time the conductor had to turn a page on the score. Thankfully, Microsoft fixed this in later versions.

Figure 9-5: The Windows 3.x File Manager took great pains to report the exact number of bytes used by files on the disk. Does this precision help us understand whether we need to clear space on the disk? Certainly not. Furthermore, is a seven-digit number the best way to indicate the disk's status? Wouldn't a graphical representation that showed the space usage in a proportional manner (like a pie chart) be more meaningful? Luckily, Microsoft Windows now uses pie charts to indicate disk usage.

Figure 9-6: In Windows XP, Microsoft has replaced the electric chair with lethal injection. Instead of long, inscrutable numbers at the bottom of the File Manager, you can request a properties dialog box from the Explorer. The good news is that you can finally see how your disk is doing in a meaningful, graphic way with the pie chart. The bad news is that you have to stop what you're doing and open a dialog box to see fundamental information that should be readily available. In Windows 2000, this graph was automatically displayed on the left side of the Explorer window when a disk was selected; XP's solution represents a step backward.

Figure 9-7: Imagine if you had to steer your car by clicking buttons on a dialog box! This will give you some idea of how normal people feel about the dialog boxes on your software. Humbling, isn't it?

Figure 9-8: Ejector seat levers have catastrophic results. One minute, the pilot is safely ensconced in her jet, and the next she is tumbling end-over-end in the wild blue yonder while her jet goes on without her. The ejector seat is necessary for the pilot's safety, but a lot of design work has gone into ensuring that it never gets fired inadvertently. Allowing an unsuspecting user to configure a program by changing permanent objects is comparable to firing the ejection seat by accident. Hide those ejector seat levers!

Chapter 10: Eliminating Excise

Figure 10-1: This is an ugly, useless error message box that stops the proceedings with idiocy. We can't verify or identify what it tells us, and it gives us no options for responding other than to admit our own culpability with the OK button. This message only comes up when the program is saving; that is, when we have entrusted it to do something simple and straightforward for us. The program can't even save a file without help, and it won't even tell us what help it needs.

Figure 10-2: Here is a horrible confirmation box that stops the proceedings with idiocy. If the program is smart enough to detect the difference, why can't it correct the problem itself? The options the dialog gives us are scary. It is telling us that we can explode one of two boxes: one contains garbage, and the other contains the family dog — but the program won't say which is which. And if we click Cancel, what does that mean? Will it still go ahead and explode our dog?

Chapter 11: Navigation and Inflection

Figure 11-1: Microsoft Excel makes use of tabbed panes (visible in the lower left) to let the user navigate between related worksheets. Excel also makes use of splitters to provide adjacent panes for viewing multiple, distant parts of a single spreadsheet without constant scrolling. Both these idioms help reduce navigational excise for Excel users.

Figure 11-2: Microsoft Internet Explorer for the Mac uses tabbed panes accessible with a vertical tab bar. The PC version has a similar idiom, but uses more standard toolbar controls to select which pane is visible. The Mac version more closely ties the function to the control, but requires users to tilt their heads to read the tab labels.

Figure 11-3: Adobe hides the Paint Bucket in a combutcon (see Chapter 26) on its tool palette. Even though users make frequent use of both the Gradient tool and the Paint Bucket, users are forced to access this menu any time they need to switch between these tools.

Figure 11-4: Amazon.com makes use of many persistent areas on the majority of its pages, such as the tab bar at the top and the Search and Browse areas on the sides. These not only help users figure out where they can go, but help keep them oriented as to where they are.

Figure 11-5: Adobe makes use of an excellent overview idiom: the Navigator palette, which provides a thumbnail view of a large image with an outlined box that represents the portion of the image currently visible in the main display. The palette not only provides navigational context, but it can be used to pan and zoom the main display as well.

Figure 11-6: A typical breadcrumb display from Amazon.com. Users see where they've been and can click anywhere in the breadcrumb trail to navigate to that link.

Figure 11-7: An annotated scrollbar. Marks on the scrollbar denote locations in the text, such as the highlighted passage shown here. When the thumb of the scrollbar passes over the mark, the location denoted by the mark is visible on the screen.

Figure 11-8: A stovetop with poor physical mapping of controls. Does the knob on the far-left control the left-front or left-rear burner? Users must figure out the mapping anew each time they use the stovetop.

Figure 11-9: Clear spatial mapping. On this stovetop, it is clear which knob maps to which burner because the spatial arrangement of knobs clearly associates each knob with a burner.

Figure 11-10: An example of a logical mapping problem. If the user wants to see the most recent items first, does he choose Ascending or Descending? These terms don't map well to how users conceive of time.

Figure 11-11: Clear logical mapping. Most Recent and Oldest are terms that users can easily map to time-based sorting.

Chapter 12: Understanding Undo

Figure 12-1: Microsoft's Undo/Redo facility is a little unusual. You can undo multiple actions, but only as a group; you can't choose to undo only the thing you did three actions ago. Redo works in the same manner.

Chapter 13: Rethinking Files and Save

Figure 13-1: This is the question Word asks when you close a file after you have edited it. This dialog is a result of the programmer inflicting the implementation model of the disk file system on the hapless user. This dialog is so unexpected by new users that they often choose No inadvertently.

Figure 13-2: The Save As dialog provides two functions: It lets you name your file, and it lets you place it in a directory you choose. Users, however, don't have a concept of saving, so the title of the dialog does not match their mental models of the function. Furthermore, if a dialog allows you to name and place a document, you might expect it would allow you to rename and replace a document as well. Unfortunately, our expectations are confounded by poor design.

Figure 13-3: If a user attempts to rename a file using the Explorer while Word is still editing it, the Explorer is too stupid to get around the problem. It is also too rude to be nice about it and puts up this patronizing error message. Rebuffed by both the editing program and the OS, it is easy for a new user to imagine that a document cannot be renamed at all.

Figure 13-4: The revised file menu now better reflects the user's mental model, rather than the programmer's implementation model. There is only one file, and the user owns it. If she wants, she can make tracked or one-off copies of it, rename it, discard any changes she's made, or change the file format. She no longer needs to understand or worry about the copy in RAM versus the copy on disk.

Chapter 16: Improving Data Retrieval

Figure 16-1: An example of a natural language output interface to an attribute-based retrieval engine, part of a Cooper design created for Softek's Storage Manager. These controls produce natural language as output, rather than attempting to accept natural language as input, for database queries. Each underlined phrase, when clicked, provides a drop-down menu with a list of selectable options. The user constructs a sentence from a dynamic series of choices that always guarantees a valid result.

Chapter 17: Improving Data Entry

Figure 17-1: Underneath the rhetoric of data integrity—an objective imperative of protecting the user and computer with sanctified data—there is a disturbing subtext: that humans are ill-intentioned screw-ups and that users will, given the chance, enter the most bizarre garbage possible in a deliberate attempt to bring the system to its knees. This is not true. Users will inadvertently enter erroneous data, but that is different from implying that they do it intentionally. Users are very sensitive to subtext; they will quickly perceive that the program doesn't trust them. Data integrity not only hampers the system from serving the user for the dubious benefit of easing the programmer's burden, but it also offends the user with its high-handed attitude. It's another case of requiring users to adapt to the needs of the computer, rather than the computer meeting the needs of users.

Figure 17-2: Microsoft Word's automatic spelling checker audits misspelled words with a wavy red underline, providing modeless feedback to users. Right-clicking on an underlined word pops open a menu of possible alternatives to choose from.

Chapter 19: Designing Look and Feel

Figure 19-1: Microsoft Word's Print dialog is a good example of elements meticulously aligned both vertically and horizontally in conformity with a grid. Note the group boxes around related functional elements. It is easy to get carried away with the use of these boxes, which can visually clutter the interface. The Print dialog treads a fine line. With a proper balance of white space around grouped elements, an explicit box is often not required to indicate grouping.

Figure 19-2: Eye movement across an interface should mirror the logical path through the interface that the user takes to accomplish goals and tasks.

Figure 19-3: Diagonal symmetry in Microsoft Word's Bullets and Numbering dialog. The axis of symmetry runs from lower left to upper right.

Figure 19-4: Vertical symmetry in the Macromedia Fireworks 4 tool palette.

Figure 19-5: Photo-realistic icons in Mac OS X.This level of detail in icons serves only to distract from data and function controls. In addition, although it might, in some instances, make sense to render in detail objects people are familiar with, what is the sense of similarly rendering unfamiliar objects and abstract concepts (for example, a network)? How many users have seen what a naked hard disk drive looks like (far right)? Ultimately, users must rely on accompanying text to make sense of these icons, unless they are quite frequently used.

Figure 19-6: Visual comparison. Photoshop filters provide interactive previews that allow users to compare results of an operation with the original before the operation has been executed. Some Photoshop filters permit the preview (which can be flipped on and off instantaneously by the user) to occur over the entire image, or a selection thereof, in addition to the thumbnail shown in the preceding dialog.

Figure 19-7: Showing multiple variables. This design created for Shared Healthcare Systems' Orcas long-term healthcare system allows nurses to compare and correlate trends in a single full-screen display. Nurses at long-term care facilities need to be proactive about quality of care issues. Cooper designers created a trend-analysis tool that allows nurses to choose which care issues to track and to interactively correlate them against other potentially related concerns. Graphs on the left show major trends as live thumbnails; these and other attributes can be added to the chart on the right. The sliding vertical vernier determines the day being looked at in the area below the chart, which breaks out all incidents according to affected residents. Clicking on a resident's name takes the nurse to that resident's chart.

Figure 19-8: Combining text, graphics, and data in a single display. This interface, also designed for Shared Healthcare Systems, permits case managers at long-term healthcare facilities to appropriately balance the quality of care and cost of care for new residents interactively. The ability to see what-if scenarios visually, as well as the details in text, allows the users to better and more quickly plan what's best for each new resident and her family.

Chapter 20: Metaphors, Idioms, and Affordances

Figure 20-1: Here is an idiomatic symbol that has been imbued with meaning from its use, rather than by any connection to other objects. For anyone who grew up in the 1950s and 1960s, this otherwise meaningless symbol has the power to evoke a shiver of fear because it represents nuclear radiation. Visual idioms, such as the American flag, can be just as powerful as metaphors, if not more so. The power comes from how we use them and associate them, rather than from any innate connection to real-world objects.

Figure 20-2: The Magic Cap interface from General Magic was used in products from Sony and Motorola in the mid-1990s. It is a tour de force of metaphoric design. All the navigation in the interface, and most other interactions as well, were subordinated to the maintenance of spatial and physical metaphors. It was surely fun to design, but not particularly easy to use after you became an intermediate. This was a shame, because some of the lower-level, non-metaphoric data-entry interactions were quite sophisticated and well designed for the time.

Figure 20-3: One of the primary reasons that GUIs are easy to use is that they enforce a restricted interaction vocabulary that builds complex idioms from a very small set of primitives: pointing, clicking, and dragging. These primitives can build a larger set of simple compounds, which in turn can be assembled into a wide variety of complex, domain-specific idioms, all of which are based on the same small set of easily learned actions.

Chapter 21: Direct Manipulation and Pointing Devices

Figure 21-1: The familiar scrollbar, shown on the left, is one of the more difficult-to-use GUI controls. To shift from scrolling up to scrolling down, you must transition from the fine motor control required by clicking the button to the gross motor control you need to move your hand to the opposite end of the bar. You then change back to fine motor control to accurately position the mouse and click the button again. If the scrollbar were modified only slightly, as in the center, so that the two buttons were adjacent, the problem would go away. (Macintosh scrollbars can be similarly configured to place both arrow buttons at the bottom.) The scrollbar on the right is a bit visually cluttered, but has the most flexible interaction. For more on scrollbars, see Chapter 26.

Figure 21-2: Microsoft Works Spreadsheet uses cursor hinting to highlight several controls that, by visual inspection, are not obviously pliant. The width of the individual columns and height of rows can be set by dragging on the short vertical lines between each pair of columns, so the cursor changes to a two-headed horizontal arrow hinting at both the pliancy and indicating the permissible drag direction. The same is true for the screen-splitter controls. When the mouse is over an unselected editable cell, it shows the plus cursor; and when it is over a selected cell, it shows the drag cursor. The addition of text to these cursors makes them almost like ToolTips.

Chapter 22: Selection

Figure 22-1: When the cursor is not on any particular object at mouse-down time, the click-and-drag operation normally creates a drag rectangle that selects any object wholly enclosed by it when the mouse button is released. This is a familiar idiom to users of drawing programs and many word processors. This example is taken from Windows XP, selecting files displayed within a file folder. The rectangle has been dragged from lower right to upper left.

Chapter 23: Drag and Drop

Figure 23-1: Microsoft, unfortunately, auto-scrolls at whatever speed the computer is capable of, or at least far too fast for users to control. Not only should there be a maximum speed limit on auto-scroll, the movement should also be graduated and user-controllable. The auto-scroll should go faster the closer the user gets to the edge of the window. To its credit, Microsoft's idea of auto-scrolling as the cursor approaches the inside edges of the enclosing scrollbox, rather than the outside, is very clever indeed.

Figure 23-2: Any object that can be both selected and dragged must be debounced. When the user clicks on the object, the action must be interpreted as a selection rather than a drag, even if the user accidentally moves the mouse a pixel or two between the click and the release. The program must ignore any mouse movement as long as it stays within the uncommitted zone, which extends three pixels in each direction. After the cursor moves more than three pixels away from the mouse-down coordinate, the action changes to a drag, and the object is considered "in play." This is called a drag threshold, and it is used to debounce the mouse.

Figure 23-3: This report-generator program offered an interesting feature that enabled the contents of one column to be interspersed with the contents of another by dragging and dropping it. This direct-manipulation action conflicted with the more-frequent drag-and-drop action of reordering the columns (like moving City to the left of Address). We used a special, two-axis drag threshold to accomplish this.

Figure 23-4: This spool-shaped drag threshold allowed a bias toward horizontal dragging in a client's program. Horizontal dragging was, by far, the most frequently used type of drag in this application. This drag threshold made it difficult for the user to inadvertently begin a vertical drag. However, if the user really wanted to drag vertically, a bold move either up or down would cause the program to commit to the vertical mode with a minimum of excise. Before this method was instituted, a vertical move involved a semipermanent mode change by using a toolbar butcon.

Chapter 24: Manipulating Controls, Objects, and Connections

Figure 24-1: The selected object has eight handles, one at each corner and one centered on each side. The handles indicate selection and are a convenient idiom for resizing and reshaping the object. Handles are sometimes implemented with pixel inversion, but in a multicolor universe they can get lost in the clutter.

Figure 24-2: These are vertex handles, so named because there is one handle for each vertex of the polygon. The user can click and drag any handle to reshape the polygon, one segment at a time. This idiom is useful for drawing programs, but it may have application in desktop productivity programs, too.

Figure 24-3: When a drag is constrained, usually by holding down the Shift key, the object is only dragged along one of the four axes shown here. The program selects which one by the direction of the initial movement of the mouse, an implementation of the drag threshold discussed later in the chapter.

Figure 24-4: @Last Software's SketchUp is a gem of an application that combines powerful 3D architectural sketching capability with smooth interaction, rich feedback, and a manageable set of design tools. Users can set sky color and real-world shadows according to location, orientation, and time of day and year. These not only help in presentation, but help orient the user while building. Users also can lay down 3D grid and measurement guides just as in a 2D sketching application; the protractor tool is visible above. Camera rotate and zoom functions are cleverly mapped to the mouse scroll wheel, allowing fluid access while using other tools. ToolTips provide textual hints that assist in drawing lines and aligning objects.

Chapter 25: Window Behaviors

Figure 25-1: Microsoft Excel provides an excellent example of both tabbed and adjacent panes. Inverted tabs are an unusual visual twist on the tab idiom (see Chapter 31), but seem to work well in context. Excel allows you to split your view of a single spreadsheet into multiple adjacent panes. Other applications like Outlook have completely different (but usually related) information in adjacent panes. The pane on the far right in this figure is an example of this type of adjacent pane being used for navigation and construction support.

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.

Chapter 26: Using Controls

Figure 26-1: Butcons in their flat, mouseover (raised), and clicked states on Windows 2000 (left) and XP (right). The button affordance on the left is clearer. The controls pictured are also examples of latching butcons, invented by applying the simple expedient of not letting the button pop back out after it has been clicked. What is remarkable about this idiom is that it moves the butcon idiom from the imperative category — a verb — into the selection category — a noun. It has all the idiomatic and space-saving advantages of the butcon, except that it sets state rather than invoking an immediate command.

Figure 26-2: Flip-flop button controls are very efficient. They save space by controlling two mutually exclusive options with a single control. The problem with flip-flop controls is that they fail to fulfill the second duty of every control — to inform the user of their current state. If the button says ON when the state is off, it is unclear what the setting is. If it says OFF when the state is off, however, where is the ON button? Don't use them. Not on buttons and not on menus!

Figure 26-3: Word's alignment controls are a radio butcon group, acting like radio buttons. One is always selected, and when another is clicked, the first one returns to its normal, raised position. This variant is a very space-conservative idiom that is well suited for frequently used options.

Figure 26-4: A combutcon is a group of latching butcons that behave like a combobox. Clicking the mouse button while over the combutcon's down-arrow drops down a menu of butcons. Slide the cursor down to the desired one and release. The newly selected butcon shows on the toolbar as the selected option. Think of this idiom as a way to cram many related latching butcons into the space of a single one. It creates more user excise than putting up separate butcons, but is useful when space is at a premium or when the functions are not used very frequently.

Figure 26-5: These combutcons are taken from Adobe Photoshop (left) and Microsoft Word (right). In Photoshop, the combutcon opens to the right, and includes a text description of each butcon. In the Word combutcon, clicking the butcon causes a tear-off menu to appear, which can become a floating palette. Colors are selected from the swatches at the top or from the text item, which brings up a color selection dialog. This dense packing of information, both input and output, is indicative of the direction in which superior user interfaces have moved in the last 15 years.

Figure 26-6: Selection is normally a mutually exclusive (mux) operation. When the need arises to discard mux in order to provide multiple selection, things can become confusing if some of the items can be scrolled out of sight. Earmarking is a solution to this. Put check boxes next to each text item and use them instead of selection to indicate the user's choices. Check boxes are a clearly non-mux idiom and a very familiar GUI idiom. Users grasp the workings of this idiom right away.

Figure 26-7: This dialog from Microsoft Outlook Express would benefit from the capability to drag a contact from the list at left into the To, Cc, and Bcc lists at right. Also notice the unfortunate use of horizontal scrollbars in all list fields. In the left-hand field, in particular, ToolTips could show the full row of information in the left-hand box.

Figure 26-8: A bounded control lets you enter only valid values. It does not let you enter invalid values, only to reject them when you try to move on. This figure shows a bounded slider control from the Display Settings dialog in Windows 95. The little slider has four discrete positions. As you drag the slider from left to right, the legend underneath it changes from "640 by 480 pixels" to "800 by 600 pixels" to "1024 by 768 pixels" to "1280 by 1024 pixels." Why didn't they use a combobox? Which would you prefer?

Figure 26-9: The Page Setup Dialog from MS Word makes heavy use of the spinner control. On the left side of the dialog, you see a stack of seven of these new controls, whose popularity is growing fast. By clicking on either of the small, arrowed buttons, the specific numeric value is made to increase or decrease in small, discrete steps. If the user wants to make a large change in one action or to enter a precise setting, he can use the edit field portion for direct text entry. The arrow button portion of the control embodies bounding, whereas the edit field portion does not. Does that make this a bounded control?

Figure 26-10: The ToolTip idiom is so effective that it could easily be extended to other uses. Instead of yellow ToolTips offering flyover labels for butcons, we could have pink ones offering flyover hints for unbounded edit fields. These clue boxes could also help eliminate error message boxes. In this example, if the user enters a value lower than allowable, the program could replace the entered value with the lowest allowable and display the cluebox that modelessly explains the reason for the substitution. The user can enter a new value or accept the minimum without being stopped by an error dialog.

Figure 26-11: The drop-down combobox makes an excellent tool for bounded entry fields because it can accommodate entry values other than numbers. The user doesn't have to remember or type words like Page Width or Whole Page because they are there to be chosen from the drop-down list. The program interprets the words as the appropriate number, and everyone is satisfied.

Chapter 27: Menus—The Pedagogic Vector

Figure 27-1: The original Lotus 1-2-3, which first shipped in 1979, exhibited a remarkable new menu structure that actually coexisted with the working screen of the program. All other menu-based programs at that time forced you to leave the working screen to make menu selections. Like all great ideas, this one was invisible in foresight and obvious in hindsight.

Figure 27-2: A menu item reading Format Gallery is likely to be more enlightening to new users than a butcon like this one. But after they become intermediates, it's a different story altogether.

Chapter 28: Using Menus

Figure 28-1: The File menu from Microsoft Word shows off the excellent Most Recently Used (MRU) list. In Chapter 13, you saw how to reconstruct the first six items so that they better reflect the user's mental model, rather than following the technically faithful implementation model as shown here.

Figure 28-2: This is a cascading menu in Microsoft Word. Hierarchies make logical sense to the programmers, but rarely to users. Cascades also demand considerable skill with a mouse, which will frustrate infrequent users. Microsoft and most major software vendors keep to the standard of no more than one level of cascading menu. One other mitigating factor in this example: The cascaded items are also available from butcons, so there is an immediate alternative provided to cascading-menu access. This figure also shows examples of menu items in their disabled state.

Figure 28-3: An expanding menu from PowerPoint in Windows XP, before and after expansion. Expanding menus get just about everything wrong, interaction-wise; they are even more annoying than cascading menus. They hide information in menus, subverting the pedagogic vector; they change the ordering of menu items, disrupting motor memory of menu item location. In the expanded menu, the slightly darker shade of gray on the left indicates, rather subtly, those items that are not on the contracted version of the menu. Luckily, expanding menus can be turned off completely.

Figure 28-4: Microsoft PowerPoint offers us a regular smorgasbord of menu idioms. The Insert menu shows us separators, cascading menus, mnemonics, accelerators, and menu icons. As you can see, the icons are the same as those on butcons that perform the identical tasks. What a wonderful way to build learning into the interface without seeming pedantic or intrusive!

Chapter 29: Using Toolbars and ToolTips

Figure 29-1: Microsoft's ToolTips were the solution to the toolbar problem. Although toolbars are for experienced users, sometimes these users forget the purpose of a less-frequently used command. The little text box that pops up as the cursor rests for a second is all that is needed to remind the user of the butcon's function. The ToolTip succeeds because it respects the user by not being pedantic and by having a very strongly developed respect for the value of pixels. ToolTips were the gate that allowed the toolbar to develop as the primary control mechanism in sovereign applications, while letting the menu fall quietly into the background as a purely pedagogic and occasional-use command vector.

Figure 29-2: The development of the toolbar soon led to an extension of its purpose. It evolved from a mere repository of imperative command buttons to a place where controls could indicate the state of the currently selected item. This is a more object-oriented concept, and it makes our software more powerful. The toolbar has become the place for control innovation, far beyond what we have come to expect from dialog boxes. This image shows part of a toolbar from Microsoft PowerPoint XP. You can see the toolbar drag control, comboboxes, and latching butcons, retaining a state after the user releases the mouse button (see Chapter 26).

Figure 29-3: Toolbars now contain drop-down lists. This example is from the Undo control in Word 2000. Irony of ironies, the drop-down menu has migrated onto the toolbar, which began as a refutation of the old-fashioned drop-down menu bar!

Figure 29-4: Toolbars can be docked horizontally (top), vertically (left), and dragged off the toolbar to form a free-floating palette. It's almost always preferable to use dockable palettes like these, rather than forcing users to perform windows management on undockable palettes. Complex palettes may not be able to organize themselves into toolbar-like strips, but should still be dockable against the sides of the sovereign window.

Figure 29-5: Microsoft's clever way of allowing users to overlap toolbars, but still get at all their functions. This provides a very lightweight kind of customization; power users would more likely perform full toolbar customization to address similar needs via the Customize .. item at the bottom of the drop-down menu.

Chapter 30: Using Dialogs

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?

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.

Figure 30-3: The Font dialog box in Word is a properties dialog. It reflects all the typographic characteristics of the current selection. When the user manipulates controls in this dialog, the typographic qualities of the selection change in the preview area, but not in the document until the OK button is clicked. The operation is essentially one of configuration. The preview box is great, but why can't the font field in the upper-left corner use the actual fonts, too?

Figure 30-4: The Insert Picture dialog box from Word is a function dialog box. It is quintessentially modal, allowing the user to first configure the function by choosing a file. Nothing happens, however, until the OK button is clicked. The dialog does not have an effect on an object, but rather performs an operation.

Figure 30-5: Microsoft got this one mostly right. For any move, copy, or delete operation in this Explorer, they show this reasonably well-designed process dialog box. It provides a hint of the time remaining in the operation, and the dialog uses animation to show paper documents flying out of the folder on the left into the folder (or wastebasket) on the right. The user's mental model is one of things moving inside the computer, and this little gem actually shows things moving. It is refreshing to see the outside of the computer reflect the inside of the computer in users' terms. The one thing missing is a countdown of the number of files left to move, which would provide even better feedback about the process at hand.

Figure 30-6: Here's a typical bulletin dialog box. It is never requested by the user, but is always issued unilaterally by the program when the program fails to do its job or when it just wants to brag about having survived the procedure. The program decides that it is easier to blame the user than it is to go ahead and solve the problem. Users interpret this as saying, "The measurement must be between −22 inches and 22 inches, and you are an incredible buffoon for not knowing that basic, fundamental fact. You are so stupid, in fact, that I'm not even going to change it for you!"

Chapter 31: Dialog Etiquette

Figure 31-1: Here is a properties dialog box from CompuServe Navigator for Windows (v1.0). The sprawling check boxes consume a lot of space. At least it has a title bar, so you can move it out of the way. Also note the poor placement of the OK button at the far left rather than at the right.

Figure 31-2: A typical function dialog box from Microsoft Word shows an excellent use of space. The controls are compact and very conservative of space. Compare this with the previous figure (Figure 31-1). Notice, also, Microsoft's willingness to use graphic objects instead of just canned, text-based controls like edit fields, check boxes, and push-buttons. Note the odd placement of the termination controls in the upper-right. In this case, the designer might have taken space efficiency a tiny bit too far.

Figure 31-3: This Properties modal dialog box from Windows XP shows how Microsoft has finally realized that Help is not a terminating command. It removed it from the suite of terminating buttons and put it on the title bar near the Close box. This is certainly an improvement, but then Microsoft went ahead and added another control to the terminating-button row: Apply. There is no use for an Apply function on this tab pane, but it is applicable on the Sharing pane. Why not put the Apply button on the pane where it means something and keep it out of the way of the terminating buttons?

Figure 31-4: This is a tabbed dialog box from Microsoft Word. Combining borders and shading on one dialog box makes sense, if you have a convenient way to do it. Tabbing provides the way. Note that the designer correctly put the terminating controls outside the tabbed pane, in the lower-right. It would be best if the OK button were the right-most button (Apple has advocated this from the start, but Microsoft just has to be different).

Figure 31-5: The Options dialog in Word is an extreme example of what can be done with tabs. There is certainly a lot crammed into this one dialog, which is good. The problem is that the tabs move around! The active tab must be on the bottom row, so if you click on Spelling and Grammar, for example, that row rolls down to the bottom and the other row rises to the top. Everybody hates it when the tabs move underneath the cursor. It's better just to break this up into smaller dialogs.

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.

Figure 31-7: Word's Customize dialog box is an example of a dynamic dialog box. Depending on what you select in the Categories list box control, the Command list box to its right will contain controls (as shown), macros, font names, or other items.

Chapter 32: Creating Better Controls

Figure 32-1: The New Contacts dialog in Outlook includes some extraction controls; look at the Full Name and Address fields in the main dialog. If you want to check the results, you can click the Full Name or Address buttons (which double as field labels), to get the dialogs that are shown. Outlook has correctly parsed one of the author's name and address—but couldn't it all have been entered into a single field?

Figure 32-2: The Layers Palette in Photoshop is an exemplary use of visual controls, especially the use of actual thumbnail images of the layers themselves, which update in real time as changes are made to them. The palette is not only able to pack a huge amount of usable functionality into a small space, but the visual nature of the controls is also appropriate for the user base of the application: artists, photographers, and other visual thinkers.

Figure 32-3: The time zone dialog box in Windows 95 is an excellent visual control. It shows the selections available to the user attractively and graphically. If you live on the East Coast of the US, for example, all you need to do is click somewhere along the eastern seaboard and the map smoothly scrolls until the Eastern US is centered and highlighted. The animation speeds up and slows down so nicely that the effect is almost sensual. It's like walking into the lobby of someone's office and finding marble, walnut, and leather instead of stucco and plywood. If you want to add a sense of aesthetics to your program, make them tactile aesthetics. Why Microsoft removed this interaction in the next OS release remains a mystery.

Chapter 33: Eliminating Errors

Figure 33-1: No matter how nicely your error messages are phrased, this is how they will be interpreted.

Figure 33-2: This is how most users perceive error message dialog boxes. They see them as Kafkaesque interrogations with each successive choice leading to a yet blacker pit of retribution and regret.

Figure 33-3: Just as there is rarely a good reason to ever use a GOTO statement in your code, there is rarely a good reason to ever issue an error message box. However, just as programmers occasionally compromise with one or two convenient GOTOs, they might occasionally issue an error message. In that case, your error message should look something like this one. It politely illuminates the problem for the user, offering him help in extricating the program from its dilemma. This error bulletin has four sections (labeled “Please take note, Scope, Action, and More) that clearly help the user understand the options available and why he might choose each. The program is intelligent enough not to lose the file just because the volume became unavailable. The dialog offers an alternative action to the user by way of the Save As…button.

Chapter 34: Notifying and Confirming

Figure 34-1: Here is a typical alert dialog box. It is unnecessary, inappropriate, and stops the proceedings with idiocy. The Find dialog in Word has finished searching the document. Is reporting that fact a different facility of Word? If not, why does it use a different dialog? It's like having to go into the dining room to use a fork and the kitchen to use a spoon. The "information" icon is a sure tip-off to clumsy interface design. Yes, software must constantly and effusively report its status to the user. But proceedings-stopping alert dialogs are an inappropriate mechanism.

Figure 34-2: This dialog, from Delrina WinFax Lite, is unnecessarily obsequious. We add an entry to our phone book, and are promptly stopped in our tracks by this important message. Do we really need the program to waste our time elaborating the obvious?

Figure 34-3: Every time we delete a file in Windows, we get this confirmation dialog box asking if we're sure. Yes, we're sure. We're always sure. And if we're wrong, we expect Windows to be able to recover the file for us. Windows lives up to that expectation with its Recycle Bin. So why does it still issue the confirmation message? When a confirmation box is issued routinely, users get used to approving it routinely. So when it eventually reports an impending disaster to the user, he goes ahead and approves it anyway, because it is routine. Do your users a favor and never create another confirmation dialog box.

Figure 34-4: If you click the Delete button in the Style dialog box in Word, you get this confirmation box. Most people will click Yes, by rote, regardless of whether that's what they really mean to do. In the Style dialog, you might occasionally inadvertently delete a style you really want to keep. This confirmation, however, doesn't do much to prevent that, nor does it allow recovery. If its appearance were based on some criteria other than simply asking for a deletion, there is some faint chance that it would be useful. Promise that you won't ever create one of these, please?

Figure 34-5: This dialog provides too little help too late. What if the program could display the printable region right in the main interface as dotted guides? There's no reason for users to be subjected to dialogs like these.

Figure 34-6: This pane from a Cooper design for a long-term healthcare information system is a good example of RVMF. The diagram is a representation of all the rooms in the facility. Color-coding indicates male, female, empty, or mixed-gender rooms; numbers indicate empty beds; tiny boxes between rooms indicate shared bathrooms. Black triangles indicate health issues, and a tiny "H" means a held bed. This RVMF is supplanted with ToolTips, which show room number, names of the occupants of the room, and highlight any important notices about the room or the residents. A numeric summary of rooms, beds, and employees is at the top. This display has a short learning curve. Once mastered, it allows nurses and facility managers to understand their facility's status at a glance.

Chapter 35: Other Communication with Users

Figure 35-1: This About box from PowerPoint is a typical example of Microsoft's approach. It tells you the exact name and version of the program, states relevant copyrights, issues legal warnings (ugh!), and displays the user's name and company. The program's icon is traditionally shown in the upper-left corner. The problem is, if a friend asked you to tell her about PowerPoint, you probably wouldn't recite the relevant copyrights, but would instead describe to her what the program is about. What's wrong with this picture?

Chapter 36: The Installation Process

Figure 36-1: This is a typical installation program's first dialog box. As when you play a video game, you have only your wits to guide you. Is a full installation too much for me to handle? Am I smart enough to customize this program? Does it make me a wimp if I choose a minimum installation?

Figure 36-2: A good installer is aware of the fact that its software has already been installed and offers maintenance and removal functionality if it is launched under those circumstances. This installer could be a bit more helpful in providing useful information up front, like which files are installed and where, how much space is taken up by them, and how much is available. (This information is shown on later screens, but users need it early to make informed decisions.) Mostly, however, this installer has the right idea. InstallShield's wizard at least gives users the ability to retrace their steps or cancel if they decide they don't want to go through with an install or uninstall.

Chapter 37: Designing for the Web

Figure 37-1: Microsoft Outlook Web Access, a good example of a sovereign Web application running in a browser. In the case of OWA, use of a browser as a container makes perfect sense because the purpose of the product is to allow access to Outlook from a computer with an Internet connection. Enterprise applications for which this need is not important or practical for users may consider using Internet-enabled technologies outside the browser. These might better support the rich interactivity and client-side processing and storage that are difficult or impossible to support with browser-based applications. Designers of browser-based sovereign Web applications should also consider hiding the standard browser controls. Use of the browser's Back and Forward buttons can produce unpredictable results in Web applications, and eliminating them from the user's view helps reinforce the mental model of an application versus a Web page. Creating a link on the user's desktop or the browser's Links toolbar can help solve the problem of initial access.

Chapter 38: Designing for Embedded Systems

Figure 38-1: A Cooper design for a smart desktop phone, exhibiting strong integration of hardware and software controls. Users can easily adjust volume/speakerphone, dial new numbers, control playback of voicemail messages with hardware controls, and manage known contacts/numbers, incoming calls, call logs, voicemail, and conferencing features using the touch screen and thumbwheel. Rather than attempt to load too much functionality into the system, the design focuses on making the most frequent and important phone features much easier to use. Note the finger-sized regions devoted to touchable areas on the screen and use of text hints to reinforce the interactions.