back to Dave Clarke's publications

Dialogue Specification and Control: A Review of Models and Techniques

© Information and Software Technology 1994, Vol 36, No 9, pp 539-547.
Elsevier Science

David T. Clarke

School of Computing and Information Technology, University of Wolverhampton, Wulfruna Street, Wolverhampton WV1 1SB, England.

Geoff P. Crum

Information Systems Group, School of Computing, PO Box 334, Staffordshire University, Beaconside, Stafford ST18 0DG, England.

Email: CMTGPC@soc.staffs.ac.uk

Abstract. This paper examines the variety of techniques and notations that have been proposed for dialogue specification and control in interactive systems. Notations covered include state transition diagrams, grammars, event-based approaches, formal notations and object-oriented techniques. The various advantages and disadvantages of each are indicated, and related user interface software tools are referenced where appropriate. Dialogue specification in the context of traditional system design is also discussed.

Free Terms. Dialogue Specification, State Transition Diagrams, STD, Grammars, Events, Formal Notation, User Interface, UIMS, Systems Design, Object-oriented.

Introduction

The dialogue component is perhaps the most crucial part of an interactive system, hence it comes as no surprise to discover that this topical subject has received a substantial amount of attention from researchers. This paper examines the variety of techniques and notations which have been proposed for dialogue specification (Dix et al 1993), with reference being made to relevant User Interface Management Systems (Clarke 1993a, Rathnam and Mannino 1991) as appropriate. Notations based on state diagrams, grammars and events are discussed initially, followed by formal techniques. The object-oriented paradigm and a selection of other methods are considered in the final part of the paper.

State Transition Diagrams

State transition diagrams (STDs) initially appeared in the 1960s when Conway (1963) used this notation to represent the specification of a compiler for a programming language. Newman (1968) and Parnas (1969) however, were the first to use such a notation for the specification of the dialogue within an interactive system.

A State transition diagram (or state transition network) is made up of a set of nodes that represent states within the system, and a set of links between the nodes, that represent possible transitions. These links* show how the dialogue can move from one state to another, and are labelled with the appropriate user action for that link, and possible computer response (Shneiderman 1992). A simple STD is presented in Figure 1, illustrating the dialogue for drawing a rubber band line, using a locator input device (e.g. mouse).

2: Record first point 3: Draw/update line to second position 4: Fix second point Figure 1.  Example STD with program actions (adapted from Green 1986)

When the user initially presses the mouse button, the starting point for the line is recorded. Each time the mouse is moved, the line is updated, and when the button is pressed a second time, the line is fixed at the current position. In its basic form, the STD does not describe the program actions, hence Figure 1 above has been extended to include actions to be performed at each state in the dialogue. Program actions may also be added to the links, allowing an action to take place when a transition occurs (Green 1986), often resulting in a smaller and more concise diagram.

Other extensions to the basic STD include recursive transition diagrams (RTDs) and augmented transition diagrams (ATDs). RTDs enhance the descriptive power of the basic notation by allowing recursive calls. ATDs extend the RTD further to incorporate functions and registers, permitting context-sensitive dialogues to be specified (Rathnam and Mannino 1991).

STDs are most beneficial for describing dialogues that involve distinct modes, clearly showing the states at each point within the system. A problem with the STD however, is the large size of diagrams that can emerge in order to cope with every possible user action, resulting in unwieldy networks of states and transitions. This can be overcome to some extent by using sub-diagrams, which are analogous to procedures/modules in conventional software engineering, allowing the dialogue to be broken down into manageable logical units.

Another problem includes the inability to handle user interfaces that let the user operate on multiple objects concurrently (Myers 1989), which is clearly a pertaining issue with regard to current GUI window based interfaces. An alternative notation termed statecharts, is a higraph-based extension to the traditional STD, which aims to overcome some of these problems (Harel 1988).

A recent development by Hudson and Newell (1992), extends the basic idea of STDs to cater for the latest input techniques such as pen-based interfaces (Rhyne 1987), body/hand gesture (Pausch and Williams 1990) and voice input (Bolt 1980). These all rely on recognition techniques to determine how they are to be interpreted, thus introducing uncertainty and ambiguity into the input process. The traditional STD model is unsuitable for modelling such interactions because it relies on inputs which are clear to their meaning. Hudson and Newell therefore introduced the concept of probabilistic state transitions, that is, an extended form of STD that supports a number of alternate states, using probabilities to decide which state the system should be in next. Although their work is still in the early stages, with no UIMS to demonstrate its use as yet, it is clearly a very promising dialogue technique for systems utilising input recognition.

A number of researchers have produced UIMS based on STDs, including Jacob (1985), Edmonds (1981), Schulert et al (1985), and Koivunen and Mantyla (1988). In addition, Wellner (1989) produced Statemaster, a UIMS based on an extended notation of statecharts.

