Previous Table of Contents Next


4.2. A USER MODEL EXAMPLE

We begin generating alternative metaphors by considering the use case in our example:

Developers build applications, in part, by including selected routines from libraries. They select the routines by finding a candidate set of routines and evaluating each of them using its documentation.

Since this use case uses programming terminology, it doesn’t immediately suggest other metaphors so we consider its underlying structure. Building applications by including selected routines suggests the assembly of something from parts. The library is a collection of these parts. The “assembly” and “collection” elements of the example’s essential model suggest several metaphors including:

  Parts can be picked from a drawer of a parts cabinet.
  Semiconductor data handbooks contain information about electronic components. For each component there is a data sheet that describes it purpose and uses, often with an example circuit that demonstrates its actual application.
  Companies distribute catalogs that describe their products and provide a means to order and obtain the products.

The alternatives are then checked against the information needs and problems listed in the essential model:

  Finding candidate routines can take a long time.
  What does a particular routine do and how is it used?
  Where is the routine located?

The parts cabinet metaphor doesn’t include any support for describing what the parts are or how they are used, and the only mechanism for finding candidates is by grouping similar parts in labeled drawers.

The catalog and data handbook metaphors each contain descriptive information. They both also have an index that supports locating items using keywords. The data handbook also has example use information while the catalog metaphor suggests that it can be used to obtain the items it shows. Each of these metaphors could be stretched a little to cover all these points. This example will develop only the catalog metaphor, but it is preferable to pursue a few alternatives to better highlight the strengths and weaknesses of the favored choice.

We check the fit by restating the objects and tasks of the essential model in terms of the metaphor:

  Tasks
  Find candidate routines — turn to a section or look in the index.
  Evaluate a routine — read an item’s documentation.
  Include a routine — copy an item to the application.
  Objects
  Item — an item in the catalog, a “component” (routine).
  Catalog — a collection of components (library).
  Description — a component’s documentation.
  Application — what we’re building.

Now that a preliminary mapping between essential model and metaphor has been developed, a user scenario can be generated by restating the primary use case:

Developers build applications by including components selected from a catalog. The catalog is divided into sections that list similar components. The developer can browse the components in a section, reading their descriptions that include information about how they are used. If developers cannot find a desired component in a section, they can look in the index for other terms that might describe it. When the desired component is found it can be copied to the application.

The information needs and problems listed in the essential model should be addressed if possible in the user scenarios using elements of the metaphor. In the scenario above, sections in the catalog and the catalog index are used to address the problem of finding candidate components, and product descriptions provide information about the components.

A preliminary sketch of a catalog is shown in Figure 4.2. The sketch is an approximate visualization of the real-life metaphor objects and points out the elements needed to perform the various tasks. Unneeded elements of the real-life objects can be ignored. The sketch is not a serious proposal for a user interface but rather just “placing some puzzle pieces on the table” that can be rearranged later. The sketch is also a useful aid when reviewing the candidate metaphors with end-users and developers. Recording the metaphor and user-level concepts makes them explicit and is useful later when reviewing many sketches.


Figure 4.2  Preliminary sketch of catalog.

4.3. THE TASK TREE

The user model has a hierarchical tree of tasks and subtasks that the application must support. Each task specifies an action to be accomplished and the objects involved, expressed in the language of the user model. The tasks should include the obstacles that can arise and the information and subtasks needed to resolve them. It is this task tree that will drive much of the layout and interaction design of the user interface.

Much of the tree can be extracted from the user scenarios — the use cases restated in terms of the metaphor — but these scenarios typically illustrate only the primary functionality of the application, often missing secondary but necessary functionality, e.g., the setting of user preferences. The task tree on the other hand ideally should include everything a user can do.

Generating the complete task tree can be tedious and sometimes difficult because the lower levels may involve significant design effort. Typically it is sufficient to enumerate all the high-level tasks and flesh out their subtasks as the design for the primary tasks solidifies. Use the structure and patterns of the metaphor and platform standards as guidelines in designing these parts of the task tree.


Previous Table of Contents Next