Previous Table of Contents Next


3.2.3. ACTIONS ON TASK OBJECTS

In this step, the participants record on pink sticky notes the actions that users need to take on the objects (the third rectangle from the top in each of the collections in Figure 2.3). These are actions done to an object, such as printing it, rather than actions done by the object. The only actions of relevance here are those actions done by users to the objects; actions done by the system are not the focus here, though they can be added as parenthetical annotations to the user actions. The starting point for discovering actions is the task flows, since each step card in the task flows has a verb as well as a noun. In addition to actions listed on the task flows, participants should consider standard actions such as view, create, delete, copy, edit, save, run, and print. Users may write whatever terms they like, such as “change” and “discard” instead of more computer-standard terms such as “edit” and “delete”. For now, these action names need not match the style guide standards for menu choices and buttons, since the names on these stickies will be translated into GUI style standard terms during Part 3.

This Actions step of Part 2 is important, because it finishes gaining one of the benefits of the OO style of GUI — using each window to represent a single data object, with several actions easily taken on that data object. We and others contend that is easier for users than is a typical procedural interface’s separate screens needed for doing different actions to the same data. “View” and “edit” actions are common examples: In many procedural interfaces users must tell the computer that they want to “view” before the computer will ask them what data are to be viewed, and they must issue a separate “edit” command before the computer will ask what data are to be edited. An OO GUI instead lets users find the data object without requiring them to specify what they want to do to it. Users can see the object’s attributes, and if these users have permission to edit this object, they can just start changing what they are already looking at. For example, different steps called “Specify which customer to check in” an “Specify which customer to check out” might be replaced with a single “Find Customer” step that is common to the check-in and check-out tasks. Checking in a customer and checking out a customer might then become just “Check-In” and “Check-Out” actions on the same menu of that customer’s window.

Figure 2.3 shows examples of actions on task objects. For instance, the task flow step “Create Customer” (shown in Figure 2.2) would have already stimulated participants to create a task object called “Customer,” and now the action “Create” would be written on the actions sticky attached to the “Customer” task object index card shown in Figure 2.3.

3.2.4. CONTAINMENT RELATIONS AMONG TASK OBJECTS

The goal of this step is to ease users’ navigation through the software by making the GUI represent the users’ existing mental model. That is done by capturing the users’ natural mental model of the real-world relationships among the task objects completely aside from any GUI, so that in Part 3 those relationships can be translated into visual containment among the GUI objects. The input to this step in Part 2 is the set of task object cards, each card having two stickies. The output is that set with a third (yellow) sticky on each task object, showing all parent and child (no grandchild) containment relationships of that object. See the bottom rectangle of each collection in Figure 2.3 for examples. The task flows are not especially relevant for this step because the goal is to capture the users’ mental model of the objects’ relations to each other aside from any particular task.

“Parent” and “child” mean only the visual containment relation between objects, not any kind of subclassing relation as is meant by those terms in object-oriented programming. These containment relations are not tied closely to the dynamics of the task flows, but are static relations. They are the intuitive hierarchies among the objects when users think about the objects they use to do their tasks. When participants design this containment hierarchy, they are designing the foundation of the users’ mental model of the GUI universe. For example, a car mechanic’s universe of cars has the car containing the engine and the engine containing the pistons, regardless of the particular activities the mechanic does with those objects:

Car
Engine
Piston

In this Containment step the distinction between child objects and properties is made sharply, in contrast to the Attributes step which listed both types on the attributes sticky. Child objects are attributes that are themselves treated as objects within the context of their parent. Properties are attributes that are not themselves treated as objects within the context of their parent. In this step the participants examine all the attributes listed on the attributes sticky for each task object and copy those attributes that are child objects onto the “In Me” (right hand) column of the containment sticky (see Figure 2.3). The child objects now are listed on both the attributes and containment stickies, whereas the properties are listed only on the attributes sticky. Then the “I’m In” (left-hand) column is filled with the names of the task objects on whose containment stickies this object is listed as a child.

Figure 2.3 shows the example of Hotel, Room, and Customer. Hotel is the ancestor of all objects within this desk clerk’s GUI, but Hotel itself lives within the Desktop — the mother of all objects in this GUI platform, which fills the entire computer screen, in which all the other windows and icons appear (e.g., the Microsoft Windows desktop). Therefore, Hotel’s third sticky has “Desktop” written in its “I’m In” column. Only two of the attributes of Hotel have their own task object cards (Room and Customer), and desk clerks do think of those two objects as children of Hotel, so “Room” and “Customer” are written in Hotel’s “In Me” column. Consequently, the Room and Customer stickies have “Hotel” written in their “I’m In” columns.


Previous Table of Contents Next