Context Free Grammars

To describe the dialogue between the human and the computer, context-free grammar is often used. One of the best known systems for representing the syntax of a programming language is that of BNF (Backus-Naur Form, Naur 1963). BNF has proved most popular for this purpose in the past, and it is perhaps not surprising therefore that various extensions of this have evolved to cater for languages that enable the human to communicate with the computer (e.g. Shneiderman 1982, Reisner 1983).

Essentially non-terminals are used to describe the high-level components, and specific strings are terminals. The example in Figure 2 illustrates the steps involved for a log-on operation, and utilises the multiparty grammar notation of Shneiderman (1982).

          <Session> ::= <U: Opening> <C: Responding>

          <U: Opening> ::= LOGIN <U: Name>

          <U: Name> ::= <U: string>

          <C: Responding> ::= HELLO [<U: Name>]

Figure 2.  BNF for log-on process (adapted from Shneiderman 1992)

Context free grammars have proved popular in the past, being used in a number of the earlier UIMS (e.g. Hanau and Lenorovitz 1980, Olsen and Dempsey 1983). Grammars are quite effective for describing text-based command sequences, but are less suitable for recent developments such as direct manipulation interfaces, which is perhaps why current UIMS are tending not to adopt this form of dialogue specification. It is also clear that grammars can become quite difficult to comprehend by humans, particularly when large dialogues are specified.

There is no doubt that UIMS research is now steering away from grammar based notations towards those that are event based, thus providing a more suitable specification technique for GUI style direct manipulation interfaces.

Event Based Techniques

In this model the input devices can be viewed as generators of events, which are processed by event handlers. Each time an event is generated (e.g. mouse button click), it is placed on a queue to be handled on a FIFO (First-In First-Out) basis by an event handler (Rathnam and Mannino 1991). Essentially event handlers are sets of processes that are able to respond to requests, although they can also call, create and delete other events/event handlers themselves if required.

Each event handler is defined by a template which describes the parameters, local variables and procedure component of the routine(s). Figure 3 illustrates an event handler version of the rubber band example presented earlier, and has been adapted from the notation proposed by Green (1986).

EVENT HANDLER rubber_band;

TOKEN button Button;       // declare tokens to be processed

      move Move;

VAR   int state;           // declare local variables

      point first, last;

EVENT Button DO {          // handle button pressed event

  IF state == 0 THEN

    first = current position;

    state = 1;

  ELSE

    last = current position;

    deactivate(self);

  ENDIF;

};

EVENT Move DO {            // handle move mouse event

  IF state == 1 THEN

    draw line from first to current position;

  ENDIF;

};

INIT                      // statements to be executed on handler creation

  state = 0;

END EVENT HANDLER rubber_band;

Figure 3.  Event handler (adapted from Green 1986)

One of the major benefits of the event model, is the ability to have multi-threaded and concurrent dialogue, a significant advantage over STDs and context free grammars. Indeed, a study by Buxton and Myers (1986) showed that performing two tasks concurrently can often provide a significant increase in interaction performance. In addition, concurrency can be a useful aid when structuring the dialogue, acting as a tool for modularisation, particularly for complex direct manipulation interfaces (Hill 1987). Constructing these style of interfaces using a single-thread of control, can result in a very perplexing structure.

A disadvantage with the event model is that the flow of control is not immediately comprehended as perhaps it is with STDs. The usability of the notation/event language is also questionable, often requiring an amount of programming/technical expertise which is beyond that of the average user*. In addition, handlers need to be written and modified with care - a change to a small piece of code at a later date may have an adverse effect on the whole of the system (Myers 1989).

A number of UIMS have been based on the event model (e.g. Sassafras Hill 1986, UofA Singh and Green 1991), and it is clear that this model has the ability to support the demands of current interface styles. Indeed, Green (1986) did an in depth comparison of the three main dialogue models (i.e. grammars, STDs and events), and concluded that the event model had the greatest descriptive power. The paper also indicated that any dialogue specified using context free grammar or STDs, could always be converted to an equivalent event based specification. Other work of interest includes that of Olsen (1990) who proposed an approach termed Propositional Production Systems (PPS), a technique which takes STDs and events a stage further to cater for semantic control over the dialogue (e.g. do not allow a save operation if there is no file open) and also introduced the idea of inheritance.

Formal Techniques

The advent of complex interaction techniques and multi-threaded dialogue, has resulted in a number of formal notations being proposed. Formal methods can be used to demonstrate the correctness of a specification and its properties (Paterno and Faconti 1992). In addition, formal models of interactive systems provide considerable benefits:

"They give new insight into general problems as the properties of the problem domain are analysed."

