In designing a user interface that presents a large amount of information to users, the designer must design the layout which will result in users' greatest comprehension of the information in the shortest amount of time. As the amount of information that is to be displayed increases, poorly designed systems often become unnecessarily complex and difficult to use. However, if a user interface metaphor that is meaningful to users is used, the interface becomes much more comprehensible to them. Useful interface metaphors minimize the amount of syntax that users must learn, and allow them to focus on the task at hand, rather than on the mechanism by which the task is completed. Interfaces that have meaningful interface metaphors are also easier to learn, making them quite useful for first-time and intermittent users.

Some designers use color in an attempt to structure a complex system. However, overuse of color can produce the reverse effect and further complicate the interface. In this experiment, we compared an interface that we believe does not use a meaningful metaphor, with an interface that does. In addition, we investigated the notion that reducing the amount of color can make a user interface more comprehensible.

An application in which a great deal of information must be displayed in a limited format is that of displaying a college student's progress in completing a degree. The user interface to represent this information should contain information about the requirements of the student's degree program and the requirements the student has completed. This information must be presented in a clear and comprehensible way, so that the student can quickly get an overview of the progress made and can plan which courses to take in future semesters. Because a degree typically has a number of requirements, and students take a number of courses, such a user interface must reduce the complexity of the problem domain and present the information in as concise a manner as possible. In addition, students do not use this application on a regular basis; a semester or more may pass between a student's use of the system. For this reason, users of the system will have difficulty remembering how to use the application, and an interface that emphasizes recognition rather than recall, is desirable [1] (p. 69).

The application currently used at the University of Maryland for students to perform a degree audit is the Degree Navigator, a product of Decision Academic Graphics. A screen shot of this application is shown below.

Degree Navigator (click to enlarge)

We believe that this interface is not well designed, and have found that students who have used the application were also dissatisfied with its interface, finding it overly complicated and confusing. Even though students used the application to view their own degree progress, they could not understand what each of the graphical elements represented. In fact, many students found that what made the application at all comprehensible was the fact that they already knew what courses they had taken, and had a rough idea of the requirements they had fulfilled. In addition, many found that the colors were quite distracting. It is for this reason that many students do not use the application at all, and monitor their degree progress manually.

There are two major flaws in this user interface. First, the metaphor used, that of islands to represent degree requirements, is not a natural one. Islands are used to represent the idea that the student is "navigating" his or her degree, but this seems contrived. We believe that a simple change of the metaphor that is used in the interface will make the application much easier to understand and use. User interface guidelines suggest that applications should build on the user's real world experience by exploiting concrete metaphors, thereby making applications easier to learn and use. An empirical study by Smilowitz [2] has shown that useful user interface metaphors can facilitate users' interactions with the system. However, not all metaphors are good--some metaphors may not be appropriate and may not be advantageous as a result. Good metaphors facilitate performance, and poor metaphors are no more effective than non-metaphoric interfaces. The results also suggest that an essential characteristic of a good metaphor is its mapping to the target domain, or its similarity.

Interface metaphors exploit prior knowledge of familiar objects and activities. For example, users of a word processing system already know about typewriting: they know what typewriters are used for; they know something of how the functions of the parts affect the function of the whole. A word processor that presents itself to the user as similar to the typewriter becomes less complex because it takes advantage of this prior knowledge [11]. Mayer [3] has experimentally studied the effectiveness of metaphors in teaching programming concepts in Basic. He showed that many programming constructs were learned more easily when they were presented in the context of a concrete metaphor (e.g., input as a ticket window, storage as a file cabinet). The key performance differences occurred in novel and complex tasks. Halasz and Moran [4] report a similar finding in their studies of learning to use calculators. Foss, Rosson and Smith [5] studied the task of learning to use a text editor by providing their subjects with an "advance organizer," which was information presented prior to the actual system manual. The organizer explained how the computer could serve as a tool, follow commands, and create, store and retrieve files, referring extensively to the metaphor of conventional file folders stored and retrieved from file cabinets. In this experiment, subjects who were provided with the advance organizer performed better than those who did not. These studies confirm that a relevant metaphor can teach users a great deal about a new application even before they have ever used it.

Erickson [6] discusses several criteria for evaluating interface metaphors:

