CHI '95 ProceedingsTopIndexes
Design BriefingsTOC

Designing a "Front Panel" for Unix: The Evolution of a Metaphor

Jay Lundell

Corvallis User Interface Lab Hewlett Packard MS 4UE3
1000 N.E. Circle Blvd.
Corvallis, OR 97330
Phone: (503) 715-4119

Steve Anderson

User Interaction Design Group
Hewlett Packard
1266 Kifer Road
Sunnyvale, CA 94086
Phone: (408) 746-5415



The Front Panel component of the Common Desktop Environment is a culmination of several year's effort in designing a "dashboard-like" element for graphical Unix desktop systems. This design was a cooperative effort between graphic design artists, human factors professionals, and software designers, and eventually became a cross-company effort as it was adopted for the Common Desktop Environment. We describe the processes that emerged to support this design, and make observations about how metaphors may evolve over time.


Metaphor, Front Panel, Software Design, Visual Design,Workspaces, Dashboard.


It is generally recognized that a metaphor provides a method by which people can quickly learn to use a system. Through metaphors, users infer the appropriate attributes of the target metaphor by mapping the aspects of the real-world source onto the software objects. Thus, users might infer that a trashcan-like object that appears on a computer screen is a container for objects that are to be discarded, and may infer that objects can be dropped into the trash without having to learn explicit instructions on how to throw away an object -- the knowledge for throwing away objects is contained in the user's knowledge about trash cans in the real world. Many critical aspects of metaphors have been identified [3], and processes for designing metaphors have been suggested by several authors [1][2][5]. In this design review, we describe the development of a front panel metaphor for a Unix desktop environment, and we identify some lessons we learned in its development.


The Front Panel is an ubiquitous interface element designed to perform an eclectic range of services for an end user in a "desktop" environment. These services include:

This interface is notable for several reasons:


The front panel was initially conceived by Steve Anderson as part an attempt to show a collection of varied ideas for extending the "desktop" metaphor. This particular component, which he dubbed the "dashboard", attempted to solve the following user problems: In addition, he wanted a component that had a strong visual signature and could be easily understood by users. He used the term "dashboard" because it was an ever-present element full of user controls, found at the bottom foreground of an ever-changing scene.

Its initial form was as a horizontal bar that appeared at the bottom of the screen. On the left side were several iconic buttons that had several of the "core" functions of electronic office workers: phone, e-mail, a rolodex, calculator, clock, etc. On the right side were labeled buttons, where the user could organize his/her own applications. These were labeled because their content was so likely to change over time --- it being much easier to type a new label than design or find a suitable icon. In the prototype, but not shown in the illustration, these buttons behaved like the fronts of small "drawers." When opened, each button slid upwards, revealing its contents, like small jewel-like objects nested in a shallow tray. At the time, (and even currently) an application that cost hundreds if not thousands of dollars seemed to merit a little extra panache in its presentation to its purchaser/user. This was seen as the place where applications were kept, not the files they would create. Those were to go in the File Space, seen in the background.

At the time, this prototype was not part of a particular project, but was instead an exercise of Steve's in attempting to learn how to use the animation application, then called VideoWorks. If it could serve as a spur to discussions with engineers, so much the better. There was also an attempt to look at how window overhead in inactive windows might be minimized, how the active window could be more efectively expressed, where iconized windows might go and what they should look like, and how different types of windows might take on more specialized and distinctive apperarances.

FIGURE 1: from June, 1988: a minimal ever-present "dashboard" that provided quick access to the user's most frequently used items .

VUE 2.0

The Hewlett Packard Visual User Environment 2.0 project got underway in late 1989 as an attempt to create a "desktop" for Unix workstations. One of the technologies incorporated into this product was to be a window manager that supported multiple workspaces. With multiple workspaces, users could create and maintain a number of different virtual screens of information, and quickly move between these different "desktops". Once it was seen that there also needed to be a means to navigate between workspaces, the dashboard metaphor, which had since been exposed in various parts of the company, became an immediate candidate as a HP VUE component, and the basic premise of a horizontal "control panel" at the bottom of the screen was adopted by the development team.

Design Environment

A wide range of different disciplines were involved in the front panel development, including visual design, human factors, R&D, documentation, and marketing. Because the dashboard concept was such a new idea, direct customer input was difficult to obtain early in the project. The visual design group produced Macromedia Director animations that played out user scenarios. These high-resolution animations were extremely useful in the development and evaluation of the software.

