Previous Table of Contents Next


3.2.1. IDENTITIES OF TASK OBJECTS

The goal of this first step within Part 2 is to discover and document the identities of the discrete units of information that users need for doing their tasks that are represented by the Realistic and Desirable task flows output by Part 1. This step is quite simple and fast and is similar to many object-oriented methods. Participants merely copy each noun from the task flows onto an index card and place the resulting cards on the table. They do not write verbs, just nouns. Participants must not write GUI object names such as “a scrolling list of customers”, but only abstract task object names such as “a set of customers”. Each card also gets a one-sentence definition written on it. The object must not be defined purely in the abstract, such as “Hotel — building used to accommodate travelers”. Instead, the object must be defined as it relates to the GUI being designed, for example, “Hotel — collection of rooms that customers rent”. To save time, everyone at the table does all this in parallel; then the group as a whole reviews the cards, revises them until getting consensus, and throws out the duplicates.

Participants should not spend much time debating whether all these task objects really qualify as full-fledged objects, but they should go ahead and throw out any cards that represent objects outside of the GUI being designed. For example, “call the bellhop” may be a step in a hotel check-in task flow, but if that is purely a manual procedure having nothing to do with the GUI (the desk clerk yells to the bellhop), then the “Bellhop” index card should be thrown out.

The output of this step would be just the topmost rectangles in Figure 2.3— the index cards labeled “Hotel”, “Room”, “Customer”, and “Reservation”. Each task object is really an object class, so the Customer task object represents the class of all customers. The actual user interface would have separate object instances such as the customers Tom Dayton and Joseph Kramer, but object instances are not represented explicitly in The Bridge methodology until Part 3.

3.2.2. ATTRIBUTES OF TASK OBJECTS

Next the participants more fully describe each object by writing its attributes on a blue sticky note that they attach to the bottom edge of that object’s index card (see Figure 2.3). There are two basic kinds of attributes each object can have: child objects, which are themselves objects and so have their own task object index cards; and properties, which are not objects. Child objects are what the object is made up of, such as a hotel being made up of rooms and customers and a customer being made up of reservations. Properties are what the object is, such as a hotel having a name, a type (e.g., luxury), and a status (e.g., sold out). At this point in the methodology, no distinction is made between those two types of attributes; participants merely write all the attributes they can think of on the attributes sticky. Some of the attributes come from what is written on the task flows, but many come from the participants’ knowledge of the domain.

Many of the index cards are discarded during this step, as the participants learn more about these nominal objects and refine their notion of objecthood. Participants should try to reduce the number of task objects during this step, because users find it easier to deal with a few object classes each having lots of attributes than with lots of object classes that are almost identical. Deciding which units of data qualify as bona fide objects is not based on hard and fast rules but on rules of thumb and the context of users doing their tasks. Objecthood is necessarily a fuzzy concept, and not until Part 3 of the session do participants get a good feel for it. Participants change their minds right through Part 3, usually by continuing to reduce the number of objects, and that is perfectly all right. Some rules of thumb:

  If users’ domain knowledge has them think of the unit of data as an object (e.g., hotel, room, customer, reservation), then make it an object.
  If users ever want to see only a few of the attributes of the unit, but sometimes want to see all of them, then the unit should be an object so that it can be presented in the GUI as both closed (e.g., a row in a list) and open (a window).
  An index card having no attributes listed on its attributes sticky means that this “object” should instead be merely an attribute of other objects, listed on their attributes stickies but not having its own index card.
  If there might be several instances of the unit of data, and especially if the number of instances that might exist is unknown but could be large, then the unit of data might be an object.
  If users want to create, delete, move, and copy the unit of information, they are treating it like they would a physical object, so the unit might be an object.

In Figure 2.3, the second rectangle from the top in each of the four collections is an attributes sticky for that task object. One of the attributes listed on the Customer object’s sticky is “Bill Info”, which stands for an entire category of attributes. That attribute category was added to the Customer only after the participants realized that the attribute category served the task just as well as a separate “Bill” object did. In the Identities step they had created a separate Bill task object by copying “Bill” from the “Print Customer’s Bill” task step card in Figure 2.2. But in this Attributes step they realized that the phrasing of the task step could be reinterpreted as “Print the Bill Info attributes of the Customer”, making Customer instead of Bill the task object. Printing the bill would then be done simply by printing the Customer, setting the Print action’s parameters to print only the bill information and in the bill format.


Previous Table of Contents Next