Alternative Views:

What:

Let the user choose among alternative views that are substantially different from the default
view.

Use When:

When we’re building something that views or edits a complex document, list, website, map, or
other content. If those lightweight changes don’t go far enough to accommodate all the things
people typically do with it. We may face design requirements that directly conflict with each
other and can’t find a way to show both feature set A and feature set B at the same time, so
that’s when we need to design both separately and let the user choose between them.

Why:

We can’t always accommodate all possible usage scenarios in a single design. There are several
other reasons for Alternative Views:
 Users have preferences with regard to speed, visual style, and other factors.
 A user might need to temporarily view data through a different “lens” or perspective in
order to gain insight into a problem. Consider a map user switching between views of
street information and topographic information (see the example at the top of the
pattern).
 If a user is editing a slideshow or website, for instance, he may do most of his editing
while using a “structural” view of the document, containing editing handles, markers
for invisible content, layout guides, private notes, and so on. But sometimes he will
want to see the work as an end user would see it.

Examples:

1
In the two examples below, two graphic editors, Microsoft PowerPoint and Adobe Illustrator,
show different views of a work product. In the slideshow, the user normally edits one slide at a
time, along with its notes, but sometimes the user needs to see all the slides laid out on a
virtual table.

Responsive Disclosure:

2
What:

Starting with a very minimal UI, guide a user through a series of steps by showing more of the
UI as he completes each step.

Use When:

The user should be walked through a complex UI task step-by-step, perhaps because he is
computer-naive or because the task is novel or rarely done. But you don't want to force the
user to go page-by-page at each step http://internativa.com.br/mobile/Livro%20-%20Designing
%20Interfaces,%202nd%20Edition,%202010.pdf you'd rather keep the whole interface on one
single page.

Why:

In this pattern, the interface actually appears to be "created" in front of the user, one step at a
time. At first, the user sees only elements that are necessary for the first step. When the user
takes that step, the next set of elements is displayed in addition to the first ones, then the next,
etc. As the user sees the task unfolding directly in front of him via a dynamically growing UI, he
can form a correct mental model of the task more quickly and easily. None of the awkward
context switches that separates wizard screens impose exist here: the users aren't yanked out
of their workflow into a rigid set of modal screens shown one at a time. Furthermore, since the
UI is kept together on one page, the user can easily go back and change his mind about earlier
choices. As each step is redone, he immediately sees the effect on subsequent steps. This is
better than jumping from one content-starved wizard screen to another. For occasional tasks,
this device can work better than presenting a complex and interlinked set of controls all at
once, because it's always obvious what the first step is and the next, and the next. The user
never has to think too hard.

Advantage:

