The Real World: Safety Catches

Lon Barfield

It's the climax of a science fiction film. The all-powerful-beings-with-the-funny-heads have got the spaceship in their clutches and have ordered the captain to send his crew down to the planet's surface. The captain tells them that he will make the preparations. He breaks contact and then turns to the second in command. "Anything is better than that, prepare to self-destruct the spaceship". The two of them flip the protective flaps on their control panels and both press the finger-print activated buttons together. The spaceship explodes in a huge fireball leaving the all-powerful-beings-with-the-funny-heads confused and angry.

Sounds familiar? Of course it doesn't sound familiar! Self destructing a space ship is never that easy. What really happens is that the captain has to ask someone in engineering to initiate the self destruct sequence and then it takes several long minutes with spoken countdowns, dimming lights and in the final stages plenty of sparks and shuddering. A delay that is not very efficient if you want to blow the spaceship up quickly, but that is vital in that it gives the all-powerful-beings-with-the-funny-heads time to say "We don't understand, you humans would rather destroy yourselves than submit to the wishes of us all-powerful-beings-with-the-funny-heads. We need time to think about this, you are free to go."

In the last issue I wrote about powerful functions and what happened when they were used in error. Well, many powerful functions are so powerful that their use needs to be made artificially complex so that accidental use is minimized. Think of the safety catch on a fire extinguisher. First the user has to remove the safety catch and then they can use the powerful function. Usually the more powerful the function, the more safety catches it has on it, or the greater the number of discreet actions that need to be taken to activate the function.

The system has a state in the interaction that is powerful and therefore dangerous in certain circumstances. Access to this state in the interaction is blocked by one or more buffer states, states that have no other function than to make the route to the powerful state more tricky and thus less likely to be reached by accident.

Getting back to science fiction films again, buffer states always play an important role in self-destruction sequences: Blowing up the mother ship in `Alien', `Star Trek' (where it almost seems to be standard procedure on first contact) and `2001' where they behave slightly more seriously, no big self-destruct scenes but well designed buffer zones for other systems. Think of Dave preparing to blow the explosive bolts on the pod door (five or six distinct actions accompanied by five or six distinct alarm sounds) or the final shutdown of the HAL computer, a long drawn-out affair with dimming lights and slurred speech.

Apart from the shutting down of HAL such buffer states also exist in more mundane computer operations such as deleting documents on your PC: The eternal "Are you sure you want to do this?" dialogue box. Actually I think that during that scene in 2001 HAL does say "are you sure you want to do this Dave?".

With some of the early word processors even the act of saving one file over another was fraught with "Are you sure? [y or n]" questions leading to the `Y file syndrome'. Users would sit there hammering on the `y' key in response to all the silly confirmation questions only to discover that they were through to the other side of the dialogue and somewhere along the line they had responded to the question of "what is the file to be called" also with a `y'. (And now that I think of it `the Y file syndrome' would make a good title for another science fiction film.)

With real world systems there is a balance to be struck between two things; the state that is being protected has dangerous consequences but it also plays a vital safety function. These states need to be protected with buffer states, but they also need to be quickly and clearly accessible in an emergency. Think of activating fire extinguishers, the emergency brakes on a train or opening the emergency door on an aeroplane.

The key goal with safety catches is that only intentional use is possible and when the user intends to reach the state it can be reached simply and quickly.

Lon Barfield is the author of `The User Interface, Concepts and Design' (Addison Wesley) and is an associate director of General Design (http://www.design.nl/). He can be contacted at lon@design.nl.

(Finally, talking about all-powerful-beings-with-funny-heads, readers may be interested to know that at the time of writing the British elections were in progress. After the major parties had released their manifestos, Labour's manifesto was so simple and clear that the Labour leadership publicly described it as a `What You See Is What You Get Manifesto'. User interface design comes of age!)

Issue
Article
Vol.29 No.3, July 1997
Article
Issue