Mister Bleigh

This article kicks of the first of a series I’m christening “Disparate Sources,” where I will take something totally unrelated to computing and web applications and turn it into a metaphor for something important to remember when building an application. This time: car keys and exit status.

My car, and I believe most vehicles, have the following two behaviors in regard to keys in the ignition:

1. They will not start the car if the car is not in park
2. They cannot be pulled out of the ignition if the car is not in park

At first blush these ‘features’ might seem to be more aggravation than benefit: the system doesn’t behave how I expect it to when I try to turn the keys and can’t. In fact, it might be downright confusing if I believe everything is in order and can’t start the car or remove the keys. However, if you think about it, the auto manufacturers are partaking in a design principle I call regret minimization; that is, interfaces should be designed such that each action the user may take will be the one that leads to minimal aggregate regret.

What does that mean exactly? Well, in the case of the ignition it’s quite simple: these features are in place to prevent you from inadvertently crashing your car into someone else’s. If you start the engine while the car’s in drive or reverse, the idling force of the motor might well propel you into something you’d prefer avoid without your noticing or being able to stop in time. In the key removal case, it’s preventing you from removing the keys so that you don’t leave your car on a hill in something other than park: you might come back and find your car in a very different place and much worse condition than you left it.

By introducing an inhibiting action that demands the driver’s attention, the car makers are better able to minimize the extremely regretful situation of having a car accident while introducing what is, in the vast majority of cases, only a minor annoyance. They are minimizing the regret of the user experience.

This has several analogs in user interface design. The ultimate representation of regret minimization is Undo: you can literally cancel out a regrettable action, setting the state back to a more agreeable time. The simple fact that anywhere it is feasible to do so, actions should have the ability to have zero consequences. In web applications this can be difficult, but there is still a comparison that can be drawn.

When you are using a web application and click “Back” or type a new URL, sometimes you get an unexpected action: rather than going back or going to the new URL, the browser pops up an alert, usually with some copy along the lines of “Are you sure you want to navigate away from this page?” There’s little question that this alert is going to annoy you, at least to some extent. By nature we don’t like things that stop us from doing what we were trying to do. However, in the perspective of regret minimization, annoyance is by far the lesser of two evils. The alternative is losing any unsaved data, which might be anything from a couple lines of contact info to a blog post someone has pored over for two hours without saving.

Navigation blockers such as this are not the ideal solution to the problem: Undo and Autosave perform much more robust and less annoying implementations of regret minimization. However, if the choice is between no protection against unintended actions and annoying protection, it is the better strategy in the long run to implement the annoying but safe solution. Every effort should be taken, however, to ensure that it is only when unsaved data is present on the page that one of these blockers reveals itself.

So the next time you try to click away from a Google Document or pull the keys out of the car before you shift into park, try to stifle the annoyance and think what might have happened if the system hadn’t stopped you. You might regret it.