Designing Interfaces | O'Reilly Media

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This book is almost entirely about the look and behavior of applications, web applications, and interactive devices. But this first chapter will be the exception to the rule. No screenshots here; no layouts, no navigation, no diagrams, and no visuals at all.

Why not? After all, that's why you may have picked up this book in the first place.

It's because good interface design doesn't start with pictures. It starts with an understanding of people: what they're like, why they use a given piece of software, and how they might interact with it. The more you know about them, and the more you empathize with them, the more effectively you can design for them. Software, after all, is merely a means to an end for the people who use it. The better you satisfy those ends, the happier those users will be.

Each time someone uses an application, or any digital product, they carry on a conversation with the machine. It may be literal, as with a command line or phone menu, or tacit, like the "conversation" an artist has with her paints and canvas—the give and take between the craftsperson and the thing being built. With social software, it may even be a conversation by proxy. Whatever the case, the user interface mediates that conversation, helping the user achieve whatever ends he or she had in mind.

As the user interface designer, then, you get to script that conversation, or at least define its terms. And if you're going to script a conversation, you should understand the human's side as well as possible. What are the user's motives and intentions? What "vocabulary" of words, icons, and gestures does the user expect to use? How can the application set expectations appropriately for the user? How do the user and the machine finally end up communicating meaning to each other?

There's a maxim in the field of interface design: "Know thy users, for they are not you!"

So this chapter will talk about people. It covers a few fundamental ideas briefly in this introduction, and then discusses the patterns themselves. These patterns differ from those in the rest of the book. They describe human behaviors—as opposed to system behaviors—that the software you design may need to support. Software that supports these human behaviors help users achieve their goals.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Everyone who uses a tool, software or otherwise, has a reason to use it. For instance:

Finding some fact or object
Learning something
Performing a transaction
Controlling or monitoring something
Creating something
Conversing with other people
Being entertained

Well-known idioms, user behaviors, and design patterns can support each of these abstract goals. Interaction designers have learned, for example, how to help people search through vast amounts of online information for specific facts. They've learned how to present tasks so that it's easy to walk through them. They are learning ways to support the building of documents, illustrations, and code.

The first step in designing an interface is figuring out what its users are really trying to accomplish. Filling out a form, for example, almost never is a goal in and of itself—people only do it because they're trying to buy something online, get their driver's license renewed, or install a networked printer. They're performing some kind of transaction.

Asking the right questions can help you connect user goals to the design process. Users and clients typically speak to you in terms of desired features and solutions, not of needs and problems. When a user or client tells you he wants a certain feature, ask why he wants it—determine his immediate goal. Then, to the answer of this question, ask "why" again. And again. Keep asking until you move well beyond the boundaries of the immediate design problem.

Why should you ask these questions if you have clear requirements? Because if you love designing things, it's easy to get caught up in an interesting interface-design problem. Maybe you're good at building forms that ask for just the right information, with the right controls, all laid out nicely. But the real art of interface design lies in

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Empirical discovery is the only really good way to obtain this information. To get a design started, you'll need to characterize the kinds of people who will use whatever you design (including the "softer" categories just mentioned), and the best way to do that is to go out and meet them.

Each user group is unique, of course. The target audience for, say, a new cell phone will differ dramatically from that for a piece of scientific software. Even if the same person uses both, his expectations for each are different—a researcher using scientific software might tolerate a less-polished interface in exchange for high functionality, whereas that same person may trade in his new phone if he finds its UI to be too hard to use after a few days.

Every user is unique, too. What one person finds difficult, the next one won't. The trick is to figure out what's generally true about your users, which means learning about enough individual users to separate the quirks from the common behavior patterns.

Specifically, you'll want to learn:

Their goals in using the software you design
The specific tasks they undertake in pursuit of those goals
The language and words they use to describe what they're doing
Their skill at using software similar to what you're designing
Their attitudes toward the kind of thing you're designing, and how different designs might affect those attitudes

