Most Software Conforms to Implementation Models

It is much easier to design software that reflects its implementation model: A button for every function, a field for every data input, a page for every transaction step, and a dialog for every code module is an all too common occurrence in the software world. But while this adequately reflects the infrastructure of the engineering effort, it does little to provide a coherent reflection of a user's goals, and the tasks he needs to perform to accomplish them. It produces an interface that affects the user rather like the ubiquitous external ductwork in Terry Gilliam's 1984-like movie, Brazil (a movie full of wonderful tongue-in-cheek examples of miserable interfaces), doing little other than to alienate and confuse the user.

Software designed by engineers follows the implementation model

Software interactions designed by engineers, who know precisely how the software works, quite often lead to a represented model that is very consistent with its implementation model. To the engineers, such models are logical, truthful, and accurate; but unfortunately, they are not very helpful or effective for users. The majority of users don't much care how a program is actually implemented.

A good example of a user interface conforming to the implementation model instead of to the user's mental model can be found in a popular software-based fax product. Every step of the process is agonizingly wrought in discrete steps that the user must laboriously control, and none of which are necessary from the user's point of view. The interaction with the user is rendered in perfect conformity with the internal logic of the software. A separate dialog box represents every possible user action. The user is prompted for information when it is convenient for the program to receive it—not when it is natural for the user to provide it.

If we want to send a fax, we'll need to send it either to a person whose name we have previously entered into the program or to a new person whose name we haven't yet entered. But the program in question follows the implementation model: The code that performs each of these functions is located in separate modules, so the program presents each of these functions in its own separate dialog box. To select or enter names, we have to sidestep the main program in two different ways, even though selecting and entering names is one of the program's primary functions. Instead of imagining the steps the user might take to create and send a fax, the designer merely translated what the program has to do.

Here's a better way to manage the problem: Whenever we enter a new fax name and number, the program should automatically record it. The program's main window should display a list of the names of previous fax recipients, allowing us to quickly choose one from the list if we want.

Even the Windows interface slips into the implementation model sometimes. The Explorer attempts to show all the storage devices on the computer as a unified system, but to successfully communicate that to the user, their behavior must also be unified. Instead, their behavior depends on the physical nature of the particular storage device. If you drag a file between directories on the same hard drive, the program interprets this as a MOVE, meaning that the file is removed from the old directory and added to the new directory, closely following the mental model. However, if you drag a file from hard drive C to hard drive D, the action is interpreted as a COPY, meaning that the file is added to the new directory but not removed from the old directory.

This is consistent with the implementation model—the way the underlying file system actually works: When the operating system moves a file from one directory to another on the same drive, it merely relocates the file's entry in the disk's table of contents. It never actually erases and rewrites the file. But when it moves a file to another physical drive, it must physically copy the data onto the new drive. To conform to the user's mental model, it should then erase the original even though that contradicts the implementation model.

Because treating the drag of a file from one disk to another as a COPY function can be desirable behavior, especially when copying files from a hard drive to removable media such as ZIP disks, many people aren't aware that it is an inconsistent side effect of the implementation model. As computers mature and logical volumes represent more than just physical drives, the side effects stop being useful and instead become irritating because we have to memorize the idiosyncratic behavior of each volume type.

Mathematical thinking leads to implementation model interfaces

Interaction designers need to shield users from implementation models. Just because a technique is well suited to solving a problem in software construction doesn't necessarily mean that it is well suited to be a mental model for the user. Just because your car is constructed of welded metal parts doesn't mean that you should have to be skilled with a welding torch to drive it.

Most of the data structures and algorithms used to represent and manipulate information in software are logic tools based on mathematical algorithms. All programmers are fluent in these algorithms, including such things as recursion, hierarchical data structures, and multithreading. The problem arises when the user interface attempts to accurately represent the concepts of recursion, hierarchical data, or multithreading.

Mathematical thinking is an implementation model trap that is particular easy for programmers to fall into. They solve programming problems by thinking mathematically, so they naturally see these mathematical models as appropriate terms for inventing user interfaces. Nothing could be further from the truth.

DESIGN TIP 

Users don't understand Boolean logic.

For example, one of the most durable and useful tools in the programmer's toolbox is Boolean algebra. It is a compact mathematical system that conveniently describes the behavior of the strictly on-or-off universe inside all digital computers. There are only two main operations: AND and OR. The problem is that the English language has an and and an or and they are usually interpreted—by non-programmers—as the exact opposite of the Boolean AND and OR. If the program expresses itself with Boolean notation, the user can be expected to misinterpret it.

For example, this problem crops up frequently when querying databases. If we want to extract from a file of employees those who live in Arizona along with those who live in Texas, we would say to a human in English, "Find all my employees in Arizona and Texas." To express this properly to a database in Boolean algebraic terms, we would say, "Find employees in Arizona OR Texas." No employee lives in two states at once, so saying, "Find employees in Arizona AND Texas" is nonsensical. In Boolean, this will almost always return the empty set as an answer.

A database query program—or any other program, for that matter—that interacts with the user in Boolean is doomed to suffer severe user-interface problems. It is unreasonable to expect users to penetrate the confusion. They are well trained in English, so why should they have to express things in an unfamiliar language that, annoyingly, redefines key words.