"They can be used as part of a formal development process to constrain the design of specific systems."

(Dix 1993)

A number of notations have been put forward to formally  specify the dialogue of interactive systems, with notations that express concurrency receiving considerable attention.

CSP - Communicating Sequential Processes (Hoare 1985), was originally intended as an extension for Algol based languages, and has since developed into a succinct and concise notation for specifying concurrent systems. The notation lends itself nicely for concurrent dialogue specification, and various extensions have since been proposed for this purpose. The example in Figure 4 illustrates a dialogue for controlling a mouse, which simply moves the text cursor to the current mouse position each time the button is pressed.

MOUSE = (button_press -> get_XY -> send_XY -> MOUSE)

TEXT_CURSOR = (send_XY -> position_text_cursor_XY -> TEXT_CURSOR)

MOUSE_CONTROL = MOUSE || TEXT_CURSOR

Figure 4.  CSP for mouse positioning of text cursor

MOUSE and TEXT_CURSOR are two separate processes running concurrently, defined as MOUSE_CONTROL. MOUSE waits for a button_press event, and then obtains the position of the mouse cursor and sends that to another process, via the send_XY event. TEXT_CURSOR waits for a send_XY event, and then positions the text cursor respectively.

Although this is perhaps a simplistic example, it clearly illustrates how CSP can be used to specify a dialogue. Alexander (1990) gives a thorough discussion on EventCSP, a subset of the full CSP notation of Hoare (1985), showing how it can be used for specifying interactive systems. In addition, a discussion on tools and implementations of CSP can be found in Alexander (1987).

The formal notation LOTOS was originally developed within the ISO (International Organisation for Standardisation) environment for specifying network protocols. It has inherited properties from the process algebras CSP and CCS (Milner 1989), and in a recent paper by Paterno and Faconti (1992), it was used to describe graphical interaction. They described how a UIMS could be developed based on a composition of graphical interacting objects, and they illustrated how LOTOS could be used to completely specify the state and events of each interacting object within the system.

The Squeak notation (Cardelli and Pike 1985), again a CSP and CCS hybrid, is essentially a programming language developed primarily to address the issue of concurrency among interaction objects. A particular feature of squeak is its explicit ability to handle temporal properties. Consider the following Squeak example:

wait[t](e.P) || Q

which means P will occur if event e happens within time t. If event e does not happen in that time, process Q continues. In the context of dialogue, an interaction such as holding down and then releasing a mouse button after a determined length of time before an event will happen, could be modelled very concisely using Squeak.

A number of notations have also been proposed that are not concurrency based, including VDM (Marshall 1986) and Z (Sufrin 1982). Unfortunately these are essentially limited to single-thread dialogues and with multi-threaded dialogues now becoming the norm, notations based on concurrency provide the most promising model for formal dialogue specification.

Object-Oriented Approaches

The object-oriented (OO) paradigm has been the basis of much development, and hype, over the last few years. It has considerable appeal from a variety of standpoints, especially in the continuity that it provides between its analytical approaches and its design activity.  The constructs of the analysis map readily onto the elements of the design. However, surprisingly this continuity does not appear to spread into the dialogue specification - specification in the OO environment is very often a statement of software design, through a derivation of objects and clusters etc., rather than a specification of the total system including all its human aspects (de Champeaux et al 1993, Graham 1991, Mullin 1990).  Where OO approaches have been applied to dialogue specification they have tended to consider the dialogue aspect separately, without reference to the overall design procedure. Some of these approaches are discussed below.

Jacob (1986) proposed a specification language for direct manipulation user interfaces, which utilised an object-oriented approach. The language was based on the notion that direct manipulation interfaces  can be modelled as collections of interaction objects, each comprising a separate dialogue specification. Classes of objects could be defined (e.g. button, scrollbar), each consisting of instance variables (e.g. size, position), and a set of methods that are permissible for use on that object (e.g. rotate, draw). Inheritance was also supported, allowing classes to be extended, advocating reuse and consistency of code.

A simple specification for a screen button is given in Figure 5, illustrating how an object is defined, although inheritance is not used in this case. A thorough discussion on the language, and on a prototype UIMS demonstrating its use, can be found in Jacob (1986).

INTERACTION_OBJECT MessageFileDisplayButton is

IVARS: position = {100,200,64,24}    -- rectangle co-ordinates

METHODS: draw()   {DrawTextButton(position,"Display")}

TOKENS:

  iLEFT           {--click left mouse button}

  iENTER          {--locator inside rectangle}

  iEXIT           {--locator outside rectangle}

  oHIGHLIGHT      {--invert video of rectangle}

  oDEHIGHLIGHT    {--as oHIGHLIGHT}

SYNTAX:

main

end INTERACTION_OBJECT;

