knowledge-based expert systems: user interface implications

ELSEVIER

Advances in Engineering Software 28 (1997) 31-41 0 1997 Elsevier Science Limited

Printed in Great Britain. All rights reserved PIl:SO965-9978(96)00030-O 0965-9978/97/$17.00

Knowledge-based expert systems: user interface implications

A. Berrais Abha College of Technology, POB 238, Saudi Arabia

(Received for publication 24 July 1996)

A good user interface is a necessity for the success of knowledge-based expert systems. Issues such as user requirements, user model and system model have been given insufficient attention in the development of the majority of many such systems, particularly those for design applications. This paper discusses the requirements, the benefits and the problems of building user interfaces for knowledge-based expert systems. The notions of a user model and system model are discussed and their impact on the success of user interfaces considered. The paper concludes with a description of the user interface developed for a knowledge-based design tool for preliminary seismic design of reinforced concrete buildings. 0 1997 Elsevier Science Limited. All rights reserved.

Key words: knowledge-based expert system, user interface, user model, system model, user requirements.

1 INTRODUCTI’ON tools, the hardware environment and the intended function of the KBES.

The user interfac,e stands between the user and the The majority of prototype KBESs for civil engineer- application program, and facilitates the communication ing applications reviewed in recent papers,lP5 particu- and interaction between the two. It can be considered as larly those relating to design applications, do not include the channel in which the user can interact with the reference to a user model or tackle the problem of user internal processes of the application program (and vice requirements in detail. Indeed, in many cases the versa). The user :mterface may be considered at three intended users of the system are often not adequately levels: defined and considered.

(1) semantic: internal granulity and inter-relationships of the system’s functions

(2) conceptual: structure of individual interactions with the system

(3) syntactic: the operation of input and output commands.

As conventional computer-aided design (CAD) systems have become larger and more complex, the need for an appropriate and effective user interface has become more critical. At the same time the expectation of users has been raised by widespread exposure to windows- based applications software. The requirements for an intuitive and easily mastered user interface is equally applicable to knowledge-based expert system (KBESs) and must be taken into account early in the development process. The design of the user interface is influenced by many factors, amongst these the cognitive model of the ufser’s thought processes, aspects of usability, the type and capabilities of the programming

Development of the user interface should take into account the global needs of users and the tasks the system is intended to support. Thus, an understanding and analysis of user requirements will facilitate design of the user interface. In this context the term user interface embraces far more than simply the visual appearance of the screen. The success of the user interface depends largely on the completeness of the user model.

This paper addresses some of the issues of establishing user requirements and the problems faced when imple- menting these requirements within a KBES. It does not go deeply into the theory of cognitive psychology (the study of how to emulate or model the human thinking process when solving problems). The concepts, the requirements and the theoretical definitions of user model and system model are presented, and an attempt is made to implement some user requirements with reference to a knowledge-based design tool called SDA,6 developed by the author for preliminary seismic design of reinforced concrete buildings.

31

32 A. Berrais

2 USER REQUIREMENTS

Before attempting to establish the user model, the anticipated users of the system must first be defined. To what extent is the user himself knowledgeable about the task domain? When the user is defined, the requirements of user and system can more easily be established. User requirements should take into account the following:7 type of users, the tasks performed and the social and dynamic environment in which they interact with the system. This will lead us to identify what system requirements are: what are the areas of the task in which the user is supported (diagnosis, planning, design, etc.) and what are the limitations of the system.

User requirements can be extracted from an analysis of the tasks the system is intended to support, user characteristics and characteristics of the information and its use. In order to have compatibility between the user’s understanding of the system and his skill of knowledge, the design of the user interface should take into account the following:8 (i) classify the user in terms of his level of skill or knowledge, (ii) analyse the functionality of user tasks, their important procedural characteristics and (iii) the type of information use.

It has been suggested that it is a good idea to separate between the semantics of the system application and the user interface.g This separation will lead to the following benefits:

(1) portability: to allow the same application to be used on different systems

(2) reusability: increase the likelihood that compo- nent can be reused in order to cut development costs

(3) customization: the user interface can be customized by both the designer and the user to increase its effectiveness without having to alter the underlying applications.

A proposed user interface model is illustrated in Fig. 1. As shown in this figure, both the user requirements

User-Interface Application

User Modelling Module

Fig. 1. User interface model.