Design Issues

As the team began to design the dashboard, they ran into some problems with the dashboard metaphor. The major problem was that real-world dashboards have many components that have no real corollary in the computer world: steering wheels, speedometers, turn signals, etc. These would have little meaning or use in the VUE environment. As an exercise, the design team came up with a number of alternate metaphors: the desk organizer, a briefcase, a stereo panel, a remote control, etc. These all had interesting attributes, but all had too many undesirable properties. Finally, the team changed the term "dashboard" to "front panel" --- a metaphor that lacked some of the concrete and distinctive attributes of the dashboard, but had fewer areas in which the mapping failed. Thus, in this case, a less concrete metaphor seemed to be more useful.

As the front panel began to take shape, it became possible to ask more specific questions: What goes into the front panel, and what are the behaviors of the front panel buttons and controls? Some sort of component had to be provided to allow users to navigate between workspaces. A set of switches were developed for moving quickly between workspaces (see figure 2, the VUE 2.0 front panel). A clock and date seemed useful. Other items were researched in a customer survey which asked users to state which services might be most frequently used, and which services were considered most critical. The survey results helped in defining which items should go into the front panel. We also discovered that some services required frequent access, while other items might not require high level access, but still needed to be easily accessible. An example of this is a "logout" capability. Although users may not need to log out more than once a day, it was seen as a critical capability. Thus, we developed a large top row for primary, frequent access and a smaller bottom row for secondary, critical access to tools.

FIGURE 2:the VUE 2.0 Front Panel

As we explored the capability of the front panel with paper mock-ups and Macromind prototypes, a few fundamental types of "controls" emerged. Some front panel controls needed to be drop zones: the trash can and the printer, in particular. Some controls were simply indicators, i.e., the clock, date, and load controls. Controls had to support a push action: clicking on the control would start up a desktop application or run a command. In addition, we needed a type of control that would change its appearance based on system status, e.g., to show the user that new e-mail had arrived. These controls were called monitor controls.

We developed design rules for the location of controls based on human factors principles of motor control and functional grouping. These principles were:

Some of these principles are contradictory, e.g., locating drop controls and indicator controls towards the ends. Because there are so many possible combinations of control locations, we have had to adopt the strategy of point testing a few possible designs with users, and have identified designs that appear to be sufficient, if not ideal. We have observed that each time a new version of the front panel is developed, new ways to organize the front panel controls emerge.

An additional feature that came directly out of user testing was the busy light. In early prototype testing, we noticed that users would often watch the disk drive light after clicking a front panel button to see if the application was actually starting up. Although this worked well for users in our test, we realized that many Unix users do not have the disk drive located at their desk. Therefore, we incorporated a "busy light" graphic directly into the front panel that looked just like the HP disk drive light to provide user feedback.

Visual Features

We had constraints of having only a few colors available, yet we wanted a visual design that used shading effects and had the 3D visual style of Motif. Because icons and graphics in Motif could only be drawn in two colors, the entire front panel was dithered in order to achieve the light/medium/dark coloration that provided the 3D look of the front panel..

The VUE 2.0 front panel had a very "hardware" look to it with large, blocky buttons and the 3D effect. The front panel metaphor carried with it some characteristics that we had not necessarily intended --- it looked heavy, and difficult to move, and its hardware-like appearance gave the impression that it was not very flexible. Although at a technical level it was simply a window, it did not look like a window, and did not lend itself to the actions available to windows --- minimization, resizing, moving around on the screen.


In spite of some of the above limitations, the visual designers entered the product in the Industrial Designers Society of America 1990 annual design awards program, and it won one of 16 Gold awards, the first time a software product had ever been given any design award. As one of the jurors said, "it appears deceptively simple, offering a representation of functionality which is easy to grasp and quick to learn... it seems obvious now that we can see it."

FIGURE 3.Summer of 1990: a screen capture of the VUE 2.0 product, showing the 3D character of the abutted butoons in the Front Panel. Also featured is the Style Manager, with which the user exerts control of numerous customization features of the environment.

VUE 3.0

In designing the next generation of the product, VUE 3.0, we had an opportunity to solicit customer feedback from the field, and were able to see firsthand how our front panel metaphor was being used.

