Simple question, but I'm on the fence as to the answer. If I design a "Press any key to X" screen, should I register the Esc
key as one of those "any key"s, or as a cancellation control? Is there an alternative answer I'm not considering?
-
10There's a school of thought that says you should never say "press any key", partly because the old joke about confused newbies looking for a key labelled "any" isn't entirely a joke. In any case, it isn't strictly any key, at least on most platforms - e.g. what if they press the shift key? Or caps lock? Does it make sense for the "Pause" key to make the computer do something other than pause?– Steve314Dec 24, 2014 at 22:28
-
1You can require that the key be held for a second or two to do the action, or to cancel. That lets you keep Esc as a cancel input and has the nice effect of filtering out accidental key presses. A game called Jamestown uses that approach for keybindings coupled with an animated bar that shows how much longer the key needs to be held.– DovalDec 25, 2014 at 0:46
-
"press any key" screens are a bit of an antiquated concept, aren't they?– DA01Dec 25, 2014 at 16:56
-
@DA01 yes, but still necessary at times– Ky -Dec 25, 2014 at 17:19
-
People aren't idiots, if they press escape and an exit menu pops up instead they will just close the exit menu and press a different key to continue.– Albert RenshawMay 26, 2016 at 8:25
3 Answers
The problem has to do with two rules not yet discussed:
Does the esc key always map to an "exit command" elsewhere in your software? And
What would the execution of such an "exit command" do logically at that screen? Is there another possible outcome than whatever happens when any other key is pressed?
In other words, if the only possible result (exit or any-key) after that screen is displayed is the same, then treat the esc as an any-key and get on with your day, because there's nothing else to worry about.
-
1I love this answer for what it is but I feel like it only covers one case, when the esc key does the same as any other. I think it would be really helpful to cover what to do if escape did serve a secondary exit function, which would be the more complicated UX case in the first place. Either way +1 May 27, 2016 at 1:35
-
Sure, ok. I suppose the limitation there is indeed in the OP's question. To pick an example, the UI should be saying something more of the form "Press any key to ..., or <esc> to abort", but there's no clear example of what he's intending here, so I took it at face value. Jun 8, 2016 at 2:22
If I design a "Press any key to X" screen
You probably should avoid doing this in the first place. Consider the following.
For most ordinary people using your software,
- "any key", taken literally, certainly includes the key labelled Esc".
- "any key", includes shift. And caps-lock and num-lock.
- "any key", includes the key labeled SysRq (System Request).
- it includes other keys that may not seen by your application - for example when your application is being run using something like a remote-desktop client or a VM console. The effects may be very undesirable and not the "X" you promised.
- it arguably might be read as either excluding shift+A or as including ctrl+alt+del. Once you start down this rabbit hole, there's no escape (ha ha).
Any person using your software is entitled to feel aggrieved if they lose data or place an order they didn't mean to because of an unstated exception in your guidance.
I would name a specific key, for example, "Press Enter to X" and thus avoid all these issues.
You could treat it as any other key but display an exit button somewhere in the screen in cases where the escape key is essential to exit the application (for example if you are in full screen mode).