=Paper= {{Paper |id=None |storemode=property |title=A Generic Model for Dialog Specification |pdfUrl=https://ceur-ws.org/Vol-961/paper23.pdf |volume=Vol-961 |dblpUrl=https://dblp.org/rec/conf/caise/RouilleBC89 }} ==A Generic Model for Dialog Specification== https://ceur-ws.org/Vol-961/paper23.pdf

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.

(