Previous | Table of Contents | Next |
3. BRIDGING THE GAP: MAJOR ISSUES/CONSIDERATIONS
The bridging process can be conceptualized as a series of transformations that begins with the gathering of user requirements and ends with the creation of a design. While all of the methods discussed in this volume can be viewed that way, each contributor construes it somewhat differently, as would be expected. Each method has its relative merits and appropriate conditions of application. In most chapters the author(s) describes that transformation in the context of a methodology used with a specific design project. While the projects, the processes, and the methods vary considerably, the common theme is the building of that bridge between User Requirements and User Interface Design.
Some contributors view the design process as overlapping, but distinct stages within a reasonably well-defined theoretical framework. One example is Graefe (Chapter 3), who construes the design process as transformations on a set of representations, emphasizing the nature of the representations. Ludolph (Chapter 4), espouses a similar framework, although he chooses to speak in terms of transforming models, beginning with important user background information and ending with a concrete representation of how a user will interact with an application.
In contrast to a well-defined theoretical framework, some of the contributors tend to be guided more from a pragmatic perspective, describing their bridging process as a design story (Nilsson and Ottersten, Chapter 6) or describing the process from the perspective of design-related activities and their relative contribution to the effectiveness of the process (Simpson, Chapter 10). Some of the techniques have been developed for smaller projects designed by small, nonspecialized teams (Monk, Chapter 5), while others are suited for converting large, complex, mainframe systems to a GUI interface (Rohlfs, Chapter 8). Rantzer (Chapter 7) describes a framework where the notion of user interface is expanded to include user documentation. Two of the chapters discuss techniques that are particularly well suited to the development of products not yet on the market (Scholtz and Salvador, Chapter 10) or what Smith (Chapter 11) refers to as new generation products that introduce new technology. Finally, Dayton, McFarland, and Kramer (Chapter 2) describe a methodology for developing object-oriented GUIs, asserting their general superiority over task-oriented GUIs, whereas Rohlfs (Chapter 8) argues the opposite for her work in redesigning so-called legacy systems.
4. INDIVIDUAL CHAPTER DESCRIPTIONS
4.1. DAYTON, MCFARLAND, AND KRAMER (CHAPTER 2)
Dayton, McFarland, and Kramer describe a methodology (which they refer to as the Bridge) for quickly designing object-oriented (OO), multi-platform GUIs. The methodology produces an OO interface, which means that the GUI reflects the users focus on the discrete units of data data objects with which they do their tasks, and the interface concretely represents each task object as a GUI object. Dayton et al. point out that their OO GUIs differ from procedural GUIs, which are oriented around particular procedures for doing tasks, and from application-oriented GUIs. Furthermore, they claim that the OO GUI style generally provides the most natural and easy-to-learn user interface. This position is in contrast with that put forth by Rohlfs (Chapter 8), who maintains that redesigned legacy systems need to be more task oriented.
Having been developed at Bellcore, the Bridge method draws heavily on previous, related techniques developed there (e.g., CARD and PICTIVE, Muller et al., 1995). All design activities are performed in a participatory manner with a five-member design team (consisting of an expert user, a novice user, a usability engineer, a developer, and a system engineer) surrounding a small table. The team is assisted and encouraged in their work by two facilitators who are intimately familiar with the method. The authors describe their methods in the context of an application to support a hotel reservation system.
The major activities of the Bridge method are (1) expressing user requirements as task flows, (2) mapping task flows to task objects, and (3) mapping task objects to GUI objects. They are carried out in a series of very intense workshops over a period of a few days, under the guidance of the facilitators. The results of design activities are first written on cards and placed on the table, where they are easily accessible to all participants and can be altered or even discarded. As consensus is reached on results, they are attached to the surrounding walls of the room, where they are conveniently available for reference.
Once the definitions of task objects and the outline of task flows have been established, these are usability tested by having one team member talk through each step in the task flows and the other members verifying that all objects with accompanying attributes and actions are available for performing the required tasks. This is performed at an early stage and is independent of any GUI representations of the objects. After the task objects have been mapped to GUI objects using paper prototypes, usability testing is again performed by the team members. Final detailed design specifications for a particular platform are performed by a usability engineer in accordance with appropriate style guides.
Previous | Table of Contents | Next |