Previous | Table of Contents | Next |
1.3. OVERVIEW OF THE BRIDGES EXPLICIT STEPS
All of The Bridges integrated three parts are the bridge from user needs to GUI design. This three-step methodology is done in a single, intense, participatory session that takes a minimum of three consecutive days. Four days is really the minimum desirable length of the session, and 5 days is more realistic if the participants are not to feel rushed and driven by the facilitators. Large projects may require multiple sessions, each session having a slightly different set of participants working on a slightly different portion of the project. Figure 2.1 shows a few examples of the outputs of the methodologys three parts.
Part 1 of The Bridge produces one or several well-documented task flows from the user perspective. The task flows concretely represent what the user wishes to accomplish with the proposed software product. However, the task flows do not refer to underlying system architecture or existing system representations of the data that the user wishes to access or manipulate. For example, the task flows would indicate that the user wants to know the customers total billable amount of charges rather than the user wanting to view The Billing Summary Screen. The task flow representation is index cards taped to flip chart paper, lines of flow between the cards being drawn on long, skinny, removable sticky notes (stickies). Each step in the task is represented as a noun and a verb written on a card, such as Print Customers Bill.
Part 2 (Task Object Design) bridges the task flows to the GUI design via creating somewhat abstract task objects from the nouns embedded in the task flows that came out of Part 1. Each task objects name is copied from a task flow step onto an index card and thrown onto the table around which the group works. For example, if one step in a task flow is Print Customers Bill, then Bill is written on an index card that is thrown onto the table.
The mapping and verification process continues within Part 2 by noting each task objects attributes on a sticky note attached to that objects index card. Many attributes are copied from their mentions in the task flows, but others come from the teams knowledge. This step eliminates many objects by discovering that their data can be adequately represented merely as attributes of other objects. If a task step is Print Customers Bill, then the Customer index cards sticky note might get the attribute category name Billing Info written on it, allowing the Bill index card to be thrown out. Then the actions that users take on that object are listed on yet another sticky; if a task step is Print Customers Bill, then the Customer index cards sticky has the action Print written on it.
The most difficult step in Part 2 is creating a strict hierarchy of all the task objects. The hierarchy is the mental model that the users feel best represents the relationships among the task objects on the table. For example, in designing an interface for managing a hotel, a user may want the Hotel object to contain a Customer object. This relationship can be totally different from the data structure being used by the developers and does not necessarily imply object-oriented inheritance. The attributes that are not child objects are properties. A concrete example is that a Closet object will have the clothing it contains as its child objects, and Type of Material The Closet Is Made Of as a property. In the hotel example, a Customer object has multiple Reservations as child objects, and an address as a property. Each objects index card gets a sticky that is marked with that objects parent and children.
Part 3 translates the task objects, with their attributes, actions, and hierarchical containment relations, into GUI objects. A GUI object is represented as a window when open and as an icon, list row, or other GUI element when closed. The window client area contents are GUI representations of the attributes listed on the task object attributes sticky. The form in which an attribute is represented in a client area depends partly on whether that attribute is listed as a child object or just a property. Each GUI objects windows are roughly prototyped in paper, with enough detail to give an idea of the type of representation (e.g., graphical, textual, list). Any object can be represented by multiple types of windows multiple views that can be open simultaneously.
What remains after the three-part Bridge is the filling in of design details. Those details are important, of course. However, they are much less important than the fundamental organization, appearance, and behavior that The Bridge does design. The remaining details are most efficiently designed by the usability engineer outside of a participatory session, though with consultation from users and others.
The output of the three-part Bridge methodology is a working paper prototype of an object-oriented GUIs foundation, whose design has been driven by the user requirements via the Task Object Design center span.
2. PERVASIVE TECHNIQUES AND ORIENTATIONS
Just as important as the three explicit steps of The Bridge are several techniques and orientations that are used in all the steps. These pervasive techniques and orientations do not just ease the steps, they are the medium in which the design team executes the steps. Here are brief descriptions of the most important ones.
Previous | Table of Contents | Next |