3.2 Idiom
Figure 3.1 shows the design activities that make up Idiom, together with arrows indicating the major paths through which activities provide informing design data to other activities. Activities can be and are performed in an interleaved fashion. There is a notion of a completion order to activities, roughly downward in the middle and right of Figure 3.1. Idiom accommodates opportunistic design practices and informing and iterative design. In opportunist design, design activities are chosen on the basis of prior experience with similar situations and on the basis of new design opportunities provided by discoveries made during ongoing design. Design opportunities occur in problems characterized by ambiguity, ill-formedness, and multiple sources of knowledge. These are all characteristics of early interactive system design. Multiple sources of knowledge characterize much, if not all, of interactive system design activities. The process in which one activity provides design information as input to another is known as informing; activities that supply information to each other are mutually informing [Henderson 1991]. Iterative design occurs when a designer repeats a design activity, often in light of new knowledge about the design problem. The new knowledge might, for example, have been generated by another design activity, as a result of a user evaluating a prototype, or as a result of a designer reframing the design problem.
){kind=link}
Figure 3.1 Design activities and major information flows in Idiom, together with subsequent development activities
The overall process of using Idiom includes the following:
User categorization, scenario generation, and task modeling as a basis for further user interface design work.
-
Construction of domain and core models. The choice of types (classes) 2 for these models is based on the objects that are required for task performance. Design of the core model is conceptual design in many user interface design methods.
Construction of the view model, an abstract specification of the component parts of views, and of how views are dynamically created and destroyed. The view model is derived from the task model and the core model. Views provide the context for task execution. In a windowed environment, views are implemented as windows.
-
Design of the concrete details of the user interface to the interactive system within the constraints of the choice of a particular implementation platform and interaction style. The resulting concrete user interface design includes the user-perceivable representations of objects in the core model, how the user interacts with these representations, selection mechanisms and their use, commands and their means of invocation, dynamic feedback during interactive operations, interaction techniques, 3 cursor design, screen/window/panel layout, and error and exception handling. The design hopefully includes a help system design, user documentation, and perhaps training aids.
Development of prototypes of the system and evaluation of those prototypes. The evaluation is a formative evaluation, where the evaluation informs redesign.
Together, the view model and the concrete user interface design specify the design of the user interface, and are, together with the task and core models, primary inputs to the rest of the development process. If the development employs use cases, these can be generated from the task model before development activities start.
The following object models, shown in Figure 3.2, are used in Idiom.
){kind=link}
Figure 3.2 Some models in Idiom (task models not shown here)
The domain model specifies the application domain that is of interest to the users and designers.
The domain model is the basis for the core system model (or, simply, the core model) of the computer system that is being designed; the types in the core model are close to a subset of those in the domain model. Core modeling has similarities to conceptual design, system analysis, and object-oriented analysis.
The types in the domain and core models represent referents (objects used by users in their task-based behavior) that are important to users in their (future) task-based behavior in the application domain.
The type definitions in the core model must eventually contain operations that correspond to abstractions of user interactions.
The core model is augmented with a view model, which specifies aspects of user interaction with the system. The view model, combined with non-object-oriented user interface design artifacts, forms part of a larger interaction specification.
The use of the term "view model" does not imply limitations only to the design of GUIs; in Idiom, a view is simply a modeling construct that is useful in designing presentation and interaction.
Together, the core and view models form the interactive system model.
Idiom also includes an extra object model that is not used in the method, but exists to emphasize the abstract nature of the previously mentioned models. The development model is a derivation of the interactive system model that preserves the interaction specification while adding extra detail needed for system implementation purposes. The development model may go through several derivation steps en route to the final model of the implementation. The process of development modeling can be usefully thought of as the construction of object-oriented models of the system for (a) object-oriented analysis (OOA) activities that are not covered by Idiom and (b) all technical object-oriented design level (OOD-level) modeling.
Within any design-implementation-evaluation cycle in Idiom, the completion order for modeling is first the domain model, then the system and interaction models, and then the development model(s). The process of development modeling may be performed with any development method, object development methods being more compatible with Idiom than with other methods. Consequently, the development model is shown as an object model in Figure 3.2.
The general emphasis in the domain, core, and view models is on the structural view [OMG 1999] of the system. Taking a formal point of view, Idiom does not use an approach based on internal interactions (message passing) within these models. Rather, Idiom uses a model-based specification approach with optional pre- and post-conditions to specify the dynamic behavior of the system in response to user interactions. Message passing can subsequently be used to depict internal model and system behavior, thereby allowing the possibility of a smooth transition to fully developed OOA models. Use cases are not used; instead a task model is used to describe envisioned user behavior. Use cases can be easily produced from task information to ensure compatibility with conventional use case based object-oriented analysis and development (OOAD). Finally, notwithstanding Idiom's eschewal of internal interactions for design purposes, it is assumed that the normal way of ensuring consistency and viability of object models, analysis of dynamic behavior, and generation of UML interaction diagrams, would be performed as a background activity, if needed.