Designing with Idiom

3.5 Formulating Abstract Descriptions of the Interactive System

Descriptions generated from the early design material include the core model, a finer-grained task model, and the view model. It is useful to categorize these models together as abstract descriptions, even though the task and view models start to articulate some concrete user interface design choices and therefore the descriptions incorporate some non-essential interaction detail. The general categorization as abstract descriptions distinguishes these models from the concrete user interface design.

3.5.1 The Core Model

The core model of a system or application represents the part of the domain that is of interest to users of that system [van Harmelen 1994] and that is (to be) represented by the computer system. Like the domain model, the core model is a structural model that is concerned with referents and relationships between them, independent of user interface concerns. ⁷

The core model is based on a subset of the domain model. For the example here, the core model is a slight transformation of a subset of the domain model.

Different kinds of users will have different tasks to perform using the facilities offered by the system and may only be concerned with different, possibly overlapping, parts of the system. Identifying the boundaries of concern delimits and focuses subsequent user interface design. Idiom can use different core models with referents derived from user-specific sets of tasks for different kinds of users and would name these by preceding "core model" with an appropriate actor name. Thus, for example, assuming that normal users of the chat system use only the chat facilities and will not need to know about chat clients and chat servers, there is no mention of clients and servers in the normal user's core model. Chat system administrators would have server objects in the administrator's core model, thereby allowing the subsequent design of a user interface that enables the administration of servers. Such partitioning is discussed by Collins [1995, p. 190] as "partitioning the analysis model into system models for different types of users." Clearly, designers should assure themselves that different core models are compatible and conform to the corresponding domain models.

Here we call normal chat users local users. In developing the local users' core model, the starting point is the domain model, as shown in Figure 3.12. Because the design is for a single local user's interface, a local user is emphasized. In Figure 3.13, only the local user's address book is considered, and not those of other users. The model is then transformed, as shown in Figure 3.14, into a representation of a chat system for the local user. In Figure 3.14, other users are represented as address book entries called User.

Figure 3.12 Chosen domain model

Figure 3.13 Intermediate model

Early core model decisions strongly influence the resulting interactive system. Giving each local user access to only a personal address book is a design decision that illustrates how the interactive system can be limited from an early stage by particular design choices. In this case, the local user is limited to the use of entries in only one address book. The core model would have to be revised in order to model the use of other address books, such as shared corporate address books.

A singular System type is introduced in Figure 3.14 to encapsulate systemwide functionality and to act as an anchor for the other objects in the model. Any types participating in associations with the local user can instead be safely associated with the system type, because both types are singular and, at this level of consideration, there is implied reachability from the user to all core objects, including the system object. System is often referred to simply as "the system object" in the context of the core model. The system object serves as:

Figure 3.14 The local users's core model—this package is later represented as a type (in Figure 3.21)

• A place for useful system operations, such as setting systemwide preferences, initiating major system functionality, or exiting the application.

• A place for operations that create core objects, typically for those core objects that are directly linked to the system object.

• An anchor for other objects in the model. In conjunction with relations between objects, the anchor ensures navigability to all objects in the model.

3.5.2 Finer-Grained Task Models

The coarse-grained task model in Figure 3.4 was limited to tasks that could be expressed without introducing tasks that reflect concrete interaction details. The task model is now extended to include more details of user interaction by moving the task model toward a finer level of granularity that expresses some concrete design choices. These choices are exemplified here by the implied use of dialog boxes in LeaveConversation, as shown in Figure 3.15.

Figure 3.15 A more detailed (or fine-grained) task model

3.5.3 The View Model

Whereas a core model is an abstraction representing a user's view of the deeper contents of the system, a view model provides a specification of how the user interacts with the system and provides the basis for subsequent concrete user interface design. A view model is composed of a static and a dynamic view model.

A static view model specifies the structure and contents of the user interface. The model is divided primarily into top-level views, each of which is implemented as a window or dialog box in a windowed environment. Top-level views are used to provide users with the information and the interactive facilities necessary for task performance. A view is composed of view objects that may be for internal view use or that may be rendered and provide interactive behavior at the user interface: some view objects exist to represent core objects or other view objects,⁸ and some view objects exist purely to specify interactive capability. In a static view model, top-level views and view objects provide an abstract specification of the composition of the interface and of some aspects of interaction. They do not reflect how the interface will be implemented.

A dynamic view model articulates the run-time view behavior of the system by describing the way in which top-level views are created and destroyed as a result of user interactions and system events.

3.5.3.1 Identifying Top-Level Views

