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 interfaces 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 objects 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 customers 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 mechanics 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 Im 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 clerks 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, Hotels third sticky has Desktop written in its Im 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 Hotels In Me column. Consequently, the Room and Customer stickies have Hotel written in their Im In columns.
Previous | Table of Contents | Next |