Tabbed Dialogs: Semantic Minefields

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 men u 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.

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.

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.