Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf)

by About Face 3- The Essentials of Interaction Design (pdf)

  26_084113 ch20.qxp 4/3/07 6:09 PM Page 436

  436

  Part III: Designing Interaction Details

  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. Each window added contributes more to users’ burden of window management excise. This overhead can grow to obnoxious and painful 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 with 57 forms can be used effectively.

  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 bottles of vintage Bordeaux at a sitting or test drive 57 sports cars on Saturday.

  Window States

  Programmers typically call an application’s primary window its top-level window. Each top-level window can be in one of three states (in Windows, Mac OS X, and some Unix GUI platforms), depending on how they are programmed. Oddly, only two of these three states have been given names by Microsoft: minimized and maximized.

  In Unix GUIs like Motif, and on pre-95 versions of Windows, minimized windows were shrunk to boxy icons (usually larger than normal desktop icons) that stacked on the desktop. Starting with Windows 95, minimizing a window collapses the window into the button that represents it on the taskbar. In Mac OS X, minimizing a window collapses it into the Dock.

  Maximized windows fill the entire screen, covering up whatever is beneath them.

  Apple refers to the button that activates this state as the Zoom button, but doesn’t seem to have a term for the actual state. Microsoft and Apple both somehow manage to avoid directly referring to the third state, and the only hint of a name is on the Microsoft system menu (click the upper-left corner of the title bar to see it) where the verb Restore describes how to get to it. This function restores a maximized top-level window to that other state. In the interests of sanity, we will call this third state pluralized, although it has also been called restored.

  The pluralized state is that in-between condition where the window is neither an icon nor maximized to cover the entire screen. When a window is pluralized, it

  26_084113 ch20.qxp 4/3/07 6:09 PM Page 437

  Chapter 20: Window Behaviors

  437

  shares the screen with icons and other pluralized windows. Pluralized windows can be either tiled or overlapping.

  Back in the days of Windows 1.0, the states of minimization and maximization were called iconized and zoomed, terms that were more descriptive and certainly more engaging. IBM, then enjoying a cozy relationship with Microsoft, demanded the change to corporate-speak in the mistaken impression that America’s executives would feel more comfortable. The weaker appellations have stuck.

  The normal state for a sovereign application is the maximized state. There is little reason for such a program to be pluralized, other than to support switching between programs or dragging and dropping data between programs or documents (the latter could be cleverly accomplished using a toolbar control instead).

  Some transient applications, like Windows Explorer, the calculator, and iTunes are appropriately displayed in a pluralized window.

  MDI versus SDI

  About 20 years ago, Microsoft began proselytizing a new method for organizing the functions in a Windows application. The company called this the multiple document interface, or MDI. It satisfied a need apparent in certain categories of applications, namely those that handled multiple instances of a single type of document simultaneously. Notable examples were Excel and Word.

  Microsoft backed up its new standard with code built into the operating system, so the emergence of MDI as a standard was inevitable. For a time in the late 1980s and early 1990s, MDI was regarded by some at Microsoft as a kind of cure-all patent medicine for user interface ills. It was prescribed liberally for all manner of ailments.

  These days, Microsoft has turned its back on MDI and embraced single document interface, or SDI. It seems that MDI didn’t fix all the problems after all.

  If you want to copy a cell from one spreadsheet and paste it to another, opening and closing both spreadsheets, in turn, is very tedious. It would be much better to have two spreadsheets open simultaneously. Well, there are two ways to accomplish this: You can have one spreadsheet program that can contain two or more spreadsheet instances inside of it. Or you can have multiple instances of the entire spreadsheet program, each one containing a single instance of a spreadsheet. The second option is technically superior but it demands higher-performance equipment.

  In the early days of Windows, Microsoft chose the first option for the simple, practical reason of resource frugality. One program with multiple spreadsheets

  26_084113 ch20.qxp 4/3/07 6:09 PM Page 438

  438

  Part III: Designing Interaction Details

  (documents) was more conservative of bytes and CPU cycles than multiple instances of the same program, and performance was a serious issue then.

  Unfortunately, the one-instance-multiple-documents model violated a fundamental design rule established early on in Windows: Only one window can be active at a time. What was needed was a way to have one program active at a time along with one document window active at a time within it. MDI was the hack that implemented this solution.

  Two conditions have emerged in the years since MDI was made a standard. First, well-meaning but misguided programmers tragically abused the facility. Second, our computers have gotten much more powerful — to the point where multiple instances of programs, each with a single document, are very feasible. Thus, Microsoft has made it clear that MDI is no longer politically correct, if not actually doomed.

  The winds of change at Microsoft notwithstanding, MDI is actually reasonable enough, as long as it is not abused. In particular, it is useful when users need to work on multiple related views of information in a single environment. While it’s not terribly inconvenient to switch between instances of Word to go back and forth between different documents, you wouldn’t want a purchasing agent to have to switch between multiple instances of his enterprise system to look at an invoice and the billing history for a vendor. These things may be used together for a single purpose, in which case, they should be presented together.

  Of course, this can be abused. The CompuServe Navigator program offered a dozen or more different types of document windows, making it very difficult to understand what was going on (and AOL still does this today). To accomplish a goal in SAP’s R3 ERP system, a user may have to open 10 windows. Confusion sets in as functions lose their sharp edges, and navigation becomes oppressive. As document windows of different types are selected, the menus must change to keep up. Users depend on the permanency of menus to help keep them oriented on the screen.

  Changing the menus bleeds away this reliability. Further, everything described in our earlier discussion about minimizing, maximizing, and pluralizing windows goes double for document windows inside an MDI application. Users are forced to manage little windows inside a big window, a truly heinous example of excise. It can be much better to go cleanly from one window to the next. Going from one fully maximized spreadsheet to another fully maximized spreadsheet is powerful and effective.

  Today there is little effective difference between MDI and SDI, as Microsoft implements them. In most Microsoft applications, you can go either to the Window menu or the taskbar to change from spreadsheet to spreadsheet, and you can go to the taskbar to change from Excel to Word.

  27_084113 ch21.qxp 4/3/07 6:10 PM Page 439

 