Because top-level views displayed as windows provide contexts for task execution, they should support the user in his or her task-based behavior by making available (a) representations of the application objects that the user needs to refer to and/or manipulate during task performance, (b) controls to invoke suitable operations, and (c) feedback during and after the operation invocation. Unless there are strong motivating reasons not to do so, the user interface design should cater to task execution without the user having to manipulate multiple top-level views in order to complete a task (see also Chapter 8). As such, all task-related information and functionality should appear in or be easily accessible from the view supporting the performance of that task. To further reduce view switching by users, views should, whenever possible, support the performance of related tasks.⁹ The analysis described here enables designers to (a) extract task contexts from task models for implementation as windows, dialog boxes, and tool palettes; and (b) inform the static and dynamic view modeling described in Sections 3.5.3.2 and 3.5.3.3. The techniques used here provide low-cost, low-commitment choices which allow for easy revision of existing choices.

The initial step is to choose tasks to be executed within particular task execution contexts that will be realized as windows. To choose task execution contexts, it is useful to annotate a task model: Figure 3.16 shows boxes drawn on a task model to represent contexts within which the boxed tasks can be executed. Overlapping boxes are necessary for tasks envisaged as being implemented with cross-window drag-and-drop operations. ¹⁰ The core objects and attributes that are used in task execution (revealed by referent identification from task descriptions in Section 3.4.4) can be recorded inside the corresponding boxes. This annotation enables the detection of any tasks using the same or similar information and, possibly, merging of the task execution contexts.

Figure 3.16 Tasks mapped to views (implemented as windows and dialog boxes)

It is also possible to use the annotated task model to record how task execution contexts are created by users prior to use. Arrows are used to show how new contexts are created. This information is later recorded more formally in the dynamic view model (see Section 3.5.3.2).

The next step is to depict the boxes on the task analysis in a separate diagram. This is done in Figure 3.17. Moded dialog boxes are drawn with a heavy outline. One of these—the conversation invitation dialog box—is worth discussing here. Its modedness is a pragmatic choice that anticipates the prevention of unnecessary interaction when disconnecting at a later time, should an unmoded version of one of these views still be open. This is a design choice that needs to be evaluated with users; as an alternative, users might prefer unmoded invitations that can be left open so that a conversation can be joined later.

Figure 3.17 Potential windows and dialog boxes for task-execution contexts

The consideration of exceptional cases is important for user interface coverage in the developing design. Thoughts about the exceptional case of all invitees refusing the invitation to a conversation prompted the invention of an extra dialog box (see Figure 3.18).

Figure 3.18 Extra dialog box

This pointed to a failure in the scenario generation process and the need for subsequent reconciliation of the new dialogue with the scenarios, task models, and task descriptions.

Users of the method may wish to experiment with rendering views as shown in Figure 3.19.

Figure 3.19 Alternative view rendition

3.5.3.2 View Behavior and the Dynamic View Model

Designers of systems need to be able to plan, communicate, and improve designs for the creation, deletion, lifetimes, and multiplicity of top-level views. A dynamic view model models this top-level view behavior.

Dynamic view modeling can be performed in a style that shows the particular paths of use and how each window, dialog box, or palette is created from another in a way similar to that shown in Figure 3.11. Constantine and Lockwood [1999] are two of the proponents of this kind of style. In their version, top-level views are represented by unadorned boxes. This kind of representation represents the description domain relatively directly, and it is easily understood by a wide variety of stakeholders. As such, it is noteworthy and significant.

However, there may be difficulties in using this form of representation to model all possible paths of view usage. Idiom solved this problem with, in retrospect, an overly complex form of parallel state machine called a view transition machine. Of primary interest to designers who like rigorous notations, a view transition machine (a) models the dynamic aspects of the existence of top level views and (b) specifies, at an abstract level, events leading to top-level view creation and destruction using threads akin to threads in a UML state machine. Details of this approach are omitted from this chapter, but the basic style of rendition, devoid of many annotations, appears in Figure 3.20.

Figure 3.20 A simplified view transition diagram

3.5.3.3 View Structure and Static View Models

The static view model augments the core model with views and their contents based on previously formulated design information. Figure 3.21 shows the most abstract form of the chat example's view structure. The figure contains the core model, three views, and the user, who interacts with the core via the views. dialog boxes have not been shown, but they could be attached to the model via the views, thereby indicating the place from which they are "created."

Figure 3.21 Abstract view structure

The abstract form shown in Figure 3.21 is useful to record and convey an overall picture of the multiplicity of different types of top-level views. In the figure, we can easily see that there is a single system control view but an unlimited (at this stage, without machine constraints) number of Chat or Start Conversation views.

The composition of the top-level views is recorded by adding more detail to the model, as depicted in Figure 3.22. dialog boxes are again omitted; at this level of detail, they would be attached to the model via the source view and via any core or view types that act as information sources for the dialog box.

Figure 3.22 Core model, static view model, and user

The types which appear in static view models represent top-level views or view objects. They may be populated with operations that correspond to user actions. Thus the type Start Conversation View in Figure 3.21 could contain operations like:

