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)

  Insert and overtype entry modes

  In most text editors there is a user-settable option toggling between insert mode, where text following the insertion point is preserved by sliding it out of the way as new text is added, and overtype mode, where text following the insertion point is lost as the user types over it. These two modes are omnipresent in the world of word processors and, like FORTRAN, never seem to die. Insert and overtype are modes that cause a significant change in the behavior of an interface, with no obvious indication until after a user has interacted, and there is no clear way into or out of these modes (at least in Windows) except by means of a rather obscure keystroke.

  Today, with modern GUI word processors, it’s hard to imagine anyone using overtype mode, but undoubtedly such people are out there. But for edit fields of a single line, adding controls beyond simple insert-mode entry and editing is foolish —

  the potential for trouble is far greater than the advantages. Of course, if you are designing a word processor, the story is different.

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

  468

  Part III: Designing Interaction Details

  Using text edit controls for output: A bad idea

  The text edit control, with its familiar system font and visually articulated white box, encourages data entry. Yet software developers frequently use the text edit control for read-only output fields. The edit control certainly works as an output field, but to use this control for output only is like pulling a bait and switch on your user, and he will not be amused. If you have text data to output, use a text display control and not a text edit control. If you want to show the amount of free space on disk, for example, don’t use a text edit field, because users are likely to think that they can get more free space by entering a bigger number. At least, that is what the control is telling them with its equivalent of body language.

  If you are going to output editable information, go ahead and output it in a fully editable text control and wire it up internally so that it works exactly as it will appear. If not, stick to display controls, described in the next section.

  DESIGN

  Use noneditable (display) controls for output-only text.

  principle

  Display Controls

  Display controls are used to display and manage the visual presentation of information on the screen. Typical examples include scrollbars and screen-splitters. Controls that manage the way objects are displayed visually on the screen fall into this category, as do those that display static, read-only information. These include pagi-nators, rulers, guidelines, grids, group boxes, and those 3D lines called dips and bumps. Rather than discuss all of these at length, we focus on a few of the more problematic controls.

  Text controls

  Probably the simplest display control is the text control, which displays a written message at some location on the screen. The management job that it performs is pretty prosaic, serving only to label other controls and to output data that cannot or should not be changed by users.

  The only significant problem with text controls is that they are often used where edit controls should be (and vice versa). Most information stored in a computer can be changed by users. Why not allow them to change it at the same point the software displays it? Why should the mechanism to input a value be different from the mechanism to output that value? In many cases, it makes no sense for the program to

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

  Chapter 21: Controls

  469

  separate these related functions. In almost all cases where the program displays a value that could be changed, it should do so in an editable field so a user can click on it and change it directly. Special edit modes are almost always examples of excise.

  For years, Adobe Photoshop insisted on opening a dialog box in order to create formatted text in an image. Thus, a user could not see exactly how the text was going to look in the image, forcing her to repeat the procedure again and again to get things right. Finally Adobe fixed the problem, letting users edit formatted text directly into an image layer, in full WYSIWYG fashion — as it should be.

  Scrollbars

  Scrollbars serve a critical need in the modern GUI — they enable smallish rectangles (i.e., windows or panes) to meaningfully contain large amounts of information. Unfortunately, they are also typically quite frustrating, difficult to manipulate, and wasteful of pixels. The scrollbar is, without a doubt, both overused and under-examined. In its role as a window content and document navigator — a display control — its application is appropriate.

  The singular advantage of the scrollbar — aside from its near universal availability —

  is that it provides useful context about where you are in the window. The scrollbar’s thumb is the small, draggable box that indicates the current position, and, often, the scale of the “territory” that can be scrolled.

  Many scrollbars are quite parsimonious in doling out information to users. The best scrollbars use thumbs that are proportionally sized to show the percentage of the document that is currently visible, as well as:

  How many pages there are in total

  The page number (record number, graphic) as we scroll with the thumb

  The first sentence (or item) of each page as we scroll with the thumb Additionally, many scrollbar implementations are stingy with functions. To better help us manage navigation within documents, they should give us powerful tools for going where we want to go quickly and easily, such as:

  Buttons for skipping ahead by pages/chapters/sections/keywords

  Buttons for jumping to the beginning and end of the document

  Tools for setting bookmarks that we can quickly return to

  Recent versions of Microsoft Word make use of scrollbars that exhibit many of these features.

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

  470

  Part III: Designing Interaction Details

  Shortcomings in contextual information aside, one of the biggest problems with scrollbars is that they demand a high degree of precision with the mouse. Scrolling down or up in a document is generally much easier than scrolling down and up in a document. You must position the mouse cursor with great care, taking your attention away from the data you are scrolling. Some scrollbars replicate both their up and down nudge arrows at each end of the scrollbar; for windows that will likely stretch across most of the screen, this can be helpful; for smaller windows, such replication of controls is probably overkill and simply adds to screen clutter (see Chapter 19 and Figure 19-1 for more discussion of this idiom).

  The ubiquity of scrollbars has unfortunately resulted in some unfortunate misuse.

  Most significant here is their shortcomings in navigating time. Without getting too philosophical or theological, we can all hopefully agree that time has no meaningful beginning or end (at least within the perception of the human mind). What, then, is the meaning of dragging the thumb to one end of a calendar scrollbar? (See Figure 21-21).

  Figure 21-21 This image shows a limitation of using a scrollbar for navigating the endless stream of time. Dragging the thumb all the way to the end of the scrollbar brings a user one year into the future. This seems a bit arbitrary and limiting.

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

  Chapter 21: Controls

  471

  There are some viable alternatives to scrollbars. One of the best is the document navigator, which uses a small thumbnail of the entire document space to provide direct navigation to portions of the document (see Figure 21-22). Many image editing applications (such as Photoshop) utilize these for navigating around a document when zoomed in. These can also be very useful when navigating time-based documents, such as video and audio. Critical to the success of such idioms is that it is possible to meaningfully represent the big picture of the document in visual form. For this reason, they aren’t necessarily appropriate for long text documents.

  In
