Stoves revisited

A lot our interaction with technology is indirect, through controls, such as buttons and knobs, that affect the behaviour of some part of a system in some way. A common principle for making these controls easier to understand and remember is to make their physical functioning and arrangement analogous to the functions they control. For example, you move the mouse on your computer to the left to move the pointer left. This is called a natural mapping. An example of an “unnatural” mapping is the QWERTY keyboard. Some mappings can’t really be made natural, because they involve non-spatial concepts. For instance, there is no right answer as to whether the left or the right button on your mobile phone should pick up a call.

A popular example for illustrating mappings was given by Donald Norman in The Design of Everyday Things and involves kitchen stoves:

Although some stoves at least use the two knobs on one side to control the two burners on the same side, it is not clear, without reading the labels (usually at the front of the stove, out of a standing adult’s line of sight), how they map to the front and back. Personally, I've been close to destroying kitchen utensils and causing minor injuries more than once. Norman suggests the following as better alternatives:

An obvious reason I can see for not using these designs is the extra space they need. I don’t know about America (where everything is big) but here in Europe, stovetops are usually roughly square, and I can imagine that manufacturers of stoves and of kitchens would prefer to keep them that way. In any case, I’m sure most users wouldn’t be willing to sacrifice precious kitchen space for a more natural mapping of stove controls.

Instead of shuffling around burners, why not leave them where they are and just move the controls instead. A subtle shifting is all that’s needed (I included a version for controls on the stovetop as well):

It’s not a perfectly natural mapping, but the arrangement contains enough information to be unambiguous, and I imagine that you’d get used to it very quickly.

Design languages

I have recently taken a great liking to the idea of design languages, which think of design as a form of communication between the designer and the user, and which provide a framework or style to work within when you’re creating a design.

Design languages are sort of like design guidelines, but specifically thinking of them as a language is helpful at several levels:

1. It provides the designer with a repertoire of visual “expressions” and constructs that have a specific meaning, helping them to express their ideas without reinventing the wheel.
2. It encourages the designer to stick to the rules and conventions of the platform. In the same way that you usually wouldn’t just throw a Russian sentence into a conversation you’re having in English, you shouldn’t use interface elements or interactions that your user won’t be familiar with.
3. A language is something users can learn. They can then transfer their knowledge between systems that use the same design language.
4. It gets the designer to think of their design as a form of communication, a way to convey the conceptual model and the functioning of the system to the user. It effectively promotes empathy.

On the Mac, the Macintosh Human Interface Guidelines (HIG) define the design language third-party developers (and Apple themselves) are supposed to use in their software. The HIG were once an exemplar of design languages. However, since the introduction of Mac OS X, rather than prescribing the design of interfaces, the HIG have developed a tendency to describe it, being frequently updated to reflect whatever new “conventions” the designers of the Finder, Mail or iPhoto have come up with, sometimes with rather unconvincing logic. The Mac’s design language has subsequently become rather bloated and flaky.

Take as an example one of the simplest interface elements of all: the pushbutton. I’m sure most long-time Mac users can easily recall what a pushbutton looked like on System 6 and 7:

In Mac OS X 10.4, it’s not so easy to say:

Taking the language metaphor a bit more literally, one could say that these are synonyms for the same concept. Worse than synonyms are homonyms, because they introduce ambiguity:

The segmented control can be cofigured to behave in three very different ways, and the only way to figure out which is the case is through trial and error or by guessing from the context. A more traditional way to express the same functionality unambiguously would be:

When Aqua first appeared, it was like a fresh start. It actually seemed simpler than Mac OS 9 in terms of its interface elements. However, Apple hasn’t been very disciplined with keeping it that way, and it’s quite astonishing how quickly the Mac design language has grown through influences from the different application teams' designers.

You could argue that these inconsistencies are just cosmetic matters of graphic design rather than of interaction, since the way Mac OS X’s interface functions is still relatively simple and coherent. But you have to remember that the graphical representation of the interface is the only communication channel from the designer to the user; we rely on it to understand what we can do, in the same way that you’re relying on my use of English to understand this article. It’s a language.

There’s a chapter on design languages by John Rheinfrank and Shelley Evenson in Terry Winograd’s book Bringing Design to Software (parts of this book are available online). Donald Norman has also written an essay about this entitled Design as Communication.