and system requirements are taken into account which in turn affect the user model and system model during the process of developing the user interface.

3 USER MODEL

The development of a user model is a difficult task which requires information about the specific users and the responses to their reaction with the system. User modelling can help match the facilities that a system provides to the needs of the user, improve user learning, guide design decisions and make design choices and assumptions explicit. A user model is required by a KBES to help to identify what needs to be explained, determine the depth and complexity of the explanation, and establish the knowledge necessary to assist the user in achieving his goals and understanding the solution.

Sparck Jones” sees three advantages in the inclusion of user models in KBESs:

(1)

(2)

(3)

Acceptability: the form in which information is elicited and explanations given need to be tailored to the intended user, be they novice or expert eficiency: the most efficient mode of system-user interaction will usually vary according to the user’s level of skill effectiveness: more effective task performance through more accurate interpretation of user behaviour and by making the system’s requirements more comprehensible to a particular user.

Slatter” argues that a good match between the computer system and the user is vital for several reasons:

(1)

(2)

(3)

without this cognitive compatibility, the system’s behaviour can appear surprising and unnatural to the user to counter the potential dehumanizing intluence of expert system technology (through ensuring the knowledge and reasoning of the system are understandable to the user, user-controlled dialogues, etc.) to ensure the system will be acceptable within its intended social and organizational context of use.

Different artificial intelligence researchers use different definitions of a user mode1,8’12-17 and thus they disagree on how to create the user model. Several user models have been proposed in the field of human- computer interaction.12 However, these user models deal more generally with user’s interactions with interactive computer systems and are more concerned with the cognitive modelling of the user rather than the interaction of the user with the application domain embedded within the computer. Examples of user models that have been proposed include: conceptual and quantitative models.13 Conceptual models are mainly concerned with representing human cognitive processes and the

Knowledge-based expert systems 33

strategies involved in human computer interactions. and interaction of the system). This model may differ Quantitative models are concerned with the interaction from a novice user to an expert user. This difference of the user with the computer and how to improve this poses different problems for the designer of the user interaction (independent of application domain). interface.

In the user model, some aspects of the user’s understanding, knowledge and processing are modelled. Majchrzak et a1.18 divided cognitive models into three categories. The first described the user’s task and goal structures. The second category is concerned with linguistic and grammatical models which emphasized the user’s understa.nding of the user-system interaction. The third category was based on the more solid understanding of the human motor system.

The user model can represent a certain aspect of the user which is implicit within the system and used to adapt the system to suit the user. It seems difficult to have a unified user model which embodies all the user requirements (because not all the users, even in the same field, think or process information in the same mode or have the same level of skill).

The system model may be considered as a conceptual model which represents the system, and in which the system developer might wish to represent to the user (system model is different from the mental model as seen by the user). In other words system model is external and explicit, whereas mental model cannot be directly expressed. Browne et aLI9 described a conceptual model as a model invented by a system developer, while a mental model is a naturally evolving internal representation of a system.

In this paper we define the user model as being the model of a typical user which resides in the KBES. This user model may encompass the following characteristics: user understanding and expertise of the application domain, user acceptability and user confidence. The building of a specific user model depends on the system designer’s understanding of these factors. This user model can be considered as a static model. A static model may represent a specific user and can then be updated to the changes occurred with the user.

While interacting with the computer, a user progres- sively builds an internal model of the system. This model is a representation of how the system works. It has been suggested that users construct such a cognitive model through a process of anchoring and adjustment.20 Generally, users create an initial system model based on their understanding of the system, and they adjust this model on the basis of interactive experiences that are not consistent with their current model. More detailed information about adjustment of the cognitive behaviour of users during interaction with computer systems is given by Lehner’ and Kralj.20

4 SYSTEM MODEL

The system model is likely to be characterized by ease of use, capabilities, friendliness, complexity and speed. The success of the user interface to explain internal system actions and reasoning processes to the user will be reflected in the system model. The system model may also reflect the task domain of the KBES which may affect the way in which the user interacts with the system.

