Optional Detail On Demand
Context: A large percentage of the available information
or actions (termed "items" for the rest of this pattern) can be considered
details, and are unneeded most of the time. This is a very
common situation which can happen in any of the primary patterns -- Narrative
Information Display (extra information), Form
(optional information provided by the user), and so on.
Windows 95 color dialog that opens to show a complete RGB color square
The "Advanced" or "Other Options" buttons that appear on many dialogs
The panel on front of some VCRs that hide everything except the basic playing
The fine print on credit card applications, purchase agreements, etc.
Visual C++ debugger tooltips that show a variable's value when the
cursor hovers over the variable in the source code
Problem: When should these usually-unneeded items
be presented to the user, and how?
Solution: Up front, show the user that which is
most important and most likely to get used. Details and further options
which won't be needed most of the time -- say 20% or less of expected uses
-- can be hidden in a separate space or working surface (another dialog,
another piece of paper, behind a blank panel). Mark it clearly
so that a user who needs this optional detail can find it immediately.
Place the "handle" to it (push button, panel door latch, etc.) very close
to the primary working surface, where everything else is, so a user doesn't
have to go hunting for it. Make sure that very little effort is needed
to get at it.
The user may be confused or overwhelmed if they are presented with lots
of items at once.
The most-often-used items should be right at hand, and distinct from the
details that may be unneeded; this helps orient the user towards what they
are most likely to need.
All the possible items should be easily available to the users that need
Sometimes there isn't enough space to show all the possible items.
Resulting Context: You need to figure out which
items are most needed, and which are optional. Know your users' needs
well. If you can't make a good enough guess on that basis, try putting
a few items on the top level and the rest hidden; observe your users using
the artifact, and as it becomes clear which items are the most often used,
"promote" them to the top level (and "demote" the ones at the top level
that never get used). In spite of this hit-or-miss approach, try
to make a coherent design out of the items at the top level.
This is a very common, simple way to manage complexity in an artifact.
It can sometimes fail, however. Consider a user who might always want to
see the optional detail: from the designer's point of view, perhaps only
10% of the total uses of the artifact require the optional detail, but
from this user's point of view, it is 100%! Now the user has to take an
extra step, every single time they use it, to see what they need to see.
If this is likely to happen, think about ways of making the optional detail
always visible, if the user takes some small action (like propping open
a panel door).
Note that you can nest these inside each other. In fact, some
computer applications bury optional details inside chains of dialogs that
can be 4 or 5 dialogs deep! This generally doesn't go over well with
users. It's easy to lose your place, for instance, and it's hard
to remember where something is or explain to someone else how to find it;
it also takes a lot of time and effort to reach something that deep.
Notes: If the optional detail takes up very little
space, don't bother with this pattern; you might as well fit it all into
the primary working surface.
Comments to: firstname.lastname@example.org
Last modified May 17, 1999
Copyright (c) 1999 by Jenifer Tidwell. All rights reserved.