Previous Table of Contents Next


5.2.3. Transforming the Conceptual Model into a user Interface Design

The work of transforming the UEDs into user interface elements is a combination of straightforward mapping of the focus areas to window elements and sparks of innovation. In most cases the focus areas translate into a child window or a dialogue box with the services as menu items and with the attributes of the objects as GUI widgets (e.g., fields, check boxes, radio buttons, etc.).

It is often possible to use the metaphor or the content of the main window as a starting point for translating a group of focus areas representing a complete task into interface components. The relevant objects in a focus area are either visible in the main window or there should be a service to make them visible. The service of selecting an object is often implemented as a mouse operation or as the result of searching or filtering.

The services connected to the selected object should now be available as menu items or through some form of direct manipulation such as a double-click or as an item on a tool bar. A typical result would be a change of focus to a new area in the UED and the opening of a dialogue box or child window in the user interface. The window would display the objects of the new focus area such as lists, fields, or other means of data entry. The services might be accessible through menu items, buttons, or keyboard entry.

Sparks of innovation are needed to know when to depart from this general approach and to search for similarities between areas and services that can be combined into more complex windows or dialogue boxes. A typical example of merging two focus areas into the same window or dialogue box is the creation of an object and the editing of its contents. Initially two separate areas may result from the users having different foci during the conceptual design. However, when areas contain basically the same objects and services, they can often be merged. An example of the conversion of a focus area into a dialogue box is shown in Figure 7.5.


Figure 7.5  A focus area converted into a dialogue box.

Once a structure of windows and dialogue boxes start to emerge it is necessary to resolve potential conflicts between different screen elements. Elements often compete for screen space, and it is necessary to decide what aspects in the dialogue box that are most important to the user. The style guides and guidelines give some guidance when selecting and organizing the dialogue boxes, but it still requires training and experience to create an attractive and well-organized user interface.

In the case study we used the hierarchical representation of the test case as the central concept in the main window. To it we added a menu containing services to cut/copy/paste the elements of a test case. We also needed some way to edit the contents of an element, a way to control the execution of a test, and a way to represent the result. For this purpose we created a dynamic workspace where the content changed depending on what the user wanted to do.

In order to supply the users with relevant information connected to the task they carried out, we added an information area in the main window. The content of this area changed depending on what elements the users were working with. Connected to this area were services to change the information and to add private or public comments.

The initial layout for the TSS 2000 main window consists of three parts:

  On the left was the hierarchic structure of the test case.
  On the right was a dynamic workspace. The content of the workspace is dependent on the element that was selected in the left window.
  At the bottom was an information area. The information is connected to the element selected.

An early version of a paper prototype is shown in Figure 7.6. Note the representation of the mouse/pointer used to manipulate the interface. This paper prototype was tested by users performing realistic test cases. At this stage the prototype was too crude to meet any of the usability requirements, but simply observing the users work with it led us to make both major and minor changes to the design.


Figure 7.6  An early version of a paper prototype. Note the mouse/printer that the users used to manipulate the interface.

The main window was split into a new main window containing the test case tree, a separate child window for information, and several additional child windows. The child windows contained the services and objects to solve specific tasks, such as writing a test program or controlling the execution of a test. The split was generated by the users’ need to have information relating to several focus areas available at the same time. A later version of the user interface with these windows can be seen in Figure 7.7.


Figure 7.7  A computer prototype showing the main window.

We also developed a prototype of the user documentation for the system. In the initial prototype, it consisted only of a table of contents with an alphabetic index on the back. When the users needed help they turned to the manual and selected what they thought to be a suitable entry. One of the designers then acted as a “talking manual” giving the user the kind of advice they would find in the finished documentation. We tried to avoid making the talking manual overly interactive, thus avoiding excessive user support. We were interested in what specific enabling information the user needed to solve the tasks.

6. AFTER THE BRIDGE

It is difficult to determine at what stage the gap has been successfully bridged. The process of prototype design and usability testing is highly iterative, but once user testing is begun, even if with a paper prototype, the gap is crossed.


Previous Table of Contents Next