Figure 5.  Screen button specification (adapted from Jacob 1986)

It is interesting to note that Jacob used STDs for the dialogue specification, showing that each individual interaction object could be modelled to have distinct states. Essentially, Jacob's formalism was a hybrid of STDs and events, allowing multiple diagrams to be active at the same time, with the control flow being transferred from one to another in a coroutine fashion (Myers 1989).

Rumbaugh (1988) presented a language, based on statetrees, that is, a set of states organised into a tree structure. Each substate is a refinement of its superstates and inherits the attributes attached to them.

Figure 6 illustrates a state tree for the process of editing in a picture editor.

Figure 6.  State tree for edit operation (Courtesy of James Rumbaugh)

The diagram shows states for creating, dragging and selecting various graphical objects. Although inputs are interpreted differently depending on the state, clearly common information is still utilised, such as line width and colour. These properties would be associated with the edit state, with the substates inheriting these properties. Rumbaugh implemented this approach in the object-oriented language DSM (Rumbaugh 1987), and used it to construct a graphical state tree editor.

Using an object-oriented database tool, Hardwick et al (1991) produced a UIMS which utilised state trees for controlling the dialogue. One nice feature of their CHIDE (Computer-Human Interface Development Environment) was that it included a graphical state tree editor for dialogue specification, allowing states to be easily added/deleted and complete tree structures to be moved. Hardwick et al are currently developing a new CHIDE UIMS, using Objective-C as the implementation language, and this promises to be a very effective architecture.

Hayball (1991) addressed the issue of dialogue specification in the context of knowledge based systems (KBS). The rule-based dialogue description language proposed, appropriately termed KBS Dialogue Language (KDL),  was designed to operate in conjunction with an object-oriented UIMS. An interesting feature of the notation, was its explicit ability to handle adaptive user interfaces, by allowing the dialogue specification to change at run-time.

A specification method which takes object-orientation a stage further, is that used in the UIDE UIMS (Foley 1991). The usual object-oriented features are supported (e.g. classes, inheritance), but also the notion of assertions have been introduced, providing a concise mechanism for specifying and constraining the behaviour of objects*. Preconditions are used to specify conditions on state variables that must be satisfied before a command can be invoked, whereas  postconditions are changes that occur to state variables when a command is executed (Foley et al 1990). One of the strengths of assertions, is the ability to express and validate the correctness of a specification, a major goal in terms of good software engineering.

Another issue is the relationship between the object-oriented paradigm and formal methods. Few researchers have addressed this, although Bastide and Palanque (1990) carried out some work in this area, developing an object-structured dialect of petri nets for the design of event-driven interfaces. Their paper also discussed the potential of this notation for dialogue validation, prototyping and integration into a UIMS.

Other Specification Techniques

A number of other dialogue specification techniques have been proposed. A popular notation is the Menu Tree, a simple and effective diagrammatic notation which show users and related parties a complete and detailed view of a menu driven system (Shneiderman 1992). Although it is limited to only simple dialogues, the major strength of the notation is the ease at which it can be comprehended, which is perhaps why it is one of the few notations to be adopted for use commercially (e.g. in user manuals).

Hartson et al (1990, 1993) produced UAN (User Access Notation), a task and user-oriented notation for the behavioural representation of asynchronous, direct manipulation interface designs. The notation focuses on user tasks, and actions to achieve those tasks. For example, consider the task of selecting a draw icon. The user would move the cursor to the draw icon, and then depress and immediately release the mouse button. The UAN description for this would be:

User Actions	Interface Feedback
~[draw_icon] Mv	draw_icon!
M^

Moving the pointer towards the icon is represented by ~[draw_icon], and the mouse button motion is represented by Mv (mouse button depress) followed by M^ (mouse button release). System response is represented by draw_icon! (i.e. highlight  icon).

The major strength of UAN is that it combines techniques of task analysis (e.g. GOMS Card et al 1983, CLG Moran 1981, TAGS Payne 1984, HTA Shepherd 1989) with that of traditional dialogue specification, clearly a very powerful combination.

Related work in this area includes that of Firth and Thomas (1991), who used CLG for specification of the user interface within a UIMS, and concluded that the major strength of CLG for specification was the layering concept, starting with the conceptual model and enforcing this model on the rest of the interface. They indicated however, that CLG has very limited facilities for expressing the dynamics and presentational aspects of GUI style interfaces, and that the notation could be considerably improved in this respect.

Conventional Design Methods

