Two iPod menus
Show each of the application's pages within a single window.
As a user drills down through a menu of options, or into an
object's details, replace the window contents completely with
the new page.
Your application consists of many pages or panels of content
for the user to navigate through. They might be arranged
linearly, in an arbitrary hyperlinked network, or -- most
commonly -- hierarchically. Address books, calendars,
web-based email readers, and other familiar applications
often use this pattern.
One or both of these constraints might apply to you:
- You are building for a device with tight space
restrictions, such as a handheld (see above), a cellphone,
or a TV. On these miniature screens,
Two-Panel Selector -- and
tiled panels in general -- are impractical because there just
isn't enough room to use them well. Traversing from one panel
to another on a TV screen is also difficult, since TVs have
- Even if you build for a desktop or laptop screen, you
may have a complexity limit. Your users may not be
habitual computer users -- having many application windows
open at once may confuse them, or they may not deal well with
complex screens or fiddly input devices. Users of information
kiosks fall into this category, as do novice PC users.
Keep it simple. When everything's on one screen or window,
the options at each stage are clear, and users know they don't
need to focus their attention anywhere else.
Besides, everyone these days knows how to use a web browser,
with its single window and simple back/forward page model.
People expect that when they click on a link or button, the page
they're looking at will get replaced, and when they click "Back,"
they'll go back to where they were before.
You could use multiple windows to show the different spaces that a
user navigates through -- a click in a main window may bring up a
second window, a click in that window brings up a third, etc. But
that can be confusing. Even sophisticated users can easily lose
track of where their windows are (though they can see several
windows side-by-side and place them where they want).
One-Window Drilldown is an alternative to several of the higher-density
patterns and techniques discussed here. As pointed out earlier,
may not fit, or it may make the screen layout
or interactions too complex for the typical user. Tiled windows,
Movable Panels, and
also have space and complexity issues. They don't work on
miniature screens, and they complicate interfaces intended
for novice computer users.
You are given one window to work with -- a miniature screen, a
full-sized screen, a browser window, or an application window that
lives on the desktop alongside other applications. Structure your
content into panels that fit gracefully into that window: not too
large and not too small.
On these panels, design obvious "doors" into other UI spaces, such as
underlined links, buttons, or clickable table rows. When the user
clicks on one of these, replace the current panel with the new one.
Thus the user "drills down" deeper into the content of the applications.
How does the user go back? If you're designing for a device with
back/forward buttons, that's one solution. If not, create those
buttons and put them in one permanent place on the window --
usually the upper left, where browsers put them. You should
put "Done" or "Cancel" controls on panels where the user completes
a task or selection; these controls give the user a sense of
closure, of "being done."
Remember that with no graphic depiction of the application's structure,
nor of where they are in that structure, a one-window application forces
the user to rely on a mental picture of how all these spaces fit
together. Simple linear or hierarchical structures work best.
In usability tests, make sure people can use the thing without
getting lost! Breadcrumbs and Sequence Maps can help if they do;
see Chapter 3, "Navigation."
Implementations of Hub and Spoke (Chapter 3) often
use One-Window Drilldown, especially on the Web and miniature
Mac OS X System Properties
The Mac OS X System Properties tool keeps everything within one window.
The main panel is on the left; a drilldown panel (for the Dock) is
shown on the right. There's only one level of drilldown panels.
The user goes back to the main panel via the "Show All" button
in the upper left.
Mac screens are often large, and OS X users are varied
in their levels of experience. The System Properties designers
may have chosen a One-Window Drilldown approach not because of
small screens, but because of the sheer number and diversity of
subpanels. That main panel takes up a lot of space, and it
probably didn't work well in a tiled
Two-Panel Selector window.
The Pine email client is a lightweight, text-only user interface
driven entirely from the keyboard. The greater-than and
less-than keys navigate the application's hierarchy: the main
screen, the list of mailboxes, the list of messages within the
selected mailbox (left), the text of the selected message (right),
and the attachments to the message.
Pine thus contains a deep hierarchy of UI "spaces," but it works well
within one window. Compare this screenshot to that of Mac Mail in the
pattern -- both are good interfaces, but they have very
different designs. We might guess that two stringent requirements
drove Pine's One-Window Drilldown design: to run in a text-based
terminal window, and to be operated with only the keyboard.