Menu

Beta — We’re reformatting our articles to work with the new site, but this is one hasn’t been done yet; it may contain formatting issues. No need to report this. We’re working on it.

Tabbed Dialogs: Semantic Minefields

by Jared M. Spool
on March 1, 1996

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 tested 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 user makes changes in more than one tab before clicking
OK or 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
OK.

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 product works.

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 InfoBox shown below 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 unpredictable manner.

InfoBox with "when do changes happen" problem

Potential Solution: Visually Distinct Buttons

Windows 95 puts OK and Cancel buttons in a visually distinct area, to convey
the notion that these buttons affect all the tabs. Risk: This difference is
subtle. We have not yet tested its effectiveness with users.

Windows '95 tabbed dialog

Summary

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. •

About the Author

Jared M. Spool is the founder of User Interface Engineering. He spends his time working with the research teams at the company and helps clients understand how to solve their design problems. You can follow Jared on Twitter at @jmspool.