Previous Table of Contents Next


3.3. PART 3: MAPPING TASK OBJECTS TO GUI OBJECTS

The goal of this part is to translate the output of the Task Object Design step (Part 2) into GUI elements such as windows and menu choices. Our terminology is that the abstract “task objects” are mapped into “GUI objects”. Task objects manifest only as index cards, whereas GUI objects are the corresponding abstract data objects that manifest as combinations of GUI elements such as windows. The resulting GUI is object oriented, conforming in fundamental look and feel with the four GUI platform styles we mentioned at the start of this chapter: IBM CUA (IBM, 1992), Microsoft Windows (Microsoft, 1995), OSF/Motif 1.2 (Open Software Foundation, 1993), and X/Open CDE (X/Open Company Ltd., 1995). A valuable tool for getting that multiplatform look and feel is the multiplatform design guide by McFarland and Dayton (1995).

Using any of those style guides (or any current or future ones) necessarily is too time consuming and difficult during the initial designing activities, especially in the midst of a participatory session. All style guides, by their essence, are useful mostly as references for designing the details of a GUI after the participatory session. Here is how our methodology largely eliminates the need to use style guides during the participatory session.

  It breaks up the design process into steps that each map strongly into well-bounded components of the style (e.g., most task objects are expressed as GUI windows).
  It uses paper prototyping materials that reflect the desired style (e.g., photocopies of empty windows printed from a screen of the desired style).
  For the few style guidelines that do require explanation during the session, the methodology communicates each by brief lecturing with just a few overheads, at just the time in the process when that particular guideline is necessary.
  It postpones designing of the details until after the participatory session. It does this by skipping some of the details (e.g., some of the standard buttons on secondary windows) and by letting participants draw some components on the paper prototype in any way they like (e.g., put the buttons either on the side or the bottom).
  It includes style experts either as participants (usually the usability engineer) or as facilitators.

Of course, many platform-specific characteristics must be specified during the session, in order to draw even the basic pictures used as the paper prototype. Therefore, one of the target GUI platform styles is chosen by the team for the purpose of paper prototyping. If the GUI must also be produced in other styles, then after the session the usability engineer copies the fundamental design while changing the platform-specific details in minor ways to make them conform exactly to the other styles.

Part 3 of the methodology designs only the fundamentals of the GUI per se. That means the resulting window definitions include window types, window views, and window commands (menu bar choices and control buttons), but not accelerator key combinations and icons. Those and other details are filled in by the usability engineer after the participatory session because the other participants usually can contribute less to those activities, and a participatory session is not a particularly efficient medium for doing that kind of detailed designing. Nor does Part 3 of the methodology design user support such as documentation and on-line help. Those things are important, but they need to be designed via methods that fully focus on them.

There are several steps in Part 3; they involve designing, documenting, paper prototyping, and usability testing the GUI fundamentals. As in the previous two parts, no step is begun until the previous step is mostly complete, but there is considerable small- and large-scale iteration among steps. Almost always, the participants gain insights during this GUI designing part that prompt them to change the task objects and even the task flows. Each step in Part 3 maps a different aspect of the task objects to GUI objects, as exemplified by Figure 2.5. The following sections briefly describe the steps that do those mappings.11


11Readers wanting more GUI style descriptions as context for better understanding these method descriptions should see McFarland and Dayton (1995), IBM (1992), or Microsoft (1995).


Figure 2.5  Mapping a task object to a GUI in Part 3. In the Identities step of Part 3, participants map the object class name into the name of the leftmost menu of a window and into an instance name in the title bar. In the Views step, participants of one or more window views — creating an additional paper window for each view — and append the view names to the window titles. (This figure does not show the Bill Info view.) In the Commands step, participants map the actions into choices from pull-down menus or into window-level buttons. Participants hand draw on photocopies of empty windows.

3.3.1. IDENTITIES OF GUI OBJECTS

The core mapping of task objects to GUI objects is done by deciding which GUI representations each task object should have. All task objects must be represented as closed objects in the GUI. There are many possible closed representations, such as list row, icon, and menu choice (for device objects). The decision on the particular closed representation is not made in this first step of Part 3. This step instead requires participants only to decide whether each GUI object’s closed representation can be opened into a window, and if so, whether that should be a primary window or a secondary window. The bias should be toward primary windows, largely because primaries can remain open despite the closing of the windows from which they were opened. (This GUI style uses only Single-Document Interface style, SDI, not Multi-Document Interface style, MDI.)

Participants document their decision to show an object as a window by paper clipping a photocopied empty primary or secondary window to the task object card. They write in the window’s title bar the name of an object instance; in the example in Figure 2.5, the title is “Tom Dayton” because Tom Dayton is one instance of a Customer. If the window has a menu bar, they name the leftmost menu with the name of the object class; in Figure 2.5 the leftmost menu is called “Customer” because the window as a whole represents a particular customer. Figure 2.5 actually shows more than the result of this first step, since this step uses only one photocopied window per task object and leaves the window’s client area empty. The next step defines additional windows.


Previous Table of Contents Next