I can't tell you what your particular target audience is like. You need to find out what they might do with the software you design, and how it fits into the broader context of their lives. Difficult though it may be, try to describe your potential audience in terms of how and why they might use your software. You might get several distinct answers, representing distinct user groups; that's okay. You might be tempted to throw up your hands and say, "I don't know who the users are," or, "Everyone is a potential user." That doesn't help you focus your design at all—without a concrete and honest description of those people, your design will proceed with no grounding in reality.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Before you start the design process, consider your overall approach. Think about how you might design its overall interaction style—its personality, if you will.

When you carry on a conversation with someone about a given subject, you adjust what you say according to your understanding of the other person. You might consider how much he cares about the subject, how much he already knows about it, how receptive he is to learning from you, and whether he's even interested in the conversation in the first place. If you get any of that wrong, then bad things happen—he might feel patronized, uninterested, impatient, or utterly baffled.

This analogy leads to some obvious design advice. The subject-specific vocabulary you use in your interface, for instance, should match your users' level of knowledge; if some users won't know that vocabulary, give them a way to learn the unfamiliar terms. If they don't know computers very well, don't make them use sophisticated widgetry or uncommon interface-design conventions. If their level of interest might be low, respect that, and don't ask for too much effort for too little reward.

Some of these concerns permeate the whole interface design in subtle ways. For example, do your users expect a short, tightly focused exchange about something very specific, or do they look for a conversation that's more of a free-ranging exploration? In other words, how much openness is there in the interface? Too little, and your users feel trapped and unsatisfied; too much, and they stand there paralyzed, not knowing what to do next, unprepared for that level of interaction.

Therefore, you need to choose how much freedom your users have to act arbitrarily. At one end of the scale might be a software installation wizard: the user is carried through it with no opportunity to use anything other than Next, Previous, or Cancel. It's tightly focused and specific, but quite efficient—and satisfying, to the extent that it works and is quick. At the other end might be an application like Excel, an "open floor plan" interface that exposes a huge number of features in one place. At any given time, the user has about 872 things that she can do next, but that's considered good because self-directed, skilled users can do a lot with that interface. Again, it's satisfying, but for entirely different reasons.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Even though individuals are unique, people behave predictably. Designers have been doing site visits and user observations for years; cognitive scientists and other researchers have spent many hundreds of hours watching how people do things and how they think about what they do.

So when you observe people using your software, or performing whatever activity you want to support with new software, you can expect them to do certain things. The behavioral patterns listed below often are seen in user observations. Odds are good that you'll see them too, especially if you look for them.

A note for patterns enthusiasts: These patterns aren't like the others in this book. They describe human behaviors, not interface elements, and they're not prescriptive like the patterns in other chapters. Instead of being structured like the other patterns, these are presented as small essays.

Again, an interface that supports these patterns well will help users achieve their goals far more effectively than interfaces that don't support them. And the patterns are not just about the interface, either. Sometimes the entire package—interface, underlying architecture, feature choice, and documentation—needs to be considered in light of these behaviors. But as the interface designer or interaction designer, you should think about these as much as anyone on your team. You may be in the best position to advocate for the users.

Safe Exploration
Instant Gratification
Satisficing
Changes in Midstream
Deferred Choices

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

At this point, you may know what your users want out of your application. You may know which idiom or interface type to use, such as a graphic editor, a form, web-like hypertext, or a media player—or an idea of how to combine several of them. If you're really on the ball, you've written down some typical scenarios that describe how people might use high-level elements of the application to accomplish their goals. You have a clear idea of what value this application adds to people's lives.

Now what?

You could start making sketches of the interface. Many visual thinkers do that at this stage. If you're the kind of person who likes to think visually, and needs to play with sketches while working out the broad strokes of the design, go for it.

But if you're not a visual thinker by nature (and sometimes even if you are), then hold off on the interface sketches. They might lock your thinking into the first visual designs you manage to put on paper. You need to stay flexible and creative for a little while, until you work out the overall organization of the application.

High-level organization is a wickedly difficult topic. It helps to think about it from several angles, so this introduction takes two aspects that I've found useful and discusses them in some depth.

