3.8 Conclusions
In comparison to Idiom94, the new version of Idiom provides a better foundation for interactive system design by incorporating a thread of development that considers scenarios of system use, task and referent identification and extraction, and interactive system design based, in part, on task execution contexts. In this respect, some of the notable features of Idiom are:
The use of task analyses and scenarios to generate task descriptions (different in approach to Rosson and Carroll's use of scenarios to generate POV analyses and thence object models; see Chapter 2).
The use of task descriptions to identify referents and populate the domain model and its derived core model with referents.
The use of a task analysis together with referents that are identified by task to identify and merge task execution contexts.
The use of task execution contexts and the core model to guide the discovery and composition of views.
The use of the view model to determine some aspects of the concrete user interface, for example, the contents of top-level views implemented as windows.
The enhanced method has been used sparingly, and more method development is anticipated, particularly with regard to participatory design. So far the enhanced method has been used in small studies, successfully applied by post-graduate computer science students to design problems in extended exercises, and used by the author and a colleague in a tool construction project. For the latter project, the method was mutated (making the method fit the problem and the resources, including the designer skill set, as recommended in Chapter 10). The domain and core models were drawn almost immediately and an envisioned task model was constructed rapidly.
Competing concrete user interfaces were designed and paper prototyped. The prototypes were iteratively re-designed with user participation during prototype evaluation and redesign. A horizontal computer-based prototype with only limited functionality was then built and tested, but due to the complexity of some of the underlying functionality for the design, a full evaluation of the resultant design could not be performed until the implementation phase was completed.
3.8.1 How Does Idiom Perform?
In developing the new method, the following five methodological concerns had to be addressed.
Coverage: Are all the relevant sources of design information incorporated into the method? Do the outputs adequately convey the interactive system design, particularly for subsequent object development?
Process: Are the design techniques capable of being used in a process framework of an opportunistic and informing design practice? Can activities be scheduled in a commercial environment?
Notation: Do the notations used in the design techniques support the creation, recording, and communication of the design information? Do they support reasoning about designs, including competing designs? Do they support the transfer of informing design information to other techniques?
Completeness: Is there at least one path from inputs to outputs?
Usability: How usable is the new version of Idiom? The new version of Idiom requires more use before questions about its usability can be answered. Preliminary results indicate that sequence diagrams need to be replaced, or, at least, used with discretion, and that the dynamic view modeling notation needs to be simplified or replaced.
Idiom now accommodates a wider range of inputs, incorporating upstream scenario-based design, and strong encouragement for user involvement. Participative approaches still need to be formally introduced into the method to more fully and effectively base the method on a deeper knowledge of user world phenomena. The outputs have been somewhat refined, incorporating a view transition model, and lessening the reliance on interaction sequences to specify dynamic behavior. A combination of task, use case, and object models, together with prototypes and concrete user interface design information, serve as a specification for subsequent development.
Supporting opportunistic design has always been an aim from the earliest days of Idiom. This is now well established at a method level. The ability to schedule work is provided by imposing a completion order on Idiom's design techniques.
The move to scenario-based design and the increased role of task-based design have been promising with regard to the use of these descriptions to create further design information. Textual representations of scenarios and tasks are used for object identification and extraction prior to the formation of object models. Task models lead to the identification of task contexts and windows and to the construction of the dynamic view model. For those that understand object modeling notation, object models successfully record and convey system structure and behavior for design purposes. As a pre-development hand-over activity, use cases can be generated from the task model. The representations support reasoning about the current state of design, development of the design, and the ability to express competing designs. The view transition notation requires further development to facilitate rapid and easy use.
Idiom provides a design path that spans from scenario generation to the specification of an interactive system and supports designers in moving to the interaction design level.
As yet, however, there is little to guide the detailed concrete design. When proceeding from the core and view model to a concrete design (as opposed to proceeding in the "opposite" direction by, say, abstracting view and perhaps core model features from a paper prototype), Idiom takes the designer as far as realizing that certain objects or features of objects and their associations have to be displayed together, but it provides no systematic guidance on the final stages of mapping the models to a concrete user interface design. This lack of process, including its aspects of participatory design and evaluation, must be addressed in future versions of Idiom.
My feeling, and this is no more than a feeling, is that scenario-based design is relatively heavyweight when compared to participatory design approachs. An observation is that to be able to use the method, a mix of user interface design and object modeling skills are needed. This has team-structure implications. In common with Gulliksen et al. (Chapter 8) current and future method work will concentrate on a greater participatory emphasis.
3.8.2 Idiom as an Accommodating Framework
The more Idiom is developed, the more it comes to reflect a particular style of framework for user interface design and object modeling activities. This is neither the only framework nor a complete framework for the kinds of methods discussed in this book (see Chapter 10 for the latter). The "Idiom framework" involves the binding of user interactions to object models by means of pre-and post-conditions. It is flexible enough to accommodate a wide variety of different specifications of system use by optionally deploying the binding mechanism. The framework is shown in Figure 3.27.
){kind=link}
Figure 3.27 Use and model binding in Idiom