Previous Table of Contents Next


3.3.2. VIEWS OF GUI OBJECTS

Then the team decides the basic appearance of each window’s content, in other words, the “views” of the GUI object. The mapping is from each task object’s attributes sticky into the corresponding windows’ client areas (Figure 2.5). The team roughly sketches the view appearances in the heretofore empty client areas of the window photocopies and appends each title bar’s object instance name with a view name. Each view of an object is drawn on its own photocopied empty window, with all the views for the same object having the same leftmost menu name and the same title bar object instance name.

Views can be used to show different attributes, such as child objects in one view and properties in another (e.g., a customer’s reservations vs. a customer’s general information — see Figure 2.5); the containment sticky on the task object helps by identifying which of the attributes are child objects. For instance, the Room object might have one view showing a diagram of the room (see Figure 2.6) and another view showing the room’s furniture, equipment, and maintenance history. Views can also be used to show the same attributes, but in different ways. An example is having one view showing customers as textual rows in a list and another view showing customers as pictures of the customers’ faces.


Figure 2.6  Prototype output by Part 3. These are just some of the windows needed for the hotel example GUI. Each window is hand-drawn in a separate photocopied empty window. The user tests the prototype by tapping and dragging a pen or finger on these windows, while the rest of the participants respond by placing and removing windows, menus, and other GUI elements. For example, the user double-tapping on the Room 101 row in the Big Al's Swank Joint window causes Room 101 to open into its own window that is an additional piece of paper on the table. The Big Al's Swank Joint window uses an indented hierarchical list to let users see its reservation grandchildren without opening their parent — Tom Dayton — into its own window. However, if users want to focus just on Tom Dayton's reservations without the distraction of any other customers, rooms, or reservations in the window, they can still open Tom Dayton into its own window.

Multiple windows showing the same object instance may be open simultaneously (e.g., the two windows in Figure 2.5). Multiple object instances may be open at once (e.g., a set of Tom Dayton customer windows and a set of Joseph Kramer customer windows), so the team may paper prototype multiple instances to increase the richness of the usability testing. These windows usually are independent of each other, with users relying on the standard GUI windowing environment mechanisms of window moving, sizing, layering, minimizing, maximizing, and closing to manage the large quantity of information.

Users easily know how and where to open closed objects into windows because closed objects are shown inside the objects that users naturally think of as their containers (Figure 2.6). The Bridge methodology produces a GUI that reflects the users’ natural mental model of those containment relations, in contrast to many traditional approaches that force users to change their mental model to match the GUI.

3.3.3. COMMANDS FOR GUI OBJECTS

Then the menu bars and entire-window-level command buttons are designed by mapping them from the actions sticky of each task object (Figure 2.5). The menus are represented by preprinted, style guide standard, menu pull-downs. The leftmost menu has a blank for its preprinted name so that the team can write in the names of object classes to match the paper windows’ hand-lettered leftmost menu names. For example, if the actions sticky for the Customer task object says “Print”, then the team leaves the standard choice “Print” in the preprinted leftmost menu that they have labeled “Customer”. Preprinted menu choices that have no corresponding sticky entries are crossed off. Actions on the sticky that have no corresponding preprinted standard choice are written on the appropriate preprinted menus. To keep all the materials together, the menus for each object are removable-taped to an index card that is paper clipped to the object’s windows and task object card.

Also in this step, participants design and paper prototype the major portions of the transaction dialogue windows that support the commands most relevant to view definition. The most important of these is the dialogue supporting the Include action, which makes visible only the subset of information that a user wants to see in a given window at the moment (i.e., it is an inverse filtering action). The Include action allows the team to avoid designing a separate view for every subset of information they might ever want to see. Some other dialogue windows that should be designed at this point are those supporting the New, Sort, and Find actions.

The team has now produced a paper prototype that contains the data needed by the users to do their tasks, the menu bars and window-level buttons to manipulate the data, and the navigational paths among the windows. The paper prototype is now ready to be thoroughly usability tested by these very same participants in this very same session.

3.3.4. USABILITY TESTING OF GUI OBJECTS AGAINST THE TASK FLOWS

Throughout Part 3, the team has done quick usability tests of the incomplete paper prototype. But now that even the commands have been prototyped, the usability testing can be more realistic and thorough. A rectangle representing the computer screen is marked off with masking tape on the table top. One participant points to and reads each step in the task flows. One user uses a pen as the mouse pointer for clicking through the paper prototype to execute the task step being read. The rest of the participants act as the computer, responding to the user’s actions by adding and removing the appropriate windows and pull-down menus from the screen. Any time a problem is found, the team stops the test, changes the design and the paper prototype, then restarts the test. Usually, the task objects and even the task flows also are changed during this phase, in a rapidly iterative process. If time allows during the session, the team now adds some polish and detail to the paper prototype. For instance, they may add short cuts for expert users and complete more of the dialogue windows.

After all the documented task flows have been successfully executed with the paper prototype, the team tries other tasks to test the flexibility of the design. Thanks to the object-oriented style, often the design can handle tasks that were not foreseen during the initial design and the design can easily be modified to accommodate many other tasks.


Previous Table of Contents Next