Bad UI of the Week: Don't Make Me Tell You Twice...
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.