Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
(
(
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 existing models are based on transition diagrams, but they give too attention to implementationconsiderations. Therefore, we reconunend a new model completely independent of any implcmentation 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 integrated 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 specification
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 communicatio n between the application and the user,and the functions of the application.
The interface serves as a showcase of the application. 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 plmidisciplinary undertaking, which involves psychology, ergonomy... Moreover, with the current tendency towards optimal exploitation ofgraphic possibilities with access terminals, consulting a layout specialist is advisable. Consequently, the functional design of the applicationand that of the user interface need distinguishable qualities and will not necessarily be implemented by the same persons.
All the above motives make it essential to distinguish between the development of the interface 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 interface 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 becomes 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 fostering 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 elementary dialog exchanges display came into being.They dealt with the display of query, result, oruser responses, by grid management, state editors ... 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 systems attempt to obtain a entire specificationof the dialog. On the one hand, there is thesyntax of I/O. One may distinguish two specification levels; concrete syntax (basic communication display) and abstracted syntax (distinguished by its application). On the other hand,there is a description of the communication dynamics between the application and the user.It is dialog management. From these specifications, 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 understanding with their graphical representation,which is not t.rue of grammars or object-oriented
(
languages. A graphical representation is especially 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 suggested a use for command language specification. These languages infer restricted dialog,the application query is always the same implicit query: "What is your command?". Interface specification problems are simplified. Nodesrepresent the application states. Arcs containthe user response and the application result.Through syntact analysis of the conunand, Parnas determines what terminal operation has tobe run and what the updated state of the terminal 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 command languages, Kieras and Polson [4] have indicated that a semantic analysis of the user response 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 response. They recommend a description of thetheoretical functionning of the condition evaluation. 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 essential 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 integrated into the principal diagram, which represents the dynamics of the dialog and the abstracted 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: keyboard entry, function key...
2.2.3 Wasserman
In the Wasserman model [6] this notion of queryis explicit. Besides, he does focus solely on command 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 specification production. The operator who uses hismodel must prove his competence in all fieldsinvolving interface design. His diagram definition is very different from the afore-mentioned.Nodes represent application ouputs, queries andresults. Arcs contain user inputs and application actions. An action is a condition or anyother way of processing the application. He introduces the notion of sub-diagram structuringthe dialog, as well his model allows a series ofouputs, responses, actions to be built. The operator 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 definition 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 independent of physical dialog. As a matter of fact, several physical dialogs may refer to a same logicaldialog. Lastly, we finish with the perspectivesthat offered by our model faced with new workstations, 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 application (server) "leisures". This server offers theuser the choice between several services : "cinema", "theater", "concert". The function of theservice "cinema" is to inform him about the cinema, timetables, films. To that purpose, theuser chooses among four criteria of selection:"cinema", "timetable", "filn1", "type". Thecombinations of these criterions lead to different 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 noncomputer scientists. It suits the addition of specific informations the description of different aspects of the dialog, logical and physical. The basic model is independent of any implementation.We give a description of this model in the chapter III. Afterwards, we evoke in the chapter IVits use in the framework of EREDIA (Environnement de REalisation des DIAlogues) for gen-
calion several interfaces must coexist accordinglo hard ware, or to the user's experience. By several 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 dialog 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 specification 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 specialist.
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 computerized. 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 dialog 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 requests. In particular, when the application putsa single query to the user, the user request is thechoice of answering this query. Later on, we indicate 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 questionnaire 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 application asks the user for his criteria of selection. That questionnaire is called" criteria", itstype is "grid" and it has two requests: "selection" which corresponds to giving the criteriaand "return" which corresponds to a return tothe first menu. In the first request are associated four data fields: "cinema", "timetable","film", "type". \Ne consider that they have noinitial value. On the other hand, the user's option 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 response.
The user response consists or a possible requestwith data. We need a semantic analysis of thisresponse, whatever the type of the dialog considered. The model of Kieras and Polson hasbrought to the fore the risk of the dialog locking. We want to avoid this at all costs.
The semantic analysis depends on a context:request choice, user's previous data or permanent application data. This analysis can bemore or less complex, that is why we have chosen to break it down into a combination of elementary 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 interpretat ion. To this purpose, we do not ask theuser for data and we do not consider that the requests depend on certain context, like the number of times the user has demanded this serviceduring a session... On the other hand, the "selection" 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 possibility 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 combination exists, and if the contrary were true,consider if there are responses to satisfy the requcst 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 functionning 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" request, 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 corresponds 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 interpretations, if there are several contexts of connection: proprieties linkcd to a user, connectionconstraints ... The start questionnaire is symbolized by a square.
3.3.2 Dialog pursual.
Once the application has answered the user request, the dialog goes on through another basicdialog exchange, or stops. It is a statically dctermined 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 models.
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 system 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", "theater" and "concert". There are two possible outputs 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 request. 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 elements of the model; it can especially call another sub-dialog. The difference between a principal dialog and a sub-dialog is that for the latter there may be several output contexts. Thefinal marks possess moreover semantic information. A sub-dialog is a pseudo-questionnaire atthe level of principal dialog. That's why it hasrequests (or pseudo-requests) which are its final marks. They can be interpreted accordingto the context of the principal dialog. A subdialog 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 informed 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 intervention 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 according 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" nonintervention". 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" abstract" 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 dialog. 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 recommend to develop an interactive applicationaround the definition of its dialogs with the user.Therein, EREDIA discerns three phases in thedevelopment of an interactive application: design of the logical dialog, layout(definition of thereal dialog) and the programming. These threesteps of the development are entrusted to experts: the designer, the model maker, and theprogrammer. Although all three work on thesame dialog, but they have not the same perception, because they have not the same interest. 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 description of a particular aspect of the dialog. Havinga basic model is interesting: it allows a communication 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 diagrams, representation of finite state machines.We have modified the structure, but nevertheless there are analogies. In the transi tion diagrams, a node represents a state of the machine and a transition allows the passage fromone state to another, it has an input and anoutput. For us, it is not a question of considering 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 questionnaires, 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 diagrams 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 interface. The user has at a given time a lot ofpossibilities, because he can direct of the dialog.
7
(
user, without being preoccupied with any physical 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 application.
Designing a conceptual schema reverts to finding what the exchanges between the application 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 exchanges presentation, nor to the programmingof the interpretations and application results.It is the approach which has been presented allthrough the model description with the presentation 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 accounting for the real dialog between the application and the user. Therefore, there is a modification 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 questionnaire 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 function key, there are several values to determinea choice of request, (1 + envoi = Cinema, 2 +
8
envoi = theater. .. ) supplementary interpretation levels are created. Moreover, the choice ofan access method (terminal management) addssome secondary exchanges to the principal dialog descri bed by the designer. For instance, inthe case of videotex access methods, every function key must be affected to at least one action.
In addition, a presentation format must bejoined to every questionnaire and to every result. The model such as it is defined docs notintegrate elements of presentation specification.According to the possible complexity of the presentation 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 specify videotex pages [31.
4.4 The programming schema.
For each presentation schema corresponds a prograrruning schema. It is an extension of the presentation schema to which we add routines toelements, state routine, interpretation routine,result routine. The programming of the core ofthe application is deduced from the programming schema. The programmer must give inaddition subroutines for the functions of the application.
4.5 The help of EREDIA III thespecification
EREDIA recommends a set of integrated toolsand methodologies for the development of an interactive application. The friendliness in EREDIA shows itself through several choices: bitmap workstations, a graphical specification ofdialog by "graphical echo", dialogs with the operator 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: question, 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 diagram. EREDIA runs a checking process and canlead the specifications of the operator, by refusing 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 problem, to which some elements of textual specification must be added to specialize it.
Up to now, the model has been principallyused to specify query/response dialogs of videotex 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 specification 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 application. 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 application 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 processing technics. In PROTEXT IT (BOOLEPRESS LIMITED), pages 133-144, 2nd International Conference on Text ProcessingSystems, Dublin, 23-25 october 1985.
Bruno CHERON and Laurence ROUILLE.Etude et realisation d'outils d'aide ala specification graphique pOll!' Ie concepteu1' ct Ieprogmmmeul' de I'atelie/' EREDJA. DEAReport, University of RENNES I, september1985.
Christian COUEPEL and Colette TANGUY. EVA: Le Logiciel de Compositionde F01'mats. Technical Report 78, INRIA RENNES, februar 1987.
David KIERAS and Peter G. POLSON. Ageneralized transition network - representation for interactive systems. In Proceedings 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 specification of human-computer interaction.IEEE Transaction on Software Enginee7'ing,SE.ll(8):699-712, august 1985.
10
I,