Knowledge-based expert systems: user interface implications

Software28 (1997) 31-41 0 1997 Elsevier Science Limited Printed in Great Britain. All rights reserved Advances in Engineering PIl:SO965-9978(96)00030-O ELSEVIER 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 successof 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 successof user interfaces considered. The paper concludes with a description of the user interface developed for a knowledge-based design tool for preliminary seismicdesign 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. tools, the hardware environment and the intended function of the KBES. The majority of prototype KBESs for civil engineering applications reviewed in recent papers,lP5 particu- 1 INTRODUCTI’ON The user interfac,e stands between the user and the application program, and facilitates the communication 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 internal processesof the application program (and vice versa). The user :mterface may be considered at three levels: reference to a user model or tackle the problem of user requirements in detail. Indeed, in many cases the (1) semantic: internal granulity intended users of the system are often not adequately defined and considered. Development of the user interface should take into account the global needs of users and the tasks the and inter-relation- ships of the system’s functions (2) conceptual: structure of individual system is intended to support. Thus, an understanding interactions and analysis of user requirements will facilitate design of the user interface. In this context the term user interface embracesfar 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 addressessome of the issuesof establishing user requirements and the problems faced when implementing 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 with the system the operation of input and output commands. (3) syntactic: 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 windowsbased 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 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 suggestedthat 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 component 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 User Modelling Module Fig. 1. User interface model. Application and system requirements are taken into account which in turn affect the user model and systemmodel 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 necessaryto assist the user in achieving his goals and understanding the solution. Sparck Jones” seesthree advantages in the inclusion of user models in KBESs: (1) Acceptability: the form in which information is elicited and explanations given need to be tailored to the intended user, be they novice or expert (2) eficiency: the most efficient mode of system-user interaction will usually vary according to the user’s level of skill (3) 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) without this cognitive compatibility, the system’s behaviour can appear surprising and unnatural to the user (2) 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.) (3) 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 humancomputer 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 strategies involved in human computer interactions. Quantitative models are concerned with the interaction of the user with the computer and how to improve this interaction (independent of application domain). 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 seemsdifficult to have a unified user model which embodies all the user requirements (becausenot all the users, even in the same field, think or process information in the same mode or have the same level of skill). 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 encompassthe 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. 4 SYSTEM MODEL 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 and interaction of the system). This model may differ from a novice user to an expert user. This difference poses different problems for the designer of the user interface. 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. While interacting with the computer, a user progressively 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 systemsis given by Lehner’ and Kralj.20 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 processesto 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. 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 @ reasoningprocess 33 I-& 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, becausethis 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 MODEL FOR USER 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 recommends that knowledge acquisition about the user’s knowledge should include the following: (1) Identifying the different classesof users likely to use the system and their needs. (2) Analysing user requirements: what are the common classesof 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. 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 suggestedthat 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 displaying 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.29The 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. Re-specify l User, Systemand InterfaceSpecification * Interfacedesign * User & systemmodelling * Task modelling l User testing Fig. 3. User requirementspecificationfor KBES designcycle.29 35 Knowledge-based expert systems 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 accomplishes 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:ussedin detail. 6 KBES IN CIVLL ENGINEERING Many KBESs have been developed to assist civil engineers in various tasks.1-4,24None of the KBES prototypes published in the literature has tackled or discussedthe 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 ‘basedon 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 sevenmain 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 C Use Fig. 4. Architectureof the SDA system I_ Short Term Memory 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 discussedpreviously. 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 backwardchaining 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 QuintecFlex 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 successof 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 systemcommands 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 Knowledge-based expert systems (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. the exchange of information and manipulation of data to serve user’s intent. These layers are: 0) Conceptualization: this layer takes into account 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 {designprocess, 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 37 (53 (3) (4) (5) 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 selectedby 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 screendisplay (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 OperatingSystem calls Restat? Facilii Fig. 5. User interface network. 38 A. Berrais yi01dJ yimld_l yidd-1 yhlC1 yield-1 yia1d-i yldd-! yield-! INELASTICDYNAMIC ANALYSISIS IN PROGRESS....... PLEASE WAIT Ti9. I SEQURJCh 03 Pl.AlX-ICICATION COWLEO MLAN 9Au I . . 32 Fig. 6. Screendisplay of the SDA userinterface. 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 XWindows 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- Knowledge-based expert systems 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 suboptions: 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 shown18that 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 39 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 variables 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. Forwardchaining 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 scienceexist, 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 realization 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 associatedwith the simulation of user knowledge (becausethis 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 humanmachine 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 processand 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 eliminated, 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 systemdesigner 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 systemsfor 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., Considerationsin user-interfacedesignfor knowledge-basedsystems.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 assistin preliminary seismicdesign.Microcomput. Civil Engng, 1994,9, 199-209. 7. Jones,R. C. & Bdrnonds,E., Knowledge-basedrequirements.In Human Aspects in Computing: Design and Use of Interactive Systemsand Information Management, ed. H. J. Bullinger. Elsevier Science,Amsterdam, 1991,pp. 796800. 8. Cole, I., Lansdale, M. BEChristie, B., Dialogue design guidelines.In Human Factors of Information Technology in Knowledge-based expert systems the Ofice, ed. B. Christie. Wiley, New York, 1985, pp. 212-241. 9. Dix, A., Finlay, J., Gregory, A. & Beale, R., HumanComputer 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 Emulation. 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 41 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: Technology and Application. American Society of Civil Engineers, 1987. 25. Quintet System Ltd., QUINTEC-PROLOG, Programmers Reference, Unix version, 1989. 26. Quintet System Ltd., QUINTEC-PROLOG, System Predictates, 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 Horwood, Chichester, UK, 1988. 29. Howey, K. R., Wilson, M. R. & Hannigan, S., Developing a user requirements specification for IKBS design. In Proc. AAAZ-90, Proc. Eighth National Conf Art$icial Zntelligence, American Association for Artificial Intelligence, 29 Ffth Conf British Computer Society Human-Computer Interaction Specialist Group, University of Nottingham, July-3 August, 1990, Vol. 2, pp. 1138-1139. Sept. 1989, pp. 277-289.