Many conventional systems design methods have come to dialogue specification at later stages in their development, and consequently the specification methods have been dictated by the already established modes of thinking and specification techniques.  For example, the most popular British method, SSADM (CCTA 1990) specifies dialogue initially at the logical level, at which decisions are made about the global structure, control and content of the dialogue, and later at the physical level, where decisions are made about detailed screen designs and sequences, wording of menus/commands etc. This layered approach is consistent with SSADM's philosophy of separating design at two levels of abstraction throughout, including both function design and data design.  The rationale for this procedure can be summarised as follows:

     A logical/physical distinction splits design decisions into two interconnected groups, thereby allowing the designer the cognitive benefit of concentrating on major design decisions without being confused by the minor decisions that they dictate;

     The logical design produced may be looked upon as an ideal design from which several implementations can be derived, and evaluated, according to the objectives of the project.  The intention is that the logical design may be used over many incarnations of the physical implementations - the real world technology may change, but the essential logical design will remain largely the same.

It is not the intention of this paper to offer a critique of this approach per se, but it is worth noting that there are no good longitudinal studies of SSADM-based projects to support the continuance of this approach (peculiar to this method), and that empirical observation of SSADM teams detects some resistance to producing two sets of design documentation, one for the logical level, and the second for the physical. In the area of dialogue specification the logical/physical distinction looks less attractive.  It can be argued that much of the significant work in dialogue specification occurs at the physical level, leaving so little work to perform at the logical level as to make its existence arguable.  In so far as dialogue design has its logical level this would be manifested in decisions concerning, for example, the control mode and general style of the dialogue, on the basis of which several physical manifestations of a physical dialogue could be constructed.  Although SSADM has some suggestions that some decisions might be carried out prior to the detailed specification of the dialogue, there is no detailed definition of the processes that might be involved in making such global decisions.

SSADM utilises some diagramming techniques of a flowcharting nature to depict the control structure and internal logic of dialogues.  These have the benefits, and the drawbacks, of state transition diagrams, which they broadly resemble.  They do not deal in any adequate way with the layout of the screen, or the use of facilities such as colour or dynamic graphics.

The LBMS Jackson System Development Method (LBMS 1993) is even more firmly embedded in a software engineering orientation than SSADM, and dialogue specification is treated in less detail. There are Dialog Definitions and Screen Designs, but all subsumed within the specification of the functionality of the system.  JSD recognises that the interface may be very complex, and require its own subsystem, but does not suggest that such a subsystem may require different techniques of design from the more conventional parts of the software. In addition, there are difficulties in relating JSD and SSADM to traditional user interface models such as the Seeheim (Green 1985) and Command Language Grammar (Moran 1981) , since the levels of abstraction do not correspond in any meaningful way.

Recent Developments in Design and Applications

Recent developments in the design and construction processes of information systems have challenged the conventional specification approaches, to the extent that it may be argued that specification approaches have little future except in a few well defined situations. Prototyping, for example, may be seen as the dominant anti-specification approach.  The design decision/software build functions are collapsed into a single fluid operation in which the designers and users are free to move between global and local design decisions, and to build the associated software, without the mediation of a dialogue specification.  The benefits of the approach are well documented, but specifically the user is properly engaged in the design process, and both user and designer are assured that the resulting product satisfies the user's true needs.

Prototyping may be seen as one example of the more participative approach to design that has emerged in the last two decades.  In the taxonomy proposed by Lyytinen (Lyytinen 1987) two major design process types were identified, named learning and discourse model types, both of which are characterised by high user involvement. The significance of this is that the dialogue specification language may in this context be a language for users as well as for designers and programmers.  Hence artificial languages, containing alien semantics and syntax that users need to learn in order to understand the specification, are unlikely to be popular for design methods of these types.  This constraint would rule out many of the specification methods outlined in earlier sections of this paper.  Prototyping is so essentially practical and visual in its approach that to specify a dialogue in any detail on paper would imply a dilution of its effectiveness.

Metaphors have recently been employed in a number of systems as an organising principle in design. Essentially the designer's task is to select an appropriate metaphor for the application by testing out the mappings between the real world situation already familiar to the user and the world of the system functions and data.  Mappings are seldom totally complete, and there are always areas where the design becomes sub-optimal, but these are usually accepted in order to enjoy the usability benefits. Specification of the dialogue then becomes involved in the metaphor selection process, since once a metaphor has been validated, a great deal of the detailed dialogue has thereby been determined. It only remains for the designer to work out the final details, particularly in areas where there is no direct mapping between real world and system world.  Specification methods currently available do not assist the designer in this process of deriving the mappings, but simply allow the recording of the final detailed decisions, which occur after the major decisions have already been made. The use of metaphors as a guiding principle for a system is one example of the growing tendency by designers to conceive solutions at a global level, and using the solution elements at this level to determine lower levels of detail.