The system model, in contrast, is the model of the computer system its seen by the user. The system model structures the interaction of the user with the system. The user may (or may not) have a model, which may be incomplete, of the system (structure, functionality

One method to help users to form their own model of the system is to use metaphorsI that explain the working of the system. Metaphors help in the learning process, they provide short cuts to understand complex concepts; they can be used to shape the user’s behaviour

1 howfriendlv compl.exity

@ - I-& reasoning process

Fig. 2. Relation between the user and the computer system via the user interface.

34 A. Berrais

in situations that are unfamiliar. Figure 2 shows the relationships between the user, computer system, user model and system model, via the user interface, and how the design of a good user interface should take into account both these two models. It is crucial that the user model and the system model match, because this will lead to a better user interface and will increase user acceptability and adaptability. If, however, the user model and the system model do not align then the user’s performance can rapidly deteriorate.

5 KNOWLEDGE ACQUISITION FOR USER MODEL

Much research has been done on the process of emulating human expert cognition but little on the emulation of the user’s cognitive task.” Since the user requirements are to be considered as a factor in developing KBESs, it is advisable that some acquisition about the user’s knowledge be performed in a similar way to the acquisition of domain knowledge from a human expert. Kidd2’ argues that the user is an active agent in the problem-solving process and he recom- mends that knowledge acquisition about the user’s knowledge should include the following:

(1) Identifying the different classes of users likely to use the system and their needs.

(2) Analysing user requirements: what are the common classes of problems and question, what advice does the user require and in what form (e.g. does he usually have his own idea of a solution and only require a critique from the KBES, or does he need to have a set of alternative solutions?) and what type of justification does he require.

(3) Analysing what type of knowledge the user brings to bear on the problem-solving process. Recent research indicates that these include the user’s goals within the domain, his constraints on acceptable solutions (e.g. time, availability, cost, etc.), his own model of the type of problems that the system can solve for him.

Re-specify

The acquisition of user requirements is a difficult process and many methods have been developed with varying approaches.7 The most widely used method is the contextual inquiry technique.** In this technique, the user is observed interacting with the system, and asked some specific questions, then the analysis is carried out.

Stelzner & Williams23 suggested that the roles of the user and the system must complement and supplement each other. When subjective decisions are to be taken it is important that the user remains in control and the system acts as an experiment consultant. For objective decisions, the system should provide more control of the process, freeing the user from unnecessary errors. They also identified five major requirements for the user interfaces to KBESs:

(1) The user interface should represent the domain in the user’s natural idiom (the way of expressing things in a person’s way of understanding).

(2) The user interface should provide immediate feedback to the user on the effect of changes to system state by explicitly maintaining and dis- playing complex constraints and inter-relationships.

(3) The user must be able to recover easily from trying different alternatives.

(4) The user interface must support the user at different granularities or level of abstractions.

(5) User interface must be implemented in such a way that it is possible to have multiple interfaces to the same knowledge.

Figure 3 shows a simplified model of how user requirements can be applied to the KBES development cycle.29 The decision cycle is based on the prototyping approach, which can allow the evaluation of the system in an iterative manner. User requirements can be obtained by structured interviewing and observations of the user during interaction with the system. These user requirements can help tailoring of the initial user interface specifications to the cognitive and behaviour characteristics of the user, and the range of the decisions to be taken by the user.

l User, System and Interface Specification

* Interface design * User & system modelling * Task modelling

l User testing

Fig. 3. User requirement specification for KBES design cycle.29


Based on the type of design problem performed, the user interface can be hierarchically organized as a set of design modules (*agents) where each module accom- plishes a portion of the design at a certain level of abstraction. The upper levels of the hierarchy are modules in the general aspects of the design problem, while the lower levels deal with more specific decisions. In the next secticm, the implementation and development of the user interface for the SDA system is described and disc:ussed in detail.

6 KBES IN CIVLL ENGINEERING

Many KBESs have been developed to assist civil engineers in various tasks.1-4,24 None of the KBES prototypes published in the literature has tackled or discussed the problem of the user interface from the user model point of v&w. They were also restricted on the external appearance and form of the user interface at the surface level. This lack of research and investigation of the user interface ‘based on user model and system model is due mainly to the shortage of established practical information, from the artificial intelligence field, on user models and system models.

As the domain tasks for KBES application differ, the requirements for building user interfaces and user models differ also. Even though it is possible to build a common user model for different type of domain tasks. The user model could be taken into account by collecting information about the user of the system; this information could be presented as the user’s expertise and knowledge about the task domain and computer manipulation. In addition, different domain tasks may require different requirements

for human-machine interaction. For example, to construct user group taxonomies, for which for each user group different explanations can be defined, both for the domain and the problem-solving knowledge.

7 SDA SYSTEM

The SDA6 system is a knowledge-based design tool to assist structural engineers in the analysis and design of reinforced concrete (RC) buildings, mainly coupled-shear walls, subjected to earthquake forces. SDA plays two roles: the role of a design assistant in which the user is helped to design RC building subjected to seismic forces, and the role of an intelligent front-end processor for external finite element analysis programs. Figure 4 provides a macro level schematic view of the architecture of SDA. This architecture has six main components:

(1) knowledge base: comprises of seven main modules as shown in Fig. 4, each module being responsible for a specific task

(2) context: contains the collection of facts which represent the current state of the problem at hand

(3) inference mechanism: controls the system by modifying and updating the context

(4) explanation facility: provides the user with the necessary explanation about the task being performed

(5) external analysis programs: contain the finite element analysis programs

(6) user interface: facilitates communication between the user and the modules of the system. The user interface is described in more detail in the next section.

Unix

Pipes I_ Short

Term Memory

C Use

Fig. 4. Architecture of the SDA system

36 A. Berrais

8 SDA USER INTERFACE

The aim of this section is not to develop a model for the user’s cognitive tasks, but to implement and validate some of the user requirements discussed previously. The development, architecture and characteristics of the user interface are also described. In the SDA system the user interface is separated from the application domain. This distinction is very important in many aspects of development, allowing the system developer to present different, independent interfaces to the same application. It also permits different representations of the same data to be displayed simultaneously. The knowledge and inference mechanism which drive the SDA user interface are independent of the domain knowledge of SDA. The user interface is driven using Quintec-Prolog25126 clauses, and Quintec-Flex27 specification language (KSL). The hardware used is a SPARCstation under the UNIX operating system. The control strategy is backward- chaining and forward-chaining. The user interface can be customized to increase its effectiveness without having to alter the underlying application. In fact, the knowledge and control strategy which drive the SDA user interface can be customized and ported for other types of systems that use Quintet-Prolog and Quintec- Flex as a programming environment.

It has to be recognized that the type and capabilities of the programming environment used is a major factor which affected the success of the implementation of the user requirements, and restricted the implementation of an ‘intelligent’ user interface. This was mainly due to the lack of learning capabilities (the system cannot learn from the user’s errors, and cannot modify its knowledge to update the information concerning a particular user). This problem can be alleviated, for example, by using machine learning techniques.

The system in question is a design tool to assist in preliminary seismic design of RC buildings and the type of users who can use SDA are classified into two types: a structural engineer, who is knowledgeable about the wider perspective of structural engineering, but without in-depth knowledge of seismic design aspects; and a structural engineer with expertise of seismic design aspects, but little knowledge of computer applications. The first type of user needs some assistance and advice on how to analyse and design RC buildings to resist seismic forces. With this type of user, the system will initiate the dialogue. The second type of user is helped to carry out the seismic design in an efficient way with a critique and justification from the SDA system. In this case, the user takes the initiative and controls the interaction in a flexible manner to suit the user’s needs. In both cases, the user has an idea of the model of the type of problem that the system can solve.

The knowledge about the two types of user was coded using Quintet-Flex production rules. This included building a help module, which determines when the

user is making errors and offers advice on how to perform commands. The help module contains information, which is conveyed to the user, about how to use and communicate with the SDA system. In addition, the help module contains meta-level reasoning in the context of explanation (e.g. why certain inferences had been drawn in preference to others). The user interface provides some intelligent assistance with the seismic design problem. Production rules have also been used to model the interaction between the user and the system, and to set the menu display according to the user’s wishes. The user errors were identified and classified into two categories: computing errors and task errors. Computing errors are concerned with system commands and functions, whereas task errors are concerned with seismic design methods. The user errors were specified in terms of Quintet-Flex production rules.

Since the type of user is defined and the task concisely described, the user model can be considered as a static model** in which the system interaction is based around that model. In this model the user and the system are required to work as a partnership; the interaction is initiated by both parties. This is called Mixed Initiative Mode and this can be fulfilled by the combination of a wide range of system options coupled with natural language. The user model is conveyed to the user through the SDA display representation, which directs the user to interact with the system in a certain desired way. The user must form a mental model of the task which is as close to the user model as possible. It has to be recognized that the static model used in the SDA does not change.

The user interface within SDA incorporated the following types of knowledge: (i) knowledge about seismic design methods and terminology; (ii) knowledge about the system operations being used; (iii) knowledge about the different tasks the user might want to carry out (static and dynamic analysis and design); (iv) knowledge about the user such as: his level of understanding and expertise, and his preferred method of interaction. Knowledge about the user was obtained by carrying out structured interviews with different types of user during interaction with the system. In a real interaction, the user will call upon a secondary source of knowledge in order to infer the required knowledge which is lacking.

The following requirements were investigated and implemented within the SDA system:

8.1 General requirements

(1) the system is easy to use, takes the initiative and questions the user

(2) inform the user about the limitations of the system

(3) allow the user to invoke the system at any level of abstract


(4) informs the user about the next step to be taken in the design process

(5) gives brief help for each task required by the user

(6) warns the user about any unpredictable actions.

8.2 Specific task domain requirements

Other more specific task requirements arise from a consideration of tthe engineering aspects of the system domain:

(1) provides the user with better understanding of the actual seismic behaviour of RC buildings

(2) provides the user with a clear distinction between elastic and inelastic analyses of a building

(3) explanation of the different mathematical models used for the structural analysis

(4) the use of passive and active graphics to integrate the seismic {design process, from conceptual design to the final structural design.

The general requirements help to guide the user actions and behaviours, and helped to implement some of the uSer mode! characteristics, so that the user will have a close mental model of the system (usability). The user is given the means by which to exert direct control over the course of the interaction with the system, and to interrupt the iteration at various levels. The components of the user interface as implemented are illustrated in Fig. 5, different types of interface were used as appropriate. The: design of the SDA user interface followed the methodology suggested by Gregory,” which consists of using several layers, interrelated in function, which present an effective and enjoyable interface to the system application. These layers allow

the exchange of information and manipulation of data to serve user’s intent. These layers are:

0)

(53

(3)

(4)

(5)

Conceptualization: this layer takes into account the user needs based on experience. This layer is critical to designing the other layers in order to minimize the differences between the user’s concepts and the system implementation. Hardware for interaction: this layer presents the physical presentation of the information and translates the physical gestures of the user into information usable to the system. This will affect the user’s mental model of the system. Window management: this layer is represented by the visible active windows of the interface (see Fig. 6). This layer controls the size, shape and number of windows, which are determined by the amount and nature of information to be exchanged. Presentation management: this layer controls the contents of the windows as well as their interactions. This layer determines the location, format and form of output. In addition, the information from the user is interpreted and transformed as the input for the application. Menus, diagrams and other interaction elements are selected by this layer to be displayed by the window layer. Application: this layer is responsible for the application data transformations which include manipulation data from the user, and preparing data for display.

The general screen display (Master Menu) of the SDA user interface is shown in Fig. 6. The Master Menu is considered to be a dynamic screen menu, where the memorization of commands is overcome, and the

Operating System calls

Restat? Facilii

Fig. 5. User interface network.

38 A. Berrais

INELASTIC DYNAMIC ANALYSIS IS IN PROGRESS . . . . . . .

PLEASE WAIT

. . 32

yi01dJ yimld_l yidd-1 yhlC1 yield-1

yia1d-i yldd-!

yield-!

Ti9. SEQURJCh 03 Pl.AlX-ICICATION

I COWLEO MLAN 9Au I

Fig. 6. Screen display of the SDA user interface.

interface is based on a hierarchical structure of modes, each corresponding to a functional subgroup.

8.3 User interface menus

The Master Menu is divided into five windows as shown in Fig. 6. The top and left-hand windows are used for the high-level options (or menus) which contain all the major functions (of SDA). In addition to the five main windows, the user interface uses other windows which are opened and closed dynamically while performing a task. The large window in the middle is the main input/ output window where most of the dialogue between the user and SDA is carried out while performing a task. The right-hand window is a graphical window which deals with the graphical explanation of the input as well as the results. The bottom window is a message/warning window which displays warnings about unusual actions by the user.

Animations using Quintet-Flex bitmaps under X- Windows have been used to increase the efficiency of the user interface. These animations were used to: convey functionality of the system, represent and explain the complex seismic design results, and as a navigation and status aid. The high-level options displayed in the top and left-hand windows (see Fig. 6) are used to activate

SDA functions by clicking with the mouse on the required button. For each option the user’s is guided through a pull-down menu with multiple sub-options; each sub-option corresponds to a specific task.

The high-level options are divided into two types based on their function (as shown in Fig. 6): engineering options and system options. On the left side are the engineering options, while across the top are the system options. These options are described briefly below:

Engineering options Engineering options are concerned with the engineering capabilities of the SDA and are divided into five options:

HELP: provides help on the SDA menus, seismic design terminology and background information. GEOMETRY CHECK: concerned with eccentricity requirements. This option is divided into the following sub-options: Help, Horizontal regularity, Vertical regularity, Eccentricity Limit and Exit. CODE LOADS: concerned with evaluating the base static shear force and the lateral static forces. ANALYSIS: concerned with the modelling and analysis of RC buildings using elastic and inelastic dynamic methods. This option is divided into the following sub-


options: Help, Modelling, Elastic Analysis, Inelastic Dynamic Analysis and Exit. DISPLAY: concerned with the graphical and textual display of building geometrical and earthquake information. This option is divided into the following sub- options: Help, 3D Building Geometry, Display Elastic/ Inelastic results, Display Earthquake Record and Exit.

System options System options are concerned with tasks related to the management of the system (see Fig. 6):

RESTART: clears the windows and return the user to the first display in a defined sequence. FILES: concerned with the management of data and system files. UNIX: gives temporary access to UNIX operating system. EXIT: to exit SDA completely; its consequences are such that the user must be required to confirm.

The use of menus can display different commands organized in tre:e-like structures. The user simply chooses the command from a menu of possible command languages. In other words, a menu might not only contain commands, but also route to other menus. The dialogue design within the menus has provided the following advantages: syntax and commands are kept simple, number of commands are limited in format, information passed by a command is limited, sequence of dialogues are organized into logical groups, simple error handling, user should not be expected to remember too much.

The philosophy behind using these different menu options is that the user can have the opportunity to initiate SDA at a:ny level of abstraction he wishes with some degree of control on SDA behaviour. Menu displays are bene:hcial because they always display the possible range of commands; research has shown18 that humans are much better at recognizing a correct choice rather than recalling that choice from memory. The user is able to volunteer information concerning the problem easily and rapidly to the system. This requires both a flexible mixed-iniriative style dialogue so that the user can easily take over control from the system at any point.

9 EXPLANATION FACILITY

The ability of the KBES to provide an explanation to its reasoning is an important aspect of its intelligibility to the user. The explanations offered by the user interface are not limited to the conventional ‘why’ or ‘how’ explanation; deep explanation about a specific task can be provided with how the ordering of hypotheses was derived. This can be activated by an Explain or More Details button associated with the textual window of the

required task. In addition, some of the textual explanation are coupled with passive and active graphical explanations; the utility of this is that the user will have more understanding of the meaning of different vari- ables and relations used by SDA. As an example, the mathematical model for the finite element method can be displayed in a graphical form showing all the different parameters with their explanation (see Fig. 6). Complex inter-relationships can be explicitly conveyed using graphics by presenting them as spatial relationships. This exploits highly developed human spatial awareness and ability to extract meaning from spatial patterns. Information provided by the system to the user is a minimum and in the usable form that is essential to making decisions or performing an action. In addition, SDA maintains a record of the decision it makes. It uses this record to explain and justify its decisions and conclusions on request. This ability of SDA to provide an explanation of its reasoning is obviously an important aspect of its acceptability to the user.

For example, the Quintet-Flex rule agenda used to provide a required explanation to the user, as he wishes, is as follows: Action seism-code

restart and ask explanation-mode and chain(lateral-method)

Chain(Group) if explanation-mode is regular1 and forward-chaining(fcfs, misfire, fail, queue,

group) and explain(Sequence).

Where Action is a sub-system of the Quintet-Flex Knowledge Specification Language (KSL). The Action is coded in the help module, and is concerned with acquiring information from the user to know what type of explanation he requires. Explanation-mode is a parameter used to categorize the explanation type required by the user concerning the operation of the system or any specific task. Group specifies the rules agenda associated with the explanation-mode. Forward- chaining is the inference mechanism for firing the rules. Queue is a program to change the rule agenda, and Group is a group of named rules that are responsible for a specific explanation mode (in this case, the group name is lateral-method). Fcfs is the method used to select the rules, misfire is a built-in program which is executed whenever the action associated with the selected rule fails. Fail is the termination call which is tested during each cycle of the forward-chaining engine.

The user interface has been tested to check its attractiveness and acceptability to potential users. These preliminary tests were carried out by inviting several research students and structural engineers to use the SDA system and obtaining a feedback from them. In general, the user interface was found to be acceptable

40 A. Berrais

and satisfactory. This was confirmed by the test users who were satisfied with the way SDA represents design information and felt that the user interface, in its present stage, increased the user’s understanding of the problem being solved.

10 SUMMARY AND CONCLUSION

The paper has focused on understanding the benefits of including user models and system models when building user interfaces for KBES. User models and system models have been largely ignored by developers of KBES for engineering design applications. Even though some literature from computer science exist, they do not give practical guidance on how to implement user models and system models, or how to gather information concerning user behaviour and user tasks. In this paper, an attempt has been made to investigate user requirements, user model and system model for user interfaces. Although many of the requirements of wer models have been investigated, comprehensive realiza- tion remains beyond the reach of the current research. Problems include the limitations of the programming tools used, the complexity of building user interface knowledge which takes more than one specific type of user into account, and the difficulties associated with the simulation of user knowledge (because this knowledge is dynamic through time and must be continuously followed and updated). User interfaces should be built and tested during development of KBESs, and not ‘tacked on’ at the end.

A user model is important for the design of an appropriate user interface, and there are no standard user models. A user model has to be established or derived on the basis of the user type, the task to be computerized, and the particular human-machine interaction under consideration. The user model should be taken into account early in the development of any KBES. A poor match between the user model of the system and system model of the user will lead to systems which are difficult to use and user-error prone.

The user interface developed in this research was aimed at a specific type of user, with a particular body of knowledge and particular goals. The type of user model adopted in this research is a static model, and human- machine interaction is determined by that model. More initiative is taken by the system, thus minimizing its passive role. Even though the static model has its drawbacks, the investigation has paved the way to understand and research more advanced user models, such as dynamic models, which could reflect user behaviour more accurately, and improve the interaction between the user and the system. The user interface has demonstrated the advantages of using both display menus and graphical windows to enhance the seismic design process and user-interaction with the system. The

research has demonstrated that menus have great advantages over keyboard commands in that memorization of complex sequences of commands is elimi- nated, interactions are simplified (fewer user-errors) and response times of both the user and the system are minimized.

The user interface could be enhanced by developing a multiple user model which would provide better interaction than the existing static model. The development of a multiple user model would require a multidimensional map with many aspects, reflecting the different user types. These user types would range from the novice user to the experienced user. The multiple user model would allow for switching between different user models. The problem of building a multiple user model stems from the difficulty of defining user types. It is unclear how to elicit this information and more difficult to build the information into a computer system. Building such a model would require the system designer to have a detailed knowledge of human behaviour, of learning patterns and of task requirements. This complex task requires sophisticated artificial intelligence techniques to work well. Additionally, there is a need for new effective cognitive-based techniques to allow the user to develop an accurate mental model of the computer system. Moreover, knowledge about users, such as intelligence, educational background and job skills, can be inferred by studying how users use computer commands and deriving user characteristics through the use of stereotypes.

REFERENCES

1. Berrais, A. & Watson, A. S., Expert systems for seismic engineering: the state of the art. Engng Struct., 1993, 15, 146-154.

2. IABSE, Proc. IABSE Colloquium Expert Systems in Civil Engineering, International Association for Bridges and Structural Engineering, Bermago, Italy, 1989.

3. CIVIL-COMP93, Third Int. Conf Application of Artificial Intelligence to Civil and Structural Engineering, Cambridge, UK, August 1993.

4. Topping, B. H. V., Developments in Artificial Intelligence for Civil and Structural Engineering. Civil-Comp Press, Edinburgh, UK, 1995.

5. Anumba, C. J., Considerations in user-interface design for knowledge-based systems. In Artificial Intelligence and Object-Oriented Approaches for Structural Engineering, eds. B. H. V. Topping and M. Papadrakakis. Civil-Comp Press, Edinburgh, 1994, pp. 47-51.

6. Berrais, A. & Watson, A. S., A knowledge-based design tool to assist in preliminary seismic design. Microcomput. Civil Engng, 1994, 9, 199-209.

7. Jones, R. C. & Bdrnonds, E., Knowledge-based requirements. In Human Aspects in Computing: Design and Use of Interactive Systems and Information Management, ed. H. J. Bullinger. Elsevier Science, Amsterdam, 1991, pp. 796- 800.

8. Cole, I., Lansdale, M. BE Christie, B., Dialogue design guidelines. In Human Factors of Information Technology in


the Ofice, ed. B. Christie. Wiley, New York, 1985, pp. 212-241.

9. Dix, A., Finlay, J., Gregory, A. & Beale, R., Human- Computer Interaction. Prentice Hall, UK, 1993.

10. Sparks, J. K., Issues in user modelling for expert systems. In Proc. AZSB8:i, University of Warwick, April, 1985.

11. Slatter, P. E., Building Expert Systems: Cognitive Emula- tion. Ellis Horwood, Chichester, UK, 1987.

12. Young, R. M., Howes, A. & Whittington, J., A knowledge analysis of interactivity. In Human-Computer Interaction, INTERACT 90, Proc. ZFZP TC 13 Third Znt. Conf Human-Compur’er Interaction, Cambridge, ed. D. Diaper, D. Gilmore, G. Cockton & B. Shackel., UK, 1990, pp. 115-120.

13. Williges, R. C., The use of models in human computer interfaces design. Ergonomics Society Lecture, Swansea, UK, 6-10 April 1987.

14. Brown, G. M.: Cognitive models in human-computer interaction. In An Introduction to Human-Computer Interaction, ed. P. Booth. Lawrence Erlbaum, UK, 1989, pp. 65-101.

15. Gregory, K., Methodology for designing a normalized user interface. In Advances in Human FactorslEraonomics - Cognitive Engineering in the Design of Huma;-Computer Interaction and Expert Systems, ed. G. Salvendy. Elsevier Science, Amsterdam, 1987, pp. 139-146.

16. Johnson, P. & Cook, S., People and computers: designing the interface. In Proc. Conf British Computer Society Human Computer Interaction Specialist Group, British Information Society, Cambridge, 1985.

17. McKeown, K. IR., User modelling and user interfaces. In AAAZ-90, Proc. Eighth National Conf Art$icial Zntelli- gence, American Association for Artificial Intelligence, 29 July-3 August, 1990, Vol. 2, pp. 1138-1139.

18. Majchrzak, A. & Tien-Chien Chang et al., Human Aspects of Computer-aided Design. Taylor 8t Francis, London, 1987.

19. Browne, D., Norman, M. & Adhami, E., Methods for building adaptive systems. In Adaptive User Interfaces, ed. D. Browne, P. Totterdell & M. Norman. Academic Press, New York, 1990, pp. 85-130.

20. Lehner, P. E. & Kralj, M. M., Cognitive impacts of the user interface. In Expert Systems: The User Interface, ed. J. A. Hendler. Norwood, NJ, 1988, pp. 307-318.

21. Kidd, A. L. Knowledge Acquisition For Expert Systems: A Practical Handbook. Plenum Press, New York, 1987.

22. Wixon, D., Holtblatt, K. & Knox, S., Contextual design: an emergent view of the system design. In Proc. CHZ’90, ACM, 1990, pp. 329-336.

23. Stelzner, M. & Williams, M. D., The evolution of interface requirements for expert systems. In Expert Systems: The User Interface, ed. J. A. Hendler. Norwood, NJ, 1988.

24. Maher, M., Expert Systems for Civil Engineers: Technol- ogy and Application. American Society of Civil Engineers, 1987.

25. Quintet System Ltd., QUINTEC-PROLOG, Program- mers Reference, Unix version, 1989.

26. Quintet System Ltd., QUINTEC-PROLOG, System Pre- dictates, Unix version, 1989.

27. Quintet System Ltd., QUINTEC-FLEX, User Manual, Unix version, 1989.

28. Cleal, D. M. & Heaton, N. O., Knowledge-based Systems: Implications for Human-Computer Interfaces. Ellis Hor- wood, Chichester, UK, 1988.

29. Howey, K. R., Wilson, M. R. & Hannigan, S., Developing a user requirements specification for IKBS design. In Proc. Ffth Conf British Computer Society Human-Computer Interaction Specialist Group, University of Nottingham, Sept. 1989, pp. 277-289.

knowledge-based expert systems: user interface implications

Documents