Honest Metaphors in User Interface Design

Abstractions and metaphors are hugely important in computing. They allow an "ordinary person" (e.g. somebody's grandma) to use a computer without first learning, say, binary numbers or machine code. But as previously noted, abstractions can also be destructive when used incorrectly. In human-computer interface design, an overly opaque (though perhaps elegant) metaphor will degrade a user's understanding of the system, while a transparent and "honest" metaphor will make it easier for the user to learn more later.

Bad Example: Mac OS X Dock/Windows 7 Taskbar

There's a current trend in all the major operating systems (Windows, Mac OS, and many Linuxes) to blur the line between programs that are installed and programs that are running. At the bottom or side of the screen, always in view, is a bar with icons for programs, some of which are running and some of which are not. If a user clicks an icon for a running program, that program's window appears. If a user clicks an icon for a program that is not running, the program is started. The latest versions of Windows, Mac OS, and Ubuntu Linux all behave this way.

For many purposes it's a sensible way to present the computer's operations to the user - if I want to listen to a song, who cares whether or not iTunes is already open? The problem is that the metaphor is an inaccurate and misleading representation of the truth, and when it doesn't model a given situation, or in the very likely event that something stops working, the user with no understanding of the difference between running programs and installed programs will be totally lost.

In fact, there are several distinct things a "program" could be:

  • An executable file on the hard drive (or flash drive, CD, etc.).
  • A process or task currently running on the system, which may have zero, one, or more windows associated with it. These are what you see in the list when you press Control-Alt-Delete on Windows.
  • A window - the box you can drag around, shrink, maximize, etc.

When the computer "runs a program", it copies an executable file from the hard drive into the RAM, creating a new process, and begins following the instructions contained in the new process. The process might create one or more windows (plus maybe a "tray icon") or it might instead remain in the background.

It's possible to have more than one process running from the same executable file, and as mentioned before, possible for a process to have zero or multiple windows. These cases do not fit into the new "programs are programs" design.

In older versions of Windows, the above three meanings of "program" were neatly divided: Executable files were on the desktop, in the Start menu, or in other folders. Windows were on the taskbar (on the bottom of the screen). Processes were visible in the task manager (upon pressing Control-Alt-Delete). Because running programs were distinct from non-running programs, users could discern that when they had many programs running, their computers tended to slow down. They could also gain an understanding of how multiple copies of a program might run at the same time.

Unfortunately I've watched tech-soaked people from my generation actually misplace running programs, or bog down their processors with no-longer-needed programs, because they had no idea what the operating system was doing.

Bad Example: Sugar's "Journal"

The One Laptop Per Child Project's custom interface Sugar replaces the traditional file and folder metaphors with an activity journal, designed to be more friendly and appropriate to kids. All work (drawings, stories, whatever) is saved by default, and listed in the journal in chronological order. When the disk space fills up, old stuff is automatically deleted, unless the child has it "starred". This way, the child doesn't have to worry about saving to a certain location, and can easily find what she's been working on recently. There's no need to fuss with file organization.

(One of the goals of Sugar, by the way, is to teach kids how computers work, in part by using only open-source software and letting the kids easily inspect the inner workings of the system.)

One could certainly argue that a journal metaphor is better for children. But here's the problem: The machine still uses the file and folder system - it's just hidden. The moment kids look behind the curtain (by viewing source code, running a console, or getting an error message) they find files and folders, abstractions completely different from the ones to which they're accustomed. The new metaphor may be more effective for child-style computer activities, but it is not at all effective for teaching kids how their computers work.

Good Example: Batch Files/Shell Scripts

When I was in elementary school I started playing with our "family computer", which ran MS-DOS and Windows 3.1. Learning how to launch programs from the MS-DOS command line, I became familiar with .BAT (batch) files. Initially, I didn't know what they were, but I did know how to use them - the same way I used .EXE files. They were just programs.

In the meantime I also learned more about the command line - at first how to type W-I-N-enter to start Windows, and eventually learning how to change drives, create folders, delete files, and so on.

Eventually, I learned that .BAT files were just like .TXT files, except .BAT files always contained lists of commands. The cool thing was, the commands were written in the same language I had already been using at the command line. So when I started looking inside .BAT files (or when I had to modify the all-important AUTOEXEC.BAT to fix an error), the contents didn't scare me.

All this is even more true for Unix/Linux's shell (similar to MS-DOS's command prompt, but much more powerful). A Unix user can take advantage of shell scripts long before he knows what they are or how they work, but as he learns to use the command line, he will find that the scripts he's been using, formerly mysterious, are nothing more than commands just like those he's been typing.

So, in a command-line environment batch files or shell scripts can abstract the complex system to make it usable, and simultaneously teach the user about the complex system. This should be the goal of all interfaces.


In general, the solution is to use "honest" metaphors - metaphors that do not attempt to deceive the user. When the user looks behind the curtain (whether from curiosity or necessity), she should not be surprised at what she sees.

Arthur C. Clark famously said, "Any sufficiently advanced technology is indistinguishable from magic." But a more correct statement would be "Any sufficiently opaque technology is indistinguishable from magic." Like skilled illusionists, our modern devices and software applications are pulling a sleight of hand, guiding us to buy into one version of the truth while something entirely different is actually happening.

Our software should instead be like a Penn and Teller magic show [1] - seeing the trick also helps us understand the secret. Such software will pave the way for more practical technology as well as more competent, confident, and curious users.

[1]Check out the second half of the video.