(

(

A GENERIC MODELFOR DIALOG SPECIFICATION

Laurence ROUILLE, Patrick BOSC, Alain CHAUFFAUT

Campus Universitaire de Beaulieu35042 RENNES Cedex - FRANCETelephone: 99 36 20 00 (p. 495) - Telex: 950'173FTelecopy : 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 implementationconsiderations. 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. EREDIAdiscerns three steps: design, which is the definition of the logical dialog, layout which is thetranslation of the logical dialog into the physical dialog dcdicatcd to an access method andprogramming which is the integration of thc application functions. EREDIA is a friendlinessenvironment, it takes into account the graphical aspects of thc generic model on bit-mappedworkstations.

Keywords:user interface, user interface managcment system, transition diagrams, graphical specifica­tion

1 Introduction. 2 Analysis of the extant.

An interactive application is an applicationwhich communicates directly with the user toobtain the data necessary to its execution. Twoparts may be discerned as regards interactiveapplication: the interface which ensures commu­nicatio n between the application and the user,and the functions of the application.

The interface serves as a showcase of the ap­plication. A favorable reaction on the user's partgarantees success. Its design therefore occupiesa preponderant position. It must be up to users'expectations.

An application may be used by several kindsof users, beginners or experts, in which casethe interface must be suited to user's knowledgelevel, without the processing of the applicationhaving to change. In addition, the applicationmay be set up on different types of equipment,thereby influencing its communication with theuser. Therefore, it is better to provide severalinterfaces for the same application, wheneverthere is not standardization in the use of theapplication.

The design of an application is a plmi­disciplinary undertaking, which involves psy­chology, ergonomy... Moreover, with the cur­rent tendency towards optimal exploitation ofgraphic possibilities with access terminals, con­sulting a layout specialist is advisable. Conse­quently, the functional design of the applicationand that of the user interface need distinguish­able qualities and will not necessarily be imple­mented by the same persons.

All the above motives make it essential to dis­tinguish between the development of the inter­face and that of the application functions. Thepresent article primarily deals with the analysisof methodologies and the development of userinterface for interactive applications. We thenoutline a new development environment, termedSH.SD IA, and based on a generic model for in­terface specification.

1

2.1 Towards dialog managementsystems.

With the technological improvements in the fieldof I/O, bit-mapped display, videotex, mouse, ... ,the interactivity between the application andthe user has been made more concrete. Its be­comes truly a dialog. Nowadays an interactivedialog is a series of basic exchanges constituedwith three steps: the application makes a query,the user keys in a reply and then the applicationprovides him with a result. The first interfacesoften allowed applications to be independent ofall management of the physical terminal, by fos­tering a degree of abstraction in communicationby means of the notion of virtual terminal. Butthis first stage was not sufficient to ensure a welllaid-out display. Management tools for elemen­tary dialog exchanges display came into being.They dealt with the display of query, result, oruser responses, by grid management, state edi­tors ... Today, another problem has come up thecoherence in the series of dialog exchanges.

It is what dialog management systems try tocome to grips with. Dialog management sys­tems attempt to obtain a entire specificationof the dialog. On the one hand, there is thesyntax of I/O. One may distinguish two spec­ification levels; concrete syntax (basic commu­nication display) and abstracted syntax (distin­guished by its application). On the other hand,there is a description of the communication dy­namics between the application and the user.It is dialog management. From these specifica­tions, dialog management systems generate theexecution core and establish links between theinterface and the application functions.

2.2 Presentation of some modelsfor dialog specification.

The transition diagram were used very at avery early date in the specification of interfaces.We prefer diagrams because they facilate un­derstanding with their graphical representation,which is not t.rue of grammars or object-oriented

(

languages. A graphical representation is espe­cially worthwhile if a specification model is to beusable by non-specialists of computer-science."Ve present some examples of models which seemus representative

2.2.1 Parnas

Parnas [5] was one of the first people who sug­gested a use for command language specifica­tion. These languages infer restricted dialog,the application query is always the same im­plicit query: "What is your command?". Inter­face specification problems are simplified. Nodesrepresent the application states. Arcs containthe user response and the application result.Through syntact analysis of the conunand, Par­nas determines what terminal operation has tobe run and what the updated state of the ter­minal is like. It is a preliminary definition ofthe use of diagrams for language specification.IIis model is too succinct, but it is a widespreadreference for the topic.

2.2.2 Kieras and Polson

As a result of their work in the field of com­mand languages, Kieras and Polson [4] have in­dicated that a semantic analysis of the user re­sponse is essential. Then they added conditionsto transitions. The application result is definedby the user response, but also by the semanticinterpretation which can be deduced. However,they do not recommend any method to achievea rigorous and coheren t analysis of the user re­sponse. They recommend a description of thetheoretical functionning of the condition eval­uation. Several conditions can be true at thesame time. They test them one at a time untilreaching an exit node. However, the dialog canend up in a dead-lock (no passable route to anultimate state). Moreover, they added an essen­tial element whenever more important dialogsmust be specified: that is the sub-diagram. Asub-diagram can be integrated to several levels(condition, action, state). This notion allowsthem to structure the dialog. In particular, thesub-diagrams are used to carry out the concrete

2

syntactic analysis of the dialog. They are in­tegrated into the principal diagram, which rep­resents the dynamics of the dialog and the ab­stracted syntax. In their model, the notion ofapplication query is treated superficially. Thenodes are more or less classified by the inputmode which they expect from the user: key­board entry, function key...

2.2.3 Wasserman

In the Wasserman model [6] this notion of queryis explicit. Besides, he does focus solely on com­mand languages, but also recommends a broadermodel. Wasserman uses the transition diagramto specify the dynamics of dialog exchanges.There is no specification of abstracted syntax; hedirectly favours specification of concrete syntaxwith a language for the application and controlcharacters as regards user inputs. His model isoriented towards an inunediately ded uced spec­ification production. The operator who uses hismodel must prove his competence in all fieldsinvolving interface design. His diagram defini­tion is very different from the afore-mentioned.Nodes represent application ouputs, queries andresults. Arcs contain user inputs and applica­tion actions. An action is a condition or anyother way of processing the application. He in­troduces the notion of sub-diagram structuringthe dialog, as well his model allows a series ofouputs, responses, actions to be built. The oper­ator must deliberately use the model to specifya coherent dialog. For this purpose, the modeldoes not warrant a breakdown of the applicationdialog in query, user response and applicationresult.

2.3 Analysis of the presentedmodels.

There is a development of the recommendedmodels through an increasingly more subtleanalysis of the dialog, which approaches the def­inition that has previously been given. However,they do not solve all the problems brought upin the first part of the introduction. We haveinfered the conclusion that for the same appli-

(

An example of dialog.

The generic model.

eral public interactive applications. EREDIA isa design for logical dialog completely indepen­dent of physical dialog. As a matter of fact, sev­eral physical dialogs may refer to a same logicaldialog. Lastly, we finish with the perspectivesthat offered by our model faced with new work­stations, including multiple windows, as well asnew designation devices like the mouse, icons...

3.1

The model is concerned with the specification ofa dialog composed of basic exchanges. It showsthe dynamics process communication and theabstracted syntax of dialog. It allows a largeposition for the graphical representation of thespecification.

';Ve take the example of the interactive applica­tion (server) "leisures". This server offers theuser the choice between several services : "cin­ema", "theater", "concert". The function of theservice "cinema" is to inform him about the cin­ema, timetables, films. To that purpose, theuser chooses among four criteria of selection:"cinema", "timetable", "filn1", "type". Thecombinations of these criterions lead to differ­ent responses. The combination "cinema" and"film" will give the list of the timetables of thefilm for the cinema, "film" and "timetable" allthe theater where the film is showing at thattime... The combinations of the two criteria"film" and "type" lead to an illicit query. Forthis purpose, we cannot ask at one and the sametime, information about a particular film andtype of films. When the list of the responses isdisplayed to the user, he can interrupt at anytime to obtain an abstract of the film, by givingthe corresponding number. We do not detail theother services, "theater" and "concert".

Our solution.2.4

Our solution to these problems lies in a genericmodel, which describes the dialogs in terms ofqueries, responses, results, accessible by non­computer scientists. It suits the addition of spe­cific informations the description of different as­pects of the dialog, logical and physical. The ba­sic model is independent of any implementation.We give a description of this model in the chap­ter III. Afterwards, we evoke in the chapter IVits use in the framework of EREDIA (Environ­nement de REalisation des DIAlogues) for gen-

calion several interfaces must coexist accordinglo hard ware, or to the user's experience. By sev­eral interfaces, we mean the form which changeswith regard to the physical display of the dialogor a mode more or less condensed according totbe user. Even if the form of the dialog shouldchange, the logic is always the same. In a dialogtwo points of view stand out: the logical dia­log independent of any implementation problem,and the physical dialog specially dedicated to amaterial environment and a grade of users. Themodels that we have studied closely blend thedesign of the logical dialog and the appearance 3of tbe physical dialog. Only one physical dialogis adapted to a logical dialog. The whole speci­fication must be revised if the display layout isto be changed. This separation is possible withthe model of I\ieras and Polson, but it does notseem to be one of their objectives. Moreover,t.his separation is particularly desirable, becausea proper display can be ensured only by a spe­cialist.

The recommended models are designed for animmediately deduced specification production.Within this framework, they do not attempt toreason at a sufficiently abstracted level to beused by non-computer scientists. That aside,the necessary abilities for the specification of aninterface are varied and not exclusively comput­erized. The dialog breakdown in term of seriesof queries, responses, results, is never explicit.Nevertheless, this definition expands the modelto thereby include the specification of any typeof dialogs.

3

(

(

(

l

3.2 The basic dialog exchange.

3.2.1 The questionnaire.

The application query may have different forms,it may be especially implicit as we have alreadyseen in command languages. The applicationwaits for a user request or data. When the di­alog is guided by the application, it decides torecommend menus to him, or to query him. Insome case, both can be combined. For instance(fig. 1), in a menu which gives the user thechoice between several leisure activities, he maybe asked to give the name of the theater at thesame time as he gives his selection of a service.Therefore, to each request are associated datafields which can have possible initial values. Aquestionnaire is composed of a collection of re­quests. In particular, when the application putsa single query to the user, the user request is thechoice of answering this query. Later on, we in­dicate that it is sometimes interesting to have atone's disposal a classification of questionnaires,and to attach a type to the questionnaire.

For instance, the first exchange asks the userto choose a type of leisure activities. The ques­tionnaire is called "leisures", its type is "menu"and it has three requests: "cinema", "theater","concert". Anyone of these three requests needsa data field. In the second questionnaire the ap­plication asks the user for his criteria of selec­tion. That questionnaire is called" criteria", itstype is "grid" and it has two requests: "selec­tion" which corresponds to giving the criteriaand "return" which corresponds to a return tothe first menu. In the first request are asso­ciated four data fields: "cinema", "timetable","film", "type". \Ne consider that they have noinitial value. On the other hand, the user's op­tion to interrupt an edition or the result to askror an abstract of the film cannot be modelizedby a questionnaire. We will come back to thisproblem subsequently.

4

cinema

theater

concert

return

Figure 1 : The questionnaires

3.2.2 The interpretation of the user re­sponse.

The user response consists or a possible requestwith data. We need a semantic analysis of thisresponse, whatever the type of the dialog con­sidered. The model of Kieras and Polson hasbrought to the fore the risk of the dialog lock­ing. We want to avoid this at all costs.

The semantic analysis depends on a context:request choice, user's previous data or perma­nent application data. This analysis can bemore or less complex, that is why we have cho­sen to break it down into a combination of el­ementary conditions. This breakdown works inravour of a methodical analysis, but also assuresus against a possible locking in the dialog. Aelementary condition can be written under therorm or a boolean function on data. So as toprovide always a single true global condition, asolution is a binary tree or the interpretation. Aboolean function gives back two values" true"and "false", these two possibilities must alwaysappear in the analysis. Then, there is no lockingin the dialog, the branch with non-conditionsis a way out of this situation. On the otherhand, at any given time just one interpretationis thrue, but this seems to us to rerIect reality.

The solution that we come lip with, seemssuitable to us and not too impractical, as canbe seen rrom its application to the example.

In the example, the choices or the requests or

the firs! questionnaire do not need particular in­terpretat ion. To this purpose, we do not ask theuser for data and we do not consider that the re­quests depend on certain context, like the num­ber of times the user has demanded this serviceduring a session... On the other hand, the "se­lection" request of the "criteria" questionnairenecds an interpretation of data provided by theuser, to determine what the new actionis andthe pursuit of dialog. The user has the possibil­ity of entering four data "cinema", "timetable","film", "type". Nevertheless, the combinationof the fields "film" and "type" leads to an illicitqucry. In this case, we must vcrify if this com­bination exists, and if the contrary were true,consider if there are responses to satisfy the re­qucst of the user. In this example (fig. 2), thereare five possibilities, that we can translate intothe conjunctions of following boolean functions:

film (F) and t.ypc(T)fum (F) and no (type(T)} and responses (C, 1-1, P,T)film (F) and no (type(T» and no (responses (C, H,F, T»no (film (F)) and responses (C, H, F, T)no (flhn ([0'» and no (responses (e, H, P, 'I)

So, we have the previously desirable binarytree, so that there is no locking in the function­ning of the diagram.

film(F) 'ypo(T)

~ 'ype(T) rcspOllSC( C, 1-1,F,T)

..., respollse(C,H,F,T)

~ film(F) rcsponsc(C,H,F,T)

-. respollsc(C,H,F,Tl

Figure 2 : Interpretation of multi-criteria inthe" leisure" server

3.2.3 The result.

An interpretation of the response of the userleads to a result of the application. The result iscomposed of two parts: processing and edition.It is symbolized by a segment.

In the intcrpretations of thc "selection" re­quest, the results are the sending of warnll1g

5

messages such as "the query is illicit" or "thereis no response", but also the display of a list ofdata, when there are responses.

3.3 The dialog.

3.3.1 The start questionnaire.

This is the starting point of the diagram, it cor­responds to a singlc fictitious questionnaire. Itis defined by an identifier and a request whichcorresponds to thc user's wish to conned to theserver. The request can have several interpre­tations, if there are several contexts of connec­tion: proprieties linkcd to a user, connectionconstraints ... The start questionnaire is sym­bolized by a square.

3.3.2 Dialog pursual.

Once the application has answered the user re­quest, the dialog goes on through another basicdialog exchange, or stops. It is a statically dcter­mined continuation of dialog. It is graphicallymodelized by the link of a result object with astate object.

We have added some dynamic dialog pursuits(fig. 3). "Ve do not find thcm in the other mod­els.

We have introduced the typed-return which isworthwhile when several paths in the diagramlead to a same state. If a return to an anteriorquestionnaire is desired, which depends on thepath followed by the user, it is better to indicatejust the type of the questionnaire. On exccutionof the last questionnaire put to the user, whichhas the type required by the typed-return, willbe the new state. In the example we have giventypes to questionnaires: " menu" , "grid"... butthere is no restriction to the classification of thequestionnaires. A typed-return is determined bythe type of the questionnaire. It is symbolizedon the diagram by a hexagon.

The second element we have introduced, is theevent-salvage. The elements that we have givenup to now partly allow us to deal with the sys­tem events. A system event can be treated as aparticular request of the questionnaire or as anadditional level of the interpretation of the user

(

(

In the example (fig. 4), we can assume thatthere are three sub-dialogs: "cinema", "the­ater" and "concert". There are two possible out­puts for each sub-dialog, we can come back tothe first questionnaire to choose a new servIceor stop the dialog.

response. A event salvage enables taking intoaccount a system event during the display of aresult.

A event-salvage is defined by an ident and bythe set of events. An event is defined as a re­quest. The event-salvage is symbolized by anoval.

}--- +jlYPCj )----_~_-<

cinemacinema

rcsearch

slop

(

(

\

e- ...evll

Figure 3 : The dynamic dialog pursual

3.3.3 The final mark.

This means the end of the dialogs. It can beduplicated on the diagram. It is characterizedby an identifier and symbolized by a triangle.

3.3.4 The sub-dialog.

This is a concept that we find in all models.Beyond their methodical aspect, the sub-dialogsby allowing concision in writing contribute to animprovement in the legibility of the diagram.

A sub-dialog can be composed of all the el­ements of the model; it can especially call an­other sub-dialog. The difference between a prin­cipal dialog and a sub-dialog is that for the lat­ter there may be several output contexts. Thefinal marks possess moreover semantic informa­tion. A sub-dialog is a pseudo-questionnaire atthe level of principal dialog. That's why it hasrequests (or pseudo-requests) which are its fi­nal marks. They can be interpreted accordingto the context of the principal dialog. A sub­dialog is symbolized by a rectangle at the levelof a diagram.

G

Figure 4: The integrated "cinema" sub-dialogin the principal dialog

3.3.5 A particular result: intervention.

Intervention is an original element in our model.It is a particular result, used for editions liableto be long. In this case, the application staysopen to the user. The long editions can be cutinto elementary results. That cutting up servesas a landmark for the application, which is in­formed of a possible intervention of the user assoon as the latter receives an elementary result.If the user does not intervene, the next result isdisplayed. In this particular case, the user hasa condensed version of the results. Any inter­vention of the user except a display stop requestis a digression of the edition (a sub-dialog). Atthe output of this sub-dialog, the iteration ofthe edition goes on, or can be abandonned ac­cording to different contexts. In an intervention,the iteration is not disturbed at each edition ofan elementary result to put a query explicitlyto the user. The user knows the requests whichare possible. During an intervention, it is theuser who has the initiative of putting a request.Intervention is a possibility in the dialog, whichis not already feasible to implement. It dependson the access method available.

User interventions are definyed in a mannersimilar to the requests of a questionnaire. In allcases, there is a standard request which is" non­intervention". We associate a cutting up of theedition with an intervention. The interventionis modelized by a rhombus.

In the example (fig. 5), the intervention has,as well as the standard request the request" ab­stract" which has a data field, the number of thefilm "number", and a request "stop".

(

thethe

The uses in EREDIA.

The conceptual schema.

Uses of the model.

The conceptual schema must account forlogical dialog between the application and

The notion of logic in the series of exchangesis not always perceptible, because the numberof scenarios is too vaste. Our model seems lessadapted to the specification of this type of di­alog. We obtain very important diagrams, butit is not without interesting. As a matter offact, the notion of series is still presen t; all thepossible actions of the user are not continuouslypermitted.

The multiple windows allow parallelism atphysicallfO device level and at the level of givenservices by the application, which then can beused simultaneously. We have not looked forthis new possible aspect of the dialog. We thinkit is important to study the possibilities of ourmodel to solve this problem.

We now consider the use of the model In theframework of EREDIA, [1], [2J. EREDIA rec­ommend to develop an interactive applicationaround the definition of its dialogs with the user.Therein, EREDIA discerns three phases in thedevelopment of an interactive application: de­sign of the logical dialog, layout(definition of thereal dialog) and the programming. These threesteps of the development are entrusted to ex­perts: the designer, the model maker, and theprogrammer. Although all three work on thesame dialog, but they have not the same per­ception, because they have not the same inter­est. Later on, we going indicate how the samemodel can be used for the specification of dialogsfor the three operators. The model is a core.Supplementary specifications must be added toelements, to specialize the model in the descrip­tion of a particular aspect of the dialog. Havinga basic model is interesting: it allows a com­munication between the different operators, whohave then the same references to work from.

4.1

4.2

display

-.response

abslracl display

response-. inlerv.

slop

.\bslracl

Figure 5 : The intervention

Conclusion.3.4

Our model gives the possibility of specifying alldialogs in term of query, response, result. Itdocs not refer to any computerized pre-requisiteand so it is easily accessible to non-computerexperts. Moreover, it is independent of anyproblem of implementation, presentation or pro- 4grammll1g.

Our model is an extension of transition dia­grams, representation of finite state machines.We have modified the structure, but neverthe­less there are analogies. In the transi tion di­agrams, a node represents a state of the ma­chine and a transition allows the passage fromone state to another, it has an input and anoutput. For us, it is not a question of consider­ing the states of the machine any more, howeverwe can recognize some points in the dialog asbeing steps in the dialog user. At these steps,the user has the possibility of intervening, orthese are radical changements in the dialog. Inour model, we have assimilated some elementsas being states of dialog. These are the question­naires, the interventions, the sub-dialogs, butalso the start questionnaire, the final marks, theevent-salvages and the typed-returns. We cansay that we have broken down the transition di­agrams into three elements: the request, theinterpretation and the result.

The dialogs which can be studied with ourmodel are numerous and various; dialogs ofqueryfresponse, command languages and whynot object-oriented dialogs. These last typesof dialogs are user initiative. This is a capitalfeature which may modify the design of the in­terface. The user has at a given time a lot ofpossibilities, because he can direct of the dialog.

7

(

user, without being preoccupied with any phys­ical representation of the exchanges. It presentstheir semantics. It is the first of the threeschemas which is established and it is thereforethe reference through the development of the ap­plication.

Designing a conceptual schema reverts to find­ing what the exchanges between the applica­tion and the user are. It means indicatingwhat the characteristics of the questionnairesare, suggesting a set of requests, putting queries,analysing the user responses and the applicationresults. There is neither reference to the ex­changes presentation, nor to the programmingof the interpretations and application results.It is the approach which has been presented allthrough the model description with the presen­tation of examples.

4.3 The presentation schema.

From this conceptual schema, several schemasof presentation can be deduced, wbich integratephysical attentions on the dialog. There maybe several representations, because there can bedifferent types of available equipment or severalkinds of users to satisfy and who do not expectthe same characteristics from an interface.

Changing from the conceptual schema to apresentation schema consists of a translation oflogical exchanges into physical exchanges ac­counting for the real dialog between the applica­tion and the user. Therefore, there is a modifi­cation of the structure of the conceptual schema,elements are added and the specifications of theelements are completed. This transformationis carried out in two parts. First, there is atranslation of conceptual requests into physicalrequests. In the example, for the first ques­tionnaire the user has the choice between threerequests: "cinema" l "theater", "concert". Hecan have access to these requests in differentmanners according to the choice of the modelmaker; by typing a number between 1 and 4or the iden t of the request, by using functionkeys, by clicking in a menu ... If for a same func­tion key, there are several values to determinea choice of request, (1 + envoi = Cinema, 2 +

8

envoi = theater. .. ) supplementary interpreta­tion levels are created. Moreover, the choice ofan access method (terminal management) addssome secondary exchanges to the principal dia­log descri bed by the designer. For instance, inthe case of videotex access methods, every func­tion key must be affected to at least one action.

In addition, a presentation format must bejoined to every questionnaire and to every re­sult. The model such as it is defined docs notintegrate elements of presentation specification.According to the possible complexity of the pre­sentation it is certainly desirable to dispose ofa specification language, which gives a directview. For instance, in EREDIA there is the LCF(Langage de Composition de Formats) to spec­ify videotex pages [31.

4.4 The programming schema.

For each presentation schema corresponds a pro­grarruning schema. It is an extension of the pre­sentation schema to which we add routines toelements, state routine, interpretation routine,result routine. The programming of the core ofthe application is deduced from the program­ming schema. The programmer must give inaddition subroutines for the functions of the ap­plication.

4.5 The help of EREDIA III thespecification

EREDIA recommends a set of integrated toolsand methodologies for the development of an in­teractive application. The friendliness in ERE­DIA shows itself through several choices: bit­map workstations, a graphical specification ofdialog by "graphical echo", dialogs with the op­erator through a set of adapted menus accordingto the operator's work ... The graphical echo isa new concept totally different from computeraided drawing tools. The operator builds theinterface in the concrete terms of dialog: ques­tion, response, result. EREDIA gives him backa graphical echo of his specifications in the formof a diagram. The graphical echo has severaladvantages. It J'reseves in all cases a lisible

drawing; the elements are placed according torules. It allows for the interactive verificationof some of the consistency properties of the dia­gram. EREDIA runs a checking process and canlead the specifications of the operator, by refus­ing hi m incorrect choices. Lastly, for a samedialog between EREDIA and the operator, wecan have several forms of echos adapted to theoperator.

4.6 Conclusion.

We have presented an use of our model in theframework of the EREDIA environment. Wedevelop a prototype of EREDIA on SPS7/BULLwith a bit-mapped workstation. But as we havejust shown the model is sufficiently broad to beintegrated to another context of use. We simplyhave to change the textual specifications linkedto each element.

is simple and does not refer to any computerizedknowledge.

On the other hand, the model must allowfor the specification of different viewpoints ofthe dialog while preserving a coherence. In ouropinion, it achieves its purpose being an genericmodel independent of any implementation prob­lem, to which some elements of textual specifi­cation must be added to specialize it.

Up to now, the model has been principallyused to specify query/response dialogs of video­tex application in the framework of EREDIA.However, we think that its definition allowsthe more general specification of any dialog(query, response, result), in which the series ofexchanges need a description. Its modularitymakes it easilly adaptable for applications ofwhich the presentation differs from this one forthe videotex applications. Thus, it is the speci­fication of I/O languages which evolves, but thedesign of logical dialog, is always the same.

5 Conclusion. References

The separation between the user interface and [1]the functions of the application is one of essen-tial guidelines for the design of interactive ap­plication. We have particulary focused on theproblem of the user interface development. Aninteractive dialog is a series of basic exchanges,which consists of three components: the appli­cation query, the user response and the applica-tion result. The interfaces management systems [2]fit together to give a coherence in the series ofexchanges. The basis to put this guideline intopractice is to dispose of a specification model ofthe conununication dynamics.

First, the model has to be understood andused by non computer experts. This is the prin- [3Jcipal motivation that made us choose a graphicalrepresentation with our extension of the transi-tion diagrams. The originality of our model liesin the transitions represented by the tree-likearcs and the addition of new elements to extend [4]the power of the diagrams, such as typed-return,intervention, event-salvage.

On the one hand, our definition of the dialog,(questionnaire, response-interpretation, result),

9

Patrick BOSC, Alain CHAUFFAUT, andBertrand HARDY. EREDIA: a systemto develop servers including text process­ing technics. In PROTEXT IT (BOOLEPRESS LIMITED), pages 133-144, 2nd In­ternational Conference on Text ProcessingSystems, Dublin, 23-25 october 1985.

Bruno CHERON and Laurence ROUILLE.Etude et realisation d'outils d'aide ala spec­ification graphique pOll!' Ie concepteu1' ct Ieprogmmmeul' de I'atelie/' EREDJA. DEAReport, University of RENNES I, september1985.

Christian COUEPEL and Colette TAN­GUY. EVA: Le Logiciel de Compositionde F01'mats. Technical Report 78, INRIA ­RENNES, februar 1987.

David KIERAS and Peter G. POLSON. Ageneralized transition network - represen­tation for interactive systems. In Proceed­ings of CHI'83, Human Factors in Computet'Systems, pages 103-106, 1983.

(

(

[5] David L. PARNAS. On the use of transitiondiagrams in the design of a user interface foran interactive computer system. Proc. 24thNational Confel'ence A CM, 379-383, 1969.

[6] Anthony 1. WASSERMAN. Extendingstate transition diagrams for the spec­ification of human-computer interaction.IEEE Transaction on Software Enginee7'ing,SE.ll(8):699-712, august 1985.

10

I,