Campus Universitaire de Beaulieu 35042 RENNES Cedex - FRANCE Telephone: 99 36 20 00 (p. 495) - Telex: 950'173F Telecopy : 99383832 - Network: chauITauirisa.irisa.fr
A GENERIC MODEL
FOR DIALOG SPECIFICATION Laurence ROUILLE, Patrick BOSC, Alain CHAUFFAUT
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.
2.1 An interactive application is an application which communicates directly with the user to obtain the data necessary to its execution. Two With the technological improvements in the field parts may be discerned as regards interactive of I/O, bit-mapped display, videotex, mouse, ... , application: the interface which ensures commu the interactivity between the application and 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 ( 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 [
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". ( ( ( ( l 3.2
The basic dialog exchange. 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 alog is guided by the application, it decides to return recommend menus to him, or to query him. In some case, both can be combined. For instance Figure 1 : The questionnaires (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 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 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 user, to determine what the new actionis and This is the starting point of the diagram, it cor the pursuit of dialog. The user has the possibil responds to a singlc fictitious questionnaire. It ity of entering four data "cinema", "timetable", is defined by an identifier and a request which "film", "type". Nevertheless, the combination corresponds to thc user's wish to conned to the of the fields "film" and "type" leads to an illicit server. The request can have several interpre qucry. In this case, we must vcrify if this com tations, if there are several contexts of connec bination exists, and if the contrary were true, tion: proprieties linkcd to a user, connection consider if there are responses to satisfy the re constraints ... The start questionnaire is sym qucst of the user. In this example (fig. 2), there bolized by a square. 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) 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)
quest, the dialog goes on through another basic dialog exchange, or stops. It is a statically dcter mined continuation of dialog. It is graphically modelized by the link of a result object with a state object.
We have added some dynamic dialog pursuits (fig. 3). "Ve do not find thcm in the other mod 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 3.2.3 The result. the type of the questionnaire. It is symbolized 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 ( ( ( \ 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.
}--
+jlYPCj )----_~_-< e- ...
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 Figure 3 : The dynamic dialog pursual soon as the latter receives an elementary result.
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 3.3.4 The sub-dialog. cording to different contexts. In an intervention, 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".
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 4.1 The uses in EREDIA. grams, representation of finite state machines.
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 4.2 The conceptual schema. 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 ( 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
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 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
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 application result. The interfaces management systems [2] Bruno CHERON and Laurence ROUILLE. fit together to give a coherence in the series of Etude et realisation d'outils d'aide ala 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. (