Previous Table of Contents Next


5.2.2. Choosing a Metaphor

The purpose of a metaphor is to exploit the users’ existing knowledge. The user can relate to the contents and operations of the user interface based on their earlier real world experiences through the metaphor.

The initial proposal for a metaphor in the case study was to visualize the test situation in terms of the physical connections of the test equipment. If a person connected something to the test tool he or she would see a representation of it on the main window. To configure a connection he or she would just click on it and fill in the relevant data. This metaphor did serve its purpose as a visualization of complex concepts such as mapping and configuration of physical and logical links. It was dismissed, however, because it supported only a small part of the task. It could not be used as a central supporting concept, but it was later reused in a window for configuring the test equipment.

The user interface of TSS 2000 needed a metaphor that could provide integration and structure to all relevant tasks. Setting up and running a test involves many different disparate activities often performed by several people. We needed a metaphor that would represent some central well-known concept that could unite the work of all users. The metaphor “test cases” was chosen as the main theme of the application. A test case is a collection of all the information that is relevant when performing a system or function test. The users of TSS 2000 either prepare the tests by developing the contents of a test case or execute the tests using the prefabricated test cases. The test case was an existing concept known to all users, but it was not reflected in any of the present applications. In order to visualize the test case we chose to impose a hierarchical structure that described its contents (see Figure 7.4). The lack of structure to the test data was a recurring comment during the task analysis, and by making the hierarchy of the test cases more explicit we aimed to solve this problem.


Figure 7.4  The hierarchy of a test case.

The metaphor also supported the testers when they reused test programs and data from old test cases or from each other. Reuse was not supported by the current tool. Instead it involved a very cumbersome procedure of making a complete copy of the database in use and then removing the irrelevant parts.

Previous experience outside this project provides a good example of how the choice of an appropriate metaphor is very important since it will affect many design decisions. During a preliminary study of what was to become one of the existing test tools, we used a prototype to help customers visualize the suggested capabilities of the system. The developers of the prototype had very limited knowledge of the domain and no usability activities had been performed. The target group for the prototype was in fact the customers and not the end users. The prototype could therefore show a very simplified view of two difficult areas that the tool needed to support — running the tests and presenting the test results.

The metaphor used to present the information during a test run was conceived from the layout of an audio mixer used to record music in studios. The channels of the mixer represented the eight test ports of the test tool. The status of the test ports was presented at run-time as “VU-meters” and test parameters could be changed dynamically by turning “knobs” on the mixer board. The execution of the test could be controlled by “play” and “stop” buttons on each channel. The metaphor supported a very simple and attractive visualization of the test execution, but it failed to support several important aspects of the task. Instead of making the system more usable, the metaphor became a liability and constricted the use of the tool.

The metaphor failed to capture the fact that most test cases would run for several hours, usually during the night. There would not be any tester to review the test results on the screen or to change the parameters during the test run. Furthermore, it did not include support for presenting or analyzing logs or other historical data that could reveal what had happened during the night. The easy operation of the tests and the instant visual feedback looked very impressive to the customers when they used the system only for a few minutes during the prototype demonstration but it did not support the work of the real users.


Previous Table of Contents Next