Our relationship to our software works the same way. We find ourselves easily memorizing facilities and commands that we use frequently and ignoring the details of commands that we use only rarely. This means that any vector that is used frequently will automatically become a candidate for a head vector. After daily use, for example, we no longer really read the menus, but find what we need by recognizing patterns: Pull down the second menu and select the bottom-most item in the next-to-last section. Pattern recognition is much faster for the human mind than reading is. We read only to verify our choices.
Memorization vectors
New users are happy with world vectors, but as they progress to become perpetual intermediates they begin to develop their working sets, and the (pedagogic) world vectors will start to seem tedious. Users like to find more immediate head vectors for the contents of their working sets. This is a natural and appropriate user desire and, if our software is to be judged easy to use, we must satisfy it. The solution consists of two components. First, we must provide a head vector in parallel to the world vector, and second, we must provide a path by which a user can learn the head vector corresponding to each world vector. This path is a vector itself: a memorization vector.
There are several ways to provide memorization vectors for users. The least effective method is to mention the vector only in the user documentation. The slightly better, but still ineffective, method is to mention it in the program’s main online help system. These methods put the onus of finding the memorization vector on users and also leave it up to users to realize that they need to find it in the first place.
Superior memorization vectors are built right into the interface, or are at least offered in an application’s interface by way of its own world vectors. The latter can be minimally implemented just by adding a menu item to the standard Help menu called Shortcuts. This item takes users directly to a section of help that describes available shortcuts. This method has the benefit of being explicit and, therefore, pedagogic.
New users can see that multiple command vectors exist and that there is an easy-to-find resource for learning them. All programs should have this Shortcut item.
32_084113 ch26.qxp 4/3/07 6:12 PM Page 555
Chapter 26: Designing for Different Needs
555
DESIGN
Offer shortcuts from the Help menu.
principle
Integrating memorization vectors directly into the main interface is less problematic than it sounds. There are already two on the menus of most programs. As defined by Microsoft, a typical Windows application has two keyboard head vectors: mnemonics and accelerators. In Microsoft Word, for example, the mnemonic for Save is Alt+F+S. The memorization vector for this mnemonic is achieved visually by underlining the F and S in the menu title and the menu item, respectively.
The accelerator for Save is Ctrl+S. Ctrl+S is noted explicitly on the right side of the menu on the same line as the Save item, which acts as a memorization vector.
Neither of these vectors intrudes on a new user. He may not even notice their existence until he has used the program for some time — that is, until he becomes an intermediate user. Eventually, he will notice these visual hints and will wonder about their meaning. Most reasonably intelligent people — most users — will get the accelerator connection without any help. The mnemonic is slightly tougher, but once a user is clued into the use of the Alt meta-key, either by direction or accident, the idiom is extremely easy to remember and use wherever it occurs.
As you’ll recall from Chapter 23, butcons are an excellent technique whereby small icons are used to provide memorization vectors for transitioning from menus to toolbar. The icon identifying each function or facility should be shown on every artifact of the user interface that deals with it: each menu, each butcon, each dialog box, every mention in the help text, and every mention in the printed documentation. A memorization vector formed of visual symbols in the interface is the most effective technique, yet it remains underexploited in the industry at large.
Personalization and Configuration
Interaction designers often face the conundrum of whether to make their products user-customizable. It is easy to be torn between some users’ need to have things done their way, and the clear problem this creates when the program’s navigation suffers due to familiar elements being moved or hidden. The solution is to cast the problem in a different light.
People like to change things around to suit themselves. Even beginners, not to mention perpetual intermediates, like to put their own personal stamps on a program, changing it so that it looks or acts the way they prefer, uniquely suiting their tastes.
People will do this for the same reason they fill their identical cubicles with pictures of their spouses and kids, plants, favorite paintings, quotes, and Dilbert cartoons.
32_084113 ch26.qxp 4/3/07 6:12 PM Page 556
556
Part III: Designing Interaction Details
Decorating the persistent objects — the walls — gives them individuality without removing them. It also allows you to recognize a hallway as being different from dozens of identical hallways because it is the one with the M. C. Escher poster hanging in it. The term personalization describes the decoration of persistent objects.
Personalization makes the places in which we work more likable and familiar. It makes them more human and pleasant to be in. The same is true of software, and giving users the ability to decorate their personal applications is both fun and useful as a navigational aide.
On the other hand, moving persistent objects themselves can hamper navigation. If the facilities people come into your office over the weekend and rearrange all the cubicles, Dilbert cartoons notwithstanding, finding your office again on Monday morning will be tough (persistent objects and their importance to navigation are discussed in Chapter 11).
Is this an apparent contradiction? Not really. Adding decoration to persistent objects helps navigation, whereas moving the persistent objects hinders navigation.
The term configuration describes moving, adding, or deleting persistent objects.
Configuration is desirable for more experienced users. Perpetual intermediates, after they have established a working set of functions, will want to configure the interface to make those functions easier to find and use. They will also want to tune the program itself for speed and ease, but in all cases, the level of custom configuration will be light to moderate.
Configuration is a necessity for expert users. They are already beyond the need for more traditional navigation aids because they are so familiar with the product.
Experts may use the program for several hours every day; in fact, it may be the main application for accomplishing the bulk of their jobs.
Moving controls around on the toolbar is a form of personalization. However, the three leftmost toolbar controls on many programs, which correspond to File New, File Open, and File Save, are now so common that they can be considered persistent objects. A user who moves these around is configuring his program as much as he is personalizing it. Thus, there is a gray boundary between configuration and personalization.
Changing the color of objects on the screen is clearly a personalization task. Windows has always been very accommodating in this respect, allowing users to independently change the color of each component of the windows interface, including the color and pattern of the desktop itself. Windows gives users a practical ability to change the system font, too. Personalization is idiosyncratically modal (discussed
32_084113 ch26.qxp 4/3/07 6:12 PM Page 557
Chapter 26: Designing for Different Needs
557
a bit later in the chapter); people either love it or they don’t. You must accommodate both categories of users.
Tools for personalizing must be simple and easy to use, giving users a visual preview of their selections. Above all, they must be easy to undo. A dialog box that lets users change colors should offer a function that r
eturns everything to the factory settings.
Most end users won’t squawk if they can’t configure your program as long as it does its job well. Some really expert users may feel slighted, but they will still use and appreciate your program if it works the way they expect. In some cases, however, flexibility is absolutely critical. If you’re designing for a rapidly evolving workflow, it’s of utmost importance that the software used to support the workflow can evolve as quickly as the state of the art.
Also, corporate IT managers value configuration. It allows them to subtly coerce corporate users into practicing common methods. They appreciate the ability to add macros and commands to menus and toolbars that make the off-the-shelf software work more intimately with established company processes, tools, and standards. Many IT managers base their buying decisions on the configurability of programs. If they are buying ten or twenty thousand copies of a program, they rightly feel that they should be able to adapt it to their particular style of work. It is, thus, not on a whim that Microsoft Office applications are among the most configurable shrink-wrapped software titles available.
Idiosyncratically Modal Behavior
Many times user testing indicates that a user population divides relatively equally on the effectiveness of an idiom. Half of the users clearly prefer one idiom, whereas the other half prefers another. This sort of clear division of a population’s preferences into two or more large groups indicates that their preferences are idiosyncratically modal.
Development organizations can become similarly emotionally split on issues like this. One group becomes the menu-item camp, while the rest of the developers are the butcon camp. They wrangle and argue over the relative merits of the two methods, although the real answer is staring them in the face: Use both!
When the user population splits on preferred idioms, the software designers must offer both idioms. Both groups must be satisfied. It is no good to satisfy one-half of the population while angering the other half, regardless of which particular group you or your developers align yourselves with.
Windows offers an excellent example of how to cater to idiosyncratically modal desires in its menu implementation. Some people like menus that work the way
32_084113 ch26.qxp 4/3/07 6:12 PM Page 558
558
Part III: Designing Interaction Details
they did on the original Macintosh. You click the mouse button on a menu bar item to make the menu appear; then — while still holding down the button — you drag down the menu and release the mouse button on your choice. Other people find this procedure difficult and prefer a way to accomplish it without having to hold the mouse button down while they drag. Windows neatly satisfies this by letting users click and release on the menu bar item to make the menu appear. Then users can move the mouse — button released — to the menu item of choice. Another click and release selects the item and closes the menu. A user can also still click and drag to select a menu item. The brilliance of these idioms is that they coexist quite peacefully with each other. Any user can freely intermix the two idioms, or stick consistently with one or the other. The program requires no change. There are no preferences or options to be set; it just works.
Starting in Windows 95, Microsoft added a third idiosyncratically modal idiom to the menu behavior: The user clicks and releases as before, but now he can drag the mouse along the menu bar and the other menus are triggered in turn. Amazingly, now all three idioms are accommodated seamlessly. The Mac now, too, supports all three of these idioms.
Localization and Globalization
Designing applications for use in different languages and cultures presents some special challenges to designers. Here again, however, consideration of command vectors can provide guidance.
Immediate vectors such as direct manipulation and toolbar butcons are idiomatic (see Chapter 20) and visual rather than textual. They are, therefore, capable of being globalized with considerable ease. It is, of course, important for designers to do their homework to ensure that colors or symbols chosen for these idioms do not have particular meanings in different cultures that the designer would not intend.
(In Japan, for example, an X in a check box would likely be interpreted as de selection rather than selection.) However, nonmetaphorical idioms should, in general, be fairly safe for globalized interfaces.
The pedagogic vectors such as menu items, field labels, ToolTips, and instructional hints are language dependent, and thus must be the subject of localization via translation to appropriate languages. Some issues to bear in mind when creating interfaces that must be localized include:
In some languages, words and phrases tend to be longer than in others (German text labels, for example, are significantly longer than those in English on average).
32_084113 ch26.qxp 4/3/07 6:12 PM Page 559
Chapter 26: Designing for Different Needs
559
Words in some languages, Asian languages in particular, can be difficult to sort alphabetically.
Ordering of day-month-year and the use of 12- or 24-hour notation for time vary from country to country.
Decimal points in numbers and currency are represented differently (some countries use periods and commas the opposite of the way they are used in the U.S.).
Some countries make use of week numbers (for example, week 50 is in mid-December), and some countries make use of calendars other than the Gregorian calendar.
Menu items and dialogs, when they are translated, need to be considered holistically. It is important to make sure that translated interfaces remain coherent as a whole. Items and labels that translate straightforwardly in a vacuum may become confusing when grouped with other independently translated items. Semantics of the interface need to be preserved at the higher level as well as at the detail level.
Galleries and Templates
Not all users of document-creation applications are capable of building documents completely from scratch. Most programs, however, offer users atomic tools: the equivalent of hammers, saws, and chisels. That is fine for some users, but others require more: the equivalent of an unfinished table or chair that they can then sand and paint.
For example, consider a program that lets you configure your own personalized newspaper from information on the Internet. Some users will really appreciate being able to put sports at the top of page one. Most users, however, will probably want a more traditional view, with world news at the top and sports at the back.
Even these more-traditional users will appreciate the fact that they can add their local news and news concerning topics of particular personal interest. They should be able to pick a premade newspaper and then make the few small changes needed to get their custom version. Constructing a whole newspaper from a blank slate would be an unpleasant task for all but the closet journalists among us.
In other words, users should be allowed to choose a starting design or document structure in any application from a gallery of possible designs, if they don’t have the need or desire to create one from scratch.
DESIGN
Offer users a gallery of ready-to-use templates.
principle
32_084113 ch26.qxp 4/3/07 6:12 PM Page 560
560
Part III: Designing Interaction Details
Some programs already offer galleries of predesigned templates, but more should do the same. Blank slates intimidate most people, and users shouldn’t have to deal with one if they don’t want to. A gallery of basic designs is a fine solution.
Help
Online help is just like printed documentation, a reference tool for perpetual intermediates. While good online help is critical, it should never be a crutch for your product. Good design should greatly reduce your users’ reliance on help.
A complex program with many features and functions should come with a reference document: a place where users who wish to expand their horizons can find definitive answers. This document can be a printed manual or it can be online help.
The printed manual is comfortable, browsable, friendly, and can be carried around.
The online help is searchable, semi-comfortable, very lightweight, and cheap.
The index
Because you don’t read a manual like a novel, the key to a successful and effective reference document is the quality of the tools for finding what you want in it.
Essentially, this means the index. A printed manual has an index in the back that you use manually. Online help has an automatic index search facility.
We suspect that few online help facilities were indexed by a professional indexer.
However many entries are in your program’s index, you could probably double the number. What’s more, the index needs to be generated by examining the program and all its features, not by examining the help text. This is not easy, because it demands that a highly skilled indexer be intimately familiar with all the features of the program. It may be easier to rework the interface to improve it than to create a really good index.
The list of index entries is arguably more important than the text of the entries themselves. A user will forgive a poorly written entry with more alacrity than he will forgive a missing entry. The index must have as many synonyms as possible for topics. Prepare for it to be huge. A user who needs to solve a problem will be thinking “How do I turn this cell black?” not “How can I set the shading of this cell to 100%?” If the entry is listed under shading, the index fails the user. The more goal-directed your thinking is, the better the index will map to what might possibly pop into a user’s head when he is looking for something. An index model that works is the one in The Joy of Cooking by Irma S. Rombaur and Marion Rombaur Becker .
That index is one of the most complete and robust of any we have used.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 73
