- Introduction
- Idiom
- Designing and Specifying User Interfaces with Idiom
- Early Work with Users and the Domain
- Formulating Abstract Descriptions of the Interactive System
- Concrete User Interface Design
- Generation of Use Cases
- Conclusions
- Acknowledgments
- References
3.3 Designing and Specifying User Interfaces with Idiom
In what follows, the use of Idiom is illustrated by the partial development of an example. Design activities are divided into early design-related work and early design, later abstract design, and later concrete design.
"Early" design-related work characterizes users, their tasks, and the application domain. Early design work includes exploring early ideas and visions of the system (see Section 3.4).
"Later" abstract design is concerned with designing and abstractly specifying the interactive system, including its core structure and aspects of its user interface, the latter by developing a view model (see Section 3.5).
"Later" concrete design is concerned with designing, describing, and specifying the detail of the concrete user interface design (see Section 3.6).
This time- and abstraction-based division is only one of convenience; activities may be ordered concurrently and opportunistically. It is likely that (a) system visualization is performed throughout the design cycle, (b) the "early" work will be revised later on, and (c) abstract and concrete design activities will be interleaved while the abstract structure is being firmed up.
To illustrate both Idiom's process of design and the resultant design artifacts, an example of an Internet-based chat system is developed in the next three sections. A simple and open-ended specification for this system is that the chat program enables users to communicate by typing messages to each other in the context of conversations that they initiate, participate in, and leave. The example illustrates the design of a single user's user interface to a distributed multi-user system.
This example was in an application area in which the author/designer had not used applications since using primitive UNIX chat utilities. It was felt that working in an unknown domain and choosing representative future users who were not current chat system users might illuminate interesting properties of Idiom when the final design was compared with current chat systems such as ICQ and Instant Messenger. For related experimental reasons there was a conscious decision to avoid some activities that would normally be part of good user interface design practice—namely, observation of the use of existing systems, discussions with existing users, and use of prototypes by existing users. Results show that these are essential activities: without performing them, there is a strong risk of not supporting the current activities of existing users.
In addition, the example has a development model that expresses a client-server architecture that, for users of the chat service, need not be considered in the domain, core, and view models. This serves to emphasize the fact that Idiom is concerned with the users' experience of the system, rather than the invisible implementation architecture and technology. 4