Technical Opinion: Deconstructing the ‘Any’ Key

A popular techies’ tale goes as follows. A user calls customer support with a problem: "The program says ‘press any key to continue’ but I can’t find the any key on the keyboard."

Stupid user.

We suppose this story is apocryphal. Most people have a reasonable understanding of language even if they aren’t familiar with computers. But we’re not surprised if some user has had this very difficulty figuring out the "any" key.

Our point is that although an actual user may or may not be as ill-informed as the apocryphal one, virtually all real programmers are insensitive. And we don’t mean personal insensitivity. We mean technical insensitivity, the kind that results from viewing a problem solely from one’s own perspective.

We imagine the programmer writing the instructions to press any key wants to delay processing until the user has acknowledged reading some message. (This is called a dialogue, although it doesn’t allow much in the way of conversation.) The programmer writes a simple program to achieve this effect—let’s call this desired behavior "acknowledged continuation." This program might look something like the following in pseudo code:

• <stuff done before>
• display("press any key to continue");
  get_character() <implied wait>
  <stuff done after>

This is a nice program and gives every indication of being reliable. The program displays a message and awaits an input from the user. As soon as an input, any input, arrives, the program can continue.

When the user sees the message "press any key to continue," he or she (usually) has a readily available keyboard. By definition, one would expect, a keyboard is something with keys.

But not all keys are alike. Experienced users know to press a key that works, such as the space bar or the enter key. However, this is more a matter of a user having been trained through past experience to press the right keys than a matter of the specification itself being clear.

For instance, some of the keys have no effect. Press the shift or control key and nothing happens. Press the caps lock key and it may affect what you type later, but the program still doesn’t budge. On some computers, when the alt key is pressed, something weird may happen. Ditto with the function keys.

Press the power on-off key, which exists on some keyboards, and the results may be far more dramatic than desired. It is fair to say the program will not continue as promised.

Some key combinations count as one key. Press shift and a letter (say, j), and it works fine, as any programmer would expect. However, some key combinations are dangerous. In the Windows world, the control-alt-delete combination opens up a window listing running programs that the user may kill. A second control-alt-delete can reset the computer. In the Unix world, control-C can kill a program and control-Z suspends it. Control-S can suspend any output.

The gist of this is that a specification saying "press any key to continue" is far from unambiguous to the user. It may seem clear from the programmer’s perspective because the program receives an input only under circumstances that the underlying operating system deems appropriate, that is, only when an acceptable key is pressed. So the right display message ought to be, "press any acceptable key to continue." However, such an instruction would be meaningless, because the term "acceptable" has no obvious interpretation.

The moral? We as programmers should take into account alternative perspectives, especially the users’ perspective. To understand a communication from the perspective of its recipient is one of the lessons of deconstruction theory.

A lot of people talk of the importance of being user-centered. Here is a case where being user-centered has direct consequences on our programs. Although thinking from another perspective is rarely as easy as in the case of the "any" key, we must keep trying.

As for the matter of acknowledged continuation, just ask the user to press the space bar.

Back to Top