The whiteboard

XI.5 September + October 2004
Page: 30
Digital Citation

Log on, tune in, drop down


Authors:
Ken Becker

You’ve got a challenge: A bank has decided to provide its customers with online banking and has declared you Web Designer Extraordinaire. On the statement page, you have to show the account number and the name of the month for the statement displayed. You want to provide a way for the user to choose a different month. You consider radio buttons, but 12 months displayed with radio buttons takes up quite a bit of screen space. You consider using a pop-up menu to display the list of months, but you’d have to add text to the page to show the current setting, again taking up more space than you want. You really want to display the current setting (the month) and also provide the user a way to change the setting using one standard GUI control, but you just can’t see how.

What do you do? You fantasize about inventing a brand new interface element (just what the world needs, eh?). Or maybe you’ll take an existing element and exercise your creativity, adapting it to your needs and modifying its behavior just a wee bit.

The drop-down list box (see Figure 1) might be just the ticket: It enables you to display the current setting (the month), while providing a way to change it. It also provides a more natural affordance: visual cues (the text box and the down arrow to its right) that hint at a list from which users can select. But this too has a hitch: Once the user chooses a new month, how does that statement get displayed? Some sites place a "Go" button next to the drop-down list. Others expedite the process by omitting the "Go" button—they invoke an action automatically, as soon as something is selected.

History of a Drop-down

The drop-down list box originally arose from the need to save valuable screen space. Drop-downs typically appeared on forms to make data entry easier and more accurate. The form included a single "submit" button to make all the changes at one time.

At some point, Web designers began using the drop-down list for navigation—the user would choose the desired link and then click the "Go" button. But Web designers wanted it to behave more like a link, where it takes you to the page as soon as you select it, so they added code to make drop-down lists automatic.

However, making a drop-down list automatically take action overloads the interface element; it’s a misuse of the drop-down.

The Heat of Debate

Now, a clever designer can find a way to misuse any interface element. In fact, the drop-down list box probably has more than its share of potential misuses—some still undiscovered! We all face temptations to base design decisions on what we ourselves like and what seems common sense to us, rather than following user interface guidelines and interaction design principles.

The automatic drop-down list violates the classic principle of predictability. Software should, by its appearance and behavior, enable users to predict how any given object will work. This will assure them that a given action will always have the same effect. But wait! Even usability professionals, who focus on how things work for users, can’t come to consensus about the usability of the automatic drop-down list.

On the one hand, usability tests consistently show that people experience problems with drop-down lists that lack a "Go" button. I’ve actually witnessed people complaining that they had no "Go" button when they encountered a drop-down list that automatically took action. In addition, many usability specialists argue that automatically performing an action overloads the original intent of the drop-down list—to make a selection.

On the other side, some tests of drop-down lists have seen few people complain about automatic activation, and some people like that it saves them a click.

Drop-down lists can also hide important contextual information: Seeing just one entry in a list of unrelated items (e.g., "Products," "Services," "Support," "Requests," and "Solutions") gives no clue to the other choices, because the visible item lacks context. In contrast, if you see "Tuesday" in a drop-down, you can easily infer that the list contains the days of the week.

A drop-down list that automatically takes action will inevitably confuse users who come to expect a certain behavior from standard interface elements. It makes them stop and think, increasing their cognitive workload and causing them to pause and wonder, "What just happened? I didn’t tell it to do anything!"

Is it worth it? I certainly don’t think it’s worth it—should we knowingly introduce confusion, simply to save the user a click? Meeting expectations for interface behavior outweighs small improvements in efficiency.

Every—and I mean every—design decision involves a tradeoff. Let’s consider what we trade off when we overload a drop-down list. In the classic GUI, we trade screen space for visibility. You can maximize visibility by displaying an entire list of available choices; or you can save screen space by displaying only one of the available choices (and requiring the user go to some effort to see them all).

Standards Settle the Debate

Misuse also invites inconsistency. I’ve seen different pages handle drop-downs differently within the same Web site. Figures 2 and 3 show two different drop-downs found on the same news site. One takes action automatically; the other has a "click" button (which looks more like a comic-strip flash than a button). This inconsistency will confuse and frustrate people. Imagine selecting a date from the list in Figure 3 but not noticing that "click" is a button. Patiently you wait for a new page to appear—and wait, and wait…

For an example of consistency that works, consider the Macintosh interface. The usability community has largely regarded the Mac as easier to use than other graphical user interfaces because Apple requires Mac applications to comply with comprehensive GUI design guidelines. Every application must provide certain basic commands and each interface element has its proper use.

Well-researched and well-written guidelines and standards should suffice to settle debates about the use of fundamental interface elements. Designing by the book isn’t boring; it simply helps make things easier and better for people who use computers. After all, that’s what usability is all about.