these cases, the structure of the document itself (in outline form) can provide a useful alternative to scrollbars. A basic example of this can be seen in Microsoft Word’s Document Map (which is well intended, but of only limited utility — it deems only first- and second-level headers worth displaying).

  Figure 21-22 Ableton Live features a document navigator on the top of the arrangement screen that provides an overview of the entire song. The black rectangle denotes part of the song that the work area below is zoomed in on.

  The navigator both provides context in a potentially confusing situation and simultaneously provides a direct navigation idiom where a user may move the rectangle to focus on a different part of the song.

  Splitters

  Splitters are useful tools for dividing a sovereign application into multiple, related panes in which information can be viewed, manipulated, or transferred. Movable splitters should always advertise their pliancy with cursor hinting. Though it is easy and tempting to make all splitters movable, you should exercise care in choosing

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

  472

  Part III: Designing Interaction Details

  which ones to make movable. In general, a splitter shouldn’t be able to be moved in such a way that makes the contents of a pane completely unusable. In cases where panes need to collapse, a drawer may be a better idiom.

  Drawers and levers

  Drawers are panes in a sovereign application that can be opened and closed with a single action. They can be used in conjunction with splitters if the amount that the drawer opens is user configurable. A drawer is usually opened by clicking on a control in the vicinity of the drawer. This control needs to be visible at all times and should either be a latching button/butcon or a lever, which behaves similarly, but typically swivels to indicate an open or closed state.

  Drawers are a great place to put controls and functions that are less frequently used but are most useful in context of the main work area of the application. Drawers have the benefit of not covering up the main work area the way a dialog does.

  Property details, searchable lists of objects or components, and histories are perfect candidates for putting in drawers.

  Although the big-picture principles discussed throughout this book can provide enormous leverage in creating products that will please and satisfy users, it’s always important to remember that the devil is in the details. Frustrating controls can lead to a constant low-level annoyance, even if an overall product concept is excellent.

  Be sure to dot your i’s and cross your t’s, and ensure that your controls are well behaved.

  28_084113 ch22.qxp 4/3/07 6:10 PM Page 473

  22

  Menus

  Menus are perhaps the oldest idioms in the GUI pantheon — revered and surrounded by superstition and lore. Most designers, programmers, and users accept without question that traditional menu design is correct — there are so many existing programs that attest to its excellence. But this belief is like snapping your fingers to keep the tigers away. There aren’t any tigers here, you say? See, it works!

  That said, a well-designed menu can be a very useful way to provide access to application functionality in certain contexts. We start this chapter with a brief history of menus and then discuss some problems with menus and how to use them appropriately.

  A Bit of History

  While the modern GUI with its drop-down menus and dialog boxes has only been mainstream since the Macintosh’s introduction in 1984, it is now so ubiquitous that it’s easy to take for granted. Before diving into the details of contemporary menu idioms, it’s useful to look back and examine the path we’ve taken in the development of modern interaction idioms as a basis for our understanding of menus’

  strengths and potential pitfalls.

  28_084113 ch22.qxp 4/3/07 6:10 PM Page 474

  474

  Part III: Designing Interaction Details

  The command-line interface

  If you wanted to talk to an IBM mainframe computer in the 1970s, you had to manually keypunch a deck of computer cards, use an obscure language called JCL (Job Control Language), and submit this deck of cards to the system through a noisy, mechanical card reader. Each line of JCL or program had to be punched on a separate card. Even the first microcomputers, small, slow, and stupid, running a primitive operating system called CP/M, had a much better conversational style than those hulking dinosaurs in their refrigerated glass houses. You could communicate directly with microcomputers running CP/M merely by typing commands into a standard keyboard. What a miracle! The program issued a prompt on the computer screen that looked like this:

  A>

  You could then type in the names of programs, which were stored as files, as commands and CP/M would run them. We called it the command-line interface, and it was widely considered a great leap forward in man-machine communications.

  The only catch is that you had to know what to type. For frequent users, who at that time were mostly programmers, the command-line prompt was very powerful and effective because it offered the quickest and most efficient route to getting the desired task done. With his hands on the keyboard in the best tradition of touch typists, a user could rip out copy a:*.* b:, and the disk was copied. Even today, for users who have mastered the command set, the command line is still considerably faster (and often more powerful) than using a mouse for many operations.

  The command-line interface really separated the men (and women) from the nerds. As software got more powerful and complex, however, the memorization demands that the command-line interface made on users were just too great, and it had to give way to something better.

  Sequential hierarchical menus

  Finally, sometime in the late-1970s, some very clever programmer came up with the idea of offering users a list of choices. You could read the list and select an item from it the way that you choose a dish at a restaurant by reading the menu. The appellation stuck, and the age of the sequential hierarchical menu began.

  The sequential hierarchical menu enabled users to forget many of the commands and option details required by the command-line interface. Instead of keeping the details in his head, a user could read them off the screen. Another miracle! Circa

  28_084113 ch22.qxp 4/3/07 6:10 PM Page 475

  Chapter 22: Menus

  475

  1979, your program was judged heavily on whether or not it was menu-based.

  Those vendors stuck in the command-line world fell by the wayside in favor of the more modern paradigm.

  Although the paradigm was called menu-based at the time, we refer to these menus as sequential and hierarchical to differentiate them from the menus in widespread use today. The old pre-GUI menus were deeply hierarchical: After you made a selection from one menu, it would be replaced by another, then another, drilling down into a tall tree of commands.

  Because only one menu at a time could be placed on the screen and because software at that time was still heavily influenced by the batch style of mainframe computing, the hierarchical menu paradigm was sequential in behavior. Users were presented with a high-level menu for choosing between major functions, for example: 1. Enter transactions

  2. Close books for month

  3. Print Income Statement

  4. Print Balance Sheet

  5. Exit

  After a user chose a function, say 1. Enter transactions; he would then be prompted with another menu, subordinate to his choice from the first one, such as: 1. Enter invoices

  2. Enter payments

  3. Enter invoice corrections

  4. Enter payment corrections

  5. Exit

  A user would choose from this list and, most likely, be confronted with a couple more such menus before the actual work would begin. Then, the Exit option would take him up only one level in the hierarchy. This meant that navigating through the menu tree was a real chore.

  Once a user made his selection, it was set in concrete — there wa
