March 31, 2010

Don’t press any key to continue

Last week, Coding Horror posted a good musing on the opposite of Fitts’ Law, observing how certain irrevocable actions should utilize the principle in reverse to make their UI elements harder to interact with. That got me thinking: How else can we make terminal actions just hard enough without becoming impediments to normal use? How can we most elegantly clarify user intention?

The classic intention clarification is, of course, the confirmation dialog, itself borne of the command-line “y/n” prompt. The confirmation dialog is actually the original reverse-Fitts’ implementation: Your pointing device must travel all the way from whatever you just clicked to the “yes, I really meant to do that” button. While still far from foolproof (this only clarifies the user’s intent to click the button and not necessarily to perform the action represented by the button), it quite effectively wards off accidental clicks.

Using a confirmation dialog can be considered “active confirmation,” utilizing modal functionality to take advantage of reverse-Fitts’, while simply using the principle by itself in UI layout becomes “passive confirmation.” The thing is, these two approaches are a long ways apart. Passive confirmation still results in an instantaneous action, while most approaches to active confirmation become cumbersome for frequently-performed actions. What else is there in between?

If this is OK, do nothing

There is a good solution, but it’s one that doesn’t get much attention in software UIs: Delayed passive confirmation. Taking a cue from the industrial “dead man’s switch,” it’s essentially a hybrid of active and passive confirmations. It uses active methods to delay the action and give feedback, making it safer, but as confirmation is implicit if left alone, it’s effectively passive, making it more convenient.

Below are two examples of delayed passive, one from logging out of Mac OS X and an essentially inadvertent one from Mozilla Thunderbird.

As before, these are rather polar examples. The sixty-second Mac OS X logout delay is really too long to be of much convenience to the average user, while Thunderbird’s outgoing-message progress bar is based on an arbitrary value (presence and size of attachments) rather than a specific time to give the user a chance to cancel the send. This points to a potentially useful middle ground, though: Why not employ a simple, short delay that appears somewhere out of the way?

Interruptible without being interrupting

Imagine clicking “send” for an email message and watching your message appear in a brief queue. Perhaps it counts down about ten seconds before sending, more than enough time to cancel an erroneous send, but little enough time in the scope of e-mail communication as to not interfere with normal usage.

I could actually see it fitting almost perfectly into Apple Mail’s activity pane:

As long as the confirmation doesn’t steal focus, such a solution requires no further interaction than sending an email without confirmation.

Delayed passive confirmation is a nice middle ground between avoiding accidental clicks only by minimizing their targets and making users confirm everything with a modal dialog. It’s not appropriate for everything, of course—permanently deleting your entire collection of Ladytron albums should always be actively confirmed, and editing a caption in a web gallery of your cat probably isn’t important enough to build a queue system for. But for those tasks that exist right on that edge, like sending an email, it can be a perfect fit.