We were surprised to find the extent to which users had modified the front panel to suit their own tastes. One of the design concerns for VUE 3.0 was the extent to which our customers had ignored our carefully crafted design practices in designing their own front panels. Some of these designs were really bad, and we had concerns not only about the poor visual design of these panels, but about the human factors implications of these panels that had been designed by our users. We decided that the VUE 3.0 front panel had to be more flexible to allow for a greater range of customization, and that the front panel had to manage the customized controls and visuals more gracefully. Thus, the VUE 3.0 front panel had a flexible geometry that would better accommodate icons of different sizes. We also provided multicolor icons for greater visual appeal and so that people who customized their front panels would not have to dither their icons to get the proper colors and shading, which had proven challenging enough for professional graphic designers.

The design team also developed a prioritized list of customer needs for VUE 3.0 as a result of a systematic effort to gather customer information known as QFD (see [6] for more details on this process). One requirement was the desire to put more items into the front panel --- some customers wanted as many as 120 buttons. Another need was for greater visual "pizzazz" --- apparently the award-winning visual appeal of VUE 2.0 had sparked even greater interest in visual design. An answer to both of these requests took the form of sub panels --- animated extensions of the front panel controls that would "slide up" out of the top of the panel. The "slide up" animation conveyed the impression that sub panels were extensions of the front panel, not separate "menus".

User testing and customer feedback provided us not only with a new set of features to add, but allowed us to look critically at whether the features we had provided in VUE 2.0 were actually providing the value we had intended. For example, we had developed a visual semantic for front panel drop zones that we discovered were not being noticed by our users. We replaced this persistent cue with an interactive cue that occurs only as the user drags an icon over a drop zone. This cue was easier for users to notice, and was built in for any drop zone control instead of requiring a special semantic that had to be drawn into the control's visual representation.

FIGURE 4.Summer of 1992: showing the new features of colored icons and slide up sub panels. The lack of distinct buttons gave us greater design flexibility in terms of arrangements and spacings.


The advent of the COSE (Common Operating System Environment) effort in late 1992 saw the front panel concept adopted as part its the Common Desktop Environment, and additional changes to the metaphor were made as a result of VUE 3.0 customer feedback, user testing, and extensive human factors evaluation from the four different companies involved in the joint effort.

Ease of configurability was a critical issue, and we developed "drop zones" by which the end user could install new controls. Users could also "promote" controls on the sub panels into the front panel, and could delete controls as well.

Screen real estate was a critical issue, and since sub panels had become pervasively used, we removed the bottom row, as its "secondary access" function was largely met by the sub panel design. Additionally, we changed the default number of workspaces from six to four, since research had shown that four was acceptable to most users, and the CDE front panel allowed easy creation of additional workspaces.

A new feature was added to the "monitor" capabilities --- the indicator light, which takes the form of a lighted up or down arrow at the top of the Front Panel. This allowed users to see an indication of a change of status for controls that are "hidden" on sub panels. Thus, a user might have a sub panel containing several in-boxes --- Fax, e-mail, voice-mail, etc. The status indicator allows the user to see from the main front panel if one of the in boxes has new messages, and to see via an LED-like graphic which of the in-boxes has changed when the sub panel is posted.

FIGURE 5.Current: the Common Desktop Environment version of the Front Panel, with the bottom row of buttons removed. Other changes include smaller icon sizes, drop zones at the top of slide up sub panels for drag and drop configuration, and 4 workspace buttons.


In any software product, the actual implementation falls short of some of the design goals, for a myriad of reasons. But with the visual prototyping techniques we have employed, we can create very realistic visions of what we think the solution calls for. One example is the area of Front Panel and sub panel configurability. The addition of the drop zone in the sub panel gives the user a simple and nearly intuitive way of installing items into the sub panel. Steps we couldn't take would allow greater ease of further configuration--- rearranging their order, intuitive deletion, allowing and positioning separators, setting default behavior, etc. While we made significant progress in enabling users to do the most basic configuration, the prototypes show that we still have potential for going further.


We have learned a great deal about the interaction between visual design, usability, and metaphor development throughout the development of the front panel. Some of the lessons we have learned are:

