Inscrutable interfaces

A recent 99% Invisible episode, Children of the Magenta, discusses the automation paradox, and in particular the loss of Air France 447. There were many issues why the aircraft crashed, but it was mostly a design issue: the pilots were unsure why the autopilot had stopped, and it seems that no one realised that the fly-by-wire system had switched to a more manual mode.

Even for systems such as GroupServer — which deals with non-critical information in an asynchronous manner — there are lessons to be learnt from the disaster of Air France 447. The lessons go both ways, as all IT systems have to deal with, at some level, the automation paradox.

Modes

In human-computer interaction a mode is a state of behaviour. When you change modes the system behaves differently with the same input. For example, typing an  a⃣  will cause an a-character to appear in an email-message but move to the left in a game. Modes are fine if it is clear what mode you are in: it is clear when you are writing an email and playing a game.

Modes are problematic when it is unclear what mode you are in. The classic example of a system with this problem is the text-editor vi. It has a text-editing mode and a command mode, and it is hard to tell which mode you are in. The phrase “What’s it doing now?” is often heard when people are having trouble with modes, like the pilots on Air France 447.

The solution to the mode problem is to make the mode clear. This is easier said than done, especially with a complex multi-display system like an aircraft. However, computers are complex too, and mode issue are becoming increasingly rare.

Magic

I hate magical interfaces. Such interfaces hide what they are doing. Normally they are fine, but when it goes wrong a magic interface is terribly confusing. Because the user is so removed from the system they have no way of answering the question “What’s it doing now?”

Magic interfaces occur more often than outsiders first suspect: often we want to make the system easier to use, so we hide complexity. For example, I get requests to make GroupServer behave in a particular way in a very particular circumstance. I try an avoid such interfaces because it is hard for the user to understand the particular circumstances: it is all too magical.

Magical interfaces are different from delightful interfaces. A delightful interface makes the user smile when it performs a task well, and the user can understand how the task was performed. The user retains agency when they are delighted.

Understandable interfaces

One of my goals when designing interfaces is to make the system understandable. For example, GroupServer organises messages by topic and post; by flicking back between these two lists the user should be able to figure out the relationship between the two (or I hope that this is the case). If magic remains I work on making an easy-to understand explanation (keywords are the words that occur frequently in the topic, but infrequently in other topics).

Understandable interfaces will help with the automation paradox. Questions remain, such as:

• How much do organisations want to keep hidden?
• What is the best way to teach people about the interface?
• Can we allow people to give up agency? How do they get it back?