Sure, standards can be stuffy old documents that people seem to talk about in quiet whispers. But they promote consistency, which pays off time after time because people need form only one mental model about how things work. That same model serves them in each interaction.

Imagine a city that uses yellow triangles for its stop signs. All of the city’s inhabitants learn that these signs mean "stop" and all is well, with no complaints or accidents among local residents. But visitors are another story. They become confused by the yellow-triangle stop signs, and have a few accidents. As typically happens, the city places the first blame on the visiting motorists because, well, surely they can’t see straight; their eyes must be shot. Yet we, with our more global perspective, can see that the designers of the road signs bear much more of the responsibility for the problem, having failed to adhere to standards. So what if they did win the Road Construction Academy Award for clever innovation in the Road Sign category?

A Worst Case of Misuse

Want to commit the worst possible offense against consistency? Build a multi-personality Web page whose drop-down lists just can’t make up their minds how to behave. Take, as an example, an online e-mail system (see Figure 4) where one drop-down is automatic and the other has a "move" button. I can’t tell you how many times I’ve expected one of them to behave like the other, having been conditioned by the one I use most often.

I continue to fall victim to it even though I know the problem exists. Why is it that an experienced, savvy user could repeatedly find himself making mistakes using common interface elements? It must be my fault, right? I’ve used this e-mail system frequently. But a finer eye toward usability observes that these "mistakes" are not the fault of the user, but owe their existence to other factors, usually cognitive ones, that explain why the same mistake occurs repeatedly.

I’ve noted some instances of popular Web sites that have stopped using automatic drop-down lists. Either they have returned to using it only for selection, and providing a "Go" button; or they have changed the design entirely and removed it altogether. Some sites that once used automatic drop-downs have changed their ways, and now include a "Go" button. Do you suppose that discovery of user confusion drove these changes? One can only hope.

But Ma, Everyone Does It!

Does this fundamental inconsistency really create a problem? Many very popular Web sites have misused the drop-down list. This widespread use sort of sets a precedent and indicates that this approach has an implied success. After all, if they’re so popular, these Web sites must be user friendly—right?

Not so fast. Remember the age-old question that parents so freely throw at their teenagers? "If all your friends jumped off a bridge," they ask, "would you do it too?" To which the kid sheepishly replies "No…" And to which, as designers, we should say, "Of course not!"

Can Everyone Use It?

Suppose you use a keyboard and screen reader (or perhaps a keyboard alone) to navigate the Web. You use the Tab key to move to the drop-down list. You hit the "down" arrow to start moving down the list of options. But as soon as you reach the first item, poof! the site whisks you to another page, without letting you read the other items in the list, let alone choose one. No one disputes that automatic drop-down lists provide a horrid experience to users in those situations.

The automatic drop-down list doesn’t work in all browsers either; which means users of such browsers can’t navigate at all. Accessibility may prove more significant than any other factor in driving the return of the "Go" button with every drop-down list.

Just "Go" for Usability

Did we not learn that we violate standards and guidelines at our own (or our user’s) peril? Maybe they’ll just stumble; then again, maybe they’ll do a full-fledged nose-dive into interaction hell! I’ve seen people fail entire tasks for less than a misused drop-down list.

Good design says it’s better to prevent errors than to have to correct them. Even if we provide a way to "Undo," people still have to go to the trouble of correcting the "mistake."

Meanwhile, back at the bank…

If you need to show the month for the currently displayed statement and want to use the same control to select a different month, the drop-down list fits the bill. But don’t undermine this useful selection mechanism by pumping it up with a little extra action. Just include a "Go" button, and you’ll reinforce the mental model that users have already developed. You will also improve the chances that your interface will behave consistently and predictably in the many different browsers and will be accessible to those who use screen readers and keyboards.

Don’t let the minor efficiency of saving a click blind you to the major benefits that consistency and predictability can provide.

Author

Ken Becker
ken.s.becker@pss.boeing.com

Ken Becker works as a usability engineer for the Boeing Company. A systems engineer and programmer turned usability guy, he enjoys the challenge of improving the user experience. Ken’s extensive work on the Boeing intranet portal has focused on usability standards, single sign-on, online community design, and search behavior of business users. At the park, he enjoys taking flying leaps at volleyballs; in the garden, coaching fragrant rose blooms to unfold.

Figures

F1Figure 1. Sample drop-down list

F2Figure 2. Drop-down list without a "go" button

F3Figure 3. Drop-down list with a "go" button (named "click")

F4Figure 4. Mixed use: automatic and select-only drop-down lists on the same page.

©2004 ACM  1072-5220/04/0900  $5.00

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2004 ACM, Inc.

Post Comment


No Comments Found