The first, "Dividing Stuff Up," encourages you to try separating the content of the application entirely from its physical presentation. Rather than thinking in terms of windows, tree views, and links, you might think abstractly about how to organize the actions and objects in your application in the way truest to your subject matter. You can postpone the decisions about using specific windows and widgets. Clearly this separation of concerns is useful when you design multimodal applications (e.g., the same content presented both on the Web and on a palmtop, with very different physical presentations), but it's also good for brand new applications or deep redesigns. This approach forces you to think about the right things first: organization and task flows.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In the Preface, I talked a bit about interface idioms.. These, you might recall, are interface types or styles that have become familiar to some user populations. They include text editors, forms, games, command lines, and spreadsheets. They're useful because they let you start a design with a set of familiar conventions; you don't have to start from first principles. And once a first-time user recognizes the idiom being used, she has a head start on under-standing the interface.

Whatever it is you're building, you've probably decided which idioms to use. But what may not be so obvious is how to organize the "stuff" you're presenting via these idioms. If your application is small enough to fit on one page or physical panel, great—you're off and running. But odds are good that you're dealing with a lot of features, tools, or content areas. The nature of the high-tech industry is to keep cramming more stuff into these interfaces, since features usually are what sell.

If you've done any work on web sites, you may know the term "information architecture." That's essentially what you'll be doing first. You need to figure out how to structure all this content and functionality: how to organize it, label it, and guide a user through the interface to get what they came for. Like a real-world architect, you're planning the informational "space" where people will dwell.

But applications are different from traditional web sites. Think about it in terms of "nouns" versus "verbs." In web sites and many other media—books, movies, music, graphic design— you work with nouns. You arrange them, present them, categorize them, and index them. Users know what to do with text and images and such. But applications, by definition, exist so people can get things done: write, draw, perform transactions, interact with others, and keep track of things. You're manipulating verbs now. You need to structure the interface so users always know what to do next (or at least have a good idea where to look).

Most applications (and many web sites) are organized according to one or more of the fol-lowing approaches. Some use nouns, others use verbs:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Once you've come up with the beginnings of a design, you have to translate it into a physical structure of windows, pages, and controls. That's one of the first aspects of an application that people perceive, especially on the desktop, which can host all the types of window arrangements described here.

I've heard this debate many times before: should an application use multiple windows, a single window with several tiled panes, or one window whose content "swaps out" like a web page? Should it use some combination thereof? See Figure 2-6.

You may already know by now which to use—the technology you're using often will set your course. Handhelds, cell phones, and most other consumer electronics simply don't give you the option for multiple windows or multiple panes. Even if you could, it's a bad idea, simply because users will find it too hard to navigate without a mouse.

Desktop software and large-screen web applications give you more choices. There aren't any hard-and-fast rules for determining what's best for any given design, but the sections that follow provide some guidelines. Before you decide, analyze the kinds of tasks your users will perform—especially whether they need to work in two or more UI areas at the same time. Do they need to refer to panel A while editing something in panel B? Do they need to compare A and B side-by-side? Do they need to keep panel A in view at all times to monitor something? Let your understanding of users' tasks drive your decisions.

Figure 2-6: Three different physical structures

Multiple windows sometimes are the right choice, but not often. They work best in sophisticated applications when users want to customize the layout of their screen. Infrequent users, and sometimes frequent users too, may find multiple windows irritating or confusing.

Sometimes users simply lose them if there are too many of them onscreen at once. On the other hand, if users really need to see two or more windows "in parallel," you need either this or the tiled-pane model.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter's patterns cover both of the approaches to application design just discussed. Some of them mix content structure with physical structure. They illustrate combinations that are known to work exceedingly well, such as the first four patterns:

Two-Panel Selector
Canvas Plus Palette
One-Window Drilldown
Alternative Views

The next few patterns don't go much into physical presentation, but instead deal with content in the abstract. Wizard talks about "linearizing" a path through a task; it can be implemented as any number of physical presentations. Extras on Demand and Intriguing Branches describe additional ways to divide up content.

Wizard
Extras on Demand
Intriguing Branches

Many patterns, here and elsewhere in the book, contribute in varying degrees to the learnability of an interface. Multi-Level Help sets out ways to integrate help directly into the application, thus supporting learnability for a broad number of users and situations.

Multi-Level Help

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The patterns in this chapter deal with the problem of navigation. How does a user know where they are now, where to go next, and how to get there from here?

