- Email: [email protected]
What kind of interface for expert systems?
Expert Systems WithApplications, Vol.2, pp. 195-200,1991
0957-4174/91 $3.00+ .00 © 1991PergamonPressplc
Printedin the USA.
What Kind of Interface for Expert Systems? M A R I E - F R A N C E B A R T H E T AND C H I H A B HANACHI Universit6 Toulouse I, Toulouse, France.
Abstract--This article intends to show how the man-machine interface can be improved in the case o f an expert system through the integration o f concepts borrowed from ergonomics and cognitive psychology. In the first section, we point out the characteristics o f the interface in an expert system as well as its relations with ergonomics and cognitive psychology. In the second section, we show how some expert systems deal with the man-machine interface issue. In the third section, we indicate how we can possibly improve this interface to get closer to the user's logic.
• • • • • • •
commands and data denomination, menu structure, data and results display, commands and data guidance (Help), explanation of the reasoning, interface operations sequencing, and error processing. We shall see in the second section that contrary to what happens with other types of software, these seven parameters can be totally dependent on the design of the Knowledge Base since they can be deduced automatically by the expert system software. Despite what could be commonly thought, this strong coupling between Knowledge Base and interface (which has the advantage of easing programming) may become a source of trouble when it comes to creating a language adapted to the users. During the design of interfaces, in order to improve the man-machine interface, we integrate the following concepts of ergonomics and cognitive psychology: • Functioning a n d user logic (Richard, 1983)--the functioning logic refers to the software structure as perceived by the computer scientist who knows how the machine and the software work. The user logic means the way the user is going to use the software to meet his/her aims. Normally, in case of a given software, there is one functioning logic as well as several user logics. This concept is determinative for the quality of man-machine interface and has an impact on the design of all the different parts of the interface as we shall see in detail in section 3. • Hierarchical planning (Sebilotte, 1987)--this is the way one figures out the work one has to do, starting from one's aims and stepping upward along a treelike pattern of prerequisites to reach the undecomposable operations. Seeking the user's aims may have an impact on the Knowledge Base structure (meta-
1. M A N - M A C H I N E INTERFACE CHARACTERISTICS IN THE CASE of expert systems, improving the m a n machine interface is an important issue. Indeed, when referring to the three objectives of expert systems (Farreny, 1985) of: easily capturing the skill units, exploiting the whole set o f skill units, and easily dealing with a reorganization of all skill units, we notice the first and the second objectives are directly dependent on the quality of the interface between the user and the software. In a principle-based expert system (Farreny, 1985), the man-machine interface is represented by a module which is independent from the other parts of the expert system, as shown in Figure 1. This representation is misleading because it may give the idea that this module is independent from the very conception of the Knowledge Base and has the same degree of generality as the inference engine, that is to say, an independence from the application described in the Knowledge Base. And, indeed, most expert systems propose a non- or hardly modifiable module of interface with the user. Yet, studies (Barthet, 1988; Coutaz, 1986) show that the man-machine interface is made up of two parts: (a) one part that is actually independent from the application and (b) one part linked to the application and even to the type of user. The part which is independent from any application includes the following parameters: (a) general definition of the screenmmono- or multi-windowing, location of the menu, of the error or service messages, and of the place o f work, (b) commands-entering device (mouse, f u n c t i o n - k e y . . . ) ; and (c) common commands---quit, interrupt, cancel . . . . The part linked to the application includes the following seven features: 195
196
M-F. Barthet and C. Hanachi
Prt'nc:ple-b~.Tse#e.s'pe.r/s.:...'s#en~
/ L Supervisor
LANGUAGE t f ) USEDTOEXPP,ESS~__[ Moduleof interface KNOWLEDGE ~
,,INFERENCEENGINE
with the user"
)
!
I i
KNOWLEDGE
BASE
ULES ) I
(
Simple arrowr,commands - Grey arrow:dataand results Capitalletters:most originalfunctions FIGURE 1.
rule) and, thereby, on the reasoning guidance and explanation. • Functioning deformation (Ochanine, Quass, & Zaltman, 1972)--shows that different users take different looks on the same object, depending on their competence (whether they are new to the task or experienced) and on their status within the organization (whether they design or execute). This concept calls for a definition of the different types of software users in order to provide them with an image of this very software which would match their needs; it has an impact on every interface feature. • Experience and automatism--one of the purposes of training is to create, within a human being's mind, a number of automatisms (that is unconscious and fast processes) that help this human being execute his/her task. To allow for the creation of these automatisms, some of the parameters of man-machine interface need to be homogenous, namely input devices, syntax, display, and commands denomination. • Specialized vocabulary--each profession develops its own specialized, functional, and task-adapted vocabulary which must be restituted in man-machine interface. The problem lies in the fact that a particular object may be described by different terminologies. 2. CRITICS O F EXISTING S Y S T E M Expert System Generators (ESG) have changed dramatically since the pioneers (Benchimol, Levine, &
Pomerol, 1986; Brownston, Farrel, Kant, & Martin, 1985; Farreny, 1985) (Emycin, 1979; KAS 1979; OPS5, 1981). The development of environments (elaborated integrated editor, multi-windowing interface to follow the reasoning and the explanations, hybrid knowledge display mode), as well as the evolution toward other softwares (spreadsheet package, database management system, programming language) are making it easier to develop other applications. 2.1. Standard Parameters
A number of ergonomics rules must be respected if we want the applications to be as accessible as possible to designers and to users (who are not always experts in the field). The guarantee of standard options is one of these rules. Standard options are all the commands independent from the application but useful at any time (Barthet, 1988), namely: • the possibilities, at any time, to interrupt a task to carry out another one, • the possibilities to quit at any time; • the possibilities to postpone the task currently under way; • the possibility to transfer data from one task to another; • the memorization of the user's activity (context management) made up of four aspects--interrupted operations, postponed operations, traces of a task, parameters inherent to the user; and
What Kind of Interface for ES? • a help for training (functional guidance and use guidance). In a rich environment, where it becomes necessary to shift from one application to another (ES, spreadsheet package, database management system), these possibilities are essential and even more welcome in a multi-windowing environment. These standard options are frequently useful. They must, therefore, be displayed homogeneously in every software where they appear. This homogeneity criterion is necessary for the user to acquire automatisms, and it will make him/her more available to carry out complex tasks. Yet, when we look through a large number of ESGs, we notice that it is only possible to quit the task or to ask for functional guidanoe. Moreover, even when these options exist, they are rarely presented homogeneously. For instance, in VP-EXPERT, the "quit" key is associated with function keys which change according to the position in the control tree. 2.2. Interface Parameters Which Depend on the
Application 2.2.1. Menu design--ESG Despite an ever-increasing development of environments, ESGs are not easier to use. The number of commands rises but, very often, a use logic fails. Menu design usually refers to an ES functioning logic. Therefore, it is quite c o m m o n to come across menus organized as follows: • inference menu with the following secondary level controls--forward chaining, backward chaining, mixed-mode c h a i n i n g , . . . ; • database menu with the following secondary level controls--edition, compilation; • trace menu with the following secondary level controis--list of all applied rules, elaborated scanning tree . . . . ; • system menu with the following secondary level controls--printing, system controls (this gives access to a spreadsheet, or a database) . . . . . It is clear that this organization is strongly linked to the ES structure and imposes, in a development mode, important displacements throughout the menu in order to achieve certain tasks. Moreover, some particular controls are not suitable for an expert who is not a computer scientist; namely, rules use strategies (forward, backward and mixed-mode chainings . . . . ) and compilation control which should be totally clear to him/her. 2.2.2. Menu Design--ES. In most cases, elaborated ESs present the same interface and the same controls as the ESG used. In the case of a final product intended for a user who will not need to act on the knowledge base, some controls are useless. Yet, freezing them is not sufficient. The menus need to be redefined and
197 adapted to the user. In fact, very few ESGs allow for a redefinition of the menus even though it is necessary to adapt to all types of users to design different menus for each type of user of the ESG (computer scientist, designer, expert) and of the ES (expert or a novice). 2.2.3. Interface in the ESs. The interface is characterized by (1) the information display and (2) the explanation strategy.
2.3. The Information Display There are two types of ESGs for the display of informations at the beginning or at the end of the session: (1) those with a standard display which generate questions automatically as the user explores the data base (VP-EXPERT) and (2) those which make it possible to define screens independently from the Knowledge Base; for instance, the forms manager of G U R U and Interface Builder which enables the user to define windows in a multi-windowing environment. The first of those two types have the advantages to ease the designer's task since they do not ask for a specification of the information display. Yet, at the same time, they do not allow for the definition of other display modes which may be more adapted to the mental representations of different users. Therefore, in most cases, it is preferable to use ESGs of the second type since they make it possible to define an interface with no connection to the Knowledge Base structure. The distinction that we have just made also has an impact on the choice of vocabulary. Indeed, in the ESGs of the first type, the vocabulary used in the interface is absolutely identical to the one used in the Knowledge Base. Yet, we know that there are several specialized vocabularies to describe the same object and that we must provide each type of user with the vocabulary adapted to his/her knowledge. Only the ESGs of the second type allow for several specialized terminologies for the same Knowledge Base. 2.4. The Explanation The explanation uses the interface in two different ways. In the development mode, it is useful for the designer and the expert for a validation of the Knowledge Base. In the use mode, it helps the user know the reason why he/she is being asked a particular question or get a general explanation about the conclusions. In fact, most ESGs permit to associate to every production rule a comment which explains that very rule. During execution, the user may usually ask two types of questions: • when the system questions him/her to establish a fact, he/she may ask why it is important to know about this fact.
198 • when he/she does not understand the deduction of a fact, he/she may ask how this fact was established. The tracer's answer is often limited to the bare list of the comments of the rules applied. Some systems have thought of several levels of explanation (Benchimol, Levine, & Pomerol, 1986): • in Teiresias (integrated module in MYCIN), it is possible to get synthesized answers to some questions, but only through a synthesis of several rule pitches. • in Argument, explanations are provided on a macroscopic level corresponding to the rule package level (notion of macro-explanation). In fact, the design o f levels of explanation must take the user's characteristics into account. For an expert user, whether he/she is a designer or a learner, the explanations may stick to the knowledge representation mode used by the ESGs. If the system is intended for a novice who does not intend to learn, other elements must be considered in the explanation strategy: • the user's language, his/her level of knowledge and his/her aims must be known. • is it necessary to provide him/her with explanations? Why? Which ones? • the explanations must be linked to the interface theme (Vilnet, 1984) (i.e., what we are talking about at the moment) and not only to the knowledge representation mode. 2.4.1. Dividing Up Control. Many people are involved in the development and use of an ES. Let us take, for instance, the case of a system intended to help financial investments for private individuals; here are a certain number a tasks related to it: • the knowledge base is brought up to date occasionally, when laws change or when a new investment type appears. • financial and economic data appear on a spreadsheet and are renewed on a regular basis. • the ES is regularly consulted by Minitel (French system of consultation of databases or services and available to the general public through the telephone network). To define the External Representation (i.e., the part of the interactive application which is visible to the user), it is necessary to define which part of the control the user should be granted. The expert obviously needs a maximum margin of decision. In the aforementioned example, a non-expert employed for maintenance may be in charge of updating data from the spreadsheet. But, for security reasons, allowing him/her to update the knowledge base is absolutely out of the question. The final user can only interrogate the system. In his/her case, the control belongs exclusively to the software. We have just seen that all different ESGs do not behave in the same way as far as interface parameters
M-F. Barthet and C. Hanachi are concerned and that there are organized between the following extremes: • the interface is automatically generated by the ESG, according to the Knowledge Base. • the interface is partly deduced from the Knowledge Base, but the menu structure, the vocabulary, the data display, and the guidance may be defined by the designer. The latter case is more favorable to an agreeable interface. 3. P R O P O S A L S FOR T H E DESIGN O F T H E INTERFACE M O D U L E Figure 2 relocates the whole interface parameters and makes a distinction between those which need to be defined regardless of the interface and those which depend strongly on it. Later on, we shall make a distinction between proposals for: * standard parameters, * parameters independent from the Knowledge Base, and • parameters depending on the Knowledge Base 3.1. Standard Parameters
As far as these parameters are concerned, it is indispensable to conform to the homegeneity parameter to allow for the users to learn automatisms. This homogeneity must, at a minimum, be internal to the ESG, but also external if the ESG is associated with other software (spreadsheet program, databases . . . . ).
Interface
parameters Standard "] parameters J ~
/'Parameterswhichneed r Q,t°tbh:k' ndoewP leenddga: tbafnsemI
(Parametersinherent1 to the apphcation
r P ra 1 ( thedk?Po~n~!tri:o:nase j) Interfacesequencmg I~ Dividingupcontrol Explanation Error processing
Menustructure Datadisplay Vocabulary Guidance FIGURE 2.
What Kind of Interfacefor ES?
199
The homogeneity must apply to: • The vocabulary of standard commands--the name of these is the same no matter what the part of the ESG is so that the user can remember them. The effects are also identical so that the user can anticipate them. • The visual display--an homogeneous display of the different zones of the screen (title, menu, message announcing mistake) enables an experienced user to see the zone he is interested in immediately, without needing the screen. • The designation mode there can be several designation modes according to the users, whether they are experienced or not; but each designation mode should be possible in the whole software. • The syntax--a homogeneous syntax of the interaction language is the only way of minimizing handling mistakes.
with some data which it will analyze and interpret for diagnosis. But, when designing, it may appear necessary to distinguish between several levels: • the computer scientist or the knowledge engineer who acts on the Knowledge Base but also, if necessary, on the inference engine and the interface module. • the expert designer who modifies the Knowledge Base. • the competent designer who may be allowed to modify part of the database; indeed, in an ES, there are usually rules related to knowledge about objects and rules related to know-how. The rules related to objects may be modified by a competent designer, even if he/she is not an expert. On the use level, we can distinguish between occasional use and frequent use, possibly leading to the creation of a personalized Facts Base.
3.2. Parameters Depending on the Knowledge Base
3.2.2. Defining the User's Aims. There are two types of aims: • the user's aims regarding the software, that is, the design or use level he/she wishes; these types of aims help in determining the sharing of guidance between man and machine. It has an impact on the definition of the command language and on the menu structure. • the user's aims regarding his/her problem and, therefore, regarding the Knowledge Base. These aims have an impact on the guidance and the explanation of the reasoning. Example. In case of an ES for financial investment, the user's aims may be to optimize his earnings, ensure his old-age pension, buy a home, or pay less taxes. The level of explanation may depend on these different aims and vary accordingly.
These parameters make up the most complex part of man-machine interface in expert systems. Indeed, just because these parameters can not be made independent from the Knowledge Base, it can prove useful to define, for the same knowledge field, several Knowledge Bases adapted to several users and/or uses. In the first example, designing an ES about "orchids identification," the Knowledge Base can not be the same whether the user is an expert in botany or just an amateur botanist. Indeed, their personal knowledge differs by: • the vocabulary, • the types of questions they are capable of answering, • the order in which these questions are asked, and • the level of the explanations. In the second example, the case of an ES specialized in medical diagnosis, the Knowledge Base is different whether the user is a doctor or a medical student. If it is intended for a doctor, the explanation and the reasoning may be compacted, whereas in case of a medical student, all the medical reasoning leading to the diagnosis will have to be detailed with a view to tuition. It is, therefore, necessary to design a Knowledge Base taking into account the different types of users, the user's aims, and the use logics. 3.2.1. Defining the Different Types of Users. We usually make a distinction between "expert users allowed to insert rules in the knowledge base and ordinary users who have, with the system, relationships similar to those they would have with a human expert" (Farreny, 1985)o But, most of the time, this classification needs to be respecified. There is, of course, always a final user: he/ she who "consults" the expert system and provides it
3.2.3. Defining the User Logics. For each goal concerning the use level of the product, and possibly for each type of user, a use logic must be defined to determine the menu structure and the vocabulary. First example. In user mode, the controls language may be reduced to a minimum and contain only the very controls necessary to the user. They are structured to minimize the user's manipulations of the machine.
Second example. For an expert designer, menus can be organized to ease both his/her design and test tasks. Design menu: Design a Knowledge Base, Test (with two options: execution with specialized expert explanations or with explanations intended for a final user), Access to a spreadsheet, standard Options. Test menu: Test (with two options: execution with specialized expert explanations or with explanations intended for a final user), standard Options.
200 S t a n d a r d O p t i o n s menu." The choice o f vocabulary al-
ways implicitly expresses a type o f logic. For instance, to express the possibility o f reshuffling a Knowledge Base thanks to an editor, "edit" m a y be used in functioning logic and "design" in user logic.
3.3. Interface Parameters Independent From the Knowledge Base For the vocabulary designation, one must make sure that: • all different types o f users e m p l o y the same vocabulary; in case they do not, the interface must be parameterized to adapt to the different types o f users. This r e c o m m e n d a t i o n m a y prove difficult to be set into practice if the interface vocabulary is automatically identical to the Knowledge Base's. • the controls vocabulary is chosen according to a use logic and not a functioning logic; for instance, the word "edit" belongs to a the functioning logic whereas the equivalent in use logic is "design." For the m e n u structure, we must design one m e n u per type o f users. Usually, we distinguish between: • a functioning-logic m e n u for the c o m p u t e r scientist • a user-logic m e n u for the expert • a user-logic m e n u for the final user For the display o f data and results, we must define: • relevant features which help decision-making or understanding. • spatial organizations which differ for different types o f users. For instance, table format for an accountant, graphic format for a b u s i n e s s m a n / w o m a n . For the guidance we should provide:
M-F. Barthet and C. Hanachi
• a functional guidance to explicit each c o m m a n d and each data • a use guidance for every use level o f the software. 4. C O N C L U S I O N In the case o f an Expert System, the way the user considers the system is highly dependent on the knowledge base. As a consequence, even though it m a y prove judicious to m a k e some interface parameters independent o f the kno~vledge base, it is necessary to integrate cognitive ergonomic concepts when designing the knowledge base.
REFERENCES Barthet, M-F. (1988). Logiciels interactifs et ergonomie. Dunod lnformatique.
Benchimol, G., Levine, P., & Pomerol, J-C. (1986). Syst~mesexperts dans l'entreprise. Hermes. Brownston, L., Farrel, R., Kant, E., & Martin, N. (1985). Programruing expert systems in OPS5: An introduction to rule-based programming. Reading, MA: Addison-Wesley. Coutaz, J. (1986). La construction d'inter&ces homme-machine (Report IMAG No. 635), France. Farreny, H. (1985). Syst~mes ewerts: principes et e~emples. Cepadues
Edition. Guru, (1985). Re~,rence manual. Micro Database Systems, Lafayette, IN. Ochanine, Quass, & Zaltman, (1972). Drformation fonctionnelle des images operatives. Journal Questions de Psychologie, 13. Richard, J-F. (1983). Logique du fonetionnement el h~gique d'utilisation (Report No. 202, INRIA), France. Sebilotte, S. (1987). "La planification hidrarchique comme m~;thode d'analyse de la tdehe (Report No. 599, INRIA), France. Vilnat, A. (1984). L'61aborationd'interventions pertinentes dans une conversation homme-machine (Doctoral Dissertation). Pierre et Marie Curie University, Paris VI, France. VP-EXPERT (1987). Reference manual. Paperback Software, SOFTISSIMO: France.
0957-4174/91 $3.00+ .00 © 1991PergamonPressplc
Printedin the USA.
What Kind of Interface for Expert Systems? M A R I E - F R A N C E B A R T H E T AND C H I H A B HANACHI Universit6 Toulouse I, Toulouse, France.
Abstract--This article intends to show how the man-machine interface can be improved in the case o f an expert system through the integration o f concepts borrowed from ergonomics and cognitive psychology. In the first section, we point out the characteristics o f the interface in an expert system as well as its relations with ergonomics and cognitive psychology. In the second section, we show how some expert systems deal with the man-machine interface issue. In the third section, we indicate how we can possibly improve this interface to get closer to the user's logic.
• • • • • • •
commands and data denomination, menu structure, data and results display, commands and data guidance (Help), explanation of the reasoning, interface operations sequencing, and error processing. We shall see in the second section that contrary to what happens with other types of software, these seven parameters can be totally dependent on the design of the Knowledge Base since they can be deduced automatically by the expert system software. Despite what could be commonly thought, this strong coupling between Knowledge Base and interface (which has the advantage of easing programming) may become a source of trouble when it comes to creating a language adapted to the users. During the design of interfaces, in order to improve the man-machine interface, we integrate the following concepts of ergonomics and cognitive psychology: • Functioning a n d user logic (Richard, 1983)--the functioning logic refers to the software structure as perceived by the computer scientist who knows how the machine and the software work. The user logic means the way the user is going to use the software to meet his/her aims. Normally, in case of a given software, there is one functioning logic as well as several user logics. This concept is determinative for the quality of man-machine interface and has an impact on the design of all the different parts of the interface as we shall see in detail in section 3. • Hierarchical planning (Sebilotte, 1987)--this is the way one figures out the work one has to do, starting from one's aims and stepping upward along a treelike pattern of prerequisites to reach the undecomposable operations. Seeking the user's aims may have an impact on the Knowledge Base structure (meta-
1. M A N - M A C H I N E INTERFACE CHARACTERISTICS IN THE CASE of expert systems, improving the m a n machine interface is an important issue. Indeed, when referring to the three objectives of expert systems (Farreny, 1985) of: easily capturing the skill units, exploiting the whole set o f skill units, and easily dealing with a reorganization of all skill units, we notice the first and the second objectives are directly dependent on the quality of the interface between the user and the software. In a principle-based expert system (Farreny, 1985), the man-machine interface is represented by a module which is independent from the other parts of the expert system, as shown in Figure 1. This representation is misleading because it may give the idea that this module is independent from the very conception of the Knowledge Base and has the same degree of generality as the inference engine, that is to say, an independence from the application described in the Knowledge Base. And, indeed, most expert systems propose a non- or hardly modifiable module of interface with the user. Yet, studies (Barthet, 1988; Coutaz, 1986) show that the man-machine interface is made up of two parts: (a) one part that is actually independent from the application and (b) one part linked to the application and even to the type of user. The part which is independent from any application includes the following parameters: (a) general definition of the screenmmono- or multi-windowing, location of the menu, of the error or service messages, and of the place o f work, (b) commands-entering device (mouse, f u n c t i o n - k e y . . . ) ; and (c) common commands---quit, interrupt, cancel . . . . The part linked to the application includes the following seven features: 195
196
M-F. Barthet and C. Hanachi
Prt'nc:ple-b~.Tse#e.s'pe.r/s.:...'s#en~
/ L Supervisor
LANGUAGE t f ) USEDTOEXPP,ESS~__[ Moduleof interface KNOWLEDGE ~
,,INFERENCEENGINE
with the user"
)
!
I i
KNOWLEDGE
BASE
ULES ) I
(
Simple arrowr,commands - Grey arrow:dataand results Capitalletters:most originalfunctions FIGURE 1.
rule) and, thereby, on the reasoning guidance and explanation. • Functioning deformation (Ochanine, Quass, & Zaltman, 1972)--shows that different users take different looks on the same object, depending on their competence (whether they are new to the task or experienced) and on their status within the organization (whether they design or execute). This concept calls for a definition of the different types of software users in order to provide them with an image of this very software which would match their needs; it has an impact on every interface feature. • Experience and automatism--one of the purposes of training is to create, within a human being's mind, a number of automatisms (that is unconscious and fast processes) that help this human being execute his/her task. To allow for the creation of these automatisms, some of the parameters of man-machine interface need to be homogenous, namely input devices, syntax, display, and commands denomination. • Specialized vocabulary--each profession develops its own specialized, functional, and task-adapted vocabulary which must be restituted in man-machine interface. The problem lies in the fact that a particular object may be described by different terminologies. 2. CRITICS O F EXISTING S Y S T E M Expert System Generators (ESG) have changed dramatically since the pioneers (Benchimol, Levine, &
Pomerol, 1986; Brownston, Farrel, Kant, & Martin, 1985; Farreny, 1985) (Emycin, 1979; KAS 1979; OPS5, 1981). The development of environments (elaborated integrated editor, multi-windowing interface to follow the reasoning and the explanations, hybrid knowledge display mode), as well as the evolution toward other softwares (spreadsheet package, database management system, programming language) are making it easier to develop other applications. 2.1. Standard Parameters
A number of ergonomics rules must be respected if we want the applications to be as accessible as possible to designers and to users (who are not always experts in the field). The guarantee of standard options is one of these rules. Standard options are all the commands independent from the application but useful at any time (Barthet, 1988), namely: • the possibilities, at any time, to interrupt a task to carry out another one, • the possibilities to quit at any time; • the possibilities to postpone the task currently under way; • the possibility to transfer data from one task to another; • the memorization of the user's activity (context management) made up of four aspects--interrupted operations, postponed operations, traces of a task, parameters inherent to the user; and
What Kind of Interface for ES? • a help for training (functional guidance and use guidance). In a rich environment, where it becomes necessary to shift from one application to another (ES, spreadsheet package, database management system), these possibilities are essential and even more welcome in a multi-windowing environment. These standard options are frequently useful. They must, therefore, be displayed homogeneously in every software where they appear. This homogeneity criterion is necessary for the user to acquire automatisms, and it will make him/her more available to carry out complex tasks. Yet, when we look through a large number of ESGs, we notice that it is only possible to quit the task or to ask for functional guidanoe. Moreover, even when these options exist, they are rarely presented homogeneously. For instance, in VP-EXPERT, the "quit" key is associated with function keys which change according to the position in the control tree. 2.2. Interface Parameters Which Depend on the
Application 2.2.1. Menu design--ESG Despite an ever-increasing development of environments, ESGs are not easier to use. The number of commands rises but, very often, a use logic fails. Menu design usually refers to an ES functioning logic. Therefore, it is quite c o m m o n to come across menus organized as follows: • inference menu with the following secondary level controls--forward chaining, backward chaining, mixed-mode c h a i n i n g , . . . ; • database menu with the following secondary level controls--edition, compilation; • trace menu with the following secondary level controis--list of all applied rules, elaborated scanning tree . . . . ; • system menu with the following secondary level controls--printing, system controls (this gives access to a spreadsheet, or a database) . . . . . It is clear that this organization is strongly linked to the ES structure and imposes, in a development mode, important displacements throughout the menu in order to achieve certain tasks. Moreover, some particular controls are not suitable for an expert who is not a computer scientist; namely, rules use strategies (forward, backward and mixed-mode chainings . . . . ) and compilation control which should be totally clear to him/her. 2.2.2. Menu Design--ES. In most cases, elaborated ESs present the same interface and the same controls as the ESG used. In the case of a final product intended for a user who will not need to act on the knowledge base, some controls are useless. Yet, freezing them is not sufficient. The menus need to be redefined and
197 adapted to the user. In fact, very few ESGs allow for a redefinition of the menus even though it is necessary to adapt to all types of users to design different menus for each type of user of the ESG (computer scientist, designer, expert) and of the ES (expert or a novice). 2.2.3. Interface in the ESs. The interface is characterized by (1) the information display and (2) the explanation strategy.
2.3. The Information Display There are two types of ESGs for the display of informations at the beginning or at the end of the session: (1) those with a standard display which generate questions automatically as the user explores the data base (VP-EXPERT) and (2) those which make it possible to define screens independently from the Knowledge Base; for instance, the forms manager of G U R U and Interface Builder which enables the user to define windows in a multi-windowing environment. The first of those two types have the advantages to ease the designer's task since they do not ask for a specification of the information display. Yet, at the same time, they do not allow for the definition of other display modes which may be more adapted to the mental representations of different users. Therefore, in most cases, it is preferable to use ESGs of the second type since they make it possible to define an interface with no connection to the Knowledge Base structure. The distinction that we have just made also has an impact on the choice of vocabulary. Indeed, in the ESGs of the first type, the vocabulary used in the interface is absolutely identical to the one used in the Knowledge Base. Yet, we know that there are several specialized vocabularies to describe the same object and that we must provide each type of user with the vocabulary adapted to his/her knowledge. Only the ESGs of the second type allow for several specialized terminologies for the same Knowledge Base. 2.4. The Explanation The explanation uses the interface in two different ways. In the development mode, it is useful for the designer and the expert for a validation of the Knowledge Base. In the use mode, it helps the user know the reason why he/she is being asked a particular question or get a general explanation about the conclusions. In fact, most ESGs permit to associate to every production rule a comment which explains that very rule. During execution, the user may usually ask two types of questions: • when the system questions him/her to establish a fact, he/she may ask why it is important to know about this fact.
198 • when he/she does not understand the deduction of a fact, he/she may ask how this fact was established. The tracer's answer is often limited to the bare list of the comments of the rules applied. Some systems have thought of several levels of explanation (Benchimol, Levine, & Pomerol, 1986): • in Teiresias (integrated module in MYCIN), it is possible to get synthesized answers to some questions, but only through a synthesis of several rule pitches. • in Argument, explanations are provided on a macroscopic level corresponding to the rule package level (notion of macro-explanation). In fact, the design o f levels of explanation must take the user's characteristics into account. For an expert user, whether he/she is a designer or a learner, the explanations may stick to the knowledge representation mode used by the ESGs. If the system is intended for a novice who does not intend to learn, other elements must be considered in the explanation strategy: • the user's language, his/her level of knowledge and his/her aims must be known. • is it necessary to provide him/her with explanations? Why? Which ones? • the explanations must be linked to the interface theme (Vilnet, 1984) (i.e., what we are talking about at the moment) and not only to the knowledge representation mode. 2.4.1. Dividing Up Control. Many people are involved in the development and use of an ES. Let us take, for instance, the case of a system intended to help financial investments for private individuals; here are a certain number a tasks related to it: • the knowledge base is brought up to date occasionally, when laws change or when a new investment type appears. • financial and economic data appear on a spreadsheet and are renewed on a regular basis. • the ES is regularly consulted by Minitel (French system of consultation of databases or services and available to the general public through the telephone network). To define the External Representation (i.e., the part of the interactive application which is visible to the user), it is necessary to define which part of the control the user should be granted. The expert obviously needs a maximum margin of decision. In the aforementioned example, a non-expert employed for maintenance may be in charge of updating data from the spreadsheet. But, for security reasons, allowing him/her to update the knowledge base is absolutely out of the question. The final user can only interrogate the system. In his/her case, the control belongs exclusively to the software. We have just seen that all different ESGs do not behave in the same way as far as interface parameters
M-F. Barthet and C. Hanachi are concerned and that there are organized between the following extremes: • the interface is automatically generated by the ESG, according to the Knowledge Base. • the interface is partly deduced from the Knowledge Base, but the menu structure, the vocabulary, the data display, and the guidance may be defined by the designer. The latter case is more favorable to an agreeable interface. 3. P R O P O S A L S FOR T H E DESIGN O F T H E INTERFACE M O D U L E Figure 2 relocates the whole interface parameters and makes a distinction between those which need to be defined regardless of the interface and those which depend strongly on it. Later on, we shall make a distinction between proposals for: * standard parameters, * parameters independent from the Knowledge Base, and • parameters depending on the Knowledge Base 3.1. Standard Parameters
As far as these parameters are concerned, it is indispensable to conform to the homegeneity parameter to allow for the users to learn automatisms. This homogeneity must, at a minimum, be internal to the ESG, but also external if the ESG is associated with other software (spreadsheet program, databases . . . . ).
Interface
parameters Standard "] parameters J ~
/'Parameterswhichneed r Q,t°tbh:k' ndoewP leenddga: tbafnsemI
(Parametersinherent1 to the apphcation
r P ra 1 ( thedk?Po~n~!tri:o:nase j) Interfacesequencmg I~ Dividingupcontrol Explanation Error processing
Menustructure Datadisplay Vocabulary Guidance FIGURE 2.
What Kind of Interfacefor ES?
199
The homogeneity must apply to: • The vocabulary of standard commands--the name of these is the same no matter what the part of the ESG is so that the user can remember them. The effects are also identical so that the user can anticipate them. • The visual display--an homogeneous display of the different zones of the screen (title, menu, message announcing mistake) enables an experienced user to see the zone he is interested in immediately, without needing the screen. • The designation mode there can be several designation modes according to the users, whether they are experienced or not; but each designation mode should be possible in the whole software. • The syntax--a homogeneous syntax of the interaction language is the only way of minimizing handling mistakes.
with some data which it will analyze and interpret for diagnosis. But, when designing, it may appear necessary to distinguish between several levels: • the computer scientist or the knowledge engineer who acts on the Knowledge Base but also, if necessary, on the inference engine and the interface module. • the expert designer who modifies the Knowledge Base. • the competent designer who may be allowed to modify part of the database; indeed, in an ES, there are usually rules related to knowledge about objects and rules related to know-how. The rules related to objects may be modified by a competent designer, even if he/she is not an expert. On the use level, we can distinguish between occasional use and frequent use, possibly leading to the creation of a personalized Facts Base.
3.2. Parameters Depending on the Knowledge Base
3.2.2. Defining the User's Aims. There are two types of aims: • the user's aims regarding the software, that is, the design or use level he/she wishes; these types of aims help in determining the sharing of guidance between man and machine. It has an impact on the definition of the command language and on the menu structure. • the user's aims regarding his/her problem and, therefore, regarding the Knowledge Base. These aims have an impact on the guidance and the explanation of the reasoning. Example. In case of an ES for financial investment, the user's aims may be to optimize his earnings, ensure his old-age pension, buy a home, or pay less taxes. The level of explanation may depend on these different aims and vary accordingly.
These parameters make up the most complex part of man-machine interface in expert systems. Indeed, just because these parameters can not be made independent from the Knowledge Base, it can prove useful to define, for the same knowledge field, several Knowledge Bases adapted to several users and/or uses. In the first example, designing an ES about "orchids identification," the Knowledge Base can not be the same whether the user is an expert in botany or just an amateur botanist. Indeed, their personal knowledge differs by: • the vocabulary, • the types of questions they are capable of answering, • the order in which these questions are asked, and • the level of the explanations. In the second example, the case of an ES specialized in medical diagnosis, the Knowledge Base is different whether the user is a doctor or a medical student. If it is intended for a doctor, the explanation and the reasoning may be compacted, whereas in case of a medical student, all the medical reasoning leading to the diagnosis will have to be detailed with a view to tuition. It is, therefore, necessary to design a Knowledge Base taking into account the different types of users, the user's aims, and the use logics. 3.2.1. Defining the Different Types of Users. We usually make a distinction between "expert users allowed to insert rules in the knowledge base and ordinary users who have, with the system, relationships similar to those they would have with a human expert" (Farreny, 1985)o But, most of the time, this classification needs to be respecified. There is, of course, always a final user: he/ she who "consults" the expert system and provides it
3.2.3. Defining the User Logics. For each goal concerning the use level of the product, and possibly for each type of user, a use logic must be defined to determine the menu structure and the vocabulary. First example. In user mode, the controls language may be reduced to a minimum and contain only the very controls necessary to the user. They are structured to minimize the user's manipulations of the machine.
Second example. For an expert designer, menus can be organized to ease both his/her design and test tasks. Design menu: Design a Knowledge Base, Test (with two options: execution with specialized expert explanations or with explanations intended for a final user), Access to a spreadsheet, standard Options. Test menu: Test (with two options: execution with specialized expert explanations or with explanations intended for a final user), standard Options.
200 S t a n d a r d O p t i o n s menu." The choice o f vocabulary al-
ways implicitly expresses a type o f logic. For instance, to express the possibility o f reshuffling a Knowledge Base thanks to an editor, "edit" m a y be used in functioning logic and "design" in user logic.
3.3. Interface Parameters Independent From the Knowledge Base For the vocabulary designation, one must make sure that: • all different types o f users e m p l o y the same vocabulary; in case they do not, the interface must be parameterized to adapt to the different types o f users. This r e c o m m e n d a t i o n m a y prove difficult to be set into practice if the interface vocabulary is automatically identical to the Knowledge Base's. • the controls vocabulary is chosen according to a use logic and not a functioning logic; for instance, the word "edit" belongs to a the functioning logic whereas the equivalent in use logic is "design." For the m e n u structure, we must design one m e n u per type o f users. Usually, we distinguish between: • a functioning-logic m e n u for the c o m p u t e r scientist • a user-logic m e n u for the expert • a user-logic m e n u for the final user For the display o f data and results, we must define: • relevant features which help decision-making or understanding. • spatial organizations which differ for different types o f users. For instance, table format for an accountant, graphic format for a b u s i n e s s m a n / w o m a n . For the guidance we should provide:
M-F. Barthet and C. Hanachi
• a functional guidance to explicit each c o m m a n d and each data • a use guidance for every use level o f the software. 4. C O N C L U S I O N In the case o f an Expert System, the way the user considers the system is highly dependent on the knowledge base. As a consequence, even though it m a y prove judicious to m a k e some interface parameters independent o f the kno~vledge base, it is necessary to integrate cognitive ergonomic concepts when designing the knowledge base.
REFERENCES Barthet, M-F. (1988). Logiciels interactifs et ergonomie. Dunod lnformatique.
Benchimol, G., Levine, P., & Pomerol, J-C. (1986). Syst~mesexperts dans l'entreprise. Hermes. Brownston, L., Farrel, R., Kant, E., & Martin, N. (1985). Programruing expert systems in OPS5: An introduction to rule-based programming. Reading, MA: Addison-Wesley. Coutaz, J. (1986). La construction d'inter&ces homme-machine (Report IMAG No. 635), France. Farreny, H. (1985). Syst~mes ewerts: principes et e~emples. Cepadues
Edition. Guru, (1985). Re~,rence manual. Micro Database Systems, Lafayette, IN. Ochanine, Quass, & Zaltman, (1972). Drformation fonctionnelle des images operatives. Journal Questions de Psychologie, 13. Richard, J-F. (1983). Logique du fonetionnement el h~gique d'utilisation (Report No. 202, INRIA), France. Sebilotte, S. (1987). "La planification hidrarchique comme m~;thode d'analyse de la tdehe (Report No. 599, INRIA), France. Vilnat, A. (1984). L'61aborationd'interventions pertinentes dans une conversation homme-machine (Doctoral Dissertation). Pierre et Marie Curie University, Paris VI, France. VP-EXPERT (1987). Reference manual. Paperback Software, SOFTISSIMO: France.