- Email: [email protected]
An architecture for dialogue management: Implications in user-computer dialogue design
Interfaces in Computing, 3 (1985) 259 - 275
259
AN ARCHITECTURE FOR DIALOGUE MANAGEMENT:
IMPLICATIONS IN USER-COMPUTER DIALOGUE DESIGN BOB KUO and BENN KONSYNSKI Universi~ty of Arizona, Tucson, AZ (U.S.A.)
Summary The management of u s e r - c o m p u t e r dialogues involves the examination of policies, procedures and methodologies that enable users and designers to control, monitor and facilitate effective u s e r - c o m p u t e r communication. Dialogue management can be facilitated by the application of software tools in the dialogue design phases. The tools and methods serve to exploit pertinent environmental attributes and result in the determination of alternative dialogue components and relations. This paper defines an architecture for dialogue management that supports conceptualization, transformation, generation and realization in dialogue design. The architecture promotes functional layering, modularization and invocability of dialogue functions by application systems.
I. Introduction Dialogue management research [1] has focused on analysis of the organizational, personal and technological characteristics of providing effective communication and control in u s e r - c o m p u t e r dialogues. In particular, increasing computing power and interface device capability, which are related to the trend in cost reduction and productivity enhancement, heightens our interest in the use of engineering modular software to support the development of user-friendly information systems. As with successful data management, successful dialogue management requires an understanding of environmental attributes and stepwise refinement in the design process; the objective is to provide easy-to-use and easy-to-maintain computer system dialogues. The traditional approaches to bridging the gap between the user and the computer system are training and the use of manuals. While these approaches are useful in educating users in the functionality of the system, they often require both background knowledge of computing and substantial investment of the user's time. Users of today's interactive systems, however, include a considerable number of non-computer professionals. The prolifera0252-7308/85/$3.30
© Elsevier Sequoia/Printed in The! Netherlands
260 tion of individual computer work stations, equipped with various interactive application software, increases the need for faster user self-instruction and better communicative system dialogues. The research reported below is an attempt to address this problem by studying the application of software technology in the dialogue design process. All interactive programs require dialogue management functions. In the survey by Sutton and Sprague [2], the proportion of code dedicated to the handling of u s e r - c o m p u t e r interface was shown to be greater than 60%. These functions include displaying information in differing forms, accepting entries from the user, coordinating with other functional components of a program, etc. Dialogue management ensures the delivery of consistent, complete, flexible and recoverable computer system dialogues by providing guidelines and software tools for both defining the dialogues and developing sharable dialogue functions. Despite the emerging needs for developing these functions, traditional system design has not properly addressed dialogue design issues. The use of various dialogue forms to represent different processes and data residing in the computer system is itself a complex issue. An identical process (e.g. duplicating an object) may utilize different dialogues and the same data (e.g. a record in the data base) may also be presented differently across various application programs. As the number of processes a n d data sets grows, dialogue design may become unmanageable. Further, the design of easy-to-use dialogues is complicated by the need for flexibility and adaptability in accommodating different classes of users (e.g. novice versus expert). The other two factors that software dialogue designers have to cope with are the need to incorporate new technologies for computer dialogues, such as those used for input and display, and the need to provide alternative forms of dialogue for the resulting information in unstructured decision environments.
2. Dialogue design issues Recent research in areas related to u s e r - c o m p u t e r interaction has suggested several issues to be studied in dialogue management. These issues can be classified as consistency, flexibility, efficiency, adaptability, integrity, recovery, shareability and completeness. We now briefly examine each in turn.
2.1. Consistency Dialogue consistency refers to the rules governing the organization of dialogue entities [3], the syntax abbreviation [4], the interaction methods [5, 6], response time [7], spatial arrangement [8], the handling of user errors [9], effects of dialogue entities [10], etc. The significance of this issue in the design could be discerned in the design of the Xerox Star work station, which has now become a model for the dialogue design of several desktop computers.
261 2.2. Flexibility A flexible dialogue environment provides different dialogue methods for different classes of users under decision situations. For instance, Carey [11] emphasized the difference between frequent users and beginning users, and Benbasat and Wand [4] studied the use of different styles of dialogue by people of different abilities (e.g. heuristic versus analytic). Carlson et al. [12] proposed the need for providing alternative information representations in unstructured decision environments. Thimbleby [13], in his study of dialogue determination, discussed in detail how dialogue flexibility affects the user's performance. Bailey and Pearson [14] also identified flexibility as a major factor in determining user satisfaction. 2.3. Efficiency The time and effort required for the completion of a dialogue session and the time required to learn to use the system are major factors in dialogue efficiency. Carey [ 11 ] reported that efficiency was a critical factor affecting l!requent computer users. Card et al. [15] studied keystroke actions to evaluate interaction efficiency. From a learning viewpoint, computer-guided style dialogues are usually more efficient than user-guided style dialogues but less efficient in the aspect of interaction [7]. 2.4. A d a p t a b i l i t y An adaptable computer system changes the way in which dialogues are conducted as the state of the user (e.g. knowledge, intention, familiarity, etc.) changes. Treu [16] defined a four-stage learning model, which was expanded to five stages by Mozeico [17]. Mozeico further designed a system that provided dialogues of different forms for users at different stages and identified positive effects of user learning. Thimbleby's study [13] of dialogue determination provided insight into the effect of dialogue structure ~e.g. rigid versus flexible) on usage. 2.5. Integrity Dialogue integrity relates the degree of correctness and relevance of dialogues to actual system functionalities. Since the user relies on dialogues to understand and predict the behavior of the system [5, 18, 19], dialogue integrity must be maintained through the system's life cycle. .2.6. R e c o v e r y It must be possible to recover from mistakes made during the dialogue process with relatively little user effort. Bannon et al. [20] recognized that the user's ability to suspend and resume operations is critical to task performance. The recent trend of using specialized function keys to undo and redo operations reflects the importance of recovery. The issues involved, however, become more complicated when the complexity of dialogue structure increases. For example, recovery at different levels of operation cannot be completed unless the system keeps track of all interactions; this bookkeeping, however, may become a major overhead in the system's operations.
262
2.7. Shareability As the definitions of dialogues are separated from the procedures for processing, dialogues can be shared by applications utilizing the same dialogue structure [21]. In addition, dialogue management functions can also be shared by applications so as to reduce system development effort. Shareable dialogues have the benefits of productivity enhancement and reduced storage requirements for dialogue definitions; interaction consistency and integrity can also be facilitated. 2.8. Completeness Incomplete dialogues are never "friendly" enough, regardless of the technologies used. Dialogue completeness is measured in terms of both the performative and the informative dialogue entities that are incorporated in the design [22]. Gaines [5] emphasized that a design is incomplete unless the user's model is incorporated. The design of informative messages for errors and help [23, 24], for example, is important in improving the user's overall performance when using the system.
3. Dialogue management architecture A well defined architecture for dialogue management emerges from an understanding of the complexities involved in the dialogue design process. Dividing the design process into manageable stages allows for complexity decomposition. Thus, a hierarchical representation of design problems can be obtained; design is also structured and simplified. Furthermore, software tools can be used to facilitate various design activities in each layer of the design hierarchy. Protocols, which are sets of rules that define interfaces between adjacent layers of software, are devised in order to eliminate one layer of the software's involvement with the internal procedural complexities of other layers. As a result, this functionally layered architecture can be used to assist in solving complex dialogue design problems in a simplified and systematic fashion. Aiming at the reduction of complexity, the proposed architecture is divided into four layers: environment interface, interface control, dialogue generation and dialogue execution. Clearly defined protocols are defined for the layers to interface with each other in a structured and simplified fashion. This architecture is illustrated in Figs. 1 and 2. In the center of Fig. 1 is the layer o f dialogue execution, which is a control center that coordinates, schedules and controls the delivery of dialogues. Adjacent to this is the layer of dialogue generation, in which the dialogue models are defined and stored and dialogue management functions are created. At the front end is the layer of environment interface software that collects and profiles attributes of various technologies, users and tasks. Between the dialogue generation layer and the environment interface layer is the layer of interface control, which provides a transparent transforma-
263 nformGtion technologf
{ Fig. 1. An architecture for generalized dialogue management: EI, environment interface; IC, interface control ; DG, dialogue generation ; DE, dialogue execution.
tion so that the execution and generation of dialogues can function independently of specific technologies, users or task requirements. A functional overview and the protocols are further illustrated in Fig. 2. In the figure, the interface control managers examine the attributes created by the front end software in the environment interface layer and perform analyses based on the knowledge stored in the knowledge base. The results are the data base, which contains the primitives necessary for dialogue modeling, and the knowledge base, which contains procedural specifications that could be used to generate the dialogue management functions. The data base is then used for the purpose of dialogue modeling through the computer-aided dialogue definition generator. The knowledge base is used to create the dialogue management functions through the use of a dialogue management function generator. The dialogue definition generator and the dialogue management function generator together constitute the dialogue generation layer. In the dialogue execution layer, the dialogue management functions are divided into two types: semantic processing and syntactic processing. The data bases that contain the definitions of the semantic and syntactic models are then accessed by the dialogue manager to invoke dialogue functions on behalf of the application systems. Various data bases,
264
Environment interface
[
Front end units
interface control managment
J
Interface control managers
Dialogue generation
Dialogue execution
I Dialogue management functions generator
I
~
Dialoguemodel ] definitiongenerator
Dialogue tmanager Syntactic processing I Semanticprocessing
V
I
Application systems
-~
_] -[
Model and data management
Fig. 2. F u n c t i o n a l o v e r v i e w of t h e dialogue m a n a g e m e n t a r c h i t e c t u r e .
which are used by adjacent layers to communicate with each other, must follow the protocols agreed by the layers. Consequently, functions on each layer can be performed freely w i t h o u t concern for the internal procedural complexities of other layers.
3.1. E n v i r o n m e n t interface layer: front end units The responsibilities of the environment interface layer are to collect critical attributes [25] concerning information technology, task and user. Information technology attributes refer to both hardware and software. Examples include video attributes, graphic attributes and software for interactive i n p u t / o u t p u t . Since there are several classes of display devices (e.g. m o n o c h r o m e versus graphics), there will be one front-end unit for each class of device. Significant task attributes include task frequency, activity flow, time distribution, etc. There also exist classes of tasks that utilize different classes of dialogue techniques. For example, a form filling technique can usually be used to handle data retrieval since this is a very structured task. On the other hand, expert consultation types of task are unstructured and will require the use of techniques such as question/answer.
265 I m p o r t a n t user attributes include the user's knowledge, familiarity and skill level, which can in turn be used to classify users (e.g. novice, casual and expert). Different dialogue techniques are then used for different user classes. As a result, different front-end units are required to profile different classes of information technologies, tasks and users. This level of support is provided by a mix of designer's functions and c o m p u t e r software. A u t o m a t e d software has been used to study task attributes 1126, 27]. I n f o r m a t i o n technology attributes can be obtained either f r o m manual d o c u m e n t a t i o n or generated by the c o m p u t e r if a library of i n fo r matio n is maintained. Experimental environments can be used to log the user activities in order to determine the user's skill level. A u t o m a t e d software support is nevertheless incomplete. A designer must participate in great depth to obtain a c om pl et e profile.
3.2. Interface control layer: interface control manager The functions of the interface control layer are to study environmental attributes in order to suggest valid dialogue entities and their grouping, dialogue techniques to be used, etc. For the information technology, the functions are determining relationships between technology attributes so that in f o r matio n can be presented to the user w i t h o u t concern for differences in the hardware devices and studying the suitability of various dialogue techniques for each class of interface device. Task attributes have the greatest impact on dialogue design. The task interface control manager will suggest alternative commands, data and their forms, and the arrangement of c o m m a n d s and data. The user interface control manager analyzes the user attributes and suggests suitable dialogue techniques and additional entities necessary to assist the user. The o u t p u t s from this layer are data bases con1;aining the resulting r e c o m m e n d a t i o n s encoded in terminologies and formats ~;hat will be u n d e r s t o o d by the dialogue generation layer. A knowledge base approach can be used for autotnated software support. ]Different display devices may use the same procedures for display handling. Consequently, the rules for utilizing the attributes may be generalized and recorded in the knowledge base. The attributes of the task and the user may also suggest requirements for higher level interactive functions. For example, the functions for accepting and validating the input could be programmed differently, such as accepting a character and validating the character immediately rather than ac.cepting the whole field and then validatmg the data entered. The decisions are d e p e n d e n t on the task organization and the user's skill and experience, bot h of which should be recorded in the knowledge base. However, most of the support described above has been provided by the designer rather than c o m p u t e r aided design software. Despite the research being c o n d u c t e d in the area of a u t o m a t e d design/code generation, the ability to p e r f o r m intelligent t r a n s f o r m a t i o n is still rarely f o u n d in any c o m p u t e r software. With recent research in applying artificial intelligence technology to system design [28], a u t o m a t e d interface cont rol software can
266
Interface control managers
Sample knowledge base for: Computer environment: Intelligent display devices must have a way to perform cursor addressing: leading characters followed by one or two characters, followed by the x and y coordinates. User: if heuristic then aggregate presentation preferred if typing low then push buttons preferred if no previous experience then computer guided dialogue with forced choice, and more manual assistance if high experience but not familiar with system, computer guided dialogue and user guided dialogue with free response preferred, but with on-line help if low familiarity, then help more and vice versa if low memory limit, fewer objects displayed Task: basic data and command attributes are inherited for less frequent task computer guided dialogue are preferred regardless of the differences in users current/past dialogue methods, if they can be simulated, are preferred at the beginning stage of the learning, while more advanced mechanisms can be introduced through further education (on line or manual) current/past dialogue styles, if they can be simulated, are preferred, eg., the full screen of form to simulate the form for data entry definitions of working context for dialogue are based on the relationship between models and data. Grouping is based on the semantics. Hierarchy structure is usually used. Information flow is then the most critical factor. This process may be changed in the conceptual model formation sta~e.
Fig. 3. I n t e r f a c e c o n t r o l m a n a g e m e n t a n d the k n o w l e d g e base. In the e x a m p l e s h o w n , t h e processing k n o w l e d g e base handles cursor addressing for class A display devices via seq u e n c e s esc + [ c h r l + chr2 . . . . ]. The dialogue c o n c e p t s data base h a n d l e s c o m m a n d att r i b u t e s t o initiate the o p e r a t i o n , data a t t r i b u t e s for decision e n t r y and message a t t r i b u t e s for help.
n o w be used to aid system design. For example, it is feasible to have the interface control layer software make recommendations of dialogue techniques based on rules such as "low speed display devices should n o t be used for screen oriented dialogue styles". Figure 3 describes the processing of the interface control managers.
267
3.3. Dialogue generation layer There are two major c o m p o n e n t s in the dialogue generation layer: the dialogue man ag e m ent functions generator and the dialogue model definition editor. Given the out put s generated by the interface control manager, different lewds of dialogue m a na ge m ent functions can then be programmed. The h)wer level functions, such as cursor addressing and m o v e m e n t , are those used to address the device d e p e n d e n t features. These functions are then used to dew, lop higher level functions such as displaying and reading a string; these in turn can be used to develop complex data display in an area, a window or the entire screen. Lower level incompatibilities can be isolated from the higher level functions. Thus, application systems that do not utilize lower level functions can be transferred from one c o m p u t e r to a n o th er w i t h o u t modification. The results from this generator are a set of dialogue functions for both semantic and syntactic processing. It is feasible to generate the lower level functions automatically, since c o m m o n procedures have been used for most of t o d a y ' s display devices. The American National Standard Institute standard is the primary motivation for this automation. The higher level functions, however, are more c u mb er s o me to generate because t hey have to cope with the c o m p l e x i t y imposed by the task and user attributes. However, the higher level functions are more stable. Changing lower level display devices will not affect them, because of the flexibility provided by the interface control layer. A stable set of higher level functions are used by the semantic manager and the syntactic manager. Generating the dialogue model is an iterative process (see Fig. 4). C" ~wen the data base containing suggestions for alternative dialogue entities ~md their grouping, computer-aided tools can be used to assist in the model general~ion. The benefit of the computer-aided dialogue model generator is i~hat it supports modeling as well as evaluation within a short period of time. This dialogue model generator includes an interactive, dialogue definition editor and dialogue model evaluator; it. generates the data base containing a complete dialogue model, which can be accessed by the dialogue execution layer. This dialogue model can be stored in language form, as the data definition language and data manipulation language for data base management. Dialogue modeling activities at the semantic level include the designation of dialogue entities, specification of interdependence between entities, definition o f operations and conditions to be invoked, grouping the entities into dialogue procedures, selection of appropriate dialogue styles and the formulation of the whole dialogue model. Syntactic dialogue modeling activities include language (words, signs, tables, symbols and the syntactic rules) definition, dialogue technique selection, planning of the screen layouts and designation of interaction mechanisms and methods. A more difficult activity for the designer is to evaluate the design according to a set of criteria. Personal bias and the lack of perform ance m e as u r emen t tools are the major factors hindering the evaluation process.
268
f 'g:::rla ~to/r:::eVe tor ~ Interacti ve didefi alongue editorition
Di alogue model evoluator
Fig. 4. The generation of dialogue definition. The editor specifies entities, interdependences, etc.; the evaluator is used for experiments, prototyping, etc.; the definition data base contains entities, interdependences, procedures, layout, methods of interaction, etc.
However, the use of a dialogue model evaluator to simulate the dialogue process before the actual construction of the information system could provide the information necessary to improve the dialogue model. The evaluator can be viewed as a prototyping machine that offers the designer the capability to visually evaluate the interaction process by activating the semantic and syntactic managers to process the model definitions. Formal specifications are employed to describe the rules of interaction. The state transition diagram can be used to represent the m a n - c o m p u t er interaction in the graphic forms. The Augmented transition diagram [29] was improved from STD. Both STD and ATD allow recursive definitions. The Bacus Normal Form is used to represent the grammar of the interaction. Reisner [3] provided an example of how BNF can be used to describe the user interface of two graphics systems. Jacob [30] used BNF notation in his design of a military message system. It is also helpful if the conceptual dialogue model can be presented as a graph for evaluation. The consistency of the whole dialogue model can be evaluated as described by Reisner.
3.4. Dialogue execution layer The dialogue execution layer consists of two major components: the semantic manager and the syntactic manager (see Fig. 5). This layer's function is to facilitate u s e r - c o m p u t e r dialogue design for all application systems. To do this, a flow control module is needed to interpret the semantics
269
~1
Interactive
dialogue
[~
model generator
Dialogue model evaluator
Interactive dialogue definition editor
/\ /
/
/
/
/
( concept ) ~data base/ (a)-'-----J
Run-time semantic manager Interpre -
rationand flow control
Data convergl,gnJ
Otis ] [
1
--Definition retrieval
Dataand model interface
1
~yntactic ] management interface
(b) Fig. 5. (a)
Semantic processing; (b) syntactic processing.
of the commands and data entered and to invoke the appropriate operations. A semantic manager consists of the dialogue definition retrievel functions, data conversion functions, interface functions to data and model managers, interface functions to the syntactic manager and the interpretation and flow functions. The semantic manager retrieves the semantic dialogue model from the definition data base through the dialogue definition retrieval functions. When any command or datum, or a group of commands and data, are
270 determined to be syntactically correct, the flow control function interprets the values on the basis of the semantic dialogue model. It then determines whether to invoke corresponding operations or to reject the commands or data due to invalid semantics. The data/model interface functions are then activated to transfer control and to transport the data to and from the model and data management functions (e.g. computation and data base update). Finally, in order to properly invoke operation of the various functions, the data entered may have to be converted into the format that the intended function requires. The format requirements may be simple type conversions such as integer to character, or very complex file format conversions for various applications. Data conversion functions can be treated as the functions shared by dialogue, data and model managers. The syntactic manager includes lower level display handling functions that are hardware dependent and higher level functions to handle the interactive i n p u t / o u t p u t operations. The components of the syntactic manager can be functionally divided into definition retrieval, interactive input/output text manipulation management, space management, message management, presentation management, graphics management, voice management and display control. The responsibility of the syntactic manager is to invoke the proper functions to facilitate the generation, manipulation and disposition of necessary dialogue objects when requested by the semantic manager. Lower level functions, such as cursor addressing and character display, have to be modified for different classes of display monitors. However, functions for testing and revealing different classes of monitors can be developed. Based on the results of this testing, proper lower level functions are then invoked. As a consequence, higher level management functions can be invoked freely, regardless of hardware differences. Thus, application systems portability is improved.
4. Comparison with other architectures Other approaches have also been followed to assist in dialogue design, although most of them concentrate on dialogue generation and dialogue execution layers. Rowe and Robson [31] use the higher level language approach in Screen Rigel. The dialogue functions are embedded in PASCAL function calls. In their implementation, field definitions for dialogue descriptions can be obtained from the data dictionary. This eliminates red u n d a n c y and reduces design overhead significantly. Kasik [32] used a similar approach for the Tiger Interactive command and control language (TICCL) for the graphics system Tiger. With TICCL, programmers specify the interface descriptions in a way similar to schema for data base systems. Run time support is obtained through an interpreter. Figure 6 illustrates TICCL's architecture. Some graphics dialogue management systems have been designed to reduce application programming efforts. Systems such as F L A I R and UIMS
271
Application specific menus
//
User interface
Other utilities
Graphics package
Data base management system
User
\
Phystcal storage
Fig. 6. T h e T I C C L a r c h i t e c t u r e .
Pre processor
I
Run-time
Post-processor
I /
I
%
I
/
u,
/definitions/
/
/
/Log
file /
Fig. 7. The UIMS a r c h i t e c t u r e .
have used different t echnol ogy to support graphics programming. F L A I R [331 is a user interface design tool that allows programmers to rapidly p r o t o t y p e a system's m a n - c o m p u t e r interface. In addition to its graphics capabilities, F L A I R also facilitates p r o d u c t i o n of m enu hierarchies so t hat the dialogue process can be observed before the program is written. UIMS [34] consists of m a ny dialogue modules for both design support and run time ex ecu tio n facilitation. Figure 7 shows the architecture of UIMS. 5. Dialogue d e v e l o p m e n t w i t h t h e architecture
The discussion above has focused on a dialogue m anagem ent archit e ctu r e and its impact on the design of m a n - c o m p u t e r interfaces. Benefits
272 accrue in a way similar to that encountered on adoption of data base management: independence, sharing, storage economics, etc. In each layer, computer system designers can concentrate on limited sets of design activities with the help of the a u t o m a t e d software tools. The overall design can be simplified and structured: the EI layer facilitates profiling environmental attributes; the IC layer performs analysis and logical design; the DG layer facilitates the generation of executable dialogue definitions and functions and the DE layer facilitates an effective dialogue delivery on behalf of application systems. As a result, design complexity is reduced due to the four-layer architecture. Put in another way, this hierarchical representation of the design process allows the designer to freely attack problems of multiple complexities. Many sophisticated application systems can be built using this simple architecture. The DG and DI layers essentially become building blocks for application systems. Thus, the implementation of these two layers deserves further attention. There are three alternative approaches. The first is the use of a very high level language that will process the dialogue definition and provide the run time support. The second is the use of an interactive dialogue definition generator and function calls for run time support. The last possibility is a combination of the first two approaches. The objective is to allow designers to concentrate on dialogue modeling w i t h o u t being concerned with the complexities of programming dialogue management functions. The last approach described appears to be the most promising. The designer describes the dialogue model in a language, through any regular editor or through a dialogue definition generator that will also record resulting dialogue specifications in the same language. The designer then develops the system through functions embedded in the programming language or stored in a utility library. The designer is free to exploit the design alternatives by using either the dialogue definition generator, or any regular editor. The evaluator can be utilized to ensure an effective dialogue design. As a result, the designer is freed from much of the procedural complexity encountered during the design process. The resulting system design will be one of the most desirable alternatives. Further, because dialogue managem e n t functions are shared, computer dialogues across applications will be consistent. Dialogue definitions may even be shared by various application systems to further improve dialogue consistency.
6. Advantages of the dialogue management architecture There are several advantages associated with the architecture defined in this paper. (1) The four-layered architecture allows for the decomposition of design complexities into a manageable and hierarchical design representation. As a result, design complexity is reduced and design issues of different com-
273 plexity can be solved systematically. Although simple, this approach can be used to develop basic building blocks for complex application systems. (2',) Separation of the dialogue modeling process from the procedural aspects of the system design allows the designer to concentrate on the semantics and alternative syntax of a dialogue model. It is a great improvement over the situation in which the designer is overwhelmed by the interrelated issues of task, user and technology -- resulting in a situation that may cause him or her to sacrifice attractive design alternatives merely in order to complete the system. (3) It is easier to exploit more design alternatives through the use of ~he definition editor and evaluator in a shorter time period. Easy modification of the design is also achieved through use of the editor. Provided there are no procedural changes in the code, the application system does not even have to be recompiled. (4) The design life cycle can be accelerated by utilizing the support of automated software tools in different layers. Conceptualization, transformation, generation and realization of dialogue design all become more structured. (!5) It is also easier to incorporate new technologies for all applications using the dialogue manager, increasing the flexibility and adaptability of dialogue functions. One important characteristic of the proposed architecture is that it anticipates new technology. The design efforts necessary could be reduced because there is no need to change every program to accommodate a new technology. The dialogue management support software is well partitioned functionally so as to minimize the effects on the application programs. (6) Overall communicative power is enhanced through the use of interface control managers and the definition editor. Completeness can be evaluated in the pre-implementation stage. Help and error types of entities can also be requested automatically. Dialogue recovery is handled by the dialogue manager. (7) The integrity of information system dialogue for different applications is better achieved through the use of the definition generator. Applications also share dialogue management functions provided by the dialogue manager so that overall design productivity and reliability is increased. In other words, the consistency of the overall dialogue model is improved. The dialogue efficiency, conversely, can be maintained at a satisfactory level through the centralized support facility. (8) Because of the use of the same run time support tools, the consistency of the interaction methods and mechanisms is guaranteed. These tools are designed to provide a generic set of interaction methods available for all applications. (9) Finally, with the separation of semantic processing from syntactic processing, the architecture facilitates intelligent dialogues for users of different skill levels. Thus, various dialogue forms and advanced technologies, such as windowing, can be more easily accommodated. Furthermore, the
274 f u n c t i o n a l l y layered feature o f the a r c h i t e c t u r e allows the a d d i t i o n o f i n f e r e n c i n g capabilities t h a t can, at run time, m a k e d y n a m i c dialogue adjustm e n t s to b o t h semantic and s y n t a c t i c models.
7. C o n c l u s i o n s T h e design, d e v e l o p m e n t , i m p l e m e n t a t i o n , delivery and m o d i f i c a t i o n o f u s e r - s y s t e m dialogues can be s u p p o r t e d b y an a r c h i t e c t u r e t h a t offers g u i d a n c e o n the analysis and design o f dialogue c o m p o n e n t s and relations. The l a y e r e d f e a t u r e o f this a r c h i t e c t u r e is t h e m o s t i m p o r t a n t , since it allows f o r d e c o m p o s i t i o n o f design activities so as to r e d u c e the overall c o m p l e x i t y . T h r o u g h design guidelines a n d s o f t w a r e s u p p o r t at each layer, dialogue consistency, flexibility, e f f i c i e n c y , a d a p t a b i l i t y , integrity, r e c o v e r y , shareability and c o m p l e t e n e s s are all i m p r o v e d . E m e r g i n g research topics include the s t u d y o f various languages for defining and m a n i p u l a t i n g u s e r - c o m p u t e r dialogues. In addition, the inc o r p o r a t i o n o f artificial intelligence t e c h n o l o g y is necessary t o bring a b o u t d y n a m i c u s e r - c o m p u t e r interface design relating to the s y s t e m ' s ability to a d a p t its dialogues to the changing e n v i r o n m e n t r e p r e s e n t e d b y changing task, user and i n f o r m a t i o n t e c h n o l o g y attributes.
References 1 R. Sprague, Decision Support Systems: A Tutorial, DSS Conference, 1981. 2 J. Sutton and R. Sprague, A study of display generation and management in interactive business applications, Research Report RJ2392, IBM Research Division, Yorktown Heights, NY, 1978. 3 P. Reisner, Formal grammer and human factors design of an interactive graphics system, IEEE Trans. Software Engineering, 7 (2) (1981) 229 - 240. 4 I. Benbasat and Y. Wand, A structured approach to designing human/computer dialogues, Working Paper No. 835, October 1982; A dialogue generator and its use in DSS design, Inf. Manage., 5 (1982) 231 - 241. 5 B. Gaines, The technology of interaction-dialogue programming rules, Int. J. ManMach. Stud., (1981) 133 - 150. 6 T. Moran, The command language grammer: a representation for the user interface of interactive computer systems, Int. Jo Man-Mach. Stud., 15 (1981) 3 - 50. 7 L. Miller and J. Thomas, Jr., Behavioral issues in the use of interactive systems, Int. J. Man-Mach. Stud., 9 (1977) 509 - 536. 8 Martine (1973). 9 V: Morland, Human factors guidelines for terminal interface design, Commun. ACM, July (1983) 484 - 494. 10 J. Carroll, The adventure of getting to know a computer, Computer, November (1982) 49 - 58. 11 T. Carey, User differences in interface design, Computer, (1982) 14 - 20. 12 E. Carlson, B. Grace and J. Sutton, Case studies of end user requirements for interactive problem-solving systems, MIS Q., March (1977) 51 - 63. 13 H. Thimbleby, Dialogue determination, Int. J. Man-Mach. Stud., 13 (1980) 295304.
275 14 J. Bailey a n d Pearson, D e v e l o p m e n t of a t o o l for m e a s u r i n g a n d a n a l y z i n g c o m p u t e r user satisfaction, Manage. Sci., 29 (5) ( 1 9 8 3 ) 54 - 67. 15 Card et al. (1980). 16 S. Treu, A f r a m e w o r k of c h a r a c t e r i s t i c s a p p l i c a b l e to graphical u s e r - c o m p u t e r interact i o n , in S. Treu (ed.), User-Oriented Design o f Interactive Graphics Systems, Association for C o m p u t i n g M a c h i n e r y , New Y o r k , NY, 1 9 7 6 , pp. 61 - 71. t7 H. Mozeico, A h u m a n c o m p u t e r i n t e r f a c e to a c c o m m o d a t e user learning sta~es, Commun. ACM, February ( 1 9 8 2 ) 100 - 104. 18 P. J o n e s , F o u r principles of m a n - c o m p u t e r dialogue, Comput. Aided Des., 10 (3) (1978). [ 9 S m i t h et al. ( 1 9 8 2 ) . 20 L. B a n n o n , A. C y p h e r , S. G r e e n s p a n a n d M. M o n t y , E v a l u a t i o n a n d analysis of users' activity o r g a n i z a t i o n , CHI'83 Proc., 1983, pp. 54 - 57. 21 B. Kuo, Dialogue m o d e l i n g for i n t e r o p e r a b i l i t y in m i c r o - b a s e d w o r k s t a t i o n s , MIS T e c h n i c a l R e p o r t No. 8 4 - 1 2 - 2 - 0 0 1 , U n i v e r s i t y of A r i z o n a , T u c s o n , AZ, 1985. 22 B. K u o a n d B. K o n s y n s k i , U n d e r s t a n d i n g m a n - c o m p u t e r dialogues in ALL-IN-1 e n v i r o n m e n t , MIS T e c h n i c a l R e p o r t No. 8 4 - 0 5 - 1 - 0 0 5 , University of A r i z o n a , T u c s o n , AZ., 1985. 23 M. Dean, H o w a c o m p u t e r s h o u l d talk to people, IBM Syst. J., 21 (4) ( 1 9 8 2 ) 42.4 453. 24 B. iSchneiderman, S y s t e m message design: guidelines a n d e x p e r i m e n t a l results, in A. Barde a n d B. S h n e i d e r m a n (eds.), Directions in Human~Computer Interaction, A b l e x P u b l i s h i n g C o r p o r a t i o n , N o r w o o d , NJ, 1 9 8 2 . 25 B. K u o a n d B. K o n s y n s k i ( 1 9 8 4 ) . 26 J. N u n a m a k e r a n d B. K o n s y n s k i , P L E X S Y S : A s y s t e m d e v e l o p m e n t s y s t e m , Working Paper, University of A r i z o n a , T u c s o n , AZ, 1981. 27 B. K o n s y n s k i , J. K o t t e m a n n , J. N u n a m a k e r a n d J. S t o t t , P L E X S Y S - 8 4 : An i n t e g r a t e d d e v e l o p m e n t e n v i r o n m e n t for i n f o r m a t i o n s y s t e m s , JMIS, I (3) (1985). 28 K. F r e n k e l , Towm'd a u t o m a t i n g t h e s o f t w a r e - d e v e l o p m e n t cycle, Commun. ACM, June ( 1 9 8 5 ) 578 - 589. 29 Woods ( 1 9 7 0 ) . 30 R. J a c o b , Using f o r m a l s p e c i f i c a t i o n s in t h e design of a h u m a n - c o m p u t e r interface, Commun. ACM, April ( 1 9 8 3 ) 2 5 9 - 2 6 4 ; E x e c u t a b l e s p e c i f i c a t i o n s for a h u m a n c o m p u t e r interface, CHI'83 Proc., 1 9 8 3 , pp. 28 - 34. 31 L. R o w e a n d K. Shoens, P r o g r a m m i n g language c o n s t r u c t s for screen d e f i n i t i o n , 1EEE Trans. Software Eng., 9 (1) ( 1 9 8 3 ) 31 - 39. 32 D. Kasik, A user i n t e r f a c e m a n a g e m e n t s y s t e m , Comput. Graphics, 16 (3) {1982) 99 106. 33 P. Wong a n d E. Reid, F L A I R - - user i n t e r f a c e dialogue design toot, Comput. Graphics, 16 (3) ( ] 9 8 2 ) 87 - 98. 34 P. T a n n e r a n d W. B u x t o n , S o m e issues in f u t u r e user i n t e r f a c e m a n a g e m e n t s y s t e m (U][MS) d e v e l o p m e n t , T e c h n i c a l Paper, U n i v e r s i t y of T o r o n t o , T o r o n t o , O n t a r i o , 1983.
259
AN ARCHITECTURE FOR DIALOGUE MANAGEMENT:
IMPLICATIONS IN USER-COMPUTER DIALOGUE DESIGN BOB KUO and BENN KONSYNSKI Universi~ty of Arizona, Tucson, AZ (U.S.A.)
Summary The management of u s e r - c o m p u t e r dialogues involves the examination of policies, procedures and methodologies that enable users and designers to control, monitor and facilitate effective u s e r - c o m p u t e r communication. Dialogue management can be facilitated by the application of software tools in the dialogue design phases. The tools and methods serve to exploit pertinent environmental attributes and result in the determination of alternative dialogue components and relations. This paper defines an architecture for dialogue management that supports conceptualization, transformation, generation and realization in dialogue design. The architecture promotes functional layering, modularization and invocability of dialogue functions by application systems.
I. Introduction Dialogue management research [1] has focused on analysis of the organizational, personal and technological characteristics of providing effective communication and control in u s e r - c o m p u t e r dialogues. In particular, increasing computing power and interface device capability, which are related to the trend in cost reduction and productivity enhancement, heightens our interest in the use of engineering modular software to support the development of user-friendly information systems. As with successful data management, successful dialogue management requires an understanding of environmental attributes and stepwise refinement in the design process; the objective is to provide easy-to-use and easy-to-maintain computer system dialogues. The traditional approaches to bridging the gap between the user and the computer system are training and the use of manuals. While these approaches are useful in educating users in the functionality of the system, they often require both background knowledge of computing and substantial investment of the user's time. Users of today's interactive systems, however, include a considerable number of non-computer professionals. The prolifera0252-7308/85/$3.30
© Elsevier Sequoia/Printed in The! Netherlands
260 tion of individual computer work stations, equipped with various interactive application software, increases the need for faster user self-instruction and better communicative system dialogues. The research reported below is an attempt to address this problem by studying the application of software technology in the dialogue design process. All interactive programs require dialogue management functions. In the survey by Sutton and Sprague [2], the proportion of code dedicated to the handling of u s e r - c o m p u t e r interface was shown to be greater than 60%. These functions include displaying information in differing forms, accepting entries from the user, coordinating with other functional components of a program, etc. Dialogue management ensures the delivery of consistent, complete, flexible and recoverable computer system dialogues by providing guidelines and software tools for both defining the dialogues and developing sharable dialogue functions. Despite the emerging needs for developing these functions, traditional system design has not properly addressed dialogue design issues. The use of various dialogue forms to represent different processes and data residing in the computer system is itself a complex issue. An identical process (e.g. duplicating an object) may utilize different dialogues and the same data (e.g. a record in the data base) may also be presented differently across various application programs. As the number of processes a n d data sets grows, dialogue design may become unmanageable. Further, the design of easy-to-use dialogues is complicated by the need for flexibility and adaptability in accommodating different classes of users (e.g. novice versus expert). The other two factors that software dialogue designers have to cope with are the need to incorporate new technologies for computer dialogues, such as those used for input and display, and the need to provide alternative forms of dialogue for the resulting information in unstructured decision environments.
2. Dialogue design issues Recent research in areas related to u s e r - c o m p u t e r interaction has suggested several issues to be studied in dialogue management. These issues can be classified as consistency, flexibility, efficiency, adaptability, integrity, recovery, shareability and completeness. We now briefly examine each in turn.
2.1. Consistency Dialogue consistency refers to the rules governing the organization of dialogue entities [3], the syntax abbreviation [4], the interaction methods [5, 6], response time [7], spatial arrangement [8], the handling of user errors [9], effects of dialogue entities [10], etc. The significance of this issue in the design could be discerned in the design of the Xerox Star work station, which has now become a model for the dialogue design of several desktop computers.
261 2.2. Flexibility A flexible dialogue environment provides different dialogue methods for different classes of users under decision situations. For instance, Carey [11] emphasized the difference between frequent users and beginning users, and Benbasat and Wand [4] studied the use of different styles of dialogue by people of different abilities (e.g. heuristic versus analytic). Carlson et al. [12] proposed the need for providing alternative information representations in unstructured decision environments. Thimbleby [13], in his study of dialogue determination, discussed in detail how dialogue flexibility affects the user's performance. Bailey and Pearson [14] also identified flexibility as a major factor in determining user satisfaction. 2.3. Efficiency The time and effort required for the completion of a dialogue session and the time required to learn to use the system are major factors in dialogue efficiency. Carey [ 11 ] reported that efficiency was a critical factor affecting l!requent computer users. Card et al. [15] studied keystroke actions to evaluate interaction efficiency. From a learning viewpoint, computer-guided style dialogues are usually more efficient than user-guided style dialogues but less efficient in the aspect of interaction [7]. 2.4. A d a p t a b i l i t y An adaptable computer system changes the way in which dialogues are conducted as the state of the user (e.g. knowledge, intention, familiarity, etc.) changes. Treu [16] defined a four-stage learning model, which was expanded to five stages by Mozeico [17]. Mozeico further designed a system that provided dialogues of different forms for users at different stages and identified positive effects of user learning. Thimbleby's study [13] of dialogue determination provided insight into the effect of dialogue structure ~e.g. rigid versus flexible) on usage. 2.5. Integrity Dialogue integrity relates the degree of correctness and relevance of dialogues to actual system functionalities. Since the user relies on dialogues to understand and predict the behavior of the system [5, 18, 19], dialogue integrity must be maintained through the system's life cycle. .2.6. R e c o v e r y It must be possible to recover from mistakes made during the dialogue process with relatively little user effort. Bannon et al. [20] recognized that the user's ability to suspend and resume operations is critical to task performance. The recent trend of using specialized function keys to undo and redo operations reflects the importance of recovery. The issues involved, however, become more complicated when the complexity of dialogue structure increases. For example, recovery at different levels of operation cannot be completed unless the system keeps track of all interactions; this bookkeeping, however, may become a major overhead in the system's operations.
262
2.7. Shareability As the definitions of dialogues are separated from the procedures for processing, dialogues can be shared by applications utilizing the same dialogue structure [21]. In addition, dialogue management functions can also be shared by applications so as to reduce system development effort. Shareable dialogues have the benefits of productivity enhancement and reduced storage requirements for dialogue definitions; interaction consistency and integrity can also be facilitated. 2.8. Completeness Incomplete dialogues are never "friendly" enough, regardless of the technologies used. Dialogue completeness is measured in terms of both the performative and the informative dialogue entities that are incorporated in the design [22]. Gaines [5] emphasized that a design is incomplete unless the user's model is incorporated. The design of informative messages for errors and help [23, 24], for example, is important in improving the user's overall performance when using the system.
3. Dialogue management architecture A well defined architecture for dialogue management emerges from an understanding of the complexities involved in the dialogue design process. Dividing the design process into manageable stages allows for complexity decomposition. Thus, a hierarchical representation of design problems can be obtained; design is also structured and simplified. Furthermore, software tools can be used to facilitate various design activities in each layer of the design hierarchy. Protocols, which are sets of rules that define interfaces between adjacent layers of software, are devised in order to eliminate one layer of the software's involvement with the internal procedural complexities of other layers. As a result, this functionally layered architecture can be used to assist in solving complex dialogue design problems in a simplified and systematic fashion. Aiming at the reduction of complexity, the proposed architecture is divided into four layers: environment interface, interface control, dialogue generation and dialogue execution. Clearly defined protocols are defined for the layers to interface with each other in a structured and simplified fashion. This architecture is illustrated in Figs. 1 and 2. In the center of Fig. 1 is the layer o f dialogue execution, which is a control center that coordinates, schedules and controls the delivery of dialogues. Adjacent to this is the layer of dialogue generation, in which the dialogue models are defined and stored and dialogue management functions are created. At the front end is the layer of environment interface software that collects and profiles attributes of various technologies, users and tasks. Between the dialogue generation layer and the environment interface layer is the layer of interface control, which provides a transparent transforma-
263 nformGtion technologf
{ Fig. 1. An architecture for generalized dialogue management: EI, environment interface; IC, interface control ; DG, dialogue generation ; DE, dialogue execution.
tion so that the execution and generation of dialogues can function independently of specific technologies, users or task requirements. A functional overview and the protocols are further illustrated in Fig. 2. In the figure, the interface control managers examine the attributes created by the front end software in the environment interface layer and perform analyses based on the knowledge stored in the knowledge base. The results are the data base, which contains the primitives necessary for dialogue modeling, and the knowledge base, which contains procedural specifications that could be used to generate the dialogue management functions. The data base is then used for the purpose of dialogue modeling through the computer-aided dialogue definition generator. The knowledge base is used to create the dialogue management functions through the use of a dialogue management function generator. The dialogue definition generator and the dialogue management function generator together constitute the dialogue generation layer. In the dialogue execution layer, the dialogue management functions are divided into two types: semantic processing and syntactic processing. The data bases that contain the definitions of the semantic and syntactic models are then accessed by the dialogue manager to invoke dialogue functions on behalf of the application systems. Various data bases,
264
Environment interface
[
Front end units
interface control managment
J
Interface control managers
Dialogue generation
Dialogue execution
I Dialogue management functions generator
I
~
Dialoguemodel ] definitiongenerator
Dialogue tmanager Syntactic processing I Semanticprocessing
V
I
Application systems
-~
_] -[
Model and data management
Fig. 2. F u n c t i o n a l o v e r v i e w of t h e dialogue m a n a g e m e n t a r c h i t e c t u r e .
which are used by adjacent layers to communicate with each other, must follow the protocols agreed by the layers. Consequently, functions on each layer can be performed freely w i t h o u t concern for the internal procedural complexities of other layers.
3.1. E n v i r o n m e n t interface layer: front end units The responsibilities of the environment interface layer are to collect critical attributes [25] concerning information technology, task and user. Information technology attributes refer to both hardware and software. Examples include video attributes, graphic attributes and software for interactive i n p u t / o u t p u t . Since there are several classes of display devices (e.g. m o n o c h r o m e versus graphics), there will be one front-end unit for each class of device. Significant task attributes include task frequency, activity flow, time distribution, etc. There also exist classes of tasks that utilize different classes of dialogue techniques. For example, a form filling technique can usually be used to handle data retrieval since this is a very structured task. On the other hand, expert consultation types of task are unstructured and will require the use of techniques such as question/answer.
265 I m p o r t a n t user attributes include the user's knowledge, familiarity and skill level, which can in turn be used to classify users (e.g. novice, casual and expert). Different dialogue techniques are then used for different user classes. As a result, different front-end units are required to profile different classes of information technologies, tasks and users. This level of support is provided by a mix of designer's functions and c o m p u t e r software. A u t o m a t e d software has been used to study task attributes 1126, 27]. I n f o r m a t i o n technology attributes can be obtained either f r o m manual d o c u m e n t a t i o n or generated by the c o m p u t e r if a library of i n fo r matio n is maintained. Experimental environments can be used to log the user activities in order to determine the user's skill level. A u t o m a t e d software support is nevertheless incomplete. A designer must participate in great depth to obtain a c om pl et e profile.
3.2. Interface control layer: interface control manager The functions of the interface control layer are to study environmental attributes in order to suggest valid dialogue entities and their grouping, dialogue techniques to be used, etc. For the information technology, the functions are determining relationships between technology attributes so that in f o r matio n can be presented to the user w i t h o u t concern for differences in the hardware devices and studying the suitability of various dialogue techniques for each class of interface device. Task attributes have the greatest impact on dialogue design. The task interface control manager will suggest alternative commands, data and their forms, and the arrangement of c o m m a n d s and data. The user interface control manager analyzes the user attributes and suggests suitable dialogue techniques and additional entities necessary to assist the user. The o u t p u t s from this layer are data bases con1;aining the resulting r e c o m m e n d a t i o n s encoded in terminologies and formats ~;hat will be u n d e r s t o o d by the dialogue generation layer. A knowledge base approach can be used for autotnated software support. ]Different display devices may use the same procedures for display handling. Consequently, the rules for utilizing the attributes may be generalized and recorded in the knowledge base. The attributes of the task and the user may also suggest requirements for higher level interactive functions. For example, the functions for accepting and validating the input could be programmed differently, such as accepting a character and validating the character immediately rather than ac.cepting the whole field and then validatmg the data entered. The decisions are d e p e n d e n t on the task organization and the user's skill and experience, bot h of which should be recorded in the knowledge base. However, most of the support described above has been provided by the designer rather than c o m p u t e r aided design software. Despite the research being c o n d u c t e d in the area of a u t o m a t e d design/code generation, the ability to p e r f o r m intelligent t r a n s f o r m a t i o n is still rarely f o u n d in any c o m p u t e r software. With recent research in applying artificial intelligence technology to system design [28], a u t o m a t e d interface cont rol software can
266
Interface control managers
Sample knowledge base for: Computer environment: Intelligent display devices must have a way to perform cursor addressing: leading characters followed by one or two characters, followed by the x and y coordinates. User: if heuristic then aggregate presentation preferred if typing low then push buttons preferred if no previous experience then computer guided dialogue with forced choice, and more manual assistance if high experience but not familiar with system, computer guided dialogue and user guided dialogue with free response preferred, but with on-line help if low familiarity, then help more and vice versa if low memory limit, fewer objects displayed Task: basic data and command attributes are inherited for less frequent task computer guided dialogue are preferred regardless of the differences in users current/past dialogue methods, if they can be simulated, are preferred at the beginning stage of the learning, while more advanced mechanisms can be introduced through further education (on line or manual) current/past dialogue styles, if they can be simulated, are preferred, eg., the full screen of form to simulate the form for data entry definitions of working context for dialogue are based on the relationship between models and data. Grouping is based on the semantics. Hierarchy structure is usually used. Information flow is then the most critical factor. This process may be changed in the conceptual model formation sta~e.
Fig. 3. I n t e r f a c e c o n t r o l m a n a g e m e n t a n d the k n o w l e d g e base. In the e x a m p l e s h o w n , t h e processing k n o w l e d g e base handles cursor addressing for class A display devices via seq u e n c e s esc + [ c h r l + chr2 . . . . ]. The dialogue c o n c e p t s data base h a n d l e s c o m m a n d att r i b u t e s t o initiate the o p e r a t i o n , data a t t r i b u t e s for decision e n t r y and message a t t r i b u t e s for help.
n o w be used to aid system design. For example, it is feasible to have the interface control layer software make recommendations of dialogue techniques based on rules such as "low speed display devices should n o t be used for screen oriented dialogue styles". Figure 3 describes the processing of the interface control managers.
267
3.3. Dialogue generation layer There are two major c o m p o n e n t s in the dialogue generation layer: the dialogue man ag e m ent functions generator and the dialogue model definition editor. Given the out put s generated by the interface control manager, different lewds of dialogue m a na ge m ent functions can then be programmed. The h)wer level functions, such as cursor addressing and m o v e m e n t , are those used to address the device d e p e n d e n t features. These functions are then used to dew, lop higher level functions such as displaying and reading a string; these in turn can be used to develop complex data display in an area, a window or the entire screen. Lower level incompatibilities can be isolated from the higher level functions. Thus, application systems that do not utilize lower level functions can be transferred from one c o m p u t e r to a n o th er w i t h o u t modification. The results from this generator are a set of dialogue functions for both semantic and syntactic processing. It is feasible to generate the lower level functions automatically, since c o m m o n procedures have been used for most of t o d a y ' s display devices. The American National Standard Institute standard is the primary motivation for this automation. The higher level functions, however, are more c u mb er s o me to generate because t hey have to cope with the c o m p l e x i t y imposed by the task and user attributes. However, the higher level functions are more stable. Changing lower level display devices will not affect them, because of the flexibility provided by the interface control layer. A stable set of higher level functions are used by the semantic manager and the syntactic manager. Generating the dialogue model is an iterative process (see Fig. 4). C" ~wen the data base containing suggestions for alternative dialogue entities ~md their grouping, computer-aided tools can be used to assist in the model general~ion. The benefit of the computer-aided dialogue model generator is i~hat it supports modeling as well as evaluation within a short period of time. This dialogue model generator includes an interactive, dialogue definition editor and dialogue model evaluator; it. generates the data base containing a complete dialogue model, which can be accessed by the dialogue execution layer. This dialogue model can be stored in language form, as the data definition language and data manipulation language for data base management. Dialogue modeling activities at the semantic level include the designation of dialogue entities, specification of interdependence between entities, definition o f operations and conditions to be invoked, grouping the entities into dialogue procedures, selection of appropriate dialogue styles and the formulation of the whole dialogue model. Syntactic dialogue modeling activities include language (words, signs, tables, symbols and the syntactic rules) definition, dialogue technique selection, planning of the screen layouts and designation of interaction mechanisms and methods. A more difficult activity for the designer is to evaluate the design according to a set of criteria. Personal bias and the lack of perform ance m e as u r emen t tools are the major factors hindering the evaluation process.
268
f 'g:::rla ~to/r:::eVe tor ~ Interacti ve didefi alongue editorition
Di alogue model evoluator
Fig. 4. The generation of dialogue definition. The editor specifies entities, interdependences, etc.; the evaluator is used for experiments, prototyping, etc.; the definition data base contains entities, interdependences, procedures, layout, methods of interaction, etc.
However, the use of a dialogue model evaluator to simulate the dialogue process before the actual construction of the information system could provide the information necessary to improve the dialogue model. The evaluator can be viewed as a prototyping machine that offers the designer the capability to visually evaluate the interaction process by activating the semantic and syntactic managers to process the model definitions. Formal specifications are employed to describe the rules of interaction. The state transition diagram can be used to represent the m a n - c o m p u t er interaction in the graphic forms. The Augmented transition diagram [29] was improved from STD. Both STD and ATD allow recursive definitions. The Bacus Normal Form is used to represent the grammar of the interaction. Reisner [3] provided an example of how BNF can be used to describe the user interface of two graphics systems. Jacob [30] used BNF notation in his design of a military message system. It is also helpful if the conceptual dialogue model can be presented as a graph for evaluation. The consistency of the whole dialogue model can be evaluated as described by Reisner.
3.4. Dialogue execution layer The dialogue execution layer consists of two major components: the semantic manager and the syntactic manager (see Fig. 5). This layer's function is to facilitate u s e r - c o m p u t e r dialogue design for all application systems. To do this, a flow control module is needed to interpret the semantics
269
~1
Interactive
dialogue
[~
model generator
Dialogue model evaluator
Interactive dialogue definition editor
/\ /
/
/
/
/
( concept ) ~data base/ (a)-'-----J
Run-time semantic manager Interpre -
rationand flow control
Data convergl,gnJ
Otis ] [
1
--Definition retrieval
Dataand model interface
1
~yntactic ] management interface
(b) Fig. 5. (a)
Semantic processing; (b) syntactic processing.
of the commands and data entered and to invoke the appropriate operations. A semantic manager consists of the dialogue definition retrievel functions, data conversion functions, interface functions to data and model managers, interface functions to the syntactic manager and the interpretation and flow functions. The semantic manager retrieves the semantic dialogue model from the definition data base through the dialogue definition retrieval functions. When any command or datum, or a group of commands and data, are
270 determined to be syntactically correct, the flow control function interprets the values on the basis of the semantic dialogue model. It then determines whether to invoke corresponding operations or to reject the commands or data due to invalid semantics. The data/model interface functions are then activated to transfer control and to transport the data to and from the model and data management functions (e.g. computation and data base update). Finally, in order to properly invoke operation of the various functions, the data entered may have to be converted into the format that the intended function requires. The format requirements may be simple type conversions such as integer to character, or very complex file format conversions for various applications. Data conversion functions can be treated as the functions shared by dialogue, data and model managers. The syntactic manager includes lower level display handling functions that are hardware dependent and higher level functions to handle the interactive i n p u t / o u t p u t operations. The components of the syntactic manager can be functionally divided into definition retrieval, interactive input/output text manipulation management, space management, message management, presentation management, graphics management, voice management and display control. The responsibility of the syntactic manager is to invoke the proper functions to facilitate the generation, manipulation and disposition of necessary dialogue objects when requested by the semantic manager. Lower level functions, such as cursor addressing and character display, have to be modified for different classes of display monitors. However, functions for testing and revealing different classes of monitors can be developed. Based on the results of this testing, proper lower level functions are then invoked. As a consequence, higher level management functions can be invoked freely, regardless of hardware differences. Thus, application systems portability is improved.
4. Comparison with other architectures Other approaches have also been followed to assist in dialogue design, although most of them concentrate on dialogue generation and dialogue execution layers. Rowe and Robson [31] use the higher level language approach in Screen Rigel. The dialogue functions are embedded in PASCAL function calls. In their implementation, field definitions for dialogue descriptions can be obtained from the data dictionary. This eliminates red u n d a n c y and reduces design overhead significantly. Kasik [32] used a similar approach for the Tiger Interactive command and control language (TICCL) for the graphics system Tiger. With TICCL, programmers specify the interface descriptions in a way similar to schema for data base systems. Run time support is obtained through an interpreter. Figure 6 illustrates TICCL's architecture. Some graphics dialogue management systems have been designed to reduce application programming efforts. Systems such as F L A I R and UIMS
271
Application specific menus
//
User interface
Other utilities
Graphics package
Data base management system
User
\
Phystcal storage
Fig. 6. T h e T I C C L a r c h i t e c t u r e .
Pre processor
I
Run-time
Post-processor
I /
I
%
I
/
u,
/definitions/
/
/
/Log
file /
Fig. 7. The UIMS a r c h i t e c t u r e .
have used different t echnol ogy to support graphics programming. F L A I R [331 is a user interface design tool that allows programmers to rapidly p r o t o t y p e a system's m a n - c o m p u t e r interface. In addition to its graphics capabilities, F L A I R also facilitates p r o d u c t i o n of m enu hierarchies so t hat the dialogue process can be observed before the program is written. UIMS [34] consists of m a ny dialogue modules for both design support and run time ex ecu tio n facilitation. Figure 7 shows the architecture of UIMS. 5. Dialogue d e v e l o p m e n t w i t h t h e architecture
The discussion above has focused on a dialogue m anagem ent archit e ctu r e and its impact on the design of m a n - c o m p u t e r interfaces. Benefits
272 accrue in a way similar to that encountered on adoption of data base management: independence, sharing, storage economics, etc. In each layer, computer system designers can concentrate on limited sets of design activities with the help of the a u t o m a t e d software tools. The overall design can be simplified and structured: the EI layer facilitates profiling environmental attributes; the IC layer performs analysis and logical design; the DG layer facilitates the generation of executable dialogue definitions and functions and the DE layer facilitates an effective dialogue delivery on behalf of application systems. As a result, design complexity is reduced due to the four-layer architecture. Put in another way, this hierarchical representation of the design process allows the designer to freely attack problems of multiple complexities. Many sophisticated application systems can be built using this simple architecture. The DG and DI layers essentially become building blocks for application systems. Thus, the implementation of these two layers deserves further attention. There are three alternative approaches. The first is the use of a very high level language that will process the dialogue definition and provide the run time support. The second is the use of an interactive dialogue definition generator and function calls for run time support. The last possibility is a combination of the first two approaches. The objective is to allow designers to concentrate on dialogue modeling w i t h o u t being concerned with the complexities of programming dialogue management functions. The last approach described appears to be the most promising. The designer describes the dialogue model in a language, through any regular editor or through a dialogue definition generator that will also record resulting dialogue specifications in the same language. The designer then develops the system through functions embedded in the programming language or stored in a utility library. The designer is free to exploit the design alternatives by using either the dialogue definition generator, or any regular editor. The evaluator can be utilized to ensure an effective dialogue design. As a result, the designer is freed from much of the procedural complexity encountered during the design process. The resulting system design will be one of the most desirable alternatives. Further, because dialogue managem e n t functions are shared, computer dialogues across applications will be consistent. Dialogue definitions may even be shared by various application systems to further improve dialogue consistency.
6. Advantages of the dialogue management architecture There are several advantages associated with the architecture defined in this paper. (1) The four-layered architecture allows for the decomposition of design complexities into a manageable and hierarchical design representation. As a result, design complexity is reduced and design issues of different com-
273 plexity can be solved systematically. Although simple, this approach can be used to develop basic building blocks for complex application systems. (2',) Separation of the dialogue modeling process from the procedural aspects of the system design allows the designer to concentrate on the semantics and alternative syntax of a dialogue model. It is a great improvement over the situation in which the designer is overwhelmed by the interrelated issues of task, user and technology -- resulting in a situation that may cause him or her to sacrifice attractive design alternatives merely in order to complete the system. (3) It is easier to exploit more design alternatives through the use of ~he definition editor and evaluator in a shorter time period. Easy modification of the design is also achieved through use of the editor. Provided there are no procedural changes in the code, the application system does not even have to be recompiled. (4) The design life cycle can be accelerated by utilizing the support of automated software tools in different layers. Conceptualization, transformation, generation and realization of dialogue design all become more structured. (!5) It is also easier to incorporate new technologies for all applications using the dialogue manager, increasing the flexibility and adaptability of dialogue functions. One important characteristic of the proposed architecture is that it anticipates new technology. The design efforts necessary could be reduced because there is no need to change every program to accommodate a new technology. The dialogue management support software is well partitioned functionally so as to minimize the effects on the application programs. (6) Overall communicative power is enhanced through the use of interface control managers and the definition editor. Completeness can be evaluated in the pre-implementation stage. Help and error types of entities can also be requested automatically. Dialogue recovery is handled by the dialogue manager. (7) The integrity of information system dialogue for different applications is better achieved through the use of the definition generator. Applications also share dialogue management functions provided by the dialogue manager so that overall design productivity and reliability is increased. In other words, the consistency of the overall dialogue model is improved. The dialogue efficiency, conversely, can be maintained at a satisfactory level through the centralized support facility. (8) Because of the use of the same run time support tools, the consistency of the interaction methods and mechanisms is guaranteed. These tools are designed to provide a generic set of interaction methods available for all applications. (9) Finally, with the separation of semantic processing from syntactic processing, the architecture facilitates intelligent dialogues for users of different skill levels. Thus, various dialogue forms and advanced technologies, such as windowing, can be more easily accommodated. Furthermore, the
274 f u n c t i o n a l l y layered feature o f the a r c h i t e c t u r e allows the a d d i t i o n o f i n f e r e n c i n g capabilities t h a t can, at run time, m a k e d y n a m i c dialogue adjustm e n t s to b o t h semantic and s y n t a c t i c models.
7. C o n c l u s i o n s T h e design, d e v e l o p m e n t , i m p l e m e n t a t i o n , delivery and m o d i f i c a t i o n o f u s e r - s y s t e m dialogues can be s u p p o r t e d b y an a r c h i t e c t u r e t h a t offers g u i d a n c e o n the analysis and design o f dialogue c o m p o n e n t s and relations. The l a y e r e d f e a t u r e o f this a r c h i t e c t u r e is t h e m o s t i m p o r t a n t , since it allows f o r d e c o m p o s i t i o n o f design activities so as to r e d u c e the overall c o m p l e x i t y . T h r o u g h design guidelines a n d s o f t w a r e s u p p o r t at each layer, dialogue consistency, flexibility, e f f i c i e n c y , a d a p t a b i l i t y , integrity, r e c o v e r y , shareability and c o m p l e t e n e s s are all i m p r o v e d . E m e r g i n g research topics include the s t u d y o f various languages for defining and m a n i p u l a t i n g u s e r - c o m p u t e r dialogues. In addition, the inc o r p o r a t i o n o f artificial intelligence t e c h n o l o g y is necessary t o bring a b o u t d y n a m i c u s e r - c o m p u t e r interface design relating to the s y s t e m ' s ability to a d a p t its dialogues to the changing e n v i r o n m e n t r e p r e s e n t e d b y changing task, user and i n f o r m a t i o n t e c h n o l o g y attributes.
References 1 R. Sprague, Decision Support Systems: A Tutorial, DSS Conference, 1981. 2 J. Sutton and R. Sprague, A study of display generation and management in interactive business applications, Research Report RJ2392, IBM Research Division, Yorktown Heights, NY, 1978. 3 P. Reisner, Formal grammer and human factors design of an interactive graphics system, IEEE Trans. Software Engineering, 7 (2) (1981) 229 - 240. 4 I. Benbasat and Y. Wand, A structured approach to designing human/computer dialogues, Working Paper No. 835, October 1982; A dialogue generator and its use in DSS design, Inf. Manage., 5 (1982) 231 - 241. 5 B. Gaines, The technology of interaction-dialogue programming rules, Int. J. ManMach. Stud., (1981) 133 - 150. 6 T. Moran, The command language grammer: a representation for the user interface of interactive computer systems, Int. Jo Man-Mach. Stud., 15 (1981) 3 - 50. 7 L. Miller and J. Thomas, Jr., Behavioral issues in the use of interactive systems, Int. J. Man-Mach. Stud., 9 (1977) 509 - 536. 8 Martine (1973). 9 V: Morland, Human factors guidelines for terminal interface design, Commun. ACM, July (1983) 484 - 494. 10 J. Carroll, The adventure of getting to know a computer, Computer, November (1982) 49 - 58. 11 T. Carey, User differences in interface design, Computer, (1982) 14 - 20. 12 E. Carlson, B. Grace and J. Sutton, Case studies of end user requirements for interactive problem-solving systems, MIS Q., March (1977) 51 - 63. 13 H. Thimbleby, Dialogue determination, Int. J. Man-Mach. Stud., 13 (1980) 295304.
275 14 J. Bailey a n d Pearson, D e v e l o p m e n t of a t o o l for m e a s u r i n g a n d a n a l y z i n g c o m p u t e r user satisfaction, Manage. Sci., 29 (5) ( 1 9 8 3 ) 54 - 67. 15 Card et al. (1980). 16 S. Treu, A f r a m e w o r k of c h a r a c t e r i s t i c s a p p l i c a b l e to graphical u s e r - c o m p u t e r interact i o n , in S. Treu (ed.), User-Oriented Design o f Interactive Graphics Systems, Association for C o m p u t i n g M a c h i n e r y , New Y o r k , NY, 1 9 7 6 , pp. 61 - 71. t7 H. Mozeico, A h u m a n c o m p u t e r i n t e r f a c e to a c c o m m o d a t e user learning sta~es, Commun. ACM, February ( 1 9 8 2 ) 100 - 104. 18 P. J o n e s , F o u r principles of m a n - c o m p u t e r dialogue, Comput. Aided Des., 10 (3) (1978). [ 9 S m i t h et al. ( 1 9 8 2 ) . 20 L. B a n n o n , A. C y p h e r , S. G r e e n s p a n a n d M. M o n t y , E v a l u a t i o n a n d analysis of users' activity o r g a n i z a t i o n , CHI'83 Proc., 1983, pp. 54 - 57. 21 B. Kuo, Dialogue m o d e l i n g for i n t e r o p e r a b i l i t y in m i c r o - b a s e d w o r k s t a t i o n s , MIS T e c h n i c a l R e p o r t No. 8 4 - 1 2 - 2 - 0 0 1 , U n i v e r s i t y of A r i z o n a , T u c s o n , AZ, 1985. 22 B. K u o a n d B. K o n s y n s k i , U n d e r s t a n d i n g m a n - c o m p u t e r dialogues in ALL-IN-1 e n v i r o n m e n t , MIS T e c h n i c a l R e p o r t No. 8 4 - 0 5 - 1 - 0 0 5 , University of A r i z o n a , T u c s o n , AZ., 1985. 23 M. Dean, H o w a c o m p u t e r s h o u l d talk to people, IBM Syst. J., 21 (4) ( 1 9 8 2 ) 42.4 453. 24 B. iSchneiderman, S y s t e m message design: guidelines a n d e x p e r i m e n t a l results, in A. Barde a n d B. S h n e i d e r m a n (eds.), Directions in Human~Computer Interaction, A b l e x P u b l i s h i n g C o r p o r a t i o n , N o r w o o d , NJ, 1 9 8 2 . 25 B. K u o a n d B. K o n s y n s k i ( 1 9 8 4 ) . 26 J. N u n a m a k e r a n d B. K o n s y n s k i , P L E X S Y S : A s y s t e m d e v e l o p m e n t s y s t e m , Working Paper, University of A r i z o n a , T u c s o n , AZ, 1981. 27 B. K o n s y n s k i , J. K o t t e m a n n , J. N u n a m a k e r a n d J. S t o t t , P L E X S Y S - 8 4 : An i n t e g r a t e d d e v e l o p m e n t e n v i r o n m e n t for i n f o r m a t i o n s y s t e m s , JMIS, I (3) (1985). 28 K. F r e n k e l , Towm'd a u t o m a t i n g t h e s o f t w a r e - d e v e l o p m e n t cycle, Commun. ACM, June ( 1 9 8 5 ) 578 - 589. 29 Woods ( 1 9 7 0 ) . 30 R. J a c o b , Using f o r m a l s p e c i f i c a t i o n s in t h e design of a h u m a n - c o m p u t e r interface, Commun. ACM, April ( 1 9 8 3 ) 2 5 9 - 2 6 4 ; E x e c u t a b l e s p e c i f i c a t i o n s for a h u m a n c o m p u t e r interface, CHI'83 Proc., 1 9 8 3 , pp. 28 - 34. 31 L. R o w e a n d K. Shoens, P r o g r a m m i n g language c o n s t r u c t s for screen d e f i n i t i o n , 1EEE Trans. Software Eng., 9 (1) ( 1 9 8 3 ) 31 - 39. 32 D. Kasik, A user i n t e r f a c e m a n a g e m e n t s y s t e m , Comput. Graphics, 16 (3) {1982) 99 106. 33 P. Wong a n d E. Reid, F L A I R - - user i n t e r f a c e dialogue design toot, Comput. Graphics, 16 (3) ( ] 9 8 2 ) 87 - 98. 34 P. T a n n e r a n d W. B u x t o n , S o m e issues in f u t u r e user i n t e r f a c e m a n a g e m e n t s y s t e m (U][MS) d e v e l o p m e n t , T e c h n i c a l Paper, U n i v e r s i t y of T o r o n t o , T o r o n t o , O n t a r i o , 1983.