A similar approach is adopted by designers in the commercial environment who begin with concepts that are then used to inform the structure and content of applications. Faced with a lack of specification methods at the global level, these designers have invented their own, story boarding being the principal example (see Cotton and Oliver 1993).  In this approach, adopted from the practice in the worlds of advertising and magazine design, screen contents and sequences are set down on some physical medium, such as multiple sheets of paper, or large flip charts, at high speed, in order to explore the overall structure and style. No attempt is made initially at detailed specification of the dialogue, and changes are made rapidly in order to produce a final version which will reflect the overall product strategy. The control structure of the dialogue may be implicit in the position of the individual screens on the flip chart, or of the sheets of paper on the working surface.  The resulting solution may then be finalised and form the basis on which a prototype may be constructed. Some schools of designers (e.g. Schon 1983, Greenbaum and Kyng 1991) now see this as a more fruitful approach than the conventional blueprint one.

The attention of designers to the global concerns of design rather than the local levels that are found in many conventional specification techniques has been partly driven by the nature of the applications now being undertaken.  Hypermedia systems, for example, may be dominated by design considerations such as navigation policy, structuring of knowledge, and screen design variety.  These may be of greater consequence in design than questions of local sequencing and control. The need therefore is for specification methods that allow the global design decision variables to be manipulated fluently before local design decisions are undertaken.

Conclusions and Future Work

It is noticeable that the majority of dialogue specification techniques proposed require an amount of technical expertise usually associated with a programmer rather than the average end-user. Demonstrational interfaces (Myers 1992), will no doubt play an important role in future developments, as these perhaps hold the key to allowing users to define interfaces at a high level of abstraction, without having to be concerned with technical specification notations. An issue which may hinder the progress of such systems however, is the examples the user must give to the system in order to demonstrate what is needed, since these need to be unambiguous and complete. Typically this is very difficult to do, and hence the domain of systems specified using this approach may well be restricted (Rathnam and Mannino 1991).

It is clear that the object-oriented approach to user interface specification is still in its infancy, and although several UIMS have been produced based on object-oriented languages, only a few dialogue notations have appeared so far. There is no doubt however, that others will emerge, as there are considerable benefits to be obtained from its use. Object-orientation is particularly effective for representing specific interface features (e.g. windows) without having to be concerned with their context. In addition, support for information hiding, inheritance and communication via message passing, work together to promote sharability, reusability and consistency within the interface implementation (Hartson and Hix 1989).

Specifications in systems design have developed multiple roles since the earliest design methods were conceived. Among the most prominent of these roles are:

     A technique for analysing the problem;

     A blueprint for the construction of the system;

     A partial/complete representation of the design solution to form a working document for designers;

     A representation of the solution in a format suitable for automatic code generation.

The requirements of these roles have often generated contradictions in practice. As has been suggested above, specifications written with sufficient formality for code generation may be inadequate for communication with users. In addition, there are factors such as the extent to which the technique supports the designer's analysis of the problem and their explanation of the correctness and reliability of the solution. Reusability is another issue which should also be considered, but is only currently seriously addressed in the object-oriented approaches. Moreover, given the development of multiple approaches to design, ranging from the prescriptive to the heuristic, and the increasing quantities of detail required for specifications for hypermedia and multimedia systems, it seems unlikely that one method will, in the future, satisfy all demands. Research, therefore, needs to concentrate on developing a portfolio of methods, with guidelines for designers on the applicability of each. This implies a much more co-ordinated attack in research, in place of the piecemeal approach that has been adopted up till now, where individual researchers have largely pursued their own perspectives.

The modes by which specifications are expressed, and the use of them, are a second area for significant investigation. Textual description maps very inadequately the visual aspects of dialogues, such as layout and colour, yet it is these elements that are seen to be fundamental to the communication capabilities of systems. The popularity of prototyping has endorsed this, in part, though prototyping itself is often limited in practice by its supporting hardware and software and may encourage designers to limit themselves to a small range of dialogue options. There is a need for an intensive review of the modes available for specification, and their appropriateness for specific types of information  and problem scenarios. It is possible that there are novel techniques as yet undiscovered which will satisfy requirements better than the existing ones (for a recent addition see Gibbs, Breiteneder and Tsichritzis 1993).

Underlying the issues raised above is the question of the conceptualisations of dialogues developed by all the stakeholders in a system, and their expression in the form of specifications that develop in their coverage and precision as the design advances. Specification methods need to support these developments, and the relationship between conceptualisation and expression needs further exploration. In essence, dialogue specification is a special case of the general problem of thought and its articulation, and it can be seen to share some of the general characteristics of that problem, while having specific concerns from its own domain.

Acknowledgements

Much of the material in this paper came as a result of research which was carried out by David Clarke, as part of a Master's degree in Computing Science (Advanced), at Staffordshire University. The research was funded by the Science and Engineering Research Council (SERC).

