Int. J. Human – Computer Studies (1997) 46 , 151 – 177
Abstract models for HCI ANDREW M. DEARDEN
AND
MICHAEL D. HARRISON
Department of Computer Science , Uniy ersity of York , York , YO1 5DD , UK. email: andyd / mdhêminster.cs.york.ac.uk (Receiy ed 28 August 1996 and accepted 29 September 1996) This paper investigates the use of formal mathematical models in the design of interactive systems and argues for the development of generic models that describe the behaviour of a class of interactive systems. In recent years a number of authors have suggested methods for modelling interactive systems using notations and frameworks drawn from software engineering mathematics. We argue that these models tend to be either: so abstract as to limit their ability to express important interaction concerns for specific systems, and limited in the degree to which they support the construction of software that conforms to the designer’s intention; or so specific to an individual system that they provide only limited re-use across development projects and are therefore likely to be too expensive to develop except in a few special applications such as safetycritical systems. We argue that it is possible to construct a generic model of a class of interactive systems at an intermediate level of abstraction. Such a model would offer wider reusability than detailed specifications of a single system, but greater expressiveness and support for software development than fully general abstract models. To support our argument we review a number of existing models in the literature and present a generic model of interactive case memories, a class of systems used in case-based reasoning. ÷ 1997 Academic Press Limited
1. Introduction This paper investigates the use of mathematical models in the design of interactive systems and considers how the level of abstraction at which such models are constructed affects their usefulness in the design of human – computer interaction (HCI). The paper discusses the roˆ le played by formal models in the development of interactive systems, and presents three important criteria which can be used to compare and contrast such models. The criteria are as follows. $ Operationality —the degree to which HCI design knowledge that is encapsulated by reference to a model, can be used to ensure that software constructed using the model, conforms to the designer’s intention. $ Expressiy eness —the ability of a model to support the expression of important interaction characteristics that apply to the software system. $ Re -usability —the degree to which a model, and the interaction characteristics encapsulated by reference to the model, can be re-used as a reference point for multiple software projects. The usefulness of a model for HCI design is dependent on the balance achieved between these three criteria. 151 1071-5819 / 97 / 010151 1 27$25.00 / 0 / hc960087
÷ 1997 Academic Press Limited
152
A. M. DEARDEN AND M. D. HARRISON
The majority of modelling approaches to HCI proposed to date can be characterized as attempting to model interactive systems at one of two levels of abstraction as follows. $ General mathematical approaches designed to support the expression of generally desirable properties of an interactive system such as predictability (Dix, 1991). $ Modelling approaches using software engineering notations to support the detailed specification of individual systems. Similarly Took (1990) distinguishes between diy ergent or cony ergent modelling approaches. This paper argues that the first of these approaches offers too little operationality, and limits expressiveness, whilst the second approach sacrifices re-usability to achieve expressiveness and operationality. Finally, the paper indicates that by modelling at an intermediate level of abstraction important advantages may be gained over both approaches. This new approach is to construct a generic model for a class of systems. This offers the advantages of the expressiveness and operationality of convergent specification models, without sacrificing the re-usability offered by general mathematical models. 1.1. STRUCTURE OF THIS PAPER
Section 2 discusses the relationship between modelling approaches, mathematical models and completed artifacts, and the roˆ le of mathematical models in the design process. The discussion is used to motivate the criteria of operationality, expressiveness and re-usability, by which such modelling approaches may be judged. Section 3 examines the use of general mathematical frameworks to encapsulate HCI design principles, and shows why they lack expressiveness and operationality. Section 4 examines attempts to encapsulate HCI knowledge within detailed specifications of individual systems, and shows that most such efforts offer limited re-usability. Section 5 demonstrates the possibility of using a generic model to encapsulate HCI knowledge related to a class of systems. Section 6 discusses how generic models could be used to support research into the design of interfaces for new software applications.
2. The roˆ le of models in HCI design This section considers how mathematical models can be used in design and develops some criteria against which such models may be judged. 2.1. THE NEED FOR MODELS
The majority of current practice in HCI design has been criticized for being reliant on craft knowledge (Long & Dowell, 1989). Craft knowledge is gained by experience, and must be interpreted by a skilled practitioner in order to be successfully applied. Long and Dowell (1989) argue that craft knowledge is not operational : ‘‘because [craft knowledge of HCI] is either implicit or informal, it cannot be directly
ABSTRACT MODELS FOR HCI
153
applied by those who are not associated with the generation of the heuristics or exposed to their use.’’ (p18).
In a large software project it is unlikely that all the software engineers will have the same level of (craft) knowledge of HCI. Therefore, these software engineers who do possess such knowledge require some means of communicating the implications of that knowledge in the context of a particular design. Notice that the requirement is to communicate the implications of the knowledge for each design, rather than the knowledge itself. It is unrealistic to expect every software engineer to become an expert in HCI, similarly we do not expect experts in HCI to obtain expertise in all other aspects of software engineering. One way in which such knowledge might be communicated is to encapsulate that knowledge within a formal model. Much work in software engineering has addressed the question of how a designer’s intention for a software system can be expressed using explicit and formal models, or specifications (Hayes, 1987; Woodcock & Loomes, 1988; Potter, Sinclair & Till, 1991; Morgan, 1994). Formal specifications can encapsulate design decisions in a way that can be applied by other programmers, i.e. specification makes the design knowledge operational. Building on the idea of formal specification of software systems, various researchers have proposed the encapsulation of knowledge about good HCI design using formal mathematical models (Harrison & Thimbleby, 1990; Abowd, 1991; Dix, 1991; Roast, 1993; Paterno’, 1995). This paper considers the different modelling approaches that have been advocated and criteria for evaluating their appropriateness for use within a software project. 2.2. OPTIONS, MODELS AND ARTIFACTS
The process of design can be characterized in terms of a search within an ‘‘Option Space’’ (Lane, 1990). An option space is a set of possible systems which could be generated as a result of a design process. Initially this set will be very large. Making a design decision at any point in the design process, reduces the option space, i.e. the set of possible systems that might be generated. A formal model initially identifies a part of the option space that is to be considered. A formal model also enables a designer to encapsulate design decisions, or interaction requirements, as mathematical constraints on the model. Each additional constraint reduces the set of points from the option space that are possible outputs from the design process. When the design process is complete one system is produced. A completed system is a single element of the option space. The relationship between constraints on a model and sets of artifacts is explored in Jacob (1991). From the point of view of HCI design, the purpose of a formal model is to allow the designer to indicate a set of points in the option space that have been identified as exhibiting desirable HCI characteristics, and to exclude points in the option space that have undesirable characteristics. Not all design processes result in the creation of a single artifact. In some instances the task of design is the development of a family of related products which share some common characteristics, but perhaps offer different subsets of possible features (MacLean, Young, Bellotti & Moran, 1991; Garlan & Notkin, 1991). For example in designing a family of telephone answering machines the length of the
154
A. M. DEARDEN AND M. D. HARRISON
answering message may vary, some of the family might offer a remote playback facility whilst others do not, some may timestamp incoming calls, etc. For such a design process, the output of the initial design is a subset of the initial option space, in which common, desirable characteristics are exhibited. 2.3. CRITERIA FOR MODELS IN HCI DESIGN
Throughout this paper, three criteria are used to evaluate different modelling approaches in terms of how well they might support HCI design. The criteria are directly applicable to individual models, and different models constructed using the same approach may vary with respect to the criteria. However, the paper argues that the criteria can be generalized to modelling approaches, because the approach used imposes limits on what can be achieved with respect to the criteria. (1) Operationality. Operationality is the degree to which HCI design knowledge that is encapsulated by reference to a model, can be used to ensure that software constructed using the model, conforms to the designer’s intention. Morgan (1994: chapter 1) relates formal specification models to the concept of a contract between a supplier and a customer. The specification sets out a contract between a software engineer who has designed a system and a programmer (or another software engineer) who is charged to deliver a system that meets the specification. A contract should be as unambiguous as possible, it should not be open to multiple, competing interpretations. Lack of ambiguity is equivalent to Long and Dowell’s (1989) concept of operationality, in that a specification should restrict the programmer to generating designs that satisfy the HCI design principles that the writer of the specification intends. (2) Expressiy eness . Expressiveness is the ability of a model to support the expression of important interaction characteristics that apply to the software system. A model that can be used to formalise a large set of principles relevant to a software system will be preferable to a model that supports expression of a subset of those principles. Value judgements may also be relevant to this criterion since some principles may be regarded as more important than others to capture during the design process. (3) Re -usability. Re-usability is the degree to which a model, and the interaction characteristics encapsulated by reference to the model, can be re-used as a reference point for multiple software projects. The construction of a formal mathematical model may require considerable time and effort. Therefore, a model that can be re-used for the development of a large number of systems, should be preferred over one that must be discarded after a single use. Other criteria are possible. One important issue is the amount of effort required on the part of software engineers in order to understand formal modelling notations, and to develop models using the notations and associated modelling approaches. This is an important research issue. Questions of the usability of formal methods, and whether the benefits that they can deliver justify the investment of time and energy required to learn them, can only be answered in the context of realistic industrial application of these methods. It is clearly beyond the scope of this paper
155
ABSTRACT MODELS FOR HCI
to consider such questions. The interested reader is referred to Rushby (1993), Craigen, Gerhart and Ralston (1993), Naftalin, Denvir & Bertran (1994).
3. Using properties in design This section considers approaches that make use of general mathematical models to encapsulate properties that might be desirable for a user interface. The approach can be related to the concept of Generative User Engineering Principles (GUEPs) as proposed by Thimbleby (Thimbleby, 1990). A GUEP is a general principle about user interface behaviour that has both a colloquial and a formal statement. The formal statement of the property is intended to operationalize the knowledge expressed in the colloquial statement. GUEPs are intended to form a bridge between users and interface designers. Users are expected to understand the colloquial statement of the principle but not necessarily the formal statement. Designers should understand the colloquial statement and be able to apply the formal statement in constructing and analysing designs. Such principles may be generative in the sense that they can be used to help a designer to generate design options. An approach that allows GUEPs to be stated can be used to constrain the option space of possible artifacts. The option space can be partitioned to include only those systems that satisfy the GUEP, and to exclude those systems that violate the GUEP. To illustrate the use of abstract models to express GUEPs the PiE model (Dix, 1991) will be used as an example. 3.1. THE PiE MODEL
The PiE model, expresses the behaviour of an interactive system in terms of four components as follows. $ A set of commands, C. $ A set of sequences of commands that can be input into the system, these sequences are named programs drawn from the set P. $ The set of effects, E , that are produced as outputs by the system. $ An interpretation function, i , that maps the input programs, P, to their effects, E. Figure 1 illustrates the PiE model. Using the PiE model the concept of a predictable system can be stated by requiring that: ;p , q , r : P 3 i ( p ) 5 i (q ) $ i ( pÊr ) 5 i (qÊr ) i.e. if any two sequences of inputs p and q give rise to the same effects, then any future continuation, r , that extends these input sequences will always give rise to equivalent effects. The PiE model can be extended to consider whether a user can predict the effects of their inputs to the system by observing the currently displayed information. The i E
P FIGURE 1. The PiE framework.
156
A. M. DEARDEN AND M. D. HARRISON
R
result i P
E display
D FIGURE 2. The RED-PiE model.
extended model is referred to as the RED-PiE model. Figure 2 shows this extended model. In the RED-PiE model the set of effects is mapped to two sets, a set of results, R , and a set of displays, D. The set of results is intended to model the state of the objects of interest in the outcome of a task, whilst the set of displays models the information available to the user at any point. Two mappings result and display map the set of effects E to the associated results and displays. In the case of a word processor the result r P R at any point would be the actual document that would result if the document were printed immediately, the display d P D would be the window on the document that was currently displayed to the user. Notice that the display d may include only a small part of the whole document represented by r , and may not include certain information, e.g. which type faces are to be used at different points in the document. Within the RED-PiE model it is possible to express the principle of observability, i.e. that the current state of the display should be sufficient to determine the current value of the result. This property is sometimes referred to by the acronym WYSIWYG (what you see is what you get). ;p , q : P 3 display (i ( p )) 5 display (i (q ) $ result (i ( p )) 5 result (i (q )) The principle requires that: if two input sequences, p and q , give rise to the same displays, this implies that the results generated by these sequences are also equivalent.* 3.2. OTHER ABSTRACT MATHEMATICAL MODELS
Sufrin and He (1990) use the Z notation to develop a model that is a general specification for any interactive process. By reference to the model, it is possible to discuss similar abstract properties to those represented in the PiE model. Roast (1993) extends work on the PiE model to include the concept of a template. Templates introduce abstractions over sets of displays, sets of results and sequences of inputs to a system. All templates are requried to correspond to some task relevant, or psychologically relevant information. Using the template model it is * A word of caution is appropriate here. The formal property of observability does not imply that the user can actually interpret the relation between displays and results, merely that such a relation exists and that it is a function.
ABSTRACT MODELS FOR HCI
157
possible to express the principle that a system be predictable with respect to particular subsets of the information displayed and a particular subset of the commands entered, or the principle that the information that the user extracts from the display should correctly reflect the relevant information in the results. Templates were initially introduced in Harrison, Roast and Wright (1989). Blandford, Harrison and Barnard (1995) offer a similarly general mathematical model to describe the joint behaviour of a user and system interacting together. The interaction framework allows the modelling of concepts such as how initiative is distributed between the system and the user, and whether a particular interaction sequence includes detours that are unnecessary in achieving a particular result. 3.3. RE-USABILITY OF GENERAL MATHEMATICAL MODELS
It is clear from our study of the PiE model, that these highly abstract models can be used to express properties that are relevant to the design of interfaces for a very wide class of systems. For instance, predictability and observability are relevant considerations for most if not all interactive systems. In presenting the PiE and RED-PiE models, Dix shows how they may be used to analyse artifacts such as word processors, graphical editors, and window managers. He also demonstrates that the models can be used to analyse detailed specifications (see Section 4) prior to an implementation being constructed. Clearly, models in this class can be highly re-usable. 3.4. EXPRESSIVENESS OF GENERAL MATHEMATICAL MODELS
Using general mathematical models many important properties have been expressed. However, as Dix (1991) points out: ‘‘Abstract models will, by their very nature, serve to specify only a subset of the properties of interest’’ (p82).
Properties that may be specific to an application cannot be expressed using general mathematical models at this level of abstraction. For instance, in designing the HCI for a database system, it may be useful to specify that certain tables or records should only be visible to particular users. The PiE framework does not serve to express this property because it makes no mention of records or tables. Similar comments can be applied to the template model, interaction framework or to Sufrin and He’s (1990) model, indeed to any model that is sufficiently abstract to encompass the design of all interactive systems. 3.5. ENSURING DESIRABLE PROPERTIES
Dix (1991: p. 9) characterizes the PiE model, and associated models, as an attempt to bridge the gap between a customer’s requirements of a system and a formal specification of that system. An important limitation of the PiE model is that the properties that can be described using the PiE are too strong to apply to whole systems. A word processor in which the result of a print operation was completely determined by what could be seen on the screen would not allow a user to produce any documents that were too large to fit onto a single screen. Dix solves this problem by considering a new level
158
A. M. DEARDEN AND M. D. HARRISON
of abstraction that corresponds to the view of the document that could be obtained by scrolling through, but without editing the document. This approach separates two sets of commands, editing commands and scrolling commands, and analyses properties with respect to each set separately. Dix clearly recognises that the PiE model should not be used indiscriminately: ‘‘The red-PIE model was always intended to be applied at many different levels of abstraction, and to various parts of the system’’ [p311]
The way the model is applied and the appropriate levels of abstraction at which it should be applied are matters for the individual designer to decide. ‘‘We have to trust to a large extent the designer’s discretion in choosing the appropriate abstractions, and applying the appropriate principles to them’’ [p156]
Thus HCI design knowledge, encapsulated by reference to the PiE and RED-PiE models, can assist a good designer in ensuring that the finished artifact exhibits desirable interaction properties. However, if the model is applied badly then the interface that results may exhibit desirable qualities at points that are not important to the user’s tasks and goals, and may fail to exhibit desirable properties at significant points in the interface. The application of the knowledge encapsulated by reference to the PiE model is dependent on the skill of the designer in selecting appropriate levels of abstraction at which to work, and the appropriate parts of the system to model. Thus, the application of the PiE model is dependent on the designer’s own store of (craft) knowledge about HCI. Therefore, the knowledge encapsulated by reference to the model is not operational. Similar comments may be made about the models presented by Sufrin and He (1990) and by Blandford et al. (1995). It may be argued that Roast’s (1993) requirement that templates must correspond to relevant psychological abstractions avoids dependence on the designer’s craft knowledge. Whilst it may be possible to discover such abstractions by empirical means following the construction of a prototype, many significant design decisions are taken prior to prototype construction. At these early stages of design, the designer must rely on craft knowledge to predict the relevant psychological abstractions that should guide the design.
3.6. SUMMARY
General mathematical models allow HCI knowledge to be encapsulated in a way that is highly re-usable, the models may be applied to any interactive system. Unfortunately, in order to interpret knowledge encapsulated by reference to these general models within the context of individual designs, craft knowledge is required. Thus, the knowledge is not encapsualted in a form that is operational. Also, models at this level of abstraction may be incapable of expressing properties that are specific to a particular system, because they do not include components that refer to specific parts of the system.
ABSTRACT MODELS FOR HCI
159
4. Specifying interactive systems The alternative modelling approach that has been advocated for HCI design, is the construction of formal specifications of the human – computer interface for individual systems. Typically, advocates of this approach have sought to adapt modelling techniques used in other branches of software engineering, by enriching them with features designed to support the specific problems encountered in modelling interactive systems. For instance, some notations provide techniques to represent and reason about what parts of a system’s state will be perceivable by a user, or indicate which operations are initiated by the user and which by the system. Examples of work that follows this type of approach can be found in Abowd (1991), Cowan and Lucena (1995), Duke and Harrison (1993), Faconti and Paterno’ (1993), Palanque and Bastide (1995), and Torres and Clares (1995). A related area of work is the development of user interface development environments such as UIDE (Foley & Sukaviriya, 1995), BOSS (Schreiber, 1995), HUMANOID (Szekely, Luo & Neches, 1993). One way to regard these systems is that they allow a designer to construct an abstract model of an interface, that is interpreted by the design environment to generate a prototype system. 4.1. INTERACTOR NOTATION
A model of a multi-media communications system presented by Duke and Harrison (1994) is considered for further analysis. The system is called AVconnections. Duke and Harrison’s approach treats AVconnections as a collection of components called interactors. Each interactor is modelled in terms of its state, behaviour and presentation. The notation used is based on the Z notation* (Spivey, 1992). Aside The requirement to model state, behaviour and presentation is a common theme in modelling interactive systems. In the interactor notation used by Duke and Harrison (1994), state is modelled using the Z notation, presentation is modelled by the introduction of special symbols, and behaviour is modelled using temporal logic formulae. In the PiE model, the function i models behaviour, the state is hidden by referring to the complete history of inputs to the system in the set P , and presentation is reflected in the RED-PiE model by the set of displays D. AVconnections provides audio-visual communication between a number of workstations. Users of AVconnections can initiate connections to other users, glance to see whether another user is busy or absent from their workstation, access a video signal from a remote video player, or access the signal from a camera located in a public place. Each user’s workstation, camera or video player is referred to as a node. The specification begins by asserting given types to represent connections, messages and nodes. [conn , mesg , node ] * A brief summary of the main symbols used in Z is presented in Appendix.
160
A. M. DEARDEN AND M. D. HARRISON
Two mappings relating nodes to connections define the source and the destination of any connection. src , dst : conn 5 node Messages from the system are intended to make users aware of connections, or to explain why a connection may not be possible, rather than representing the content of the communication from another user. The relationship between messages and connections is represented by the mapping about. – about – : mesg ↔ conn The global state of the AVconnections system is represented by the Z schema AVnodes. In a Z schema the components of the state are represented by type declarations in the top section of the schema box, and constraints on those components are stated in the lower section. The state of AVnodes consists of a finite set of nodes, a function that indicates the set of connections that each node may be able to initiate, and a function that indicates the set of messages that each node has received. The constraints on this schema indicate that: $ the initiate and messages functions must be defined for all the nodes in the system; $ if a node initiates a connection, then the node must be the source of that connection; $ the messages sent to a node should be about connections that involve that node. AVnodes ay nodes : F node uu initiate : node 5 F conn uu messages : node 5 F mesg dom initiate 5 ay nodes 5 dom messages ∧ (;n : node ; c : conn ; m : mess 3 m P messages (n ) $ (src (c ) 5 n ï c P initiate (n )) ∧ (m about c é src (c ) 5 n ∨ dst (c ) 5 n )) In order to specify the behaviour of each node, Duke and Harrison model each node as an interactor. In the notation, an interactor is represented by a structure similar to a Z schema, but divided into three rather than two sections. The first section presents the state of the interactor (in the same way as the first section of a Z schema); the second section presents the set of actions that the interactor can engage in, and indicates whether these will be initiated by the interactor, or whether they are expected to be initiated by some external agent (possibly another interactor); the final part expresses constraints on the behaviour of the interactor (similar to the lower part of a Z schema) expressed using a temporal logic notation. The interactor AVcore represents the abstract state and behaviour of one node. The state of the AVcore interactor consists of the following. $ An identity for the node. $ A set of sets of connections, representing all the combinations of connections that could be possible concurrently.
ABSTRACT MODELS FOR HCI
161
$ A set current that represents the currently active connections. $ A relation failures that relates connections to sets of connections. The middle section of the interactor states that the interactor can engage in the operations, request, permit, deny, link or break. The symbol , indicates that the interactor does not initiate any of these operations. Another symbol n can be used to specify operations that the interactor may initiate, these operations may involve other interactors. The bottom part of the interactor specifies some constraints on the behaviour of the interactor. The constraints are either constraints on the initial state of the system or they are linear temporal logic formulae. The symbol h can be read as ‘‘it is always the case that’’. The constraints are that: $ the identity of the interactor never changes; $ if it is possible to establish a set of connections concurrently, then any subset of that set can also be established concurrently; $ the failures relation relates a connection, c , to a set of connections, cs , precisely when it is not possible to establish c if cs is the current connection set. AVcore identity : node possible : FF conn current : F conn failures : conn ↔ F conn , request , permit , deny , link , break : conn hidentity 5 identity 9 ∧ h(;cs : possible $ F cs ‘ possible ) ∧ h( failures 5 hc : conn ; cs : possible u (;cs 9 : possible $ cs ‘ cs 9 é c ¸ cs 9) $ (c , cs )j) Interactors support an operation of inclusion with similar semantics to those of Z schema inclusion. Thus, to describe how messages are handled at individual nodes, Duke and Harrison (1994) describe a new interactor Messages. Messages xAVcore ê audwarn : F mesg ,) y ismesg : F mesg messages : F mesg : : messages 5 [ ∧ haudwarn < y ismesg ‘ messages ∧ : : In this new interactor the symbol ê indicates that audwarn will be audible to the
162
A. M. DEARDEN AND M. D. HARRISON
user. The symbol ,) indicates that y ismesg will be visible to the user. The constraints on behaviour are that the set of messages is initially empty, and that all the messages in audwarn or y ismesg are also in the set messages. 4.2. OPERATIONALITY OF SPECIFICATION MODELS
By integrating information that is relevant to interaction into the detailed specification of a system, approaches such as that presented by Duke and Harrison (1994) allow desirable interaction properties to be expressed in formal statements that make direct reference to elements of the specification model. The software engineer developing the specification model is then obliged to prove that the model meets the requirements stated. If the model meets the requirements, and a suitable development method is followed, then the final system should also meet the stated requirements. Thus, this approach provides a high degree of operationality. 4.3. EXPRESSIVENESS OF SPECIFICATION MODELS
Duke and Harrison’s (1994) specification of AVconnections permits a number of important interaction properties relevant to the system, to be given formal mathematical expression. Two examples are shown below. (1) any connection that will not fail to be made can be initiated by the user. ;c : conn $ (c , current ) ¸ failures é c P initiate (src (c )) If this property were not satisfied then the user may not be able to initiate a connection by interacting with their workstation, although the underlying system could support the connection. (2) For any connection made to a node in the state immediately preceding the connection being made (represented by @ ) it will be the case that at some time – ) a message will have been received at the destination about the in the past (e connection. ;c : conn $ h(c P current ) é @e – ('m : messages (dst (c )) $ about c ) This property deals with a concern for privacy, that users should be informed whenever someone else is able to observe them. These properties are directly related to user concerns about the system. It is possible to express these properties in Duke and Harrison’s (1994) model precisely because the model refers to components of the systems such as the connections, nodes, messages and the operations that can be performed on the system. Thus, models at this level of abstraction provide much greater expressiveness than the highly abstract models studied in Section 3. 4.4. RE-USABILITY OF SPECIFICATION MODELS
The major limitation of detailed specification models is the degree of re-use that they support. The specification developed in Duke and Harrison (1994) encapsulates many design decisions about the functionality of AVconnections. Some of these decisions are explicitly stated as HCI requirements, such as the privacy requirement
ABSTRACT MODELS FOR HCI
163
expressed above; some of these decisions are based on HCI design knowledge and are implicit in elements of the model, and some design decisions are implicit in the model and based on other factors. The interweaving of these design decisions limits the re-usability of the encapsulated HCI knowledge. For instance, the use of the source and destination functions throughout the specification limits the design to systems in which all connections are between pairs of nodes. Thus, the model could not be used (without major revision) for the design of a system that permitted the user to request multiple connections of the same type in order to generate a conference call. Similarly, the operation that allows the user to open a connection is modelled by a function from sets of buttons to connections. This choice of a button as the control mechanism means that the model cannot be applied to design a telephone system where connections are requested by a sequence of digits. One way of overcoming this limitation may be to re-use such models via adaptation. However, adapting the model to deal with a new system may result in inappropriate design decisions being carried over to the new application; and may change the elements within the model that are referenced by the explicit statements of interaction requirements. When interaction requirements are affected, it will be necessary to ensure that they are re-stated in a suitable form for the new application. This will only be possible by applying HCI design knowledge. Thus, the HCI design knowledge, encapsulated implicitly in the form of the original model, and stated explicitly by statements referencing the model, will not be directly re-usable within the new application. Thus, detailed specification models can encapsulate much HCI design knowledge, but only in the context of the development of one system. The above comments about specification models do not necessarily mean that the efforts to develop specialized modelling languages to support the specification of interactive systems is a wasted effort. These languages can support many different levels of abstraction, and so may be used in the context of the generic models suggested in the next section. 4.5. SUMMARY
Specification models such as the example above, are more expressive than the highly abstract general mathematical models discussed in Section 3 because they can incorporate elements that denote objects in the domain of interest, e.g. connections and nodes for the AVconnections system. Also, because they leave less freedom for interpretation by the programmer, they may be more operational in the sense of Long and Dowell (1989). However, detailed specifiation models may encapsulate additional design decisions that are not based on HCI design knowledge, but may be inappropriate in the new application. Detailed specification models, therefore, provide only limited re-use.
5. A generic model for a class of interactive systems The previous two sections have shown how modelling at different levels of abstraction involves a trade-off between re-usability, expressiveness and operationality. Models that attempt to cover the set of all interactive systems, or very broad classes of interactive systems, are liable to limit their expressiveness and may
164
A. M. DEARDEN AND M. D. HARRISON
sacrifice operationality. On the other hand, specification models of individual systems may have too small a range to support wide re-use. This, in turn, may make the cost of developing such models, within a single software project, prohibitive. This section shows that a third level of abstraction can be found at which a generic model for a class of interactive systems may be constructed. Examples of this class of model applied to interactive systems can be found in: Kotze´ (1993) and Dearden (1995a ). Other generic models of classes of software system have been reported by Garlan and Delisle (1990), Garlan and Notkin (1991) and Goodwin (1995), but these authors were not concerned with interaction properties. The example selected for analysis is the model developed in Dearden (1995a ) of a class of systems called interactive case memories (ICMs). The application of this modelling approach to ICMs is interesting because ICMs are a relatively new class of systems where there is a lack of agreed terminology, and where only a small part of the possible design space has been explored to date. By constructing a generic model of ICMs, insight can be gained into the issues and opportunities that may arise in designing new ICMs. First, an informal introduction to ICMs is appropriate. 5.1. INTERACTIVE CASE MEMORIES
The development of interactive case memories can be traced back to research in case-based reasoning. Case-based reasoning (CBR) is the process of solving new problems by reference to previous examples (Kolodner, 1993). CBR is generally characterized as involving the following steps. (1) Analyse the current problem to identify important indexing features. (2) Search a store of previous cases to find cases which are similar in some way to the current problem. (3) Modify the retrieved solution (or solutions) to solve the new problem. An essential element of any CBR system is a mechanism for storing and retrieving previous cases. Such a mechanism is called a case memory system. A case memory system does not modify retrieved cases, i.e. it only performs steps 1 and 2 above. Many case memory systems assume that all the information about the current problem is available before step 1 above is conducted. In some applications of CBR this may not be true, i.e. it may be necessary to collect the information about the current problem incrementally. This problem may be solved by using an ICM. An ICM is a system which interacts with a human user to gather information about a problem, interpret that information and search a store of previous cases to find cases that may be useful in solving the new problem. Two examples of ICMs illustrating the range of applications and the range of implementations that exist are CBR Express (Klahr & Vrooman, 1991), and PATDEX (Richter & Wess, 1991; Wess, 1993). CBR Express is an ICM shell for use in help desk applications. Each case in CBR Express is described by a set of question – answer pairs, a piece of free text, and a description of a solution that may include text, graphics and animations. To use CBR Express the operator first types in a piece of free text. This text is matched against some free text in each of the stored cases, resulting in a numeric score between zero and 100 and the best scoring five cases are selected. These five cases
ABSTRACT MODELS FOR HCI
165
generate a set of candidate questions from which the operator can select one to answer. After answering the question the store of cases is searched again and matched against the answer and the free text, and the highest scoring five cases retrieved. This process iterates until one case scores over 95 points. The scoring process is based on a weighted function associated with each case. PATDEX is an ICM used in technical diagnosis of faults in a robot arm. Each case in PATDEX consists of a situation description, Sit , which is recorded as a set of attribute – value pairs, and a diagnostic class f . Diagnostic classes may indicate a solution or a test that can be carried out to further refine the solution. Cases are stored in a ‘‘situation graph’’ which includes a directed link between two cases c1 5 (Sit 1 , f 1) and c 2 5 (Sit 2 , f 2) if and only if Sit 2 is a superset of Sit 1 containing exactly one additional attribute – value pair, and there is a diagnostic test that will determine the attribute – value. The user of PATDEX enters some information about the current problem and PATDEX scores all the cases. If some case scores above a certain threshold, then the diagnosis or test associated with that case is used. If the diagnostic class of the highest scoring case is a test then that test will be used. Otherwise, PATDEX selects the test associated with the link with the highest probability in the set of links starting from the currently highest scoring case. 5.2. A GENERIC MODEL FOR AN ICM
The development of the generic model for ICMs begins by applying craft knowledge about ICMs to identify interaction characteristics that may be important for designers to consider, and common features that are included in the state of all ICMs.* The characteristics of ICMs and issues related to their design identified by Dearden (1995a ) included the following. $ Different ways in which similarity between the new case and previous cases is assessed, and different types of ordering that could be constructed. $ The degree to which a user can direct problem solving attention during interaction, rather than the system directing the search process. $ The ability to distinguish monotonic and non-monotonic reasoning processes, i.e. the degree to which the user can change or retract statements about the current case. In order to describe these characteristics a basic state model needs to refer to: the representation of the set of cases in the case base; the current representation, within the system, of the problem being solved (this representation will change as a problem solving session progresses); the way in which similarity is assessed; and the way that it is reported to the user of the ICM. Figure 3 illustrates the main elements of the state of an ICM. A Z schema can be constructed to represent the internal state of a generic ICM. In the schema ICMstates , below, Cb represents the set of cases in the case base; currP is the current internal representation of the problem to be solved, i.e. a value * Whether it is appropriate to begin modelling some classes of system by identifying common behaviours rather than common state elements, is an open question. However, all the examples of generic specifications cited in this paper begin from a state-based perspective.
166
A. M. DEARDEN AND M. D. HARRISON
User
Ordering over cases currCs
Problem Statement currP
Similarity function Enquire
Case base Cb
FIGURE 3. The main elements of the state of an interactive case memory.
drawn from the set Problem – Statements ; currCs is the ordering of cases that is currently being presented to the user; and Enquire is a function that describes how cases are to be retrieved from the case base to form an ordering for presentation to the user. The constraints on the schema state that the current ordering presented to the user is the output of the function Enquire , also that the output of the function Enquire will be a pre-order over the set of cases in the case base. ICMstates Enquire : P Cases 3 Problem – Statements T (Cases ↔ Cases ) currP : Problem – Statements currCs : Cases ↔ Cases Cb : P Cases currCs 5 Enquire (Cb , currP ) ∧ ;C : P Cases ; P : Problem – Statements $ Enquire (C , P ) P pre – orders (C ) Note that the set Problem – Statements includes, but does not restrict itself to, representations of the current problem based on attribute – value pairs such as those used by PATDEX and CBR Express. Similarly, the choice of pre-orders as the general form of the output from Enquire includes the rank orderings of cases such as used by CBR Express, selection of a single case, as in PATDEX, or general dominance orderings such as those that are typical in multi-criteria decision making (Vincke, 1992), and have been used in (non-interactive) case memory systems (Ashley & Rissland, 1988). The schema ICMstates represents the internal state of the ICM. The display presented to the user of the ICM represents certain projections from that state. In particular, if the case base is large, it may not be possible to display the complete
ABSTRACT MODELS FOR HCI
167
ordering of cases that has been formed. A number of projection functions can be defined which extract those parts of the case ordering that are displayed.* shown : ICMstates 5 P Cases top : ICMstates 5 P Cases focus : ICMstate 5 P Cases ;(Cb , Q , currP , currCs ) : ICMstate $ shown (Cb , Q , currP , CurrCs ) ‘ dom(currCs ) < ran(currCs ) ∧ top (Cb , Q , currP , currCs ) 5 hc 1 : dom(currCs ) < ran(currC ) 3 (;c2 : Cases $ (c 2 , c 1) P currCs é (c 1 , c 2) P currCs )j ∧ focus (Cb , Q , currP , currCs ) ‘ top (Cb , Q , currP , currCs ) > shown (Cb , Q , currP , currCs ) The function shown represents the subset of the cases that are actually displayed to the user. top represents the set of all cases in the case ordering that have no cases that are strictly ‘‘higher’’ in the ordering. The set focus represents the current focus of the system’s problem solving. The constraint requires that the focus must be a set of cases that are currently shown, and that are currently at the top of the case ordering. In CBR Express these three sets top , shown and focus would all correspond to the top scoring set of five cases. For PATDEX all three sets would correspond to the single top scoring case. However, in an ICM that generates a partial order over cases the sets top , shown and focus may be distinct. The development of the system over time is modelled using Sufrin and He’s (1990) abstract mathematical model for interactive systems and refining this general model to the specific case of ICMs. This approach models: the single step transitions ˆ , which takes as input an event and an that the ICM can engage in by a function b ICMstate and returns a new ICMstate; an initial state for the ICM; and a set Trace that describes the set of all legal sequences of events that the ICM can engage in, this set is constrained to be prefix closed. A simplified version of the model from Dearden (1995a ) is shown by the schema ICM process. ICMProcess i : ICMstate bˆ : E T (ICMState T ICMstate ) Trace : P seq E k l P Trace ∧ ;t1 , t 2 : seq E $ t1Ê t2 P Trace é t1 P Trace
bˆ can be generalized to a function b that takes a sequence of events and maps an input ICMstate to a new state that would be reached after the sequence has been applied. b : seq E 5 (ICMstate T ICMstate ) ;s : seq E ; e : E ; I : ICMstate $ ˆ e ((b s )I ) ∧ (b (e )Ê s )I 5 b (b k l)I 5 I * The recognition that these particular elements are significant, is again reliant on the craft knowledge of the modeller.
168
A. M. DEARDEN AND M. D. HARRISON
Aside In the ICM model, Z is used to express state, presentation and behaviour. ICMstates represents the state. The presentation can be encapsulated by reference to projections such as shown and focus. ICMprocess models behaviour. The choice of method for modelling behaviour affects the set of properties that can be expressed (Dearden & Harrison, 1995). However, this is independent of the effect of the level of abstraction on expressiveness and operationality. 5.3. RE-USABILITY OF THE GENERIC ICM ODEL
To date only a small number of ICMs have been described in published literature. Examples include: CBR Express (Klahr & Vrooman, 1991); the CARS ICM (Dearden, 1995b ) , which is intended to support a customer in choosing a car to purchase; PATDEX (Richter & Wess, 1991; Wess, 1993); and CASSYS (Manago & Conruyt, 1992), an ICM shell based around a decision tree learning algorithm. All of these examples can be described as refinements of the generic model, although they have been applied in different knowledge domains, and there are significant differences in their similarity functions and interactive behaviours. Additionally, Dearden (1995a ) shows that the generic model of a similarity function, as a function from sets of cases and problem statements to orderings over cases, can be applied to a very wide range of (interactive and non-interactive) case memories. This suggests that the model could be re-used widely by the developers of new case memories and ICMs. 5.4. EXPRESSIVENESS OF THE GENERIC ICM MODEL
A number of interaction properties that we expect to be important to the developers of new ICMs can be expressed by reference to the model. Three examples are given below. 5.4 .1 . Specifying a requirement to include a particular operation One concern for ICM designers might be that the user be permitted to change the focus of the system’s attention at any stage in an interaction. This can be required by defining an operation at the level of the generic model. change – focus nICMstate cs ? : P Cases focus (currCs 9) 5 cs ? ∧ Cb 9 5 Cb ∧ Enquire 9 5 Enquire This operation takes as input a set of cases, identified by the user, that will form the focus for the ICMstate. Using the generic model it is possible to show that the ease of implementation of this operation is dependent on the form of the function Enquire. The generic nature of the ICM model makes it possible to investigate the types of function that are
ABSTRACT MODELS FOR HCI
169
most suitable for the implementation of this operation. Dearden (1995a ) offers some suggestions of functions for which this operation is relatively easy to implement, and others for which it is not possible to implement. Thus, the generic model can be used to support researchers investigating the properties of ICMs. 5.4 .2 . Expressing a reachability property Having directed the focus of the ICM’s attention to a particular case or set of cases it may be useful to express a requirement that for any case that is currently shown to the user, there is some sequence of inputs that the user can make to the system that will result in that case being brought to the top of the case ordering. A possible statement of this requirement is that; ;t : Trace ; c : Cases u c P shown (b (t )(u )) $ ('comms : seq command $ (;t1 : seq E u t1pcommand 5 comms ∧ t t1 P Trace $ c P top (b (t Êt1(i )) ∧ (;t2 : seq E u t2pcommand Ô comms ∧ t t2 P Trace $ ('t3 : seq E $ (t 2Êt 1)pcommand 5 comms ∧ t Êt 2Êt 3 P Trace ))) Here a Ô b denotes that sequence a is a prefix of b. The function p restricts a sequence to the elements of the sequence that are in a given set. Thus t pcommands is the sequence of commands that is embedded within t. The requirement states that: for any t in Trace that leads to a state in which the case c is shown to the user, there is some sequence of commands comms that can be given by the user; such that for any sequence of events t 1 , where t 1 restricted to the set commands input by the user is equal to comms , the result of extending t by t 1 is that c is brought to the top of the ordering. A secondary constraint requires that for any sequence of events, t2 , in the system where the user has performed some prefix of comms there is a continuation of the system, t3 , that permits the sequence comms to be performed. This second constraint eliminates the possibility that the system might deadlock before the user had input the required sequence. Notice that this property is stated without reference to any specific details about the operations that the ICM supports, or to particular implementation details of an ICM. The concept of reachability in this form can, therefore, be used to analyse any ICM design, given that the sets shown and top can be identified. 5.4 .3 . Expressing a general interaction property Some interaction properties may not be expressible at the very highest level of abstraction, and may require that the option space modelled is narrowed. One such example concerns the idea of flexibility of interaction. A number of investigations into the design of interfaces to other types of knowledge based systems have highlighted the importance of allowing the user the flexibility to investigate their own hypotheses (Roth, Bennett & Woods, 1988; Keravnou & Washbrook, 1989). For an ICM, such flexibility may depend on the way in which the value of currP can be altered in each interaction step. By defining a set, Ready , to represent the set of all values of the Problem – Sta -
170
A. M. DEARDEN AND M. D. HARRISON
tement that can be reached by a single interaction cycle requirements relating to flexibility can be given an operational expression within the model. Ready : ICMstates 5 P Problem – Statements ;I : ICMstates ; h : seq Ey ents 3 h P Trace ∧ b (h , i ) 5 I $ Ready (I ) 5 h p 5 Problem – Statements 3 ('e : Ey ents ; I 9 : ICMstates $ bˆ (e )(I ) 5 I 9 ∧ h ke l P Trace ∧ I 9.Cb 5 I.Cb ∧ I 9.currP 5 p )j If the model is restricted slightly by requiring that the set of Problem – Statements is composed of sets or sequences of question – answer pairs, it is then possible to use the Ready set to specify constraints on the design that require this set to include certain possibilities. For instance, it is possible to give expression to requirements such as: ‘‘It will always be possible for the user to retract any single question – answer pair that is part of the current problem description’’;
or ‘‘The user will always be able to input any observation consisting of a question – answer pair, and will not be restricted to those questions the system may be presenting at the time’’.
This can be by imposing constraints on the set Ready. Notice that the trade-off between the re-usability of the generic model and its expressiveness has had to be made explicitly here. In order to discuss these flexibility properties the model needs to be restricted to ICMs with a particular type of representation of Problem – Statements. 5.5. ENSURING DESIRABLE PROPERTIES
To demonstrate the operationality of the generic model, Dearden (1995a ,b ) reports on the design of the Cars ICM. The Cars ICM is intended to support a user who is buying a car in selecting one that most closely meets his or her requirements. Each car is described in terms of a number of known attributes and features, such as the engine size, maximum speed, fuel consumption rate, whether the car has a sunroof, the price of the car, etc. Interacting with the ICM the user can input a number of constraints, e.g. a maximum price, specifically required features, a minimum or maximum engine size. The ICM then attempts to find cars that match a maximal subset of the specified requirements. Up to three such subsets are presented to the user, corresponding to the cars matching maximal subsets that are close to the top of the user’s list of requirements. Figure 4 shows the ICM after a user has presented a list of five requirements: that the engine size is less than 1600 cm3, that the price is less than £12000, that the fuel type is diesel, that the fuel consumption is greater than 60 miles per gallon, and that the car can accelerate from 0 to 60 miles per hour in less than 12 s. The requirements are presented in the centre left of the display. The subsets selected are shown at the bottom of the display. In this case, no cars meet all the requirements, but three sets of cars are presented: the Fiat Uno 60D and Citroen ZX 1.9D meet all the requirements except for the acceleration; the Ford Escort 1.8TD meets all the
171
ABSTRACT MODELS FOR HCI
FIGURE 4. Searching in the cars ICM : 2.
requirements except for the fuel consumption; and the Fiat Tempra meets all the requirements except for the price. Various operations are available to the user of the ICM, including adding more requirements, removing requirements, moving individual requirements to a new point in the ordering, selecting a car to inspect its specification and to enter constraints corresponding closely to the car and changing the order of requirements to make the set of 2nd best or 3rd best cars become the ‘‘Best matched’’. To analyse the design of the cars ICM in terms of the model it is necessary to map each part of the ICM to elements of the model. Dearden (1995a ) suggests the mappings shown in Table 1.* TABLE 1 Mapping the cars ICM onto the generic ICM model Cars ICM
Generic ICM model
Set of cars List of users priorities Set of all cars displayed at bottom of screen Set ‘‘best matched’’ bottom centre of screen Set ‘‘best matched’’ bottom centre of screen ;x ,y : Cb $ x $ y ï (x P BestMatched ∨ (x P 2ndBest ∧ y ¸ BestMatched ) ∨ (x P 3rdBest ∧ y ¸ BestMatched < 2ndBest ))
Cb in ICMstates currPs in ICMstates shown focus top currCs in ICMstates
* The precise definition of the function Enquire for the cars ICM are beyond the scope of this paper, the interested reader is referred to Dearden (1995a ).
172
A. M. DEARDEN AND M. D. HARRISON
The operationality of the model can be measured by considering the degree of freedom that is available to a software engineer in constructing such a mapping. The mappings of Cb , currP and currCs offer very little freedom since they identify commonly recognized components of an ICM or non-interactive case memory. The interpretation of the sets shown , focus and top are more problematic. For example, in the cars ICM when the similarity function only selects a small number of cars (as in Figure 4) the sets shown can be defined as those cases that are actually presented in the display, but where a large number of such cases are returned, they are presented in a scrollable window. Dearden (1995a ) treats the cases that could be viewed as members of the set shown , but this is not the only possibility. Similarly, the model underspecifies the sets top and focus. top could be interpreted as the set of cases in BestMatched , or more broadly as the union of the three sets displayed. Thus, the user of this model still has some freedom to construct different mappings. The freedom to construct different mappings for shown , focus and top implies that, in order to make the model fully operational, it will be necessary to agree on a single interpretation within any given project. This freedom may be related to the problems of selecting ‘‘psychologically relevant abstractions’’ of a system in the template model (Roast, 1993) see Section 3. However, unlike the general template model, the knowledge encapsulated in the generic model suggests specific abstractions to look for when designing ICMs. On the basis of the mappings shown in Table 1 Dearden (1995a ) presents an analysis of interaction properties for the cars ICM. The analysis shows the following. $ The cars ICM provides a change focus operation that allows the user to change the focus to either the sets ‘‘2nd Best’’ or ‘‘3rd Best’’ by revising the value of currP. This is achieved by taking the matching attributes of the selected set, moving them to the top of the user’s priority list, with the result that the cars matching on this set of attributes are then selected as the ‘‘Best matched’’ set. $ The flexibility of the cars ICM permits: any question and answer pair to be added to currP ; any question – answer pair within currP to be removed; or any question – answer pair in currP to be moved up to a higher priority, as well as the re-arrangement of priorities within currP that is used to implement the change focus operation. $ That any case that is in the set shown is reachable by adding to currP. This property is ensured by providing a ‘‘zoom in’’ dialogue that allows the user to select constraints that apply to a selected car and add these constraints directly to currP. Other work that has sought to develop generic specifications such as that by Garlan and Delisle (1990), Garlan and Notkin (1991), Kotze´ (1993), and Goodwin (1995) provide a similar or greater degree of operationality. 5.6. SUMMARY
The generic model of an ICM demonstrates an alternative level of abstraction at which models can be developed. By modelling a class of systems at a generic level a model can be developed that is more expressive and more operational than highly
ABSTRACT MODELS FOR HCI
173
abstract models of general interactive systems, but is also re-usable for the development of multiple software systems. It should be recognized that the activity of constructing a generic model still relies on the modeller’s craft knowledge of the class of systems. The benefit of generic modelling is that this craft knowledge is then encapsulated in an operational and re-usable form.
6. Conclusion This paper demonstrates three distinct levels of abstraction at which interactive software systems might be modelled. Modelling interactive systems at a very high level of abstraction such as that provided by the PiE model (Dix, 1991) or the interaction framework (Blandford et al. , 1995) allows generic interaction properties to be described. These formalisms may improve our understanding of what properties such as ‘‘predictability’’ or ‘‘what you see is what you get’’ really mean for any interactive system. However, such models may be unable to express requirements specific to particular systems, and HCI design knowledge encapsulated by reference to such models may not be operational. Modelling individual systems using detailed specifications may permit a more operational encapsulation of HCI design knowledge. However, because such models offer a limited range, and therefore limited opportunities for re-use, the effort required to develop a complete model for each new project may be unreasonable. Of course there may be some systems where the effort is justified. For instance, in designing interfaces for safety critical applications the potential cost of a failure arising from an interface design flaw might justify a complete model being developed for some parts of the system. Finally, the possibility of constructing a generic model for a class of systems was presented. Models of this type can be both operational and expressive, but allow the cost of development of the model to be spread over multiple projects. This type of model may be particularly useful in investigating interaction properties for classes of system that are not yet sufficiently common for relevant HCI design knowledge to be widely distributed as craft knowledge. At present we are investigating the application of a similar modelling approach to the design of user interfaces for theorem proving assistants (Merriam & Harrison, 1996). The authors would like to thank Derek Bridge of the University of York, Tom Maibaum of Imperial College, London and Alan Dix of the University of Staffordshire, for their constructive comments on earlier versions of this work.
References ABOWD, G. D. (1991). Formal aspects of human – computer interaction. Ph.D. Thesis, University of Oxford, Oxford, UK. ASHLEY, K. D. & RISSLAND, E. L. (1988). A case-based approach to modeling legal expertise. IEEE Expert , 3 , 70 – 77. BLANDFORD, A. E., HARRISON, M. D. & BARNARD, P. J. (1995). Using interaction framework to guide the design of interactive systems. International Journal of Human – Computer Studies , 43 , 101 – 130.
174
A. M. DEARDEN AND M. D. HARRISON
COWAN, D. D. & LUCENA, C. J. P. (1995). Abstract data views: an interface specification concept to enhance design for re-use. IEEE Transactions on Software Engineering , 21. CRAIGEN, D., GERHART, S. & RALSTON, T. (1993). An international sury ey of industrial applications of formal methods. Technical Report NISTGCR 93 / 626, US Department of Commerce, National Institute of Standards and Technology, Computer Systems Laboratory. DEARDEN, A. M. (1995a ). The use of formal models in the design of interactiy e case memories. Ph.D. thesis, Department of Computer Science, University of York, York, UK. DEARDEN, A. M. (1995b ). Improving the interfaces to interactive case memories. In I. D. WATSON, Ed. Proceedings of the First UK Case Based Reasoning Workshop , No. 1020 in Lecture Notes in Artificial Intelligence, pp. 73 – 85. Berlin: Springer Verlag. DEARDEN, A. M. & HARRISON, M. D. (1995). Modelling interaction properties for interactive case memories. In F. PATERNO’, Ed. Interactiy e Systems: Design , Specification and Verification , 301 – 316. Berlin: Springer Verlag. DIX, A. J. (1991). Formal Methods for Interactiy e Systems. London: Academic Press. DUKE, D. J. & HARRISON, M. D. (1993). Abstract interaction objects. Computer Graphics Forum , 12 , 23 – 36. DUKE, D. J. & HARRISON, M. D. (1994). Connections from A(V ) to Z. Technical Report System Modelling / WP21, AMODEUS II project, ESPRIT Basic Research Action 7040. FACONTI, G. P. & PATERNO’, F. (1994). A GIO y iew of AV Connections. Technical Report SM / IR5, AMODEUS II project, ESPRIT Basic Research Action 7040. FOLEY, J. D. & SUKAVIRIYA, P. N. (1995). History, results and bibliography of the user interface design environment (UIDE), an early model-based system for user interface design and development. In F. PATERNO’, Ed. Interactiy e Systems: Design , Specification and Verification , pp. 3 – 14. Berlin: Springer Verlag. GARLAN, D. & DELISLE, N. (1990). Formal specifications as reusable frameworks. In B. BJORNER, C. A. R. HOARE & H. LANGMAACK, Eds. VDM and Z: Formal Methods in Software Dey elopment , No. 428 in LNCS, pp. 150 – 163. Berlin: Springer Verlag. GARLAN, D. & NOTKIN, D. (1991). Formalizing design spaces: implicit invocation mechanisms. In S. PREHN & W. J. TOETENEL, Eds. VDM , 91 , in LNCS , pp. 31 – 44. Berlin: Springer Verlag. GOODWIN, R. (1995). Formalizing properties of agents. Journal of Logic in Computer Science , 5, 763 – 781. HARRISON, M. & THIMBLEBY, H., Eds. (1990). Formal Methods in Human – Computer Interaction. Cambridge: Cambridge University Press. HARRISON, M. D., ROAST, C. R. & WRIGHT, P. C. (1989). Complementary methods for the iterative design of interactive systems. In G. SALVENDY & M. J. SMITH, Eds. Designing and Using Human – Computer Interfaces and Knowledge Based Systems, pp. 651 – 659. Amsterdam: Elsevier. HAYES, I., Ed. (1987). Specification Case Studies. London: Prentice-Hall. JACOB, J. (1991). The varities of refinement. In J. M. MORRIS & R. C. SHAW, Eds. 4th Refinement Workshop , pp. 441 – 455. Berlin: Springer Verlag. KERAVNON, E. T. & WASHBROOK, J. (1989). What is a deep expert system: an analysis of the architectural requirements of second-generation expert systems. Knowledge Engineering Rey iew , 4 , 205 – 233. KLAHR, P. & VROOMAN, G. (1991). Commercialising case based reasoning technology. In I. M. GRAHAM & R. W. MILNE, Eds. Research and Dey elopment in Expert Systems VIII , pp. 18 – 24. Cambridge: Cambridge University Press. KOLODNER, J. L. (1993). Case -Based Reasoning. San Mateo, CA: Morgan Kaufmann. KOTZE´ , P. (1993). Using a formal model for the evaluation of the human – computer interface properties of authoring systems. In P. BRNA, S. OHLSSON & H. PAIN, Eds. AI in Education: 93. Charlottesville, VA: Association for the Advancement of Computing in Education (AACE). LANE, T. G. (1990). Studying software architecture through design spaces and rules. Technical Report CMU / SEI-90-TR-18, Software Engineering Institute, Carnegie Mellon University.
ABSTRACT MODELS FOR HCI
175
LONG, J. & DOWELL, J. (1989). Conceptions of the discipline of HCI: craft, applied science, and engineering. In A. SUTCLIFFE & L. MACAULAY, Eds. People and Computers V , pp. 9 – 32. Cambridge: Cambridge University Press. MACLEAN, A., YOUNG, R. M., BELLOTTI, V. & MORAN, T. (1991). Questions options and criteria: elements of design space analysis. Human – Computer Interaction , 6, 201 – 250. MANAGO, M. & CONRUYT, N. (1992). Using information technology to solve real world problems. In F. SCHMALHOFER, G. STRUBE & T. WETTER, Eds. Contemporary Knowledge Acquisition and Cognition , No. 622 in Lecture Notes in Artificial Intelligence. Berlin: Springer Verlag. MERRIAM, N. A. & HARRISON, M. D. (1996). Evaluating the interfaces of three theorem proving assistants. In F. BODART & J. VANDERDONCKT, Eds. Design Specification and Verification of Interactiy e Systems ’96 , pp. 330 – 346. Wein: Springer. MORGAN, C. (1994). Programming from Specification , 2nd Edn. New York: Prentice Hall. NAFTALIN, M., DENVIR, T. & BERTRAN, M., Eds. (1994). FME ’94: Industrial Benefit of Formal Methods. No. 873 in LNCS. Berlin: Springer Verlag. PALANQUE, P. A. & BASTIDE, R. (1995). Petri net based design of user-driven interfaces using the interactive cooperative objects formalism. In F. PATERNO’, Eds. Interactiy e Systems: Design , Specification and Verification , pp. 383 – 400. Berlin: Springer Verlag. PATERNO’, F., Ed. (1995). Interactiy e Systems: Design , Specification and Verification. Berlin: Springer Verlag. POTTER, B., SINCLAIR, J. & TILL, D. (1991). An Introduction to Formal Specification and Z. New York: Prentice Hall. RICHTER, M. M. & WESS, S. (1991). Similarity, uncertainty and case-based reasoning in patdex. In R. S. BOYER, Ed. Automated Reasoning: Essays in honour of Woody Bledsoe , pp. 249 – 265. Dordrecht: Kluwer Academic Publishing. ROAST, C. R. (1993). Executing Models in Human – Computer Interaction. Ph.D. thesis, Department of Computer Science, University of York, York, UK. ROTH, E. M., BENNETT, K. B. & WOODS, D. D. (1988). Human interaction with an ‘‘intelligent’’ machine. In E. HOLLNAGEL, G. MANCINI & D. D. WOODS, Eds. Cognitiy e Engineering in Complex Dynamic Worlds , pp. 23 – 69. London: Academic Press. RUSHBY, J. (1993). Formal methods and the certification of critical systems. Technical Report CLS-93-7, Computer Science Laboratory, SRI International. SCHREIBER, S. (1995). The BOSS-System: coupling visual programming with model based user interface design. In F. PATERNO’, Ed. Interactiy e Systems: Design , Specification and Verification , pp. 161 – 180. Berlin: Springer-Verlag. SPIVEY, J. M. (1992). The Z Notation: A Reference Manual , 2nd Edn. New York: Prentice Hall. SUFRIN, B. & HE, J. (1990). Specification, refinement and analysis of interactive processes. In M. D. HARRISON & H. W. THIMBLEBY, Eds. Formal Methods in Human – Computer Interaction , Chapter 6. Cambridge: Cambridge University Press. SZEKELY, P., LUO, P. & NECHES, R. (1993). Beyond interface builders: model-based interface tools. In S. ASHLAND, K. MULLET, A. HENDERSON, E. HOLLNAGEL & T. WHITE, Eds. Proceedings of InterCHI 93 , Amsterdam , The Netherlands , pp. 383 – 390. New York: ACM. THIMBLEBY, H. (1990). User Interface Design. New York: ACM Press. TOOK, R. (1990). Putting design into practice: formal specification and the user interface. In M. HARRISON & H. THIMBLEBY, Eds. Formal Methods in Human – Computer Interaction , pp. 63 – 96. Cambridge: Cambridge University Press. TORRES, J. C. & CLARES, B. (1995). Using an abstract model for the formal specification of interactive graphics systems. In F. PATERNO’, Ed. Interactiy e Systems: Design , Specification and Verification , pp. 275 – 292. Berlin: Springer Verlag. VINCKE, P. (1992). Multicriteria Decision -Aid. Chichester: John Wiley and Sons. WESS, S. (1993). PATDEX—ein Ansatz zur wissenbasierten und inkrementellen Verbes¨ hnlichskeitsbewertungen in der fallbasierten Diagnostik. In G. PUPPE, Ed. serung von A Expertensysteme XPS -93 , pp. 42 – 55. Berlin: Springer Verlag. WOODCOCK, J. & LOOMES, M. (1988). Software Engineering Mathematics. London: Pitman.
176
A. M. DEARDEN AND M. D. HARRISON
Appendix: A glossary of Z Z makes use of standard mathematical notation, together with a number of syntactic ‘‘sugaring’’ devices that aid the description of complex specifications. For a comprehensive introduction to Z, the reader is directed to Spivey (1992). What follows is a brief introduction to the meanings of the particular symbols and syntactic structures that are used in this paper. TYPES
[T ] x :T x1 , x 2 , . . . , xn : T x1 : T1; . . . ; xm : Tm
—definition of T as a given type. —declaration of x as a variable of type T. —compound declaration of multiple variables of type T. —compound declaration of variables of differing types.
SETS
[ PS FS <, >, \ S1 3 S2 t PS t ¸S S1 ‘ S2
—the empty set. —the set of subsets of S. —the set of finite subsets of S. —set union, intersection and difference. —cartesian product. —set membership, t is a member of S. —non membership, i.e. —l(t P S ). —Subset: each element of S1 is also a member of S2 .
RELATIONS AND FUNCTIONS
A relation between two sets is represented in Z by a subset of the cartesian product of the two sets, i.e. by a set of pairs. Any operation that can apply to a set can also be applied to a relation. (x , y ) X ↔Y X 5Y X TY f (x )
a pair drawn from the cartesian product X 3 Y. —the set of relations between X and Y (equivalent to P(X 3 Y )). —the set of total functions from X to Y. —the set of partial functions from X to Y. —function application, the (unique) y such that (x , y ) P f.
SEQUENCES
seq X k l sÊ t
—the set of sequences over the set X. —the empty sequence. —concatenation: kx 1 , . . . , xn l Ê k y1 , . . . , ym l5 5 kx1 , . . . , xn , y1 , . . . , ym l.
PREDICATES
If D is a declaration and P and Q predicates. ∧ , ∨ , —l , é , ï ',;
—standard logical connectives. —existential and universal quantification.
ABSTRACT MODELS FOR HCI
177
;D 3 P $ Q
—for all values of the variables declared in D. where P is true it is also the case that Q is true. 'D 3 P $ Q —there exists some values for the variables in D such that P is true and it is also the case that Q is true. Note that a single quantifier ' or ; is permitted for the outer scope of each predicate. Thus ;x : X ; y : Y universally quantifies both x and y. If the predicate P is empty then it is assumed to be true , i.e. ;D $ 5 5 ;D 3 true $ Q 'D $ Q 5 5 'D 3 true $ Q SCHEMATA
The most important structuring device is the schema. A schema is a notational device used to describe the state space of a system. A schema consists of a signature in which variables are declared, and a predicate that describes some situation in terms of these variables. For instance, the schema Diary below is intended to model a diary. Diary ey ents : TIME T TEXT busy : P TIME dom ey ents 5 busy The schema declares two variables, the function ey ents that is a partial function between times and text describing the event that is planned for that time, and busy which represents a set of times that are no longer free. The predicate states that the set of times at which the diary user is busy is equal to the domain of the function ey ents. An operation to change the state represented in a schema can be indicated by using the symbol n followed by the schema name. Thus nDiary represents an operation to change the state of the Diary. The convention is used that primed variables of the schema refer to the values after an operation, the non-primed variables refer to the state before the operation. Variables decorated with the symbol ? are interpreted as input parameters for the operation. Thus, an operation of adding an entry to the Diary may be described by the schema ADD: ADD nDiary new – ey ent ? : TEXT t ? : TIME ey ents 9 5 ey ents % h(t ? , new – ey ent ?)j ∧ busy 9 5 busy < ht ?j Here ey ents 9 and busy 9 are the set of events in the diary and the set of busy times after the operation has occurred; ey ents and busy are the respective sets before the operation.