1. Metaphors must have structure. From a user perspective, this comes in the form of knowledge of both domains. Users must be able to map objects from the source domain to the target domain.
2. Users must be able to apply the structure. Is the metaphor relevant to the problem?
3. How representative is the metaphor? Does it create effective visual or auditory representations?
4. The metaphor must be suitable to the target audience. Do users understand the metaphor?
5. How extensive is the metaphor? This refers to the need for a metaphor to be expandable to related target domains.

The Degree Navigator interface fails to meet the guidelines stated above. Current users of this application are unable to map objects from the source domain to the target domain, because there is no relation between an island and a degree requirement. In addition, this metaphor is not relevant, representative, or suitable. In fact, the metaphor is so unsuitable that many users do not even realize that the displayed entities are islands. In addition, the metaphor cannot be expanded to any related target domains.

It seems more appropriate to view degree requirements as entities in which the student has made a particular amount of progress in completing, as opposed to the arbitrary notion of "requirement islands." It is natural for students to think of themselves as "halfway done" or "almost done" a particular requirement, so a user interface metaphor that mirrors this is useful. Therefore, we propose that using progress bars to show the percent completion of requirements in the student's degree program will result in an interface that is clearer and easier to understand. Progress bars are used quite often in commercial applications, and they are a familiar and popular user interface element. Because of users' familiarity with progress bars, they can easily map objects from the source domain to the target domain. Progress bars mirror the task concept of a requirement that is partially (or fully) complete. This metaphor is a relevant one, and has an effective visual representation. Due to its wide use in other applications, this metaphor is quite a suitable one, because users already understand it. Finally, the metaphor is very extensive, as it applies to related domains.

A new layout for the Degree Navigator, which uses progress bars instead of islands, is shown below. We hypothesized that users would be able to better understand the information displayed in this interface than in the original.

A new layout using progress bars (click to enlarge)

Myers [7] showed that people prefer progress indicators, as they give novices confidence that a task has been accepted and is progressing successfully, while expert users can predict the completion time of the task. Practical experience and formal experiments show that progress indicators are an important and useful user-interface tool, and that they enhance the attractiveness and effectiveness of interfaces that incorporate them. Progress indicators give the user enough information at a quick glance to estimate how much of the task has been completed and when the task will be finished. There are a number of applications that use the progress bar, for example, progress bars are often used to indicate the status of a file download, or the number of files that have been copied in a software installation.

The second main flaw in the Degree Navigator interface is that color, which is presumably used to separate the islands, is quite overused and only results in complicating the interface. Color is a powerful communication tool in a GUI, so powerful, in fact, that color is easy to misuse or overuse [8]. It is necessary to understand the function of color so it is used with proper skill and sophistication. In general, similar colors imply a relation among objects, therefore, color should be used to group related items. The ways in which the elements are grouped plays an important role in both the ease with which the users can extract the information and the interpretations they assign to it [9]. Grouping similar items in together improves their readability and can highlight the relationships between different groups of data. In the original Degree Navigator interface, there are a number of random color duplications, which are mistakenly perceived as groupings by users. In addition, the color for courses that have been completed and courses that are currently in progress are very similar to each other and are hard to distinguish. We propose using colors which have the same hue (blue), but different amounts of lightness, to emphasize that blue-colored items are courses that have been taken; dark blue items are courses that have been completed, and light blue items are courses still in progress. In addition, we propose using the same background color to represent requirements, so they can be grouped together by the user.

The principle of color economy [8] suggests using a maximum of 5 +/- 2 colors. The original interface uses 8 colors; we propose using 3. Interfaces with too much color and saturation can produce a visual headache [10], a phenomenon that many users of the original application have commented on. In addition, colors that are simultaneously high in chroma and located at the extreme ends of the visual spectrum, e.g. red and blue, should not be chosen [8]. The original interface ignored this important detail.

It appears that the Degree Navigator does not follow any of the guidelines for using color given by Shneiderman [1] (p. 402):

• Use color conservatively
• Limit the number and amount of colors
• Recognize the power of color to speed or slow tasks
• Color coding should support the task
• Color coding should appear with minimal user effort
• Color coding should be under user control
• Design for monochrome first
• Color can help in formatting
• Be consistent in color coding
• Be alert to common expectations about color codes
• Use color changes to indicate status changes
• Use color in graphic displays for greater information density

Moreover, a color-blind user will have a difficult time with the interface, as there is not enough difference in brightness between the background and the islands.

In order to determine the effects of correcting these two design flaws, we created four applications (available in the Appendix), varying the parameters of layout and use of color. We hypothesized that changing either the use of color or the layout would result in an easier-to-understand interface which would be preferred by users.

next section >