21

  Controls

  Controls are manipulable, self-contained screen objects through which people interact with digital products. Controls (otherwise known as widgets, gadgets, and gizmos) are the primary building blocks for creating a graphical user interface.

  Examined in light of users’ goals, controls come in four basic flavors: imperative controls, used to initiate a function; selection controls, used to select options or data; entry controls, used to enter data; and display controls, used to directly manipulate the program visually. Some controls combine one or more of these flavors.

  Most of the controls that we are familiar with are those that come standard with Windows, the Mac OS, and other common windowing interfaces. This set of canned controls has always been very limited in scope and power.

  Avoiding Control-Laden Dialog Boxes

  The easiest thing to build in most windowing systems is a dialog box. The dialog box facility offers automatic tools for specifying how and where controls will be placed.

  Unfortunately, it’s quite easy for developers to create user interfaces composed mostly of control-laden dialog boxes. It’s much more difficult to create a visual interface with direct manipulation idioms that are consistent with user mental models and workflows. As a result, most existing literature covers the canned-control world reasonably well, while ignoring other approaches. However, control-laden dialog

  27_084113 ch21.qxp 4/3/07 6:10 PM Page 440

  440

  Part III: Designing Interaction Details

  boxes are not the key to successful user-interface design. (For more about the strengths of a user interface based around direct manipulation, see Chapter 19. For more about dialogs boxes, see Chapter 24.)

  A multitude of control-laden dialog boxes doth not a good user

  DESIGN

  principle

  interface make.

  To be clear, we’re not suggesting the elimination of standard controls. However, while using these controls in your designs may guarantee ease of implementation, it absolutely won’t guarantee ease of use. Controls must be used appropriately and judiciously, like all elements of a good user interface.

  We’ll now look at each of the four types of controls — imperative, selection, entry, and display — in more detail.

  Imperative Controls

  In the interaction between humans and computers, there is a language of nouns (sometimes called objects), verbs, adjectives, and adverbs. When we issue a command, we are specifying the verb — the action of the statement. When we describe what the action will affect, we are specifying the noun of the sentence. Sometimes we choose a noun from an existing list, and sometimes we enter a new one. We can modify both the noun and the verb with adjectives and adverbs, respectively.

  The control type that corresponds to a verb is called the imperative control because it commands immediate action. Imperative controls take action, and they take it immediately. Menu items (which we discuss in Chapter 22) are also imperative idioms. In the world of controls, the quintessential imperative idiom is the button; in fact, it is the only one, although it comes in numerous guises. Click the button and the associated action — the verb — executes immediately.

  Buttons

  Buttons are most often identified by their simulated-3D raised aspect (see Figure 21-1). If the control is rectangular (or sometimes oval) and appears raised (due to its shadow on the right and bottom and highlight on the top and left), it has the visual affordance of an imperative. It will execute as soon as a user clicks and releases it with the mouse cursor. In dialogs, a default button is often highlighted to indicate the most reasonable typical action for a user to take.

  27_084113 ch21.qxp 4/3/07 6:10 PM Page 441

  Chapter 21: Controls

  441

  Figure 21-1 Standard buttons from Microsoft Windows (on the left) and Apple OS X (on the right). The use of shading and highlights suggest dimensionality, which gives these buttons affordance or clickability.

  The button is arguably the most visually compelling control in the designer’s toolkit. It isn’t surprising that it has evolved with such diversity across the user interface. The manipulation affordances of contemporary faux three-dimensional buttons have prompted their widespread use. It’s a good thing — so why not use it a lot?

  Part of the affordance of a button is its visual pliancy, which indicates its “press-ability.” When a user points to it and clicks the mouse button, the button onscreen visually changes from raised to indented, indicating that it is activated. This is an example of dynamic visual hinting, as discussed in Chapter 19. Poorly designed programs and many Web sites contain buttons that are painted on the screen but don’t actually move when clicked. This is cheap and easy for the developer to do (especially on the Web), but it is very disconcerting for users, because it generates a mental question: “Did that actually do something?” Users expect to see the button move — the pliant response — and you must satisfy those expectations.

  Butcons

  With the release of Windows 3.0 came the introduction of the toolbar (which we discuss at length in Chapter 23), an idiom that has grown into a de facto standard as familiar as the menu bar. To populate the toolbar, the button was adapted from its traditional home on the dialog box. On its way, it expanded significantly in function, role, and visual aspect.

  On dialog boxes, the button is rectangular (with rounded edges on the Mac) and exclusively labeled with text. When it moved to the toolbar, it became square, lost its text, and acquired a pictograph, an iconic legend. Thus was born the butcon: half button, half icon (see Figure 21-2). In Windows 98, the butcon, or toolbar button, continued to develop, losing its raised affordance except when used — a move to reduce visual clutter in response to the overcrowding of toolbars. Unfortunately, this makes it more difficult for newcomers to understand the idiom; starting with Windows 2000, the toolbar butcon now reveals its button affordance only when pointed at.

  27_084113 ch21.qxp 4/3/07 6:10 PM Page 442

  442

  Part III: Designing Interaction Details

  Figure 21-2 Butcons from Microsoft Office 2003. On the left are examples in Office for Windows, and on the right are the same examples in Office for OS X.

  Notice how each item isn’t rendered as a distinct button until the mouse cursor passes over it.

  Butcons are, in theory, easy to use: They are always visible and don’t demand as much time or dexterity as a drop-down menu does. Because they are constantly visible, they are easy to memorize, particularly in sovereign applications. The advantages of the butcon are hard to separate from the advantages of the toolbar — the two are inextricably linked. The consistently annoying problem with the butcon derives not from its button part but from its icon part. Most users have no problem understanding the visual affordance. The problem is that the image on the face of the butcon is seldom that clear.

  Most icons are difficult to decipher with certainty upon first glance, but ToolTips can help with this. It takes a skilled and talented visual designer to be able to create an icon that is sufficiently recognizable and memorable that users aren’t required to rely upon ToolTips every time they look for a butcon. A good icon will be learned and remembered when users return to that function frequently. This is the type of behavior we typically see from intermediate and advanced users.

  However, even the best icon designer in the world will be hard pressed to devise an icon system that will be usable without text labels by novice users. Of course, ToolTips will help them, but it is terribly awkward to move a mouse cursor over each icon and wait for the ToolTip for every butcon. In these cases, menus with their explicit wording are a much better command vector. For more about menus, see Chapter 22. We’ll speak more about butcons, toolbars, and ToolTips in Chapter 23.

  Hyperlinks

  Hyperlinks, or links, are a Web convention that have found their way into all sorts of different applications. Typically taking the form of underlined text (though of cou
rse, images can be linked too), a link is an imperative control used for navigation. This is a simple, direct, and useful interaction idiom. If a user is interested in an underlined word, she may click on it and will be brought to a new page with more information.

  Unfortunately, the idiom’s success and utility have given many designers the wrong idea: They believe that replacing more common imperative controls such as buttons or butcons with underlined words will automatically result in a more usable

  27_084113 ch21.qxp 4/3/07 6:10 PM Page 443

  Chapter 21: Controls

  443

  and successful user interface. By and large this is not the case. Because most users have learned that links are a navigational idiom, they will be confused and disoriented if clicking a link results in the execution of an action. In general, you should use links for navigation through content, and buttons or butcons for other actions and functions.

  DESIGN

  Use links for navigation, and buttons or butcons for action.

  principle

  Selection Controls

  Because the imperative control is a verb, it needs a noun upon which to operate.

  Selection and entry controls are the two controls used to define nouns (in addition to direction manipulation idioms). A selection control allows the user to choose this noun from a group of valid choices. Selection controls are also used to configure actions — in the case of a direct manipulation idiom, the noun may be defined and the selection control is used to define an adjective or adverb. Common examples of selection controls include check boxes, list boxes, and drop-down lists.

  Traditionally, selection controls do not directly result in actions — they require an imperative control to activate. This is no longer always the case. In some situations, such as the use of a drop-down list as a navigation control on a Web page, this can be disorientating to users. In other cases, such as using a drop-down to adjust type size in a word processor, this can seem quite natural.