Every couple of weeks or so, I fill my car with gas at the self-service station near my house. The visual interface for payment, somewhat unfortunately, looks like a child's paint box: the buttons are red, green, yellow, and white, some with stripes and some solid-colored. From a procedural point of view, however, the system is well-designed.

A small screen asks me, "Would you like to pay inside?" I usually pay directly at the pump with a credit card, so I press the "No" button. The screen instructs me to slide my card through the reader, which I do, and then asks me, "Is this a debit card?" Again I press "No". The screen tells me that my card is being authorized, and after a few seconds instructs me to pick a grade of gasoline and begin pumping. When I put the nozzle back into its slot, the system beeps and asks, "Would you like a receipt?" I am not such an organized person, and so I press "No", get back into my car, and take off.

The system lays out a straightforward procedure with guidance at each step, well-suited for people who encounter it for the first time. But what about frequent users? Once, when I was in a bit of a hurry, I had a thought: what would happen if I simply ignored the system's messages and followed the sequence of actions that I always do? As it turned out, this works perfectly well. Instead of pressing a button three times and waiting for instructions about what to do next and when, I just slide my card and pump my gas.

Paying inside the convenience store is no more difficult; I use the pump and then go inside to pay with cash or plastic when I'm done. Paying at the pump with a debit card is more involved, because then I must press a button to tell the system the difference between a credit card and a debit card, but the extra interaction step is not unreasonable, since I will have to spend the time to enter my personal identification number in any case. Overall, the process is as streamlined as possible and flexible enough to meet the limited requirements of the task. (Whether the streamlining is easily discoverable is a topic for another essay.)

While there are several ways we might describe the design of such interactive systems in human-computer interaction terms, my favorite description comes from the literature of statistical software. Daryl Pregibon and David Lubinsky use the word "accommodation" to describe the extent to which a system allows its behavior to be controlled by knowledgeable human guidance. If users lack this knowledge, they run into problems. My students have reported several examples from their interaction with embedded computers:

"In the campus library there is a machine that lets students add money to their copy cards, so that they can use the photocopiers. The machine has directions on the front panel that instruct the user about the process. However, the instructions are in no particular order, but rather are written next to each slot for the copy card, cash, change, etc. It can take people a few tries to successfully put money on a card because they have skipped a step or carried out steps in the wrong order."

"At my job we have a machine that customers have to use to pick up larger items that they have bought. The machine scans a receipt and notifies the stockers which items should be brought out. Unfortunately, customers often complain that the machine is broken--it doesn't scan their receipt, or it doesn't work at all. Someone has to come out and tell them that they need to answer a few questions on the machine, using the touch screen, and only scan their receipt when the machine is ready for it."

"When I use the ATM at the check-out counter in my supermarket, the first choice it gives me, even before I can swipe my credit card, is "English" or "Espanol". It seems to me that almost everyone who uses the machine will speak English, so it would be more efficient if English were the default. At some other ATMs, you can enter your PIN and so forth right away, but in the bottom corner there's a button that lets you switch to another language if you need to. I think on average it's faster, even if it's only one step saved for most people."

At first glance, it might seem straightforward to avoid comparable problems in software that runs on desktop platforms, independent of a physical task that must be carried out. After all, if accommodation is about allowing users to do what they want, unconstrained by an arbitrary task ordering, then direct manipulation interfaces, with their pull-down menus, non-modal dialog boxes, and so forth, are as accommodating as might be desired. As with most apparently desirable interface properties, however, there are tradeoffs involved.

Applications continue to grow in complexity (offhand, I don't know of any software package that has less functionality than in its previous release). Many applications now offer the user wizards, assistants, macro definition capabilities, and so forth, to help walk through complex procedures. Maintaining the balance between system guidance and accommodation of user decisions can be difficult. Every time I begin a computer-based presentation using popular software, for example, an interface assistant will ask me whether I need help with the projector, until I explicitly tell it not to ask me again. The same assistant sometimes blocks my view of buttons I would like to press and must be moved out of the way. These are only minor irritations, but they illustrate the pitfalls in supporting effective human-computer collaboration.