Let the Tasks Drive the Metaphor Our initial visual approach was very hardware-like, with large modular buttons. We soon realized that this was an inhibitor to easy configurability. Users needed easy methods of altering the front panel to suit their needs, including changing the orientation from horizontal to vertical, and adding and removing controls. Thus, we modified the metaphor, making it more abstract, and softened the visual design to give it a more flexible appearance. We also added drop zones to allow users to install new buttons via drag and drop. In this case, the changes to the metaphor were accepted by users because the new metaphor accommodated the tasks users wanted to perform.

Don't Be a Slave to Self-Consistency Grudin [1] has pointed out that consistency just for the sake of consistency can be misguided. We observed that there was a tendency to rigidly define the behavior of the front panel metaphor at the expense of efficacy. For example, pressing a front panel button initially would always bring up a new instance of a window. However, we realized that in some cases, users did not want a new instance of a window, but instead wanted a button to bring a current window to the top of the window stack if it had already been opened previously. Thus, we allowed the apparent inconsistency that some buttons always created new windows, while others did not. Users do not seem bothered by this, and often do not even notice the difference, as long as the "inconsistent" aspect performs the behavior suitable to the task.

Subtle Visual Cues Can Make a Big Difference

When we "softened up" the visual design of the front panel and relaxed the 3D button-like appearance of the front panel icons, we were concerned that the icons would be seen as having the same dragability characteristics as the icons in the File Manager, i.e., users would think that the front panel icons were could be moved around on the desktop. In an attempt to create a visual distinction to reflect the behavioral one, we gave the front panel icons an "etched in" appearance which successfully conveys the impression that the icons are imprinted into the front panel and cannot be moved around. The subtle visual cue appeared to work in this case, and has been adopted in the Common Desktop Environment as a visual cue for all non-draggable icons.

Subtle Visual Cues Can Make Little Difference

As we previously mentioned, our initial version had a visual semantic for indicating buttons that were drop regions vs. no-drop regions. In user testing, we noticed that these cues were not being picked up by users. Since the cues added visual complexity to the design with no apparent benefit, they were dropped from the design, with no measurable decrease in user performance or learning. User testing is the only reliable way to determine what works and what does not work as subtle visual cues, but our feeling is that subtle cues are effective when they reinforce the basic metaphor, but are ineffective when they are used to suggest additional functions that are outside the metaphor or are inconsistent with the metaphor.

Don't Design Metaphors in a Vacuum

The front panel exists in an environment that contains many other metaphors. As each design issue came up we had to anticipate problems in the interaction between the front panel design and aspects of other metaphors in the environment. For example, the initial design called for users to open applications with a single click on the front panel button. This caused problems when the Front Panel is used in the context of the File Manager, as users open files with a double-click. Thus, users were always getting two instances of their applications because they would double click on front panel buttons. We changed the design such that either a single or double click would produce the same results.

Let the Visual Designers use their tools to do their thing.

First, and not after the fact. Having the interactive prototypes was crucial to exposing and selling the concepts embodied here. It is extremely rare for software developers to be able to produce conceptual things like this in the short time spans and with the visual appeal that visual design professional can bring to such an effort. Admittedly, having the right people available at the right time, with their objectives and responsibilities properly aligned, is a considerable challenge. But all of the ideas adopted here existed in visual prototpye form at least one or two years before they were ever incorporated into the actual products. And many more have not yet made it into products. None of them would have ever made it if the visual designer role was to execute nice icons at the end of the development cycle.


1. Carroll, J.M., Mack, R.L., & Kellogg, W.A. Interface metaphors and user interface design. In M. Helander (Ed.), Handbook of Human-Computer Interaction, Elsevier Science Publishers B.V., 1988.
2. Erickson, T.D. Working with interface metaphors. In B. Laurel (Ed.), The Art of Human- Computer Interface Design, Addison-Wesley Publishing Co., Inc. 1990.
3. Gentner, D. Structure mapping: A theoretical framework for analogy. Cognitive Science, 7, 155-170.
4. Grudin, J. The case against user interface consistency. Communications of the ACM, vol. 32, number 10, 1164-1173, 1989.
5. Mountford, S.J. Tools and techniques for creative design. In B. Laurel (Ed.), The Art of Human-Computer Interface Design, Addison-Wesley Publishing Co., Inc. 1990.
6. Rideout, T., & Lundell, J. Hewlett Packard's Usability Engineering Program. In M. E. Wiklund (Ed.), Usability in Practice. AP Professional, 1994.