They apply to a large class of different systems.
That is they are
generic.
| At time of publication: | University of York |
| Currently: | Lancaster University alan@hcibook.com |
Paper presented at HCI'88, Manchester.
Full reference:
A. J. Dix (1988).
Abstract, generic models of interactive systems.
People and Computers: From Research to Implementation - Proceedings of HCI'88, Ed. D. M. J. &. R. Winder. Cambridge University Press. pp. 63-78.
http://www.hcibook.com/alan/papers/hci88/
For related work see my topics pages on formal methods in HCI
For several years at York, we have been investigating the use of abstract models in the design of interactive systems. I will describe why we originally pursued this line and the benefits that have ensued. I will only briefly describe specific models as examples where appropriate. There is an underlying assumption that formal methods are being used during the software design process, but the analysis proves useful even when this is not the case.
Keywords: formal methods, design principles, requirements capture
Since 1984, the HCI group at York have been investigating the role of formal methods in interactive systems design. This paper reviews a significant strand of this research, the use of abstract models in the design process. These are formal models which are both generic (they describe a whole class of systems) and abstract (they only describe what is necessary), and have been used extensively to define principles of usability. Specific abstract models have been described at previous HCI conferences [1,2,3] and elsewhere [4,5,6,7].
This paper will not describe any particular model but instead it will give some of the rationale behind the use of abstract models, give an overview of different models developed and describe some of the benefits of this approach in the design of a specific application.
There has been a mounting interest in the use of formal methods in software design; that is in the precise mathematical description of the intended functionality of computer systems. This has been mainly in response to the software crisis, the demand for increasingly large and complex systems together with high costs for failure. Software designers may use formal methods directly when they produce a formal specification of a specific program. In addition they may make indirect use of formal methods, for instance when the features in the programming language used have been influenced by the formal study of language design.
The term formal methods is also applied within both software design and HCI to formal methodologies, where fixed steps and guidelines are given for achieving some part of design. However it is the former use of the term which is used in this paper.
There is a certain amount of culture shock when first bringing together the concepts of formal methods and interactive systems design. The former is largely perceived as dry and uninspiring in line with the popular image of mathematics. Interface design is on the other hand a more colourful and exciting affair. Smalltalk for instance is not so much a programming environment, as a popular culture. Also it is hard to reconcile the multi-facetedness of the user with the rigours of formal notations. Some of these problems are to do with misunderstandings of the nature of formalisms (although even I, a mathematician, find a lot of computer science formalism very dry). Also, arguably, the shock really occurred when living users met dry unemotional computers and has therefore been dealt with already. However, the gut reaction still exists and must be taken account of.
No matter how strong the reaction against it, there is clearly a necessity for a blending of formal specification and human factors of interactive systems. If systems are increasingly designed using formal methods, then the interface will de facto be also, and if the issue isn't addressed explicitly the methods used will not be to the advantage of the interface designer. Further, the sort of large critical system where the software crisis is most in evidence clearly need an effective interface to their complexity. The penalty for not including this interface in the formal standards will be increased accidents due to human error such as at Chernobyl and Three Mile Island, and the more powerful the magnifying effect of the control system the more damaging the possible effects.
The need for more formal design is seen also in more mundane software. Many of the problems in interactive systems are with awkward boundary cases and inconsistent behaviour. These are obvious targets for a formal approach.
There are many principles for the design of interactive systems, some are very specific (e.g., "error messages should be in red") and others cover more general properties (e.g., "what you see is what you get"). Hansen [8] talks about using user engineering principles in the design of a syntax directed editor, 'Emily', and Thimbleby and Bornat describe the use of principles in the design of the display editor 'ded' [9].
Thimbleby [10] introduced the concept of generative user engineering principles (GUEPS). These principles have several properties:
They apply to a large class of different systems.
That is they are
generic.
They can be given both an informal
colloquial
statement and also a
formal
statement.
They can be used to constrain the design of a given system.
That is they
generate
the design.
The last requirement can be met at an informal level using the colloquial statement - as was the case with the development of ded. While not superceding this, it seems that at least some of the generative effect should be obtained using the formal statements. Other workers who have specified particular interactive systems have proved certain properties of their systems, by stating the properties they require in terms of the particular specification and then proving these as theorems [11]. The same approach could be taken for GUEPS, however there are some problems.
Commitment
- The statement of the principles cannot be made until sufficient of the
design has been completed to give an infrastructure over which they can be
framed.
This means that the principles cannot be used to drive this early part of the
design process, which lays out the fundamental architecture, and hence may be
crucial for the usability of the system.
Consistency
- Because the principles are framed in the context of a particular design,
there is no guarantee that a given informal principle has been given equivalent
formal statements in the different domains.
Conflict
- Expanding on the last point there is a conflict between the desire for
generic
principles and the requirement for
formal generative
principles.
Formal abstract models (also called interaction models" ) have been used to resolve this conflict. These do not represent a particular interactive systems, but instead model a whole class of systems. The principles required are given a formal statement using this abstract model. When a particular system is being designed, the abstract model can be mapped at a very early stage onto the design - or even refined into the first design. The principles defined over the abstract model can then be applied to the particular system.
We see that this tackles the problem of commitment because the principles are stated before the particular system is even conceived, and the problem of consistency because the principles are only stated once and then the same statement is applied to many systems.
Designing a system involves a translation from someone's (the client's) informal requirements to an implemented system. Once we are within the formal domain we can in principle verify the correctness of the system. For example, the compiler can be proved a correct transformer of source code to object and we can prove the correctness of the program with respect to the specification. Of course, what can not be proved correct is the relation between the informal requirements and the requirements as captured in the specification. This gulf between the informal requirements and their first formal statement is the formality gap. (fig. 1)
Figure 1. Abstract model bridges the formality gap
For a DP application like a payroll, this may not be too much of a problem. The requirements are already in a semi-formal form (e.g., pay scales, tax laws) and they are inherently formalisable. The capture of HCI requirements is far more complex. Not only are they less formally understood to start with, but it is likely that they are fundamentally unformalisable. We are thus aiming to only formalise some aspect of a particular requirement and it is difficult to know if we have what we really want.
If the abstract model is designed well for a particular class of principles, it can bridge the formality gap. It is designed to described the user interface requirements, rather than a particular system. Thus although there is still a gap between it and the requirements, it is smaller. Yet it is a formal model, and thus the relationship between it and the specification of the full system can be verified formally. To achieve this aim, there must be a close correspondence of structure between the abstract model and the informal concepts. This principle of structural correlation is a recurrant theme both at this level and throughout the design process.
As we've noted, the abstract model should reflect the requirements in order to bridge the formality gap. What does this mean for interactive systems and user centred design? For particular classes of properties there will be particular structures of importance that must be reflected in the abstract model. Not only will the model depend on the domain of interest, but to some extent on those who use the model. The important thing is that the formal statement obviously corresponds to the requirements, and therefore one should strive for the most natural representation possible.
Not all the features of the abstract model are dependent on the particular principles required. If we are after a user centred design, then we should not be concerned with parts of the system that are not apparent to the user. That is we should adopt a surface philosophy when designing abstract models. We are not interested in the internal details of systems, such as hardware characteristics, languages used, or even specification notations! The models should be as far as possible black box models concerned with the user inputs the system outputs, and the relation between them defined as abstractly as possible.
This approach does not imply we can 'peel off' the surface and consider it as the interface, that is study the interface and the underlying functionality separately, quite the reverse. It is the whole functionality as viewed from the surface that is of interest. Consider a radio, the surface view of it is a set of knobs and a grill (with the speaker behind it). We might be tempted to just take the case, without the internal circuitry, and call this the interface. This does not do as a surface approach as the original radio and the stripped down version would have radically different behaviours when considered as black boxes: the former would work, the latter wouldn't!
Sometimes it may be necessary to break this black box slightly. Often the user may perceive some of the internal structure, and where this is relevant the model should reflect this user model. This may arise because the system is badly designed and you can "see the bits between the pixels". For instance, one may be aware of implementation details, such as recirculating buffers or event polling, by the way the system behaves, or even worse be presented with error messages such as "stack overflow"! It may also occur in a more acceptable fashion. For instance, it is reasonable for the user to be aware of the filing system as a separate layer of abstraction within an operating system. Similarly, when moving the radio about to improve reception, it's useful to know there is a coil inside it that is being aligned.
All this corresponds to drawing the interface line slightly within the machine, looking through the glass of the VDU to the structures within. Sometimes it is appropriate to move the line in the opposite direction and consider the effective interface within the user. For instance, where the user has learnt some key-stroke sequence and the user's conceptual commands may correspond to several physical interactions. Similarly, a learner driver may consider operating the clutch and gear lever as separate actions whereas when experienced "changing gear" is a single conceptual action. Ideally the system will be designed around the user's expected conceptual model, in addition the documentation will reveal the system model to the user. In this case the two directions of movement may be equivalent, the internal details and the user's conceptual model agreeing. This corresponds to one of the facets of direct manipulation described by Hutchins et al. [12]. There is thus a strong dualism between models of systems, and models of users.
Thinking of formalism as the precisely written rules and formulae, what is its range of applicability for interface design? If we asked instead more definitely - "Will we be able to generate a precise definition of usability?" we could answer "NO" with little fear of contradiction. However, just where between being useless and essential formal methods lie is not obvious.
The use that is most obvious and most "formal" for the abstract models and principles is as a safety net". We can see this if we look at the role of formalism in the design of a building. We have two putative designs, one a thatched cottage, and one a concrete block of flats:-
Formal properties of building materials can tell us things like the thermal conductivity of thatch, whether a concrete lintel can bear the required weight, whether the structures are water-tight. This may be codified into formal requirements, either explicit like building regulations on insulation and drainage, or implicit - it mustn't fall down. The formal analysis doesn't tell us which is the best design. Even if we formalise more of the requirements for a particular context - How many people will live there? Are they scared of heights? We will still have an incomplete picture. It will not of course tell us that uPVC windows on the cottage would be barbaric and leaded pains on the flats plain silly. So the formalism of building design can tell us whether the building will fall down or leak, but not whether it will be beautiful or pleasant to live in.
Going back to interface design, by defining suitable principles we will be able to stop interfaces being fundamentally unusable, but not ensure that they are usable. So we can't make a bad interface good, but we can stop it being abysmal. The challenge of course is can we do this and also allow the good interface designer to be creative? In fact I have found that the uses of abstract models for principled design go way beyond being just a safety net. However even in that capacity only, the experience of other disciplines shows that they would still be worthwhile.
We have developed various abstract models dealing with different aspects of interactive systems, these include:
General models
- (in particular the PIE model
[1])
looking simply at the commands entered (e.g., keystrokes, mouse
clicks) and the effects that arise.
The effects can be left undifferentiated or divided into permanent
results
(e.g., print-out) and ephemeral
displays
(the actual screen image) (fig. 2).
Principles of interaction include:
Figure 2. Simple red-PIE model
Windowed systems - Here we have
been interested in the problem of interference between windows [2]. Where different
windows represent different tasks, the user wants to treat these as independent.
That is, while there is only one user there are effectively several different
personnae, one for each task (fig. 3). Hence a multi-windowed system
is rather like a multi-user system, except without most of the protection mechanisms
that operate between users. Interference between windows can therefore be very
damaging and understanding and defining forms of sharing between windows is
crucial.
Figure 3. Multiple windows - multiple personnae
Temporal models
[3]
- Real time interface issues, such as keyboard buffering and display strategies
have been considered.
Mechanisms to ensure predictability even when the system response time is slow
have been specified.
Pointers
[7]
- Both older cursor based systems and mouse based systems make use of the
concept of pointers as the locus of interaction.
These pointers have important properties:
For example, we are using a text editor and mark a block starting in the 100th
line.
We then insert several lines before its start.
Of course, we no longer expect the block to begin at the 100th line,
but to have moved with the text.
That is we are interested in
dynamic
or
semantic
pointers.
These occur widely in interactive systems and often have strange idiosyncratic
behaviour, frequently inconsistent within the same application.
Models to express these which do "open up" the black box slightly have been
formulated, in particular to emphasise consistency and simplicity of different
pointers.
Editing the view
[7]
- Often interaction is modelled linearly, the user's commands affect the system
state, from which display feedback is generated.
We have also considered models where the focus of attention is on the display,
and the user's commands are seen as affecting the display directly, the internal
state being changed in accordance.
This leads to a different way of understanding the interface,
in particular it focuses the designers attention on what should remain
constant.
For instance, if designing a new component on a CAD system, and the system runs
out of room, it would be perfectly consistent with our view (the new component)
to delete existing components in order to make room.
This is clearly not acceptable, and no one would be likely to design such a
system.
However as the data base and the views of it
become more complex it is not so easy to know what is or is not acceptable.
Hence, for any view the user has of the system we must specify
a complementary view that remains unchanged.
Non-determinism
[7]
- When considering various formal properties of the models above there arose
the need to use non-deterministic models.
For instance, in describing the interaction with one window ignoring the
interleaved actions in other windows, the perceived
effects will be non-deterministic if
there is any interference.
Considering this
formal
non-determinism lead to an
informal
recognition of non-determinism as a real interface phenomenon, and prompted
the analysis of many common interface problems in terms of the paradigm.
The different models cover different facets of interactive behaviour, so the principles formulated differ. There are some informal concepts that arise with slightly different formal statements in several models.
Predictability is one such concept. This was originally prompted by the desire to formalise the modiness of systems, but is far more wide ranging than that. Early statments over the general models were of the form: "if I've forgotten what I've already typed, can I work out what will happen next by looking at the screen alone". A frequent reason for forgetting exactly what has already been typed is going away for a cup of tea, and then returning some minutes (or hours!) later. Similarly when considering temporal models we wanted to express principles which allow the user to predict whether the system is in steady state, or is still responding to outstanding buffered keystrokes. Clearly only a small amount of information can be on the screen at once, and thus we also studied principles focused on the information, not currently displayed, but easily accessible.
Another related issue that arose repeatedly was aliasing. That is the content of an object does not unambiguously define its identity. For example, if I copy one file into another intending to edit the new file, I may accidentally edit the original file. Once in the editor the mistake will not be apparent unless the file name is displayed. Similar problems arise within a single file when two portions are similar. After encountering these problems within the general models, it was not surprising to meet them again when considering windowed systems. One finds that in order to maintain predictability each window must be distinguishable, and in general this means unique banners as the window contents may be similar. For instance, I frequently confuse windows communicating with two different computers.
When starting this work there were several expected benefits to using abstract models for principled design.
Bridging the formality gap
Generic statement of principles
Constraining design
Evaluation of systems
The first two of these refer more to the generation of models and principles and the later to the formal use of these. The first two have certainly been fulfilled by the models and principles we have used. We noted earlier that any principles produced would be necessary but not sufficient for good design, and hence the formal use in generation (and evaluation) would be limited to that of a safety net. The principles have been applied in that fashion to the design of small multi-window hyper-text system, this consists of about 50 pages of formal specification and about 10,000 lines of code and is thus a reasonable test of the methods. A particular issue that arises when applying the abstract models is what level to apply them at. We discussed earlier that different users may perceive different conceptual interfaces, so task oriented knowledge about the users' models must be used when applying principles. Frequently the user group is heterogeneous and thus the same principle may be applied at several levels, e.g., keystroke level, command level, conceptual chunks of commands...
There have also been specific developments of the concept of abstract models by various researchers: Anderson [13,14] has developed the general models with the intention of easing the proof of properties, Sufrin [15] has expressed a variant of the models in 'Z', a widely used specification language, and Runciman and Toyn [16] have represented the PIE model in a functional programming framework to aid its use in rapid prototyping.
The abstract models and principles are also used in order to evaluate existing systems. For instance, not only do most systems fail the predictivity conditions for fully temporal systems, but many window managers and operating systems make it impossible to write conformant systems [3]. Further, Monk [17] has produced a notation based on the ideas of PIEs, which can be used by non-mathematical interface designers as an early paper and pencil method for evaluating and improving interface decisions.
There are additional uses of the principles beyond the formal ones.
General understanding
The models have lead to a general understanding of the concepts and principles involved. This clarification of concepts is an often stated advantage of formal methods which I thoroughly endorse. Often this general understanding has resulted not so much in the solving of problems, but in the better understanding of them, or in the discovery of problems otherwise unnoticed. This leads on to:
Derivation of concepts
Various concepts resulted from the formal analysis. For instance, the recognition of interface non-determinism. All of these could be noted without formal analysis, but it is the formal analysis that forces them to attention. In addition diffuse vague notions became solidified, and this was the origin of concepts such as predictability, observability and reachability. The realisation of generality and far reachingness of these concepts was the direct result of formalising them. Further, they become well understood, not just as formal properties but at a much deeper intuitive level also.
Informal application
This semi-formal and informal understanding meant that the use of the models and principles went far beyond their strict domains and influenced other parts of the design at a semi-formal or informal level. The formalism of the method lead to advantages well beyond the limits of strict notational and mathematical formalism.
So we have seen that the formalism has far exceeded the goals we set for it. We expected it to be convergent, defining precisely existing ideas and principles. In practice it has been more divergent than this suggesting new principles, opening up avenues and ideas. This is not as surprising as it seems. By its nature formalising one aspect leaves others ambiguous. This ambiguity being of course the generality. Mathematics is all about relationships, abstracting out the critical part of things, taking ideas from one domain and seeing similarities elsewhere. This is far from the dry view of formalism. From this perspective mathematics and poetry look like two sides of the same coin, and taking this analogy further, we could liken the complete system specification to an epic saga. The abstract model is of course a Haiku.
The work described was carried out under SERC/Alvey grant GR/D/02317, "Mechanisms for Specification, Implementation and Evaluation of Interactive Systems", by Michael Harrison, Colin Runciman, Harold Thimbleby, Andrew Monk, Nick Hammond, Paul Walsh, Eliot Miranda, Ian Toyn and myself. This paper was written whilest supported by a SERC Post-Doctoral Fellowship.
[1] A.J. Dix and C. Runciman, "Abstract models of interactive systems", pp. 13-22 in People and Computers: Designing the Interface, ed. P. Johnson & S. Cook, Cambridge University Press (1985).
[2] A.J. Dix and M.D. Harrison, "Principles and interaction models for window managers", pp. 352-366 in People and Computers: Designing for Usability, ed. M.D. Harrison & A. Monk, Cambridge University Press (1986).
[3] A.J. Dix, "The myth of the infinitely fast machine", pp. 215-228 in People and Computers III, ed. D. Diaper & R. Winder, Cambridge University Press (1987).
[4] A.J. Dix, M.D. Harrison and E.E. Miranda, "Using principles to design features of a small programming environment", pp. 135-150 in Software Engineering Environments, Peter Peregrinus (1986).
[5] A.J. Dix and M.D. Harrison, "Formalising models of interaction in the design of a display editor", pp. 409-414 in Human-computer interaction - Interact'87 ed. H.-J. Bullinger & B. Shackel, North-Holland (1987).
[6] A.J. Dix, M.D. Harrison, C. Runciman and H.W. Thimbleby, "Interaction models and the principled design of interactive systems", pp. 127-135 in Proceedings European Software Engineering Conference, Springer-Verlag (1987).
[7] Alan J. Dix, Formal Methods and Interactive Systems: Principles and Practice, D.Phil thesis, Department of Computer Science, University of York (1987).
[8] Wilfred J. Hansen, "User engineering principles for interactive systems", pp. 217-231 in Interactive Programming Environments, ed. D.R. Barstow, H.E. Shrobe and E. Sandewall (1984).
[9] R. Bornat and H.W. Thimbleby, The life and times of ded, display editor, (1986).
[10] H.W. Thimbleby, "Generative user-engineering principles for user interface design", pp 102-107 in Human-computer interaction - Interact'84, ed. B. Shackel, North-Holland (1984).
[11] Bernard Sufrin, "Formal specification of a display-oriented text editor", Science of Computer Programming (1), pp. 157-202, North-Holland (1982).
[12] E.L. Hutchins, J.D. Hollan and D.A. Norman, "Direct manipulation interfaces", pp. 87-124 in User Centred System Design, ed. D.A. Norman & S.W. Draper, Lawrence Erlbaum Associates (1986).
[13] S.O. Anderson, Specification and Implementation of user Interfaces: Example: A File Browser, Heriot-Watt University (1985).
[14] S.O. Anderson, "Proving properties of interactive systems", pp. 402-416 in People and Computers: Designing for Usability, ed. M.D. Harrison & A. Monk, Cambridge University Press (1986).
[15] B. Sufrin, "A formal framework for classifying interactive information systems", in IEE Colloquium - Formal Methods and Human-Computer Interaction (1987).
[16] C. Runciman and I. Toyn, Transformational development of purely functional prototypes from PiE interaction models, University of York (1987).
[17] A. Monk and A.J. Dix, "Refining early design decisions with a black-box model", pp. 147-158 in People and Computers III, ed. D. Diaper & R. Winder, Cambridge University Press (1987).