Tag Archives: negative example

Door Bomb and Safety Catches

by

5

Johnny leaves the airport by taxi, ending up in a disreputable part of town. During his ride we see another video phone call with a different interface, and the first brief appearance of some high tech binoculars. I’ll return to these later, for the moment skipping ahead to the last of the relatively simple and single-use physical gadgets.

Johnny finds the people he is supposed to meet in a deserted building but, as events are not proceeding as planned, he attaches another black box with glowing red status light to the outside of the door as he enters. Although it looks like the motion detector we saw earlier, this is a bomb.

jm-12-doorbomb-a-adjusted

This is indeed a very bad neighbourhood of Newark. Inside are the same Yakuza from Beijing, who plan to remove Johnny’s head. There is a brief fight, which ends when Johnny uses his watch to detonate the bomb. It isn’t clear whether he pushes or rotates some control, but it is a single quick action.

jm-12-doorbomb-b-adjusted

This demonstrates an interesting difference between interface design for the physical world and for software systems. Inside a computer, actions are just flipping bits in storage and thus easy to undo. Even supposedly destructive actions such as erasing files can often be reversed. In the real world, the effects of, for example, explosions tend to be much more permanent.

We generally don’t want destructive actions to be too easy to perform, from guns and other things that go boom to formatting computer disks.

A widely used solution in the real world is the safety catch, as with guns, or arming switch, seen in countless thriller films with nuclear weapons. Another example are the two-hand safety switches used in high voltage electrical distribution panels. Activation of these requires two individual actions, separated in time and at least a short distance in space. Some systems, both real and in film, go even further and have covers on the arming switches, so even just preparing for activation requires two separate physical actions.

While the bomb is on his belt, Johnny doesn’t have to worry about accidentally pressing the “explode” button on his watch because the bomb is not active. Only after he has armed it and placed on the door can the watch activate the bomb, so he can take his time and verify whether or not it is necessary before doing so. And when it is active, he can do so very quickly even though he is in the middle of a fight.

But safety catches and arming switches introduce modes to an interaction, which have a bad reputation in interface design. Had the watch-bomb designers followed most conventional GUI design guidelines, there would be no arming switch on the bomb. Instead the watch would have popped up a “Do you really want to explode the bomb (Y/N)?” dialog, possibly with a short delay to ensure Johnny thought about his decision before answering. He would have been decapitated.

Compare to LoTek

Later on in the film we see an example of a poorly designed system without a safety catch. The LoTeks in their bridge home have a defensive “bug dropper”, so called because it drops ancient Volkswagens from a great height.

jm-12-bugdropper-animated

The bug dropper can be activated by pushing just a single handle. Because there is no safety switch, a guard accidentally drops a flaming VW Beetle onto the lead characters, nearly killing them.

Conclusion

From the description above it would seem that safety catches are the obvious solution. But of course it’s more complicated than that. Consider what would have happened if Johnny had met friends instead of enemies and settled down for a conversation. Thirty minutes later they’ve agreed on another meeting, and Johnny taps his watch to bring up the reminders app. Oops!

Should the bomb have disarmed itself after a given time period? If it did, how would Johnny be notified of this?

Most of us do not design interfaces for lethal hardware and life or death situations. There are however an increasing number of drones and other physical devices which are now remotely controlled from phone or tablet apps rather than dedicated hardware controllers as in the past. The “Internet of Things” will bring even more real world actions under computer interface control. In the future, we will most likely see more of these safety catches and arming switches in computer interfaces, and we need to figure out how to use them properly.

Zorg’s desk

by

2

fifthelement-184

When Zorg begins to choke on a cherry pit, in his panic he pounds a numeric keypad on his desk, clearly hoping that this will contact someone or help him in some way. His clumsy mashing instead causes a number of bizarre things to happen around his office; i.e. the doors lock, a lifejacket inflates (bearing the charming label “HEAD THROUGH HOLE”), a cactus raises and lowers, a Rolodex of photographs appears and spins wildly, a rack begins to shoot plastic wrapped tuxedo shirts into the air, cards spit out of a slot, and a strange piglet-sized, hairless pet with a trunk is roused from its napping place as it raises to the surface of the desk and stares at Zorg helplessly.

In the talk I give about the lines of influence between interfaces in sci-fi and the real world, I cite this as a negative example of affective computing.

If you’re unfamiliar with it, affective computing largely deals with giving computers a sense of emotion or empathy for their users. In this case, of course Zorg doesn’t want to summon his elephantito from its adorable genetically modified slumber. He’s panicking. He wants help. The joke in the scene is largely about how the unfeeling technology on which Zorg relies is of little practical value in a crisis, but we know that a smarter design would have accounted for this case of panicked mashing.

If (a bunch of key chords are pressed rapidly in succession) {summon help}.

Interaction designers should take care to learn from this fictional example that though some scenarios may be rare, they may be dire enough to demand design attention.

TheFifthElement-zorgdesk-003

This poor Ouliman Akaptan is named Picasso, designed by Hélène Girard.

For a general analysis, I find the number pad to be the worst choice of input for this system. On the plus side it’s useful for arbitrarily-long combinatorial and chorded input. It’s for this reason the telephone network system adopted this strategy to provide access to any one of its 10,000,000,000 nodes. (And that’s only with a ten digit number.) Fine. If Zorg needs a phone pad for dialing numbers than give him a phone. But for this desk interface, it burdens his long-term memory, forcing him to remember the codes for the things he wants. If he really has only around a dozen or so things to control, give him individual controls that are well grouped, distinguished, labeled, and mapped. Also in taking this tack, someone in his service might have thought to give the vengeful, psychopathic industrialist an actual panic button.