I’m Old, Part LXVIII: It’s Hard to Be Easy

“It’s hard to be easy” was one of the mantras of early Macintosh UI design. The notion was that in order to write an application that was intuitive took a great deal of iterative design and work. I bring this up in the wake of the awful, erroneous missile launch warning issued in Hawaii recently. Preliminary information indicates that the first few why’s in the 5 why analysis are:

A warning for a ballistic missile launch went out.

Why?

The operator selected the wrong menu item.

Why?

The two options, test warning and warning were adjacent to each other.

Why?

There was no confirmation box for the more dangerous path.

It reminds me of a situation that happened at Bell Labs in the 80’s, although certainly not so dangerous or so grave.

There was a cool type of terminal called the Blit (the one above is a 5620, a successor to the Blit with a different processor). It had a 1 bit display the size of a legal sheet of paper and had a resident 68000 microprocessor. On its own, the Blit was just a dumb terminal, but you could download programs to run on it including a windowing program called mpx which could multiplex communications to the host computer as well as run separate programs. Mpx was written primarily by Rob Pike.

One of the problems/features of mpx in the initial version was that there was no way to exit it. Once you started mpx, that was it until you turned off the Blit.

I should point out that I’m going on my own memory of being told about these events. If there are UNIX people who want to correct/amend this, please by all means do so.

My understanding is that users complained to Rob that there was no way to exit. Rob’s response was apparently typical Rob, “Why would you ever want to exit mpx?” He put in a menu. The problem was that it was the first choice in the menu and if you nudged the mouse button, it would select it and dump you out of mpx.

This is much less devastating version of the Hawaii bug: damaging UI actions should be protected by at least confirmation and shouldn’t be easy to initiate by accident.

Users complained: “now it’s too easy to exit mpx. Make it harder.”

Rob removed the menu and created an application called exit_mpx which would ask you a “hard” UNIX trivia question and if you got it right, it would let you exit. When I was in high school, I found this response to a user request hilarious. It was like a djinn granting a wish. Yes, he granted their wish but not in a particularly thoughtful way. That will teach you users to not to fully spec your wishes!

I don’t recall that this was ever changed. I learned a few of the questions and just reran the program until a question I knew came up. My favorite being, “how many pieces was Ken’s deer cut into?” (3)

Jokes aside, the missile warning issue is the kind of thing that should have been addressed in the specification if not the first UI mock-up. This is not entirely a trivial problem though. Upon the first indication of an in-bound ballistic missile, there’s something like a half hour until impact. That means that 1.4 million people need to get to shelter in that time so I can understand why the action is unguarded: make it quick and accessible, but this weekend’s actions have shown us that this is wrong. How much of a warning is enough to make it quick but can remove false negatives? A box that says, “You are about to send the following message to all of Hawaii. Continue? OK/Cancel”. Put in a check box in the warning that needs to be checked like a EULA before OK is an option? Put a divider in the menu? Move the actions to two different menus? User testing for sure.

At any rate, I would like to read a full 5 why analysis on this one.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.