References

Alexander H (1987). Formally Based Tools and Techniques for Human-Computer Dialogues. Ellis Horwood Series.

Alexander H (1990). Structuring Dialogues Using CSP. In Formal Methods in Human-Computer Interaction, Harrison and Thimbleby (Eds), Cambridge University Press.

Bastide R and Palanque P (1991). Petri net objects for the design, validation and prototyping of user driven interfaces. Proceedings of INTERACT'90, 27-31 August 1990, 625-631.

Bolt R (1980). Put-That-There: Voice and Gesture at the Graphics Interface. Computer Graphics, Vol 14, No 3, 262-270.

Buxton W and Myers B (1986). A Study in Two-Handed Input. Proceedings of HCI'86, 321-326.

Card S K et al (1983). The Psychology of Human-Computer Interaction. Lawrence Erlbaum, Hillsdale N J 1983.

Cardelli L and Pike R (1985). Squeak - A language for communicating with mice. ACM Computer Graphics, Vol 19, No 3, 199-204.

CCTA (1990). SSADM Version 4 Reference Manual. NCC Blackwell.

Clarke D T (1993a). Interface Management Systems. Computing, VNU Publishing, London, 25 March 1993.

Clarke D T (1993b). UIMS: Software Support for User Interface Design, Construction and Run-Time Management. Master's Thesis, Staffordshire University.

Clarke D T (1993c). HCI Tools. Computing, VNU Publishing, London, 7 October 1993.

Conway M E (1963). Design of a Separable transition-diagram compiler. Communications of the ACM, 6, 7.

Cotton B and Oliver R (1993). Understanding Hypermedia. Phaidon.

de Champeaux D, Lea D and Faure P (1993). Object-Oriented System Development. Addison-Wesley.

Dix A J (1993). Formal Methods in HCI: Moving Towards an Engineering Approach. Proceedings of NDISD'93, HCI: Making Software Usable, University of Wolverhampton, 30-48.

Dix A J, Finlay J, Abowd G, Beale R (1993). Human Computer Interaction. Prentice Hall.

Edmonds E A (1981). Adaptive Man-Computer Interfaces. Computing Skills and the User Interface, Academic Press, 389-426.

Firth C and Thomas R C (1991). The use of Command Language Grammar in a Design Tool. International Journal of Man-Machine Studies, 34, 479-496.

Foley J D (1991). UIDE - An Intelligent User Interface Design Environment. Intelligent User Interfaces, ACM Press 1991.

Foley J D et al (1990). Computer Graphics: Principles and Practice. 2nd Ed, Addison Wesley.

Gibbs S, Breiteneder C and Tsichritzis D (1993). Data Modeling of Time-Based Media. In Tsichritzis D (ed), Visual Objects. Universite de Geneve.

Graham I (1991). Object Oriented Methods. Addison-Wesley.

Green M (1985). Report on Dialogue Specification Tools. User Interface Management Systems, Pfaff G (ed), Springer Verlag, 9-20.

Green M (1986). A Survey of Three Dialogue Models. ACM Transactions on Graphics, Vol 5, No 3, 244-275.

Greenbaum J and Kyng M (eds) (1991). Design at Work:Cooperative Design of Computer Systems. Laurence Erlbaum.

Hanau P and Lenorovitz D (1980). Prototyping and Simulation Tools for User/Computer Dialogue Design. Proceedings of SIGGRAPH'80, 271-278.

Hardwick M et al (1991). Implementing a User Interface Management System for Existing Applications using an Object-oriented Database Tool. Software Practice and Experience, Vol 21(2), 167-185.

Harel D (1988). On Visual Formalisms. Communications of the ACM, Vol 31, No 5, 514-529.

Hartson H R and Hix D (1989). Human-computer interface development: concepts and systems for its management. Computing Surveys, Vol 21, Iss 1, 5-92.

Hartson H R et al (1990). The UAN: A User-oriented Representation for Direct Manipulation Interface designs. ACM Transactions on Information Systems, Vol, No 3, 181-203.

Hartson H R and Hix D (1993). Developing User Interfaces. Wiley 1993.

Hayball C (1991). Dialogue Specification for Knowledge Based Systems. Proceedings of Workshop on User Interface Management Systems and Environments, Eurographic Seminars, 4-6 June 1990, 169-178.

Hill R D (1986). Supporting Concurrency, Communication and Synchronisation in Human-Computer Interaction - The Sassafras UIMS. ACM Transactions on Computer Graphics, Vol 5, No 3, 179-210.

Hill R D (1987). Event-response systems - A technique for specifying multi-threaded dialogues. Proceedings of SIGCHI+GI'87, 241-248.

Hoare C A R (1985). Communicating Sequential Processes. Prentice Hall Int.