s no going back.

  People, of course, made mistakes all the time, and the more progressive developers of the day added confirmation menus. The program would accept the user’s choice as before, then issue another menu to enquire: Press the Escape Key to Change Your Selection, Otherwise Press Enter to Proceed. This was an incredible pain, because regardless of whether you had made a mistake or not, you needed to answer this awkward and confusing meta-question, which could lead you to make exactly the kind of mistake you were hoping to avoid.

  28_084113 ch22.qxp 4/3/07 6:10 PM Page 476

  476

  Part III: Designing Interaction Details

  Such menu-based interfaces would be terrible judged by today’s standards. Their chief failing was that with such a limited command vector, the hierarchies became quite deep. They also demonstrated a striking lack of flexibility and clarity in communicating with people. Still, they were better than command lines, where you had to remember a sometimes complex command syntax, as well as the exact spelling of every operand you wanted to act upon. Sequential hierarchical menus lightened the amount of memory work required of users, but forced them to laboriously navigate a maze of confusing choices and options. They, too, had to give way to something better. (Though it doesn’t take much looking to find current-day devices and kiosks that fall back on these idioms — take most ATMs, for example.)

  The Lotus 1-2-3 interface

  The next great advance in user-interface technology came in 1979 from Lotus Corporation with the original 1-2-3 spreadsheet program. 1-2-3 was still controlled by a deeply hierarchical menu interface, but Lotus added its own twist — the visible hierarchical menu. This helped make it the most successful piece of software ever sold at that point.