Previous Table of Contents Next


This step of designing containment should be focused on the abstract containment relations among objects as represented by the containment stickies rather than being focused on any GUI representations of objects or containment. Not until Part 3 of the methodology will containment be given GUI form. However, part way through this step the participants usually need a glimpse into the GUI consequences of the containment relations they are now deciding. Figure 2.4 is the kind of picture that should be shown briefly to participants at this point: A hotel instance, Big Al’s Swank Joint, is represented as the open window in the top left of the figure. Individual customer and room instances are children of that hotel and are represented when closed as rows in a list. The children’s containment in the hotel means nothing more than visual containment of the children’s closed representations within their parent hotel’s open window. Users might be able to see enough information about the customers and rooms just by reading the attribute values displayed in columns across the rows. If users do need to see more information about Room 101, they double-click on that row to open it into its own, additional, window, as shown in Figure 2.4. The closed representation of Room 101 continues to exist within its parent’s window, but Room 101 now has its own open representation as well. Only one or two examples of this kind should be shown to participants at this point in the methodology, since more than that would get them thinking too much about GUI details.


Figure 2.4  The eventual GUI consequences of task object containment. A few pictures such as this are briefly shown to participants during Part 2 to help them understand why they are deciding the containment relations among the abstract Part 3. This figure shows instances of the Hotel and Room objects as they appear after being mapped into GUI during Part 3. The Hotel task object had “Room” written in its “In Me” column (see Figure 2.3), so here the corresponding Hotel window contains closed Room instances as rows. Double-clicking on the closed Room 101 row opens that room into its own window, and double-clicking other rows would open yet more windows. The room windows are outside of the hotel window since containment means only that closed objects are shown within their open parents.

Participants must check that the hierarchy is not tangled — that each task object has just one parent. In the polishing phase of the design process, multiple parents may be allowed, but at this point in the methodology it is best to keep the hierarchy simple. It is also important to check that objects do not contain their own parents as their children.

Although the parent of an object must not be shown as a child object of that object, it is perfectly legitimate to show the name of the parent as a property of the object. For example, the Room object’s attributes sticky may have “Hotel” written on it as a property, but certainly “Hotel” will not be written in Room’s “In Me” column. Rather, “Hotel” will be written in Room’s “I’m In” column. In general, context determines whether an object is shown on another object’s card as a child object or just the name shown as a property. It’s okay for an object to be a child of one object while having its name shown as a mere property of another object. One difference between child object and property in the GUI to be designed during Part 3 is that a child object can be opened by double-clicking on its closed representation. In contrast, object names shown as mere properties are just strings of text; to open the named object, users must find its representation as a true child in some other window.

There are ways to shortcut the single-parent restriction, but our methodology protects participants from such complexities until the end of Part 3. Here in Part 2, every object usually should have a single parent, with all other names of that object being mere properties. This produces a simple, strict hierarchy that is a solid basis for the steps of the remainder of the design process. During the GUI designing (i.e., Part 3), some of those object-names-as-properties may be turned into links, or a multiple-parent model may be adopted. Those activities usually should not be done here in Part 2.

Many task objects are converted to mere attributes of other objects during this step; in other words, their index cards are thrown out after their attributes stickies are moved to other objects. The team’s bias should be to have very few task objects (i.e., object classes) even if that requires each object to have lots of attributes. A plethora of attributes in an object can later be managed in the GUI representation of the object by bundling the attributes into frames, notebook pages, Included subsets, and views, all of which are more easily accessible than are entirely different objects.

3.2.5. USABILITY TESTING OF THE TASK OBJECTS AGAINST THE TASK FLOWS

You don’t need a GUI to do a usability test! The team (which, as always, still includes real users) now tests whether the set of task objects is usable for executing the task flows it designed in Part 1. One person talks through each step in the task flows, with the other participants checking the task object cards and stickies for the presence of all the objects, attributes, and actions needed to execute that task step. The team usually will discover that the task objects or even task flows are incomplete or incorrect. If so, the team should change them; this entire workshop methodology is an iterative process.

As of yet, any GUI is irrelevant. The team must do this usability test only at the rather abstract level of task flows and task objects. This is a usability test, but of the conceptual foundation of the GUI instead of the surface of the GUI. Discovering usability problems at this early stage saves the resources you might otherwise have spent on designing the surface of the GUI incorrectly. The earlier in the design process that usability testing happens, the more leverage is gotten on resources.

The output of Part 2 is a set of task objects sufficient and usable for doing the task, each task object documented as an index card with stickies as shown in Figure 2.3. This set of task objects is the input for Part 3, which maps those rather abstract task objects into GUI objects.


Previous Table of Contents Next