1. Abstract
This paper explores the reasoning, motivation, and general design theory behind development of an intelligent user interface for a generic expert system. Reasoning behind the development is supported by close examination of user and domain factors and the research of other interface designers. Presentation of the design architecture points out structures to manage and abstract out the complexities of a domain independent interface, providing the user with a useful, intuitive work environment.
2. Introduction
Generic expert systems such as PESKI (Probabilities, Expert Systems, Knowledge, and Inference) [BAN95; SAN95b] are beginning to make their way into the field of artificial intelligence. PESKI utilizes a Bayesian knowledge base to provide reasoning power that is not designed around a specific application domain. Therefore, this system allows adaptability to any domain in which it is used. Adaptability must extend to the system's user interface as well, requiring the interface to be general purpose in nature.
This general purpose user interface must be designed very carefully, keeping the needs of the user at the forefront of design. The user interface for any system plays a major role in how the user perceives the effectiveness of the system [GON93]. Therefore, the interface for a generic expert system must be adaptable and adaptive to the needs of a multitude of user types. Likewise, the interface must be adaptable and adaptive to any application domain in which the system is utilized. These criteria drive the need for general design theory and methodology for developing an interface for a generic expert system.
3. User Profiles
Who are the users of a generic expert system? This must be the first question asked before designing an interface for the system. After all, a computer system is useless if the user does not perceive the system as a convenient tool for which to get useful work done. Furthermore, if the system's interface is developed without a focus on user needs, the system may prove to be difficult to operate and be promptly labeled worthless.
It would be quite arduous to develop a system based on every possible user's individual needs since we can not possibly know who each user may be. Therefore, we must attempt to classify general groups of users and develop user profiles for each group. Although it is very difficult to put users into specific classifications [SAN93a], doing so will narrow down the requirements of the interface to a manageable level. With this in mind, a general purpose expert system, such as PESKI, is assumed to have four general types of users: application users, application experts, knowledge engineers, and computer scientists.
The application user employs the expert system "on-the-job." This user is not necessarily an expert in the application domain nor is this user necessarily knowledgeable in the inner workings of an expert system. This user simply needs the ability to query the expert system for the appropriate knowledge to get useful work done.
An application expert is extremely knowledgeable in the field where the application is being used. For example, an application expert is a doctor in a hospital. This user is not necessarily knowledgeable in expert systems, but may wish to use the system to query for some required knowledge. Since the application expert are experts in their domain, these users may also be responsible for providing new knowledge to the existing system.
A knowledge engineer is a person who specializes in acquiring knowledge, usually from humans. This user acts as an intermediary between experts and the computer, able to break data down into its most basic forms for entry into the expert system. This user needs a more detailed view of the knowledge base than the application expert or the application user. The knowledge engineer also needs to view and analyze the structure of the knowledge in the knowledge base to ensure that the knowledge is being built correctly.
The computer scientist is also an important user to consider for an expert system interface. This user is interested in development, design, and maintenance of the expert system and needs the lowest or no amount of abstraction. The user interface must allow the computer scientist to directly manipulate knowledge base structures, to examine knowledge interactions, and discover how to improve knowledge structuring techniques.
The user of a generic expert system may fall within more than one of these general categories. For example, a civil engineer can use the expert system to design a building's foundation but can also add new information concerning building design to the knowledge base. Therefore, the civil engineer is an application user and an application expert. The interface must allow users who maintain multiple roles the ability to switch between the needs of the various roles while using the system.
Not only are there general classifications of users but there are various skill levels in computer knowledge among individuals of various groups. A widely accepted scale of computer knowledge is low, medium, and high [TRU94]. This computer knowledge can range from general knowledge to specific knowledge in particular applications. For example, a user that is very knowledgeable about particular word processing systems may have no idea how operating systems work. Studies show users with high, broad computer knowledge prefer faster, less explanatory methods of interfacing with a system, such as typing at a command line. On the other hand, users with low computer knowledge prefer more graphical methods such as menu or icon manipulation [TRU94].
4. User Functional Needs
Once the users of the system are classified, the specific needs of the users must be addressed. Users need methods to acquire and extract knowledge as well as methods to perform utility processes. These utility processes include manipulating the knowledge base, viewing the knowledge base, and effecting changes to the user interface.
Knowledge is gained from many sources, such as an interview by a knowledge engineer, retrieval of on-line text, and data entry directly from an application expert. Since a generic expert system may accumulate knowledge from sources such as these, the generic system must contain diverse tools for which to acquire knowledge in varied ways. These tools must be easily accessed by the user through the system's user interface. Once knowledge is stored, some methods must exist to retrieve that knowledge. Query tools must be available so the user can communicate effectively to the expert system as to what knowledge is needed. The user interface must be able to turn these queries into meaningful data for processing by the system's tools.
Users, such as computer scientists and knowledge engineers, may be interested in how the acquired knowledge is structured within the knowledge base. Therefore, tools must be available that allow the user to examine the contents of the knowledge base in different forms, and the interface must facilitate the display of these forms to the user. Viewing the structure of the data in the knowledge base can give rise to the user's need to manipulate or change the data in the knowledge base. A tool must also be available that allows the user to easily manipulate the data as the data is being observed.
5. User Communication Needs
Most basic to all the needs a user may have is the means to communicate with the expert system. To create an effective user interface, communication must be the cornerstone of any design. This communication can take on various forms such as natural language, graphical manipulations, and structured text. The user interface should provide for many communication forms and should assist the user with choosing the appropriate communication form for each application or tool [BOS94].
A natural language interpreter allows the user to communicate with an expert system through typed sentences of text. For example, a doctor can create a relationship between "polio" and "disease" in the knowledge base by typing "Polio is a disease" onto a text line. The interpreter breaks the sentence into its most basic forms, translates the forms into a relationship, and sends the update request to the expert system's knowledge base.
A graphical interpreter allows the user to build graphical relationships that can later be manipulated to communicate relations [AVO93]. For example, an icon that represents "polio" can be moved, using a mouse, from a pool of icons to a window that represents "diseases." The graphical communicator interprets the move as creating a relationship between polio and disease and sends the update request to the system's knowledge base.
A structured text interpreter allows the user to build pre-defined textual relations which, when receiving text, create the desired relation. Again, if "polio" needs to be associated with "disease," then a text entry box is created labeled "disease." The user can then type "polio" in the box and the structured text interpreter creates the relationship and sends the update request to the expert system's knowledge base.
6. Domain Adaptability
Many studies on adaptable systems have focused on the presence of tools in a system that allow the user to adapt the system to meet the user's needs [OPP94; KAN89]. This has led to studies that explore ways to make systems adaptive, or able to modify themselves based on perceived user needs [MEY94; THO93; TRU94]. However, very little has been explored concerning domain adaptability or adaptivity for generic expert system user interfaces. The abilities of an expert system user interface to be altered or alter itself based on the application domain is crucial to the effectiveness of a generic expert system. This leads to the obvious question as to what is the difference between a domain dependent interface and a domain independent interface.
With a domain dependent expert system, the developer knows who the users of the system will be, how the system will be utilized, and how the system integrates into the domain. Therefore, the user interface design can be targeted at a small subset of users. Also, the interface can be customized with the appropriate tools and a suitable layout to integrate the system with the rest of the domain environment.
On the other hand, the user interface for a domain independent expert system is not targeted at a small subset of users. Instead, the interface must be designed for a larger, more general set of users of many different types and knowledge levels. Various tools must be available to meet the needs of any domain, and the interface must have customization flexibility to allow integration of the system into the application domain.
For an interface to be truly domain independent it also must be portable. A generic expert system designed for use in numerous application domains has a level of portability designed into it. Likewise, the user interface requires portability, especially to any computer architecture where the expert system will be used.
7. Interface Intelligence
Given the various design considerations discussed thus far and the enormous complexity of the expert system, no ordinary graphical user interface can be used for a generic expert system. Therefore, the interface must be designed with an intelligence that can manage all the needs presented thus far. This intelligence must manage the communication between the user and the expert system, user-initiated adaptations to the interface, and adaptivities deemed necessary by the interface. This idea of creating an intelligent assistant drives a joining of adaptation and adaptivity research into a management tool that helps the user exploit the full capability of the expert system.
8. Interface Architecture
A general architecture has been developed for the PESKI user interface based on the analysis of requirements discussed thus far. This architecture is composed of three main layers: a graphical layer, an intelligent assistant layer, and a system layer. These layers abstract out the expert system's complexity to a level of complexity desired by the user. Therefore, the computer scientist can interact with the complex structures of the knowledge base, while the application user can avoid the knowledge base structure altogether and simply query the system for some required knowledge.
The graphical layer creates an efficient, graphical work environment for the user. Typical interface objects such as windows, menus, and text entry lines are combined into a functional display that is customized to meet the user's work environment needs. The graphical support is extracted through any number of different interface development tools, and choice of the appropriate tool is based on the architectural platform where PESKI is being used.
The intelligent assistant layer is the most complex and the most significant layer of this architecture. It manages the enormous number of interface control tasks through a three layered construction: the adaptation layer, the adaptive layer, and the communications layer. All transactions that occur between the expert system and the user traverse these three layers for translation and management of data.
In this architecture, the adaptation layer acts as an advisor to the user for accomplishing user-performed adaptations. This advisor duty is divided into two tasks: helping the user make adaptations and advising the user on potential adaptations. When helping the user perform an adaptation, the adaptation layer provides on-line instructions to the user on how to effect the adaptation. The adaptation layer leads the user through the adaptation step by step and gives the user feedback during the process. To recognize potential adaptations, this layer collects detailed metrics on system use, including commonly used routines and task procedures. The interface recognizes those routines and procedures that can be performed more efficiently and reports its findings to the user. If the user decides to enact the suggested adaptation, the online help is used as previously described. All adaptations are stored in an adaptation log that the user can view.
The adaptivity layer of the intelligent assistant encapsulates those elements of the interface that adapt themselves based on perceived user needs. Interface elements that adapt themselves include menus and object layout schemes. As the user employs the interface, this layer collects metrics on which activities are performed and which layout schemes are used. The activities and layout schemes that are more frequently used are made more available to the user. As the use of the interface changes over time, the more easily available activities and layouts are changed adaptivly. In this way, the adaptivity layer abstracts out the infrequently used activities and schemes from the user's view, allowing the user to focus on only those that the user needs. As with the previous layer, the adaptivity layer keeps a log of all interface-enacted adaptations for the user's viewing.
The communications layer of the intelligent assistant is responsible for managing all the data that is passed between the user and the expert system. To manage this communication, this layer is equipped with the three communication tools previously mentioned: a natural language interpreter, a graphical interpreter, and a structured text interpreter. These tools facilitate various modes of communication to and from the user and satisfy the requirement of flexible communication. The communications layer allows for each of these communication tools to be used individually or combined into various structures that will enable more effective communication between the user and the expert system. With the available communication tools, the user is given the ability to explicitly choose which communication fits their need based on the domain of the data.
The system layer of the architecture allows connectivity between the user interface and the expert system through a series of tool drivers. Tools are the link between the interface and the knowledge base, providing the functionality to perform work on the expert system. At the point where each tool connects to the interface, there is a driver that provides the interface with the input and output requirements of the tool. This driver is physical link between the interpreted user's request and the execution of system functions.
Together, the layers of this architecture create an intelligent interaction capability for the user interface. For example, the user communicates a request through the visual elements of the graphical layer. This communication is translated by the communication layer of the intelligent assistant, and the adaptation and adaptive layers collect metrics about the request. The adaptation and adaptivity layers take any actions they reason as necessary to aid the user based on the collected data. The request is then sent to the system layer where the request is turned into a physical action on the system. The process is reversed for sending output back to the user.
Portability of the architecture is assured through the design methodology and the layered nature of the architecture [RUM91]. The requirements analysis of the interface has been converted into a working design through the use of object-oriented design techniques. This working design was designed to be as implementation independent as possible to allow for various platform applications of PESKI. Also, the layered design of the architecture lends itself to easily adapt to a PESKI instance. Particularly, modifications to the drivers in the systems layer allow easy connection to the candidate system. This portability may even lend itself to use of the interface on non-PESKI systems.
9. Implementation of the Architecture
The working prototype of this interface is currently being integrated into the PESKI computer software architecture at the Air Force Institute of Technology. It is being constructed using the OpenWindows Developer's Guide, known as Devguide, on a Sun workstation under the UNIX operating system.
10. Bibliography
[AVO93] Avouris, Nicholas M. and Sandra Finotti. "User Interface Design to Expert Systems Based on Hierarchical Spatial Representations," Expert Systems With Applications, 6: 109-118 (1993).
[BAN95] Banks, Darwyn O. Acquiring Consistent Knowledge for Bayesian Forests. MS thesis. Graduate School of Engineering, Air Force Institute of Technology, Wright-Patterson AFB OH, December 1995.
[BOS94] Bos, Edwin, Huls, Carla, Claassen, Wim. "EDWARD: full integration of language and action in a multimodal user interface," International Journal of Human-Computer Studies, 40: 473-495 (1994).
[GON93] Gonzalez, Avelino J. and Douglas D. Dankel. The Engineering of Knowledge-Based Systems. Englewood Cliffs NJ: Prentice Hall, 1993.
[KAN89] Kantorowitz, Eliezer and Oded Sudarsky. "The Adaptable User Interface," Communications of the ACM, 32-11: (November 1989).
[MEY94] Meyer, Beth. "Retail User Assistant: Evaluation of a User-Adapted Performance Support System," in Lecture Notes in Computer Science, 4th International Conference, EWHCI'94. Berlin: Springer-Verlag, 1994.
[OPP94] Oppermann, Reinhard. "Adaptively supported adaptivity," International Journal of Human-Computer Studies, 40: 455-472 (1994).
[RUM91] Rumbaugh, James and others. Object-Oriented Modeling and Design. Englewood Cliffs NJ: Prentice Hall, 1991.
[SAN93a] Santhanam, Radhika and Susan Wiedenbeck. "Neither novice nor expert: the discretionary user of software," International Journal of Man-Machine Studies, 38: 201-229 (1993).
[SAN95b] Santos, Eugene Jr. and Darwyn O. Banks. A Probabilistic Framework for Representing Uncertainty. Graduate School of Engineering, Air Force Institute of Technology, Wright-Patterson AFB OH, December 1995.
[THO93] Thomas, C, G. "Design, implementation and evaluation of an adaptive user interface," Knowledge-Based Systems, 6: 230-238 (Dec 1993).
[TRU94] Trumbly, James E. "Productivity gains via an adaptive user interface: an empirical analysis," International Journal of Human-Computer Studies, 40: 63-81 (1994).