Bad UI of the Week: Don't Make Me Tell You Twice...

Tired of furnishing the same information over and over again? It happens in the real world and with your applications, too. This week, David Chisnall takes a look at the habit of some software to make users repeat themselves and some of the ways it can be avoided.

I recently spent some time on board a flying machine on the way to the USA.
Since it’s a long flight, the airlines tend to serve you some
approximation of food. They also tend to try hard to not give you enough to
drink, so I always end up dehydrated and bad-tempered when I land.

On this particular trip, as always, I had booked a vegetarian meal via my
travel agent. Somehow, this piece of information failed to be passed on to the
airline. This was particularly incompetent, since a friend who had booked her
flight at the same time, with the same booking service, did manage to get her
wheat-free meal order passed on correctly.

This was not a new experience for me. I tend to assume incompetence on the
part of airlines, and so I had eaten before boarding. As such, I was quite happy
to skip the meal (they were able to provide some snacks, but I didn’t eat
most of them in the end).

On the way, back, exactly the same mistake happened. I’ve been in this
situation before, and been told that I need to telephone the airline 72 hours
before my return to get them to fix their act. This is not always possible, and
is very inconvenient when it is not. (Incidentally, I’m not naming
airlines here because exactly the same thing has happened with several of
them.)

Now the obvious problem is that the airline already knows that I am a
vegetarian. Why do I need to telephone them and tell them again?

The fact that only one part of the organization knows—and a different
part needs to know—might be a valid reason from the perspective of a
manager, but not when viewed by a user of their services.

Exactly the same problem exists for a number of applications. For example,
most operating systems I have installed have asked me to select a language,
keyboard layout, and finally a time zone. Once I have selected British English
as the language, and a UK keyboard layout, they seem to think that somewhere in
the US is the most sensible location for a time zone.

To a software designer, these three attributes are completely independent.
One is used to set the resource file that is loaded by the installer (and later
by other applications), one is used to set a key mapping, and the last is used
to set the system clock.

To a user, however, it is obvious that they ought to be connected. They are
all attributes that are likely to be tied to location. If I am in France, I am
likely to want French, an AZERTY keyboard layout, and GMT+1 as my base time
zone.

Asking for information twice is not limited to installers, although they are
the most common culprits. In some cases, even asking for information from the
user once is too much. Installing an office suite very often asks you to enter
your full name and address, so that this can be used with "letter"
templates.

All this information can be found in the system-wide address book, in the
"me" vCard. On most multiuser systems, the user’s real name is
part of their login record, and can be retrieved at runtime by any program.
Similarly, the locale is stored on a per-user basis, giving a good default for a
dictionary language.

The whole concept can be generalized to that of sane defaults. Very few
pieces of information exist in isolation. In any program, it is likely that
something that is being requested from the user can be inferred from existing
knowledge.

Unless a bad guess would result in data loss, it is usually a good idea to
make the guess and let the user change it later.

If you’re right 90 percent of the time, even if it takes twice as long
for users to have to make an explicit selection, they have saved some time.