If you use Responsive Enabling, you will put all the controls for all choices on the UI you'll just
disable the irrelevant ones until they become relevant (again, in response to the user's choices).
Sometimes that can make the UI too cluttered or complicated-looking. It's a judgment call: if
you need to fit the UI into a very small space, or if you think too many controls on the UI might
look bad or make users nervous, use Responsive Disclosure instead.

Example:

This example comes from an internal application at Northwestern Mutual. The user first selects
"TSO" for Request Type; the application then shows a new box, asking for TSO information.
When the user then selects "Delete ID," a third box appears. The history of this user's choices
remains visible on the page.

3
Responsive Enabling:

What:

Starting with a UI that's mostly disabled, guide a user through a series of steps by enabling
more of the UI as each step is done.

4
Use When:

The UI walks the user through a complex task step-by-step, perhaps because he is computer-
naive, or because the task is rarely done. But you don't want to force the user to go page by
page at each step you'd like to keep the whole interface on one page. Furthermore, you want
to keep the interface stable; you'd rather not dynamically reconfigure the page at each step, as
you would with Responsive Disclosure.

Why:

Like Responsive Disclosure, this pattern takes advantage of the malleability of computer
displays to guide the user through the interface interactively. The user thus gets a chance to
form a correct mental model about cause and effect. The UI itself tells him the possible
consequences of some choices: if I turn this checkbox on, then I have to fill in these four text
fields that just got enabled. Furthermore, the user can't do things that would get him into
trouble, as the UI has "locked out" those actions by disabling them. Unnecessary error
messages are thus avoided.

Example:

This is a typical example of disabling based on a binary choice: should OS X show the date and
time on the menu bar, or not? If the user chooses to show it, then she gets panoply of choices
about how it ought to be shown. If not, the choices are irrelevant, so they're disabled. This
behavior (plus the indenting of the options under the checkbox) tells the user that these
choices affect the date/time display which the checkbox toggled and nothing else.

Mac OS X System Preferences

Progress Indicator:

Progress bar in a modal window

5
What:

Show the user how much progress has been made so far on a time-consuming operation.

Use when:

A time-consuming operation interrupts the UI, or runs in the background, for longer than two
seconds or so.

Why:

Users get impatient when the UI just sits there. Even if you change the mouse pointer to a clock
or hourglass (which you should in any case, if the rest of the UI is locked out), you don’t want to
make a user wait for an unspecified length of time. Experiments show that if users see an
indication that something is going on, they’re much more patient, even if they have to wait
longer than they would without a Progress Indicator.

Example:

Adobe installation progress indicator

Multi-Level Undo:
What:

Provide a way to easily reverse a series of actions performed by the user.

Use when:

You’re building a highly interactive UI that is more complex than simple navigation or form fill-
in. This includes mail readers, database software, authoring tools, graphics software, and
programming environments.

6
Why:

The ability to undo a long sequence of operations lets users feel that the interface is safe to
explore. While they learn the interface, they can experiment with it, confident that they aren’t
making irrevocable changes even if they accidentally do something “bad.” This is true for users
of all levels of skill, not just beginners.

Examples:

The figure given below shows a more typical presentation of Multi-Level Undo. In this case, the
user typed some text and then inserted a table. The first undo removes the table. Once that’s
done, the following undo the next action in the undo stack represents the typed text, and
invoking Undo again will remove that text. Meanwhile, the user has the opportunity to “undo
the undo” with the Redo menu item. If we’re at the top of the stack, there is no redo, and that
menu item is overloaded with a Repeat action.

Local Zooming:
What:

Show all the data in a single dense page, with small-scale data items. Wherever the mouse
goes, distort the page to make those data items large and readable.

Use when:

You’re showing a large data set using any organizational form—plots, maps, networks, or even
tables on either a large or a small screen. The user is able to “point at” places of interest with a
mouse cursor or a touch screen. Users will browse through the data or search for points of
interest within that organizational structure (e.g., finding a date in a calendar). High-level
overviews are necessary for finding those points of interest, but users don’t need to see all
available detail for all data points at once zooming in is sufficient for getting fine detail. Some
forms of Local Zooming, especially fisheye lenses, are appropriate only if your users are willing
to learn a new interaction technique to gain proficiency with a particular application.

7
Why:

Ordinary zooming works well for most high-density information graphics, but it takes away
context: a fully zoomed view no longer shows an overview of the whole data set. Local Zooming
focuses on local detail while retaining context. The user remains in the same conceptual space.

Example:

Cartifact’s map lenses literal ones, yet remarkably beautiful allow the user to set both the
magnification level and the drawing style inside the lens. These remove much of the user’s
need to keep zooming into the map for detail, then back out again for context, then back in
again for more detail. The alternate drawing styles let the user see one area in several
complementary ways, without affecting the entire map.

Treemap:
What:

Express multidimensional and/or hierarchical data as rectangles of various sizes. You can nest
those rectangles to show the hierarchy, and color or label them to show additional variables.

Use when:

Your data is tree-shaped (hierarchical). Alternatively, it may be multivariate each item has
several attributes, such as size and category, which permit items to be grouped according to
those attributes. Users want to see an overview of many data points maybe hundreds or
thousands and they’re using screens large enough to accommodate a large display. Treemaps
are not always easy to read, especially for people who haven’t seen them before. Furthermore,
they work better on-screen than they do on paper, because Datatips, Dynamic Queries, and
other interactive mechanisms can help users understand the data.

8
Why:

Treemaps encode many data attributes into a single dense diagram. By taking advantage of
position, size, containment, color hue and/or value, and labeling, a treemap packs a lot of
information into a space that encourages the human visual system to seek out trends,
relationships among variables, and specific points of interest.

Example:

The Newsmap illustrated the “news landscape” as described by Google News in figure given
below. At any given moment, the Newsmap could collect Google’s top headlines and draw a
treemap in which the largest blocks represented the most reportedon stories.

The encodings here are:

 Block size: “popularity” of news item; how many news outlets reported this story
 Color hue: topic
 Top-level grouping: also topic
 Color value (darkness/lightness): age

Because the headline’s text size is proportional to block size, which in turn is proportional to
popularity, your eyes are immediately drawn to the biggest news items. This treemap is thus an
automatically constructed visual hierarchy

9
10