TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Tabbed Dialogs: Usability Information From:"Jared M. Spool" <jspool -at- UIE -dot- COM> Date:Thu, 29 Aug 1996 23:42:26 -0500
The following article is a reprint, with permission, from Eye For
Design, a newsletter dealing with interfaces and usability.
Information on getting a complimentary issue of Eye for Design
follows the article:
TABBED DIALOGS: SEMANTIC MINEFIELDS
They're All The Rage In Paris
Tabbed Dialogs are popping up everywhere from Windows 95 to OS/2
Warp. They seem to be the latest "de-facto standard" for offering
users controlled options in a GUI. Since they're so popular, they
must be easy to learn and use, right? Well, not so fast. Our
observations of the current generation of tabbed dialogs suggest that
they may be creating more usability problems than they solve. Here's
why these GUI elements may not be as helpful as they initially seem.
Designers Love Them But Users Struggle
The perceived benefit of tabbed dialogs is that they group several
related functions together, theoretically making the user more
productive by quicker access to functionality. At the same time,
the designer combats an ever-increasing usability problem-complexity
and multiple levels in the top-level menu- by pushing some of this
functionality down to the tabbed dialog.
Tabbed dialog design contains the following implicit assumptions:
* The user typically uses the functions grouped in the dialog
together ( if not, there may be no advantage in combining them)
* Order of usage is difficult to predict (if it is predictable, a
fixed sequence of screens makes more sense)
Well, this is fine in theory. What appears to be the case with
current implementations is that old usability problems have been
replaced with new (and better) ones. In most cases usability
problems we see have a common underlying (and familiar) pattern;
Users mess up and they can't figure out why...
When Do Changes Take Effect?
When we've teated tabbed dialogs, the biggest problem we have seen
is that users have trouble knowing exactly when changes will take
effect. The confusion arises when the makes changes in more than one
tab before clicking OK of Cancel.
Users' behavior indicates that they expect the changes to take
effect when they leave that tab (when in fact it isn't until they OK
the entire dialog). For example, we've seen spreadsheet users
(experienced with Excel 4) go into Excel 5's Format Cells and make
some changes under several tabs. Then they switch to another tab
that doesn't have anything they need, so they click Cancel. Users
react with surprise and dismay when they see that the application did
not make any of their changes.
Part of the problem is that clicking OK commits the user to changes
they can no longer see. One solution is to ask users each time they
switch tabs whether or not to save any changes. This could be
cumbersome if they frequently make changes in more than one tab
(which after all, is part of the reason why we have tabbed dialogs in
the first place). A variation of this idea is to put up a message
informing the user that changes are not accepted until they click
A Distraction From Users' Goals
There's also a problem with the amount of time users are taken away
from their goal. Tabbed dialogs are, by implementation, a
distraction. Users want to think about the content of their work,
not manipulating the interface. Once they get to the tabs they are
two levels away from their work -- one level is the options (font,
color, borders), one level is how to work the tabs (What does OK do?
What does Cancel do?). While coping with the semantics of tabbed
dialogs, users become too removed from their work.
These confusing semantics appear to be a given for functionality
"organized" in tabbed dialogs. Not many other controls in user
interfaces ask users to deal with second-order semantics to this
degree, or to operate at such a cognitive distance from the task
they are working on.
Inaccurate Mental Models
As users interacts with a product, they form a mental model of how
that product works. The model grows incrementally based on cause
and effect observations of user actions and product response. When
changes happen "in the dark" (such as changes made under one tab
becoming effective when the user exits the dialog-perhaps from
another tab entirely), it is difficult for users to understand how
and why the changes occurred. When users make mistakes with tabbed
dialogs they often do not figure out how or why the mistakes
happened. So users develop an inaccurate mental model of how the
There are two consequences of an inaccurate model: either the user
builds inefficient patterns of use into his or her way of working
with the product, or the user abandons functionality because the
mental model shows it to be unreliable or taxing. Either way the
user's productivity and satisfaction with the product takes a hit.
Non-Modal Tabbed Dialogs: Different, But Not Better
The Lotus Approach Info Box avoids the "when-do-changes happen"
problem. The InfoBox has no OK or Cancel-as the user makes each
change, it is immediately reflected on the selected object. The set
of tabs presented to the user depends on what object is currently
selected. This leads to another kind of confusion.
The InfoBox's behavior confuses users because they don't realize
that any click outside the InfoBox selects a different object. For
example, we've seen users click outside the InfoBox in order to
close a drop-down menu without making changes. This has a side
effect of selecting a different object, which can cause the set of
tabs displayed in the InfoBox to change.
Some users were unable to explain why the tabbed dialog kept
changing, even when we showed it to them several times. As far as
they could tell, the InfoBox was behaving in a spontaneous and
Tabbed dialogs seem to be very effective for complex operations
which are used infrequently. However, using them (as currently
designed and applied) for simple, frequently-repeated operations such
as property settings will lead to annoyance and lost productivity.
To use tabbed dialogs properly, users must reach beyond the familiar
set of GUI operations. Nothing else in the standard tools requires
this kind of abstraction, and experience with other applications does
not help explain what went wrong when the user gets an unexpected
result from these dialogs.
Tabbed dialogs are seductive. Designers like them because they
organize and arrange complex sets of operations clearly. Users like
them at first glance for the same reason, but in using the product
user attention is focused on the work, not the user interface tools.
The intricate semantics that make the organization of the dialog
possible become hazardous when the user's attention is elsewhere.
Our final judgment on the current generation of tabbed dialogs is
that they often cause more confusion than they are worth.
Eye for Design is published 6 times per year from User Interface
Engineering, a consulting firm specializing is product usability
issues. If you would like a complimentary issue, send your postal
address to EFD -at- uie -dot- com -dot-
Jared M. Spool User Interface Engineering
jspool -at- uie -dot- com 800 Turnpike Street, Suite 101
(508) 975-4343 North Andover, MA 01845
fax: (508) 975-5353 USA
Check out User Interface '96: http://www.uie.com
TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send administrative commands
ALL other questions or problems concerning the list
should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-