The reason why I call it a "problem" is this. Navigating around a web site or application is like commuting. You have to do it to get where you need to go, but it's dull, it's sometimes infuriating, and the time and energy you spend on it just seems wasted. Can't you do something better with your time, like playing a game or getting some actual work done?

The best kind of commuting—all else being equal—is none at all. Having everything you need right at your fingertips, without having to travel somewhere, is pretty convenient. Likewise, keeping most tools "within reach" on an interface is handy, especially for intermediate-to-expert users (i.e., people who have already learned where everything is). Sometimes you do need to put lesser-used tools in separate dialog boxes, where they don't clutter things up; sometimes you need to group things onto different pages so the interface makes sense. All this is fine, as long as the "distances" that a user has to travel remain short.

So: less is better. Let's talk terminology for a minute and come back to this concept.

Let's say you've built a large web site or application that you've had to break up into sections, subsections, specialized tools, pages, windows, and wizards. How do you help users navigate?

Signposts are features that help users figure out their immediate surroundings. Common signposts include page and window titles, web page logos and other branding devices, tabs, and selection indicators. Patterns such as Global Navigation, Color-Coded Sections, Sequence Map, Breadcrumbs, and Annotated Scrollbar—all described in this chapter—tell a user where they currently are, and often, where they can go with only one more jump. They help a user stay "found" and plan his next steps.

Wayfinding is what people do as they find their way towards their goal. The term is pretty self-explanatory. But how people actually do it is quite a research subject—specialists from cognitive science, environmental design, and web site design have studied it. These common-sense features help users with wayfinding:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Let's say you've built a large web site or application that you've had to break up into sections, subsections, specialized tools, pages, windows, and wizards. How do you help users navigate?

Signposts are features that help users figure out their immediate surroundings. Common signposts include page and window titles, web page logos and other branding devices, tabs, and selection indicators. Patterns such as Global Navigation, Color-Coded Sections, Sequence Map, Breadcrumbs, and Annotated Scrollbar—all described in this chapter—tell a user where they currently are, and often, where they can go with only one more jump. They help a user stay "found" and plan his next steps.

Wayfinding is what people do as they find their way towards their goal. The term is pretty self-explanatory. But how people actually do it is quite a research subject—specialists from cognitive science, environmental design, and web site design have studied it. These common-sense features help users with wayfinding:

