A GENERIC MODEL FOR DIALOG SPECIFICATION Laurence ROUILLE, Patrick BOSC, Alain CHAUFFAUT Campus Universitaire de Beaulieu 35042 RENNES Cedex - FRANCE Telephone: 99 36 20 00 (p. 495) - Telex: 950'173F Telecopy : 99383832 - Network: chauITauirisa.irisa.fr ( Abstract : This article deals with the dialog specification for interactive applications. Most of exist- ing models are based on transition diagrams, but they give too attention to implementation considerations. Therefore, we reconunend a new model completely independent of any im- plcmentation problem. The dialog is broken down into a serics of queries, responses, results. This generic model is the main tool for the dialog specification in EREDlA, a new inte- grated environment for the user interface development of interactive applications. EREDIA discerns three steps: design, which is the definition of the logical dialog, layout which is the translation of the logical dialog into the physical dialog dcdicatcd to an access method and programming which is the integration of thc application functions. EREDIA is a friendliness ( environment, it takes into account the graphical aspects of thc generic model on bit-mapped workstations. Keywords: user interface, user interface managcment system, transition diagrams, graphical specifica- tion 1 Introduction. 2 Analysis of the extant. 2.1 Towards dialog management An interactive application is an application systems. which communicates directly with the user to obtain the data necessary to its execution. Two With the technological improvements in the field of I/O, bit-mapped display, videotex, mouse, ... , parts may be discerned as regards interactive the interactivity between the application and application: the interface which ensures commu- nicatio n between the application and the user, the user has been made more concrete. Its be- and the functions of the application. comes truly a dialog. Nowadays an interactive dialog is a series of basic exchanges constitued The interface serves as a showcase of the ap- with three steps: the application makes a query, plication. A favorable reaction on the user's part the user keys in a reply and then the application garantees success. Its design therefore occupies provides him with a result. The first interfaces a preponderant position. It must be up to users' often allowed applications to be independent of expectations. all management of the physical terminal, by fos- tering a degree of abstraction in communication An application may be used by several kinds by means of the notion of virtual terminal. But of users, beginners or experts, in which case this first stage was not sufficient to ensure a well the interface must be suited to user's knowledge laid-out display. Management tools for elemen- level, without the processing of the application tary dialog exchanges display came into being. having to change. In addition, the application They dealt with the display of query, result, or may be set up on different types of equipment, user responses, by grid management, state edi- thereby influencing its communication with the tors ... Today, another problem has come up the user. Therefore, it is better to provide several coherence in the series of dialog exchanges. interfaces for the same application, whenever It is what dialog management systems try to there is not standardization in the use of the come to grips with. Dialog management sys- application. tems attempt to obtain a entire specification of the dialog. On the one hand, there is the The design of an application is a plmi- syntax of I/O. One may distinguish two spec- disciplinary undertaking, which involves psy- ification levels; concrete syntax (basic commu- chology, ergonomy... Moreover, with the cur- nication display) and abstracted syntax (distin- rent tendency towards optimal exploitation of guished by its application). On the other hand, graphic possibilities with access terminals, con- there is a description of the communication dy- sulting a layout specialist is advisable. Conse- namics between the application and the user. quently, the functional design of the application It is dialog management. From these specifica- and that of the user interface need distinguish- tions, dialog management systems generate the able qualities and will not necessarily be imple- execution core and establish links between the mented by the same persons. interface and the application functions. All the above motives make it essential to dis- tinguish between the development of the inter- 2.2 Presentation of some models face and that of the application functions. The for dialog specification. present article primarily deals with the analysis of methodologies and the development of user The transition diagram were used very at a interface for interactive applications. We then very early date in the specification of interfaces. outline a new development environment, termed We prefer diagrams because they facilate un- SH.SD IA, and based on a generic model for in- derstanding with their graphical representation, terface specification. which is not t.rue of grammars or object-oriented 1 languages. A graphical representation is espe- syntactic analysis of the dialog. They are in- cially worthwhile if a specification model is to be tegrated into the principal diagram, which rep- usable by non-specialists of computer-science. resents the dynamics of the dialog and the ab- "Ve present some examples of models which seem stracted syntax. In their model, the notion of us representative application query is treated superficially. The nodes are more or less classified by the input mode which they expect from the user: key- 2.2.1 Parnas board entry, function key... Parnas [5] was one of the first people who sug- gested a use for command language specifica- 2.2.3 Wasserman tion. These languages infer restricted dialog, the application query is always the same im- In the Wasserman model [6] this notion of query plicit query: "What is your command?". Inter- is explicit. Besides, he does focus solely on com- face specification problems are simplified. Nodes mand languages, but also recommends a broader ( model. Wasserman uses the transition diagram represent the application states. Arcs contain the user response and the application result. to specify the dynamics of dialog exchanges. Through syntact analysis of the conunand, Par- There is no specification of abstracted syntax; he nas determines what terminal operation has to directly favours specification of concrete syntax be run and what the updated state of the ter- with a language for the application and control minal is like. It is a preliminary definition of characters as regards user inputs. His model is the use of diagrams for language specification. oriented towards an inunediately ded uced spec- IIis model is too succinct, but it is a widespread ification production. The operator who uses his reference for the topic. model must prove his competence in all fields involving interface design. His diagram defini- tion is very different from the afore-mentioned. 2.2.2 Kieras and Polson Nodes represent application ouputs, queries and results. Arcs contain user inputs and applica- As a result of their work in the field of com- tion actions. An action is a condition or any mand languages, Kieras and Polson [4] have in- other way of processing the application. He in- dicated that a semantic analysis of the user re- troduces the notion of sub-diagram structuring sponse is essential. Then they added conditions the dialog, as well his model allows a series of to transitions. The application result is defined ouputs, responses, actions to be built. The oper- by the user response, but also by the semantic ator must deliberately use the model to specify interpretation which can be deduced. However, a coherent dialog. For this purpose, the model they do not recommend any method to achieve does not warrant a breakdown of the application a rigorous and coheren t analysis of the user re- dialog in query, user response and application sponse. They recommend a description of the result. theoretical functionning of the condition eval- uation. Several conditions can be true at the same time. They test them one at a time until 2.3 Analysis of the presented reaching an exit node. However, the dialog can models. end up in a dead-lock (no passable route to an ultimate state). Moreover, they added an essen- There is a development of the recommended tial element whenever more important dialogs models through an increasingly more subtle must be specified: that is the sub-diagram. A analysis of the dialog, which approaches the def- sub-diagram can be integrated to several levels inition that has previously been given. However, (condition, action, state). This notion allows they do not solve all the problems brought up them to structure the dialog. In particular, the in the first part of the introduction. We have sub-diagrams are used to carry out the concrete infered the conclusion that for the same appli- 2 calion several interfaces must coexist according eral public interactive applications. EREDIA is lo hard ware, or to the user's experience. By sev- a design for logical dialog completely indepen- eral interfaces, we mean the form which changes dent of physical dialog. As a matter of fact, sev- with regard to the physical display of the dialog eral physical dialogs may refer to a same logical or a mode more or less condensed according to dialog. Lastly, we finish with the perspectives tbe user. Even if the form of the dialog should that offered by our model faced with new work- change, the logic is always the same. In a dialog stations, including multiple windows, as well as two points of view stand out: the logical dia- new designation devices like the mouse, icons... log independent of any implementation problem, and the physical dialog specially dedicated to a material environment and a grade of users. The models that we have studied closely blend the design of the logical dialog and the appearance 3 The generic model. of tbe physical dialog. Only one physical dialog is adapted to a logical dialog. The whole speci- ( The model is concerned with the specification of fication must be revised if the display layout is a dialog composed of basic exchanges. It shows to be changed. This separation is possible with the dynamics process communication and the the model of I\ieras and Polson, but it does not abstracted syntax of dialog. It allows a large seem to be one of their objectives. Moreover, position for the graphical representation of the t.his separation is particularly desirable, because specification. a proper display can be ensured only by a spe- cialist. The recommended models are designed for an immediately deduced specification production. Within this framework, they do not attempt to 3.1 An example of dialog. reason at a sufficiently abstracted level to be used by non-computer scientists. That aside, ';Ve take the example of the interactive applica- the necessary abilities for the specification of an tion (server) "leisures". This server offers the interface are varied and not exclusively comput- user the choice between several services : "cin- erized. The dialog breakdown in term of series ema", "theater", "concert". The function of the of queries, responses, results, is never explicit. service "cinema" is to inform him about the cin- Nevertheless, this definition expands the model ema, timetables, films. To that purpose, the to thereby include the specification of any type user chooses among four criteria of selection: of dialogs. "cinema", "timetable", "filn1", "type". The combinations of these criterions lead to differ- 2.4 Our solution. ent responses. The combination "cinema" and "film" will give the list of the timetables of the Our solution to these problems lies in a generic film for the cinema, "film" and "timetable" all model, which describes the dialogs in terms of the theater where the film is showing at that queries, responses, results, accessible by non- time... The combinations of the two criteria computer scientists. It suits the addition of spe- "film" and "type" lead to an illicit query. For cific informations the description of different as- this purpose, we cannot ask at one and the same pects of the dialog, logical and physical. The ba- time, information about a particular film and sic model is independent of any implementation. type of films. When the list of the responses is We give a description of this model in the chap- displayed to the user, he can interrupt at any ter III. Afterwards, we evoke in the chapter IV time to obtain an abstract of the film, by giving its use in the framework of EREDIA (Environ- the corresponding number. We do not detail the nement de REalisation des DIAlogues) for gen- other services, "theater" and "concert". 3 3.2 The basic dialog exchange. cinema 3.2.1 The questionnaire. theater concert The application query may have different forms, it may be especially implicit as we have already seen in command languages. The application waits for a user request or data. When the di- return alog is guided by the application, it decides to recommend menus to him, or to query him. In ( Figure 1 : The questionnaires some case, both can be combined. For instance (fig. 1), in a menu which gives the user the choice between several leisure activities, he may 3.2.2 The interpretation of the user re- be asked to give the name of the theater at the sponse. ( same time as he gives his selection of a service. Therefore, to each request are associated data The user response consists or a possible request fields which can have possible initial values. A with data. We need a semantic analysis of this questionnaire is composed of a collection of re- response, whatever the type of the dialog con- quests. In particular, when the application puts sidered. The model of Kieras and Polson has a single query to the user, the user request is the brought to the fore the risk of the dialog lock- choice of answering this query. Later on, we in- ing. We want to avoid this at all costs. dicate that it is sometimes interesting to have at The semantic analysis depends on a context: one's disposal a classification of questionnaires, request choice, user's previous data or perma- and to attach a type to the questionnaire. nent application data. This analysis can be more or less complex, that is why we have cho- For instance, the first exchange asks the user sen to break it down into a combination of el- to choose a type of leisure activities. The ques- ementary conditions. This breakdown works in ( tionnaire is called "leisures", its type is "menu" ravour of a methodical analysis, but also assures and it has three requests: "cinema", "theater", us against a possible locking in the dialog. A "concert". Anyone of these three requests needs elementary condition can be written under the a data field. In the second questionnaire the ap- rorm or a boolean function on data. So as to plication asks the user for his criteria of selec- provide always a single true global condition, a l tion. That questionnaire is called" criteria", its solution is a binary tree or the interpretation. A type is "grid" and it has two requests: "selec- boolean function gives back two values" true" tion" which corresponds to giving the criteria and "false", these two possibilities must always and "return" which corresponds to a return to appear in the analysis. Then, there is no locking the first menu. In the first request are asso- in the dialog, the branch with non-conditions ciated four data fields: "cinema", "timetable", is a way out of this situation. On the other "film", "type". \Ne consider that they have no hand, at any given time just one interpretation initial value. On the other hand, the user's op- is thrue, but this seems to us to rerIect reality. tion to interrupt an edition or the result to ask The solution that we come lip with, seems ror an abstract of the film cannot be modelized suitable to us and not too impractical, as can by a questionnaire. We will come back to this be seen rrom its application to the example. problem subsequently. In the example, the choices or the requests or 4 the firs! questionnaire do not need particular in- messages such as "the query is illicit" or "there terpretat ion. To this purpose, we do not ask the is no response", but also the display of a list of user for data and we do not consider that the re- data, when there are responses. quests depend on certain context, like the num- ber of times the user has demanded this service 3.3 The dialog. during a session... On the other hand, the "se- lection" request of the "criteria" questionnaire 3.3.1 The start questionnaire. necds an interpretation of data provided by the This is the starting point of the diagram, it cor- user, to determine what the new actionis and responds to a singlc fictitious questionnaire. It the pursuit of dialog. The user has the possibil- is defined by an identifier and a request which ity of entering four data "cinema", "timetable", corresponds to thc user's wish to conned to the "film", "type". Nevertheless, the combination server. The request can have several interpre- of the fields "film" and "type" leads to an illicit tations, if there are several contexts of connec- qucry. In this case, we must vcrify if this com- tion: proprieties linkcd to a user, connection bination exists, and if the contrary were true, consider if there are responses to satisfy the re- constraints ... The start questionnaire is sym- bolized by a square. qucst of the user. In this example (fig. 2), there are five possibilities, that we can translate into the conjunctions of following boolean functions: 3.3.2 Dialog pursual. film (F) and t.ypc(T) Once the application has answered the user re- fum (F) and no (type(T)} and responses (C, 1-1, P, T) quest, the dialog goes on through another basic film (F) and no (type(T» and no (responses (C, H, dialog exchange, or stops. It is a statically dcter- F, T» no (film (F)) and responses (C, H, F, T) mined continuation of dialog. It is graphically no (flhn ([0'» and no (responses (e, H, P, 'I) modelized by the link of a result object with a state object. So, we have the previously desirable binary We have added some dynamic dialog pursuits tree, so that there is no locking in the function- (fig. 3). "Ve do not find thcm in the other mod- ning of the diagram. els. film(F) 'ypo(T) We have introduced the typed-return which is worthwhile when several paths in the diagram ~ 'ype(T) rcspOllSC( C, 1-1, F,T) lead to a same state. If a return to an anterior questionnaire is desired, which depends on the ( ..., respollse(C,H,F,T) path followed by the user, it is better to indicate just the type of the questionnaire. On exccution ~ film(F) rcsponsc(C,H,F,T) of the last questionnaire put to the user, which has the type required by the typed-return, will ( -. respollsc(C,H,F,Tl be the new state. In the example we have given Figure 2 : Interpretation of multi-criteria in types to questionnaires: " menu" , "grid"... but the" leisure" server there is no restriction to the classification of the questionnaires. A typed-return is determined by the type of the questionnaire. It is symbolized 3.2.3 The result. on the diagram by a hexagon. An interpretation of the response of the user The second element we have introduced, is the leads to a result of the application. The result is event-salvage. The elements that we have given composed of two parts: processing and edition. up to now partly allow us to deal with the sys- It is symbolized by a segment. tem events. A system event can be treated as a In the intcrpretations of thc "selection" re- particular request of the questionnaire or as an quest, the results are the sending of warnll1g additional level of the interpretation of the user 5 response. A event salvage enables taking into In the example (fig. 4), we can assume that account a system event during the display of a there are three sub-dialogs: "cinema", "the- result. ater" and "concert". There are two possible out- A event-salvage is defined by an ident and by puts for each sub-dialog, we can come back to the set of events. An event is defined as a re- the first questionnaire to choose a new servIce quest. The event-salvage is symbolized by an or stop the dialog. oval. cinema rcsearch cinema }--- +jlYPCj )----_~_-< slop Figure 4: The integrated "cinema" sub-dialog ( e- . . 3.3.5 in the principal dialog A particular result: intervention. Intervention is an original element in our model. It is a particular result, used for editions liable evll to be long. In this case, the application stays ( open to the user. The long editions can be cut into elementary results. That cutting up serves as a landmark for the application, which is in- formed of a possible intervention of the user as soon as the latter receives an elementary result. Figure 3 : The dynamic dialog pursual If the user does not intervene, the next result is displayed. In this particular case, the user has 3.3.3 The final mark. a condensed version of the results. Any inter- This means the end of the dialogs. It can be vention of the user except a display stop request duplicated on the diagram. It is characterized is a digression of the edition (a sub-dialog). At by an identifier and symbolized by a triangle. the output of this sub-dialog, the iteration of the edition goes on, or can be abandon ned ac- cording to different contexts. In an intervention, 3.3.4 The sub-dialog. the iteration is not disturbed at each edition of This is a concept that we find in all models. an elementary result to put a query explicitly Beyond their methodical aspect, the sub-dialogs to the user. The user knows the requests which by allowing concision in writing contribute to an are possible. During an intervention, it is the improvement in the legibility of the diagram. user who has the initiative of putting a request. A sub-dialog can be composed of all the el- Intervention is a possibility in the dialog, which \ ements of the model; it can especially call an- is not already feasible to implement. It depends other sub-dialog. The difference between a prin- on the access method available. cipal dialog and a sub-dialog is that for the lat- User interventions are definyed in a manner ter there may be several output contexts. The similar to the requests of a questionnaire. In all final marks possess moreover semantic informa- cases, there is a standard request which is" non- tion. A sub-dialog is a pseudo-questionnaire at intervention". We associate a cutting up of the the level of principal dialog. That's why it has edition with an intervention. The intervention requests (or pseudo-requests) which are its fi- is modelized by a rhombus. nal marks. They can be interpreted according In the example (fig. 5), the intervention has, to the context of the principal dialog. A sub- as well as the standard request the request" ab- dialog is symbolized by a rectangle at the level stract" which has a data field, the number of the of a diagram. film "number", and a request "stop". G The notion of logic in the series of exchanges -. inlerv. response is not always perceptible, because the number display of scenarios is too vaste. Our model seems less -.response adapted to the specification of this type of di- alog. We obtain very important diagrams, but .\bslracl it is not without interesting. As a matter of abslracl display fact, the notion of series is still presen t; all the slop possible actions of the user are not continuously Figure 5 : The intervention permitted. The multiple windows allow parallelism at physicallfO device level and at the level of given 3.4 Conclusion. services by the application, which then can be Our model gives the possibility of specifying all used simultaneously. We have not looked for dialogs in term of query, response, result. It this new possible aspect of the dialog. We think docs not refer to any computerized pre-requisite it is important to study the possibilities of our and so it is easily accessible to non-computer model to solve this problem. experts. Moreover, it is independent of any problem of implementation, presentation or pro- 4 Uses of the model. grammll1g. ( Our model is an extension of transition dia- grams, representation of finite state machines. 4.1 The uses in EREDIA. We have modified the structure, but neverthe- We now consider the use of the model In the less there are analogies. In the transi tion di- framework of EREDIA, [1], [2J. EREDIA rec- agrams, a node represents a state of the ma- ommend to develop an interactive application chine and a transition allows the passage from around the definition of its dialogs with the user. one state to another, it has an input and an Therein, EREDIA discerns three phases in the output. For us, it is not a question of consider- development of an interactive application: de- ing the states of the machine any more, however sign of the logical dialog, layout( definition of the we can recognize some points in the dialog as real dialog) and the programming. These three being steps in the dialog user. At these steps, steps of the development are entrusted to ex- the user has the possibility of intervening, or perts: the designer, the model maker, and the these are radical changements in the dialog. In programmer. Although all three work on the our model, we have assimilated some elements same dialog, but they have not the same per- as being states of dialog. These are the question- ception, because they have not the same inter- naires, the interventions, the sub-dialogs, but est. Later on, we going indicate how the same also the start questionnaire, the final marks, the model can be used for the specification of dialogs event-salvages and the typed-returns. We can for the three operators. The model is a core. say that we have broken down the transition di- Supplementary specifications must be added to agrams into three elements: the request, the elements, to specialize the model in the descrip- interpretation and the result. tion of a particular aspect of the dialog. Having The dialogs which can be studied with our a basic model is interesting: it allows a com- model are numerous and various; dialogs of munication between the different operators, who query fresponse, command languages and why have then the same references to work from. not object-oriented dialogs. These last types of dialogs are user initiative. This is a capital The conceptual schema. 4.2 feature which may modify the design of the in- terface. The user has at a given time a lot of The conceptual schema must account for the possibilities, because he can direct of the dialog. logical dialog between the application and the 7 user, without being preoccupied with any phys- envoi = theater. .. ) supplementary interpreta- ical representation of the exchanges. It presents tion levels are created. Moreover, the choice of their semantics. It is the first of the three an access method (terminal management) adds schemas which is established and it is therefore some secondary exchanges to the principal dia- the reference through the development of the ap- log descri bed by the designer. For instance, in plication. the case of videotex access methods, every func- Designing a conceptual schema reverts to find- tion key must be affected to at least one action. ing what the exchanges between the applica- In addition, a presentation format must be tion and the user are. It means indicating joined to every questionnaire and to every re- what the characteristics of the questionnaires sult. The model such as it is defined docs not are, suggesting a set of requests, putting queries, integrate elements of presentation specification. analysing the user responses and the application According to the possible complexity of the pre- results. There is neither reference to the ex- sentation it is certainly desirable to dispose of changes presentation, nor to the programming a specification language, which gives a direct ( of the interpretations and application results. view. For instance, in EREDIA there is the LCF It is the approach which has been presented all (Langage de Composition de Formats) to spec- through the model description with the presen- ify videotex pages [31. tation of examples. 4.4 The programming schema. 4.3 The presentation schema. For each presentation schema corresponds a pro- From this conceptual schema, several schemas grarruning schema. It is an extension of the pre- of presentation can be deduced, wbich integrate sentation schema to which we add routines to physical attentions on the dialog. There may elements, state routine, interpretation routine, be several representations, because there can be result routine. The programming of the core of different types of available equipment or several the application is deduced from the program- kinds of users to satisfy and who do not expect ming schema. The programmer must give in the same characteristics from an interface. addition subroutines for the functions of the ap- Changing from the conceptual schema to a plication. presentation schema consists of a translation of logical exchanges into physical exchanges ac- 4.5 The help of EREDIA III the counting for the real dialog between the applica- specification tion and the user. Therefore, there is a modifi- cation of the structure of the conceptual schema, EREDIA recommends a set of integrated tools elements are added and the specifications of the and methodologies for the development of an in- elements are completed. This transformation teractive application. The friendliness in ERE- is carried out in two parts. First, there is a DIA shows itself through several choices: bit- translation of conceptual requests into physical map workstations, a graphical specification of requests. In the example, for the first ques- dialog by "graphical echo", dialogs with the op- tionnaire the user has the choice between three erator through a set of adapted menus according requests: "cinema" l "theater", "concert". He to the operator's work ... The graphical echo is can have access to these requests in different a new concept totally different from computer manners according to the choice of the model aided drawing tools. The operator builds the maker; by typing a number between 1 and 4 interface in the concrete terms of dialog: ques- or the iden t of the request, by using function tion, response, result. EREDIA gives him back keys, by clicking in a menu ... If for a same func- a graphical echo of his specifications in the form tion key, there are several values to determine of a diagram. The graphical echo has several a choice of request, (1 + envoi = Cinema, 2 + advantages. It J'reseves in all cases a lisible 8 drawing; the elements are placed according to is simple and does not refer to any computerized rules. It allows for the interactive verification knowledge. of some of the consistency properties of the dia- On the other hand, the model must allow gram. EREDIA runs a checking process and can for the specification of different viewpoints of lead the specifications of the operator, by refus- the dialog while preserving a coherence. In our ing hi m incorrect choices. Lastly, for a same opinion, it achieves its purpose being an generic dialog between EREDIA and the operator, we model independent of any implementation prob- can have several forms of echos adapted to the lem, to which some elements of textual specifi- operator. cation must be added to specialize it. Up to now, the model has been principally used to specify query/response dialogs of video- 4.6 Conclusion. tex application in the framework of EREDIA. We have presented an use of our model in the However, we think that its definition allows framework of the EREDIA environment. We the more general specification of any dialog develop a prototype of EREDIA on SPS7/BULL (query, response, result), in which the series of with a bit-mapped workstation. But as we have exchanges need a description. Its modularity just shown the model is sufficiently broad to be makes it easilly adaptable for applications of integrated to another context of use. We simply which the presentation differs from this one for have to change the textual specifications linked the videotex applications. Thus, it is the speci- to each element. fication of I/O languages which evolves, but the design of logical dialog, is always the same. 5 Conclusion. References The separation between the user interface and [1] Patrick BOSC, Alain CHAUFFAUT, and the functions of the application is one of essen- Bertrand HARDY. EREDIA: a system tial guidelines for the design of interactive ap- to develop servers including text process- plication. We have particulary focused on the ing technics. In PROTEXT IT (BOOLE problem of the user interface development. An PRESS LIMITED), pages 133-144, 2nd In- interactive dialog is a series of basic exchanges, ternational Conference on Text Processing which consists of three components: the appli- Systems, Dublin, 23-25 october 1985. cation query, the user response and the applica- tion result. The interfaces management systems [2] Bruno CHERON and Laurence ROUILLE. fit together to give a coherence in the series of a Etude et realisation d'outils d'aide la spec- exchanges. The basis to put this guideline into ification graphique pOll!' Ie concepteu1' ct Ie practice is to dispose of a specification model of progmmmeul' de I'atelie/' EREDJA. DEA the conununication dynamics. Report, University of RENNES I, september ( First, the model has to be understood and 1985. used by non computer experts. This is the prin- [3J Christian COUEPEL and Colette TAN- cipal motivation that made us choose a graphical GUY. EVA: Le Logiciel de Composition representation with our extension of the transi- de F01'mats. Technical Report 78, INRIA - tion diagrams. The originality of our model lies RENNES, februar 1987. in the transitions represented by the tree-like arcs and the addition of new elements to extend [4] David KIERAS and Peter G. POLSON. A the power of the diagrams, such as typed-return, generalized transition network - represen- intervention, event-salvage. tation for interactive systems. In Proceed- On the one hand, our definition of the dialog, ings of CHI'83, Human Factors in Computet' (questionnaire, response-interpretation, result), Systems, pages 103-106, 1983. 9 [5] David L. PARNAS. On the use of transition diagrams in the design of a user interface for an interactive computer system. Proc. 24th National Confel'ence A CM, 379-383, 1969. [6] Anthony 1. WASSERMAN. Extending state transition diagrams for the spec- ification of human-computer interaction. IEEE Transaction on Software Enginee7'ing, SE.ll(8):699-712, august 1985. ( I, 10