• selectParticipant()

• chooseParticipant()

• deselectParticipant()

• inviteAllParticipants()

• cancel()

In Figures 3.21 and 3.22 these operations could only appear in the Start Conversation View. However, placing an operation in a view object that constitutes part of a top-level view removes the necessity to list the operation in the top-level view type. Thus if the selection panel in Figure 3.11 had been modeled in Figure 3.22 with a Selection Panel type that was a constituent part of the Start Conversation View and that was associated with the User View type via associations labeled with the roles invited and not invited, then the first three of the above operations could be positioned in the Selection Panel with optional replication in Start Conversation View.

Sometimes, in making the transition between an abstract form like that of Figure 3.21 and a more detailed form as shown in Figure 3.22, the cardinalities become less than clearly expressive. This occurs for cardinalities on associations between core objects and view objects for those top-level views that may optionally exist once or more than once at a given moment at run time. In such a case it may be more useful to express the view structure as it is (partially) developed in Figure 3.23. There the larger boxes represent the core model type and a Start Conversation top-level view type, and the association between these boxes represents the optional "instantiation" of the top level view one or more times. The cardinalities between User and User View are now more reflective of the desired situation, that each of the users in the local user's address book (each of the set of instances of User in the core) is represented once in the Start Conversation View.

Figure 3.23 Partial refinement of a detailed static view structure

In terms of an abstract-to-concrete continuum, static view models provide intermediate-level descriptions; they articulate aspects of choices that specify concrete user interface design features. Imagine two different ways of initiating a conversation: (a) by using a dialog box (as illustrated in Figure 3.11) and (b) by dragging user photographs from an address book view to a chat view using drag-and-drop interaction techniques. These different forms of interaction would be articulated differently in the view model; in scheme (b), the Start Conversation view would be omitted from the view structure shown in Figure 3.21, and the user would interact by using a view displaying photographs of other users and a conversation view. Corresponding changes would be made at the more detailed level of Figure 3.22.

The construction of the view model can easily lead to re-evaluation of existing aspects of concrete design decisions. The positioning of invitee status feedback (accepted, refused, and so on) in the chat example was revised, in part, as a result of the informing role played by a static view model level consideration of the chat system.

3.5.3.4 More Complex View Models

Idiom incorporates a general model of interactive system structure that can cater for transactions¹¹ on the core model to enable query and interactive updates of the model [Wills 1988, van Harmelen 1994]. Transactions can be modeled with views and view objects.

The motivation for transactions in Idiom is derived from the observation that humans are limited in the things that they can do at one time and that under certain circumstances (for example, in editing an engineering drawing) modifications of core objects via the view model must be done one step at a time. This may perhaps leave the user's data in a temporarily inconsistent state. To avoid an inconsistent state, the changes are performed using a transaction that is a less stringently constrained copy of (part of) the core. When the transaction is again consistent in respect to the core's more stringent constraints, a change can be made to the core in a single transaction completion operation, and the transaction can be discarded. Thus, a transaction is a model-level representation of interactive capability.

There are three kinds of transactions, which are classified according to how they work:

• A creation transaction first gathers all the information needed to perform a change in the core and then invokes an update operation on the core. This is a kind of change transaction; it changes the core. If the chat system gathered a transcript of a conversation and, when the conversation was finished, saved that copy to an archive maintained by the core, the system would implement a creation transaction.

• A copy transaction is a less constrained "copy" of (part of) the core in which intermediate inconsistent core states are allowed and supported. To change the core after one or more changes have been made to the copy, a consistency check is run to see if the transaction is consistent with regard to core constraints, and, if so, an update operation is invoked on the core. This is a kind of change transaction.

• A read transaction simply presents copy information drawn from the core model without the possibility of changing that information.

Transactions may contain a range of objects that have nothing to do with the domain of interest per se. Thus, a typical change transaction might contain objects representing whatever the transaction is being used to edit, as well as objects required for interaction, such as cursor position, selection markers, and cut-copy-paste buffers. (See [van Harmelen 1994].) If this detail is recorded in a static view model, the purpose is to articulate interactive behavior, not to specify implementation mechanisms.

A top-level view or a view object may also be a view in the Model-View-Controller (MVC) [Krasner and Pope 1988] sense, or, less confusing terminologically, an observer in the Observer pattern [Gamma et al. 1995] sense. Such an observer reflects the state of a subject that the observer watches; the observer is dynamically notified of changes in the subject and updates itself accordingly. The subject might be changed by one of its observers as a consequence of user interaction with that observer, or the subject may be changed as the result of a system event. The pattern is useful in the specification of interfaces which dynamically display changing system data (control systems, for example), and for the specification of interfaces where the same user-manipulated data is displayed potentially multiple times, possibly in different forms, and needs to be kept up to date each time it is displayed.