PARC s Principles

PARC's Principles

The researchers at PARC, in addition to developing a revolutionary set of hardware and software technologies to create the Alto, also pioneered many of the concepts held as gospel today in the world of GUI design and development.

Visual metaphors

One of the ideas that emerged from PARC was the visual metaphor. At PARC, the global visual metaphor was considered critical to the user's ability to understand the system, and thus critical to the success of the product and its concept. In Part IV, we discuss some of the problems of relying completely on such metaphoric design.

Avoiding modes

Another principle associated with the modern GUI is the notion that modes should be avoided. A mode is a state the program can enter where the effects of a user's action changes from the norm—essentially a behavioral detour.

For example, older programs demanded that you shift into a special state to enter records, and then shift into another state to print them out. These behavioral states are modes, and they can be extremely confusing and frustrating. Larry Tesler, former PARC researcher and former Chief Scientist at Apple, was an early advocate of eliminating modes from software and was pictured in an influential magazine wearing a T-shirt with the bold legend "Don't mode me in." His license plate read, "NOMODES." In a command-line environment, modes are indeed poisonous. However, in the object-verb world of a GUI, they aren't inherently evil, although poorly designed modes can be terribly frustrating. Unfortunately, the don't-mode-me-in principle has become an unquestioned part of our design vernacular.

Arguably, the most influential program on the Macintosh was MacPaint, a program with a thoroughly modal interface. This program enables the user to draw pixel-by-pixel on the computer screen. The user selects one tool from a palette of a dozen or so and then draws on the screen with it. Selecting a tool is entering a mode because, when a tool is selected, the behavior of the program conforms to the attributes of that tool. The program can only behave in one way.

The PARC researchers weren't wrong, just misunderstood. The user interface benefits of MacPaint, when compared with contemporary programs, were great; but they didn't accrue from its imagined modelessness. Rather, they resulted from the ease with which the user could see which mode the program was in and the effortlessness of changing that mode.

Modes based on implementation models are confusing modes. Edit mode versus Preview mode is convenient only for the program, not the user. Modes based on the user's mental model are often harmless, such the Spray Can or the Paintbrush modes in MacPaint, for example.

Overlapping windows

Another Mac fundamental that emerged from PARC (and which has metastasized in Microsoft Windows) is the idea of overlapping rectangular windows. The rectangular theme of modern GUIs is so dominating and omnipresent that it is often seen as vital to the success of visual interaction.

There are good reasons for displaying data in rectangular panes. Probably the least important of these is that it is a good match for our display technology: CRTs and LCDs have an easier time with rectangles than with other shapes. More important is the fact that most data output used by humans is in a rectangular format: We have viewed text on rectangular sheets since Gutenberg; and most other forms, such as photographs, film, and video also conform to a rectangular grid. Rectangular graphs and diagrams are also the easiest for us to make sense of. There's something about rectangles that just seems to work cognitively for humans. Rectangles are also quite space-efficient.

Overlapping windows demonstrated clearly that there are better ways to transfer control between concurrently running programs other than typing in obscure commands.

Overlapping rectangular windows were initially intended to represent overlapping sheets of paper on the user's desktop. Okay, but why? The answer again goes back to the global metaphor of the desktop. Your desk, if it is like the authors', is covered with papers; when you want to read or edit one, you pull it out of the pile, lay it on top, and get to work. The problem is that this works only as well as it does on a real desktop and that isn't particularly well, especially if your desk is covered with papers and is only 17 inches across diagonally.

The overlapping window concept is good, but its execution is impractical in the real world. The overlapping-sheets-of-paper metaphor starts to suffer when you get three or more applications and documents on the screen—it just doesn't scale up well. The idiom has other problems, too. A user who clicks the mouse just one pixel away from where he thought he was can find his program disappearing, to be replaced by another one. User testing at Microsoft has shown that a typical user might launch the same word processor several times in the mistaken belief that he has somehow "lost" the program and must start over. It is problems like these that prompted Microsoft to introduce the taskbar; Apple still hasn't completely sorted out the problem.

Another part of the confusion regarding overlapping windows comes from several other idioms that are also implemented using an overlapping window. The familiar dialog box is one, as are menus and floating tool palettes. Such overlapping within a single application is completely natural and a well-formed idiom. It even has a faint metaphoric trace: that of someone handing you an important note.