Hudson S E and Newell G L (1992). Probabilistic State Machines: Dialog Management for Inputs with Uncertainty. Proceedings of UIST'92, 199-208.

Jacob R J (1985). A State Transition Diagram Language for Visual Programming. IEEE Computer, August 1985, 51-59.

Jacob R J (1986). A Specification Language for Direct-Manipulation User Interfaces. ACM Transactions on Computer Graphics, Vol 4, No 4, 283-317.

Koivunen M and Mantyla M (1988). HutWindows: An Improved Architecture for a User Interface Management System. Computer Graphics & Applications, January 1988, 43-52.

LBMS (1993). LBMS Jackson System Development Method. Reference Manual. Learmonth and Burchett Management Systems, London, UK.

Lyytinen K (1987). Different Perspectives on Information Systems : Problems and Solutions. ACM Computing Surveys, 19, 1, March 1987.

Marshall L (1986). A Formal Description Method for User Interfaces. PhD Thesis, University of Manchester.

Meyer B (1988). Object-oriented Software Construction. Prentice Hall 1988.

Milner R (1989). Communication and Concurrency. Prentice Hall.

Moran T P (1981). The command language grammar: a representation for the user interface of interactive systems. International Journal of Man-Machine Studies, 15, 3-50.

Mullin M (1990). Rapid Prototyping for Object-Oriented Systems. Addison-Wesley.

Myers B A (1989). User-Interface Tools: Introduction and Survey. IEEE Software, January 1989, 15-23.

Myers B A (1992). Demonstrational interfaces: A step beyond direct manipulation. Computer, August 1992, 61-73.

Naur P (1963). Revised report on the algorithmic language ALGOL. Communications of the ACM, 6 January.

Newman W M (1968). A System for Interactive Graphical Programming. Proceedings of Spring Joint Computer Conference, 47-54.

Olsen D R (1990). Propositional Production Systems for Dialogue Description. Proceedings of CHI'90, 57-63.

Olsen D R and Dempsey E (1983). SYNGRAPH: A Graphical User Interface Generator. Proceedings of SIGGRAPH'83, 43-50.

Parnas D L (1969). On the Use of Transition Diagrams in the Design of a User Interface for an Interactive System. Proceedings of the National ACM Conference, 379-385.

Paterno F and Faconti G (1992). On the Use of LOTOS to Describe Graphical Interaction. Proceedings of HCI'92, BCS Conference Series, 155-173.

Pausch R and Williams R D (1990). Tailor: Creating Custom User Interfaces Based on Gesture. Proceedings of ACM UIST 1990, 123-134.

Payne S J (1984). Task-Action Grammars. In Proceedings of INTERACT'84, Elsevier Science Publishers.

Rathnam S and Mannino M V (1991). User Interface Management Systems: Themes and Variations - A Review of the Literature. Proceedings of the 24th Annual Hawaii Conference on Systems Sciences. Jan 1991, Vol 3, 489-498.

Reisner P (1983). Formal Grammer as a Tool for Analysing Ease of Use: Some Fundamental Concepts. Human Factors in Computer Systems, Ablex, New Jersey, 53-78.

Rhyne J (1987). Dialogue Management for Gestural Interfaces. Computer Graphics, Vol 21, No 2, 137-142.

Rumbaugh J (1987). Relations as Semantic Constructs in a Object-oriented Language. Proceedings of ACM OOPSLA'87, 466-471.

Rumbaugh J (1988). State Trees as Structured Finite State Machines for User Interfaces, Proceedings of ACM SIGGRAPH Symposium on User Interface Software, 17-19 October 1988, 15-29.

Schon D A (1983). The Reflective Practitioner. How Professionals Think in Action. Gower.

Schulert A et al (1985). ADM - A Dialogue Manager. Proceedings of CHI'85, 177-183.

Shepherd A (1989). Analysis and Training in Information Technology Tasks. In Diaper D (ed), Task Analysis for Human Computer Interaction, Ellis Horwood.

Shneiderman B (1982). Multiparty Grammars and Related Features for Designing Interactive Systems. IEEE Systems, Man and Cybernetics., 12, 2, 148-154.

Shneiderman B (1992). Designing the User Interface, 2nd Ed, Addison Wesley 1992.

Singh G and Green M (1991). Automating the lexical and syntactic design of graphical user interfaces: The UofA* UIMS. ACM Transactions on Computer Graphics, Vol 10, No 3, 213-254.

Sufrin B (1982). Formal Specification of a Display-oriented Text Editor. Science of Computer Programming, Vol 3, No 1, 157-202.

Wellner P D (1989). Statemaster: A UIMS Based on Statecharts for Prototyping and Target Implementation. Proceedings of CHI'89, 177-182.