by Wynn Inney
May, 2005
You're entering your mailing address into a form on the screen. In the box
labeled City you type Baltimore. But then you discover there's no box to enter your state. Instead
you see a scrollable list. When you click on it, you see an alphabetical list
of U.S. states from Alabama through Georgia with a vertical scroll bar to the
right. Using the mouse you scroll down until Maryland is visible. Then, just as you click on it, the mouse slips and
you've entered Massachusetts.
Even if you didn't make a slip, it took you much longer to go through that ritual than it would have taken you to type "MD" or even "Maryland".
Later on the same form you have to enter your birthday. When
you come to the month, you can't just type Oct or 10. You may even run into the
same process for the year, and if you're a mature person you now have to scroll
backward instead of forward.
| "A mouse will be useful for word processing when typists have three hands."
-- a 1980 software vendor's prediction |
Actually pointing devices have turned out to be quite helpful for many kinds of operation, even in word processing. But reaching for a mouse in the midst of entering data breaks one's rhythm and, at best, slows you down. Consequently, users who have strong keyboard skills prefer to rely on the arrow keys for movement and various "shortcut keys" for commands.
Furthermore, a mouse is really an analog device. It's all too easy to
slip and get an adjacent entry, not just with list boxes but also with
closely spaced buttons or other items. The effect of such an error may be
minor and easily corrected, as in the Massachusetts
example above, but in other situations, for example choosing
from a list of files, an error you don't notice right away can have very
severe consequences.
Of course, a scrollable list box doesn't require one to use the mouse, but it does tempt the unskilled user to do so.
The original notion behind the list box for data entry was to limit the users' choices to
legitimate values of a discrete data item, thereby reducing opportunity for
error. If I can't enter a non-existent or misspelled state abbreviation,
then that's one less possible data-entry mistake the program has to deal with.
Better still, I'm unlikely to enter MI
(Michigan) for Minnesota or
CO (Colorado) for
Connecticut1.
But what we've done is to simplify the program logic at the expense of the users. One of the first principles of software design I learned from Bob Rich2 was that it's better for a small number of people (programmers) to go to a lot of trouble once than for a large number of people (users) to go to a little trouble repeatedly. In most of these cases, it's a straightforward matter for the program to accept a name or abbreviation and then verify that it's a legal value.
It's not just the scrolling. The user doesn't need to be reminded that the acceptable values for sex are "M" and "F". Having to select from such a trivial list is not only annoying and inefficient but also tends to insult the user's intelligence.
As a general rule, we should prefer a simple text field to a scrollable list box or other type of predefined list of values. However, these two situations call for a list to prompt the user:
In such cases a so-called combo box, if well designed, may serve the needs of users of varying skill. The experienced user can type a text entry, which may or may not match an item in the list. On the other hand a less skilled user can still scroll through the list entries to find the desired one.
2 -- My boss and mentor at the Johns Hopkins Applied Physics Laboratory in the 1960s.
Return to GUI guidelines
IDI home page
Last modified May, 2005