Good signage: Clear, unambiguous labels anticipate what you're looking for and tell you where to go; signs are where you expect them to be, and you're never left standing at a decision point without guidance. You can check this by walking through the artifact you're designing and following the paths of all the major use cases. At each point where a user must decide where to go next, make sure it's signed or labeled appropriately.
Environmental clues: You'd look for restrooms in the back of a restaurant, for instance, or a gate where a walkway intersects a fence. Likewise, you'd look for a Cancel button at the bottom or right of a dialog box, and logos in the upper-left corner of a web page. Keep in mind that these clues often are culturally determined, and someone new to the culture (e.g., someone who's never used a given operating system before) will not be aware of them.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When you walk into an unfamiliar room, you look around. In a fraction of a second, you take in the shape of the room, the furnishings, the light, the ways out, and other clues; very quickly, you make some assumptions about what this room is and how it relates to why you walked in. Then you need to do what you came in to do. Where? How? You might be able to answer immediately—or not. Or maybe you're just distracted by other interesting things in the room.

Similarly, bringing up a web page or opening a window each incur a cognitive cost. Again, you need to figure out this new space: you take in its shape, its layout, its contents, its exits, and how to do what you came to do. All of this takes energy and time. The "context switch" forces you to refocus your attention and adjust to your new surroundings.

Even if you're already familiar with the window (or room) you just went into, it still incurs a cost. Not a large cost, but it adds up—especially when you figure in the actual time it takes to display a window or load a page.

This is true whether you're dealing with web pages, windows, dialog boxes, or device screens. The decisions that users make about where to go are similar, whether they use links or buttons—labels still need to be read, or icons decoded, and the users still will make leaps of faith by clicking on links or buttons they're not sure about.

Knowing that there's a cost associated with jumping from page to page, you can understand now why it's important to keep the number of those jumps down. Two of the patterns in this chapter— Global Navigation and Pyramid—give you specific ways to do that in complex applications and sites, by taking common navigation paths and turning them into easy single jumps. Patterns in other chapters, like Card Stack (Chapter 4), can help you pack more into a single page, thus sparing you the need to jump to a new one.

But the real efficiency gains come from the structure of the application. One of the nastiest things a designer can do is force a user to go into multiple levels of subpages or dialogs. every time they need to accomplish a simple, everyday task. (Worse is to lead him there, tell him he can't accomplish it because of some missing precondition, and send him back to Square One. Happens to the best of us.)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

To recap, this chapter talks about several aspects of navigation: overall structure, knowing where you are, figuring out where you're going, and getting there efficiently. The patterns address these issues to varying degrees.

The structure of an application or site is tied intimately to navigation within it. It's impossible to separate them, actually. One could arguably put structure-related navigation patterns like Clear Entry Points, Hub and Spoke, and Pyramid into Chapter 2, which discussed how to organize the content, because these patterns talk about how multiple pages interrelate. You can "tack on" some others—Global Navigation, Color-Coded Sections, Sequence Map, Breadcrumbs, and Escape Hatch—to individual pages after the basic navigational structures are designed, and thus they might move further down the design progression into page layout (the topic of Chapter 4).

And there's one more thing to note. Clear Entry Points, Modal Panel, and Hub and Spoke restrict access to navigation, not expand it (as many of the others do). Complete freedom to move anywhere at any time isn't an unalloyed good; sometimes clarity of understanding means that less is better.

In any case, we'll start with the patterns that describe navigational structures: how the pages (or windows or dialog boxes) of a UI interlink. If you draw a picture of the links between the pages of the UI, you might see some of these patterns:

Clear Entry Points
Global Navigation
Hub and Spoke
Pyramid

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Page layout is the art of manipulating the user's attention on a page to convey meaning, sequence, and points of interaction.

If the word "manipulating" sounds unseemly to you, think about it this way. Film and television directors make their living by manipulating your attention on the movie or TV screen, and you are presumably a willing participant. Likewise for editors who arrange articles, headlines, and ads on a newspaper. If all this content were presented in a drab monotone, with no graphic emphasis to grab and move your attention, you would actually find it harder to extract meaning—what's supposed to be important, and what's not?

Even though it is ultimately an art, there might be more rationality to good page layout than you think. Some important ideas from graphic design are explained in this chapter introduction; each can guide you in the layout of pages, screens, and dialog boxes. We'll talk about visual hierarchy, visual flow and focal points, and grouping and alignment—all are predictable and rational approaches to page design. This chapter's patterns describe concrete ways to apply those high-level concepts to interface design.

But the changeable, interactive nature of computer displays makes layout easier in some ways, harder in others. We'll talk about why that's true. Some of these patterns work as well in print as they do onscreen, but most of them would be useless in print because they presume that the user will interact with the page.

This section discusses five major elements of page layout: visual hierarchy, visual flow, grouping and alignment, how to put these three elements together, and how to use dynamic displays.

The concept of visual hierarchy plays a part in all forms of graphic design. Put simply, the most important content should stand out the most, and the least important should stand out the least. Titles ought to look like titles, and secondary content ought to look like secondary content—in other words, a reader should be able to deduce the informational structure of the page from its layout.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This section discusses five major elements of page layout: visual hierarchy, visual flow, grouping and alignment, how to put these three elements together, and how to use dynamic displays.

The concept of visual hierarchy plays a part in all forms of graphic design. Put simply, the most important content should stand out the most, and the least important should stand out the least. Titles ought to look like titles, and secondary content ought to look like secondary content—in other words, a reader should be able to deduce the informational structure of the page from its layout.

Examples explain this concept best. Figure 4-1 shows text that wasn't formatted with any visual hierarchy at all.

Figure 4-1: No visual hierarchy

Passable, but not great. What's the most important information in that paragraph? You can guess that the first sentence is the most important, but otherwise, it's hard to tell, since the whole block of text is visually monotonous. Once you've read it and realize it's an invitation, you can tell from context—but you had to read it first.

Now let's improve on this example. Whitespace is one of the best tools you have for organizing a visual hierarchy. It's a cheap and graceful way of pulling apart monotonous blocks of information.

Figure 4-2: With whitespace

In Figure 4-2, you can at least see distinct groups of information. And the headline at the top—"Zelda's 30th Birthday Party"—stands out a bit more because it has whitespace around it. So does the not-quite-as-important RSVP message at the bottom. But the text that your eye falls on first is probably "You're invited to". It's sitting up there by itself, at the upper left corner, where every speaker of left-to-right languages looks first. That alone gives it unwarranted importance.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter's patterns give you specific ways to put all these layout concepts into play.

The first two, Visual Framework and Center Stage, address the visual hierarchy of the whole page, screen, or window, regardless of the type of content you put into that page. You should consider Visual Framework early in a project, since it affects all the major pages and windows in an interface.

Visual Framework
Center Stage

The next group of patterns represents four alternative ways of "chunking" content on a page or window. They're useful when you have a lot of stuff to show on the page at once. Once you've made a decision to break up your content into thematic sections, you need to choose how to present them. Should they all be visible at once, or can they (or should they) be viewed independently? Is it okay for users to manipulate those sections on the page? These patterns deal with visual hierarchy, but they also involve interactivity, and will help you choose among the specific mechanisms available in UI toolkits.

Titled Sections
Card Stack
Closable Panels
Movable Panels

Right/Left Alignment and Diagonal Balance draw on the concepts of visual flow, alignment, and other things discussed in this introduction. They deal with the spatial relationships among smaller, more static elements on a page, like text and controls.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter is devoted to the "verbs" in the interface. We've spent a lot of pages talking about overall structure and flow, visual layout, and "nouns" such as windows, text, links, and static elements in pages. Chapter 6 spends even more pages on nouns, and Chapter 7 handles traditional (and a few nontraditional) controls and widgets: things that let users supply information and set state, but that don't actually do much.

So now let's talk about buttons and menus.

Sounds exciting, doesn't it? Probably not. Desktop interfaces have been using menu bars as long ago as the first Macintosh, and buttons for even longer. What we think of as "buttons" are only a visual rendering of a physical device that predated GUIs anyway.

It's true that there is a lot of history here, and many best practices to follow. The standard platform style guides, such as Windows, Macintosh, and PalmOS, generally get you pretty close to a workable UI. Most users depend upon learned conventions to negotiate menus and find buttons, so it behooves you to follow those conventions, even when they feel restrictive or nonsensical.

Common functionality like cut, copy, and paste also carries lots of historical baggage—if it could be reinvented now, it probably would work differently, but even moderately experienced desktop computer users have learned how it's "supposed to work." The same is true for pop-up menus (context menus), which some users seem to look for everywhere, and other users never look for at all. Drag-and-drop isn't as bound by history, but it absolutely has to work the way users intuitively expect it to, or the illusion of direct manipulation is broken.

All that said, you can do some cool things to make your interface less dull and more usable. Your goals should be to make the right actions available, label them well, make them easy to find, and support sequences of actions. There are a few creative ways to do it.

First, I'll list the common ways actions are rendered to the user.

Buttons

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Some application idioms give you freedom to design nonstandard buttons and controls. Visual editors, media players, applications intended mostly for experts, instant messaging, games, and anything that's supposed to be fun and interesting all have users who might be curious enough to figure out how to use unusual but well-designed interface elements.

Where can you be more creative? Consider the items on the first list above; visible buttons and menus usually are easier to use than keyboard actions. Generalizing from those items, actions could be:

Clickable icons
Clickable text that doesn't look like a button
Something that reacts when the mouse pointer rolls over it
Something that looks like it may be a manipulable object
Something placed on almost any piece of screen real estate

How much creativity can you get away with before the application becomes too hard to figure out?

Figure 5-1: GarageBand

For a real-life example, look at the GarageBand application, shown in Figure 5-1. A lot is going on in this interface. Some objects are obviously buttons, like the player controls—rewind, play, fast forward, etc.—and the scrollbar arrows. You will find some sliders and knobs, too.

But look harder at the far right of the window, between the red line and the wood-grain edge. To your eyes, what pieces of the interface look clickable? Why? If you want, you can look ahead to Figure 5-2 and cheat. (And if you already know GarageBand, please bear with me.)

Figure 5-2: GarageBand actions

Figure 5-2 shows which objects on the interface perform actions. You clearly couldn't have known what they all do, since this book doesn't give you the benefit of tooltips, rollover cursors, or experimentation. But did you figure out that some of these objects could be clicked or manipulated? I'm guessing you did.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The first two patterns in this chapter talk about two of the many ways to present actions—one common, one not. When you find yourself reflexively putting actions on an application's menu bar or pop-up menu, stop for a moment and consider using Button Groups or Action Panels instead.

Button Groups
Action Panel

Prominent "Done" Button improves the single most important button on many web pages and dialog boxes. Smart Menu Items is a technique for improving some of the actions you put on menus; this is a very general pattern, useful for many kinds of menus (or buttons and links).

Prominent "Done" Button
Smart Menu Items

We'd like it if we could complete all user-initiated actions in an application instantly, but that's not reality—some actions are time-consuming. Preview shows the user what's going to happen before such an action is committed. Progress Indicator is a well-known technique for letting the user know what's going on while an operation proceeds, while Cancelability refers to a UI's ability to stop an operation when the user asks it to.

Preview
Progress Indicator

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Information graphics—including maps, tables, and graphs—communicate knowledge visually rather than verbally. When done well, they let people use their eyes and minds to draw their own conclusions; they show, rather than tell.

These graphics are my favorite kinds of interfaces. However, poor tools or inadequate design can sharply limit what you can do with them, and many information-rich interfaces just don't quite work as well as they could.

The patterns in this chapter will help you make the best of the tools you have, and introduce you to some useful and interesting innovations in visualization design. The ideas described in this introduction can help you sort out which design aspects are most important to you in a given interface.

"Information graphics" simply means data presented visually, with the goal of imparting knowledge to the user. I'm including tables and tree views in that description because they are inherently visual, even though they're constructed primarily from text instead of lines and polygons. Other familiar static information graphics includes maps, flowcharts, bar plots, and diagrams of real-world objects.

But we're dealing with computers, not paper. You can make almost any good static design better with interactivity. Interactive tools let the user hide and show information as she needs it, and they put the user in the "driver's seat" as she chooses how to view and explore it.

Even the mere act of manipulating and rearranging the data in an interactive graphic has value—the user becomes a participant in the discovery process, not just a passive observer. This can be invaluable. The user may not produce the world's best-designed plot or table, but the process of manipulating that plot or table puts her face-to-face with aspects of data that she may never have noticed on paper.

Ultimately, the user's goal in using information graphics is to learn something. But the designer needs to understand what the user needs to learn. The user might look for something very specific, like a particular street on a map, in which case she needs to be able to find it—say by searching directly, or by filtering out extraneous information. She needs to get a "big picture" only to the extent necessary to reach that specific data point. The abilities to search, filter, and zero in on details are critical.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

"Information graphics" simply means data presented visually, with the goal of imparting knowledge to the user. I'm including tables and tree views in that description because they are inherently visual, even though they're constructed primarily from text instead of lines and polygons. Other familiar static information graphics includes maps, flowcharts, bar plots, and diagrams of real-world objects.

But we're dealing with computers, not paper. You can make almost any good static design better with interactivity. Interactive tools let the user hide and show information as she needs it, and they put the user in the "driver's seat" as she chooses how to view and explore it.

Even the mere act of manipulating and rearranging the data in an interactive graphic has value—the user becomes a participant in the discovery process, not just a passive observer. This can be invaluable. The user may not produce the world's best-designed plot or table, but the process of manipulating that plot or table puts her face-to-face with aspects of data that she may never have noticed on paper.

Ultimately, the user's goal in using information graphics is to learn something. But the designer needs to understand what the user needs to learn. The user might look for something very specific, like a particular street on a map, in which case she needs to be able to find it—say by searching directly, or by filtering out extraneous information. She needs to get a "big picture" only to the extent necessary to reach that specific data point. The abilities to search, filter, and zero in on details are critical.

On the other hand, she might try to learn something less concrete. She might look at a map to grasp the layout of a city, rather than to find a specific address. Or she may be a scientist visualizing a biochemical process, trying to understand how it works. Now overviews are important; she needs to see how the parts interconnect into the whole. She may want to zoom in, zoom back out again, look at the details occasionally, and compare one view of the data to another.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Because this book deals with interactive software, most of these patterns describe ways to interact with the data—moving through it; sorting, selecting, inserting or changing items; and probing for specific values or sets of values. A few deal only with static graphics: information designers have known Alternating Row Colors, Multi-Y Graph, and Small Multiples for a while now, but they translate well to the world of software.

And don't forget the patterns elsewhere in this book. From Chapter 2, recall Alternative Views and Extras On Demand, both of which can help you structure an interactive graphic. Chapter 3 offers Annotated Scrollbar and Animated Transition, which help users stay oriented within large and complex data spaces.

The first group of patterns can apply to most varieties of interactive graphics, regardless of the data's underlying structure. (Some are harder to learn and use than others, so don't throw them at every data graphic you create— Data Brushing and Local Zooming, in particular, are "power tools," best for sophisticated computer users.)

Overview Plus Detail
Datatips
Dynamic Queries
Data Brushing
Local Zooming

Next is a set of patterns for tables and lists.

Row Striping

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Sooner or later, the software you design probably will ask the user to answer some kind of a question. It might even happen in the first few minutes of interaction: where should this software be installed? What's your login name? What words do you want to search for?

These kinds of interactions are among the easiest to design. Everyone knows how to use text fields, checkboxes, and combo boxes. These input controls often are the first interface elements novice designers use as they build their first GUIs and web sites.

Still, it doesn't take much to set up a potentially awkward interaction. Here's another sample question: for what location do you want a weather report? The user might wonder, do I specify a location by city, country, or postal code? Are abbreviations okay? What if I misspell it? What if I ask for a city it doesn't know about? Isn't there a map to choose from? And why can't it remember the location I gave it yesterday, anyhow?

This chapter discusses ways to smooth out these problems. The patterns, techniques and controls described here apply mostly to form design—a "form" being simply a series of question/answer pairs. However, they also will be useful in other contexts, like for single controls on web pages or on application toolbars. Input design and form design are core skills for interaction designers, as you can use them in every genre and on every platform.

First, a few principles to remember when doing input and form design:

Make sure the user understands what's asked for, and why.: This is entirely context-dependent, and any generalizations here risk sounding vapid, but let's try anyway. You should write labels with words that your target users understand—plain language for novice or occasional users, and carefully chosen argon or specialized vocabulary for domain experts. If you design a long or tedious form, take some space to explain why you need all the information you're asking for. If you're putting a control on a toolbar (or somewhere else equally space-constrained), and its use isn't immediately obvious, use a descriptive tooltip or other type of context-sensitive help to tell the user what it does.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

First, a few principles to remember when doing input and form design:

Make sure the user understands what's asked for, and why.: This is entirely context-dependent, and any generalizations here risk sounding vapid, but let's try anyway. You should write labels with words that your target users understand—plain language for novice or occasional users, and carefully chosen argon or specialized vocabulary for domain experts. If you design a long or tedious form, take some space to explain why you need all the information you're asking for. If you're putting a control on a toolbar (or somewhere else equally space-constrained), and its use isn't immediately obvious, use a descriptive tooltip or other type of context-sensitive help to tell the user what it does.
If you can, avoid asking the question at all.: Asking the user to answer a question, especially if it comes in the middle of some other task, is a bit of an imposition. You might ask him to break his train of thought and deal with something he hadn't expected to think about. Even in the best of cases, typing into text fields isn't most people's idea of a fun time. Can you "prefill" an input control with already-known or guessable information, as the Autocompletion pattern recommends? Can you offer a reasonable default value that removes the burdens of choice from 80 percent of your users? Can you avoid asking for it altogether?

There's one glaring exception to this principle: security. Sometimes we use input controls in a challenge/response cont

Table of Contents