User Modeling for Adaptive and Adaptable Software Systems

Abstract

Introduction

No single interface will satisfy every user. Users have different needs as they learn to use an interface. Some users review manuals or consult online or offline help for guidance before touching the system. Others want to start using it for productive work immediately, presenting what has been called the "paradox of the active user", as they attempt to use the system before fully learning it [6]. Moreover, users' needs change as they use a software system and become more familiar with its capabilities and the task domain. See the related paper Accommodating Both Experts and Novices in One Interface for a description of different techniques useful for novices and experts.

Users have their own interests and preferences. This can be seen in the many web sites that -- driven by competitive market forces -- now generate content customized (to some degree) based on user profiles. For example, Amazon.com provides book suggestions tailored to the users apparent interests, and CNN allows users to specify the type of news stories that they want to see on their "personal" myCNN web page. 

Adaptive systems monitor the user's activity pattern and automatically adjust the interface or content provided by the system to accommodate such user differences as well as changes in user skills, knowledge and preferences. Adaptable systems allow the user to control these adjustments, often providing guidance or specialized help to the user.

Adaptive systems can be contrasted with "training wheels" systems [7], which simplify an interface by disabling or removing components not typically used by novices. Adaptive systems generally retain the full power of the system, but hide rarely used components, much as lesser used controls on a television or VCR are often hidden behind a flip-down panel. These controls are made visible to the user when they reach the appropriate level of expertise, or the user can often explicitly enable them through a "preferences" setting.

This paper introduces the techniques of user modeling and adaptive systems, highlights several examples of such systems and provides guidelines for practitioners who are considering the benefits and trade-offs of these techniques. For convenience, we will use the term adaptive to mean both type of systems in this paper, since many of the issues and techniques are similar.

User Models

Figure 1 shows an archetypal system employing a user model. While neither the figure nor the following description correspond precisely to any system, most user models have these elements in common.

The user model contains all information that the system knows about the user. It is generally initialized either with default values or by querying the user. Thereafter, it is maintained by the system, although the user may be able to review and edit their profile. User actions and events at various conceptual levels, such as mouse clicks, task completion and requests for help, are reported by the user interface or core application to the user profile. An analysis engine combines the user profile with other models of the system to derive new "facts" about the user. The analysis engine can update the user profile with the derived facts or initiate an action in the application (such as interrupting the user with a suggestion). The analysis engine also responds to queries from the application.

Figure 1. An archetypal system employing a user model

User modeling parallels well-accepted user interface design principles as described in [15,17]. Both focus on user needs, and generally involve a detailed analysis of the task domain. In traditional UI design, however, the result is a single interface specified at design time, whereas user modeling for adaptive interfaces yields a set of models and rules for generating the interface at run time. When developing a system, designers model the user characteristics to be captured as well as the variations of the user interface.

Stereotypes are often used to classify users [11]. By categorizing users, the designer can treat them as a single unit, simplifying the design as well as processing load at run-time. A simple system may support only a single stereotype for each user. More sophisticated systems support multiple, possibly conflicting, stereotypes.

A wide variety of user models and analysis techniques have been developed to support specific applications. The following bullet lists (adapted from [22]) provide a sample of model elements and techniques:

Typical attributes maintained in the user model:

• User preferences, interests, attitudes and goals
• Proficiencies (e.g. task domain knowledge, proficiency with system)
• Interaction history (e.g., interface features used, tasks performed/in progress, goals attempted/achieved, number of requests for help)
• User classification (stereotype)

Inputs to the user model:

• Explicit preferences, goals from questionnaires
• Explicit personal characteristics (e.g., job title, level of education)
• Self assessments
• Specific actions
• Vision and gaze tracking

• Bayesian (probabilistic)
• Logic-based (e.g.inference techniques or algorithms)
• Machine learning techniques (e.g. neural networks)
• Stereotype-based
• Inference rules

        If (user_level = intermediate) and
           (number_of_mistakes < mistake_threshhold) and
           (number_of_help_requests < help_threshhold)
        Then set user_level = expert             

Adaptive and Adaptable Interfaces

This example is deliberately simplified. Most practical systems are complex enough that few users are experts in the whole system. Advanced users will typically understand the portion of the system relevant to their job very well, but not other parts. (Consider a typical PC network administrator: she may be an expert at configuring network drivers but a relative novice at configuring a web server.) Thus it may not be practical to create a stereotype of an expert user in the context of the entire system. Rather, stereotypes have to be related to certain application purposes of the system. Similarly, low-level actions such as opening a file may have to be aggregated into higher level concepts to make the data storage requirements and computational load feasible [8].

The user model and analysis engine can also be used to derive user goals, interests, and implicit user preferences. Actions that the system can take include offering advice, providing customized instructions, suggesting potential next steps or proactively retrieving and presenting content [22].

System Examples

Adaptive systems have been designed or implemented for a variety of purposes. The following six systems illustrate aspects of the user model described above.

P-TIMS [21] -- A commercial financial management system was revised to add an adaptive and adaptable interface using a simple user model and rule set. As the user spends more time using the system and uses more complex functions, the system reveals a more extensive interface. The user model is explicitly exposed by providing a "preferences" dialog box, which the user can adjust at any time. Empirical evaluation showed that it improved a subjective measure of user satisfaction.

AVANTI [9,10] -- A hypermedia information system about a metropolitan area (e.g. public services, transportation, buildings) for a variety of users with different needs (e.g., tourists, residents, elderly people, blind persons, wheelchair-bound people and users with slight forms of dystrophy). It uses an initial interview to create the initial primary assumptions (i.e., user profile), draws inferences to generate additional assumptions, and uses stereotypes for certain subgroups of users (e.g. tourists, blind users). It then customizes the web pages presented to the user. For example, wheelchair users are presented with information about physical accessibility of facilities when viewing relevent web pages.

Interbook [2,3] -- An advanced WWW application that supports incremental learning and incremental interfaces. The web presents challenges when maintaining the user model. Adaptive systems derive much of their data for the user model from the user interface component, which can track user actions and report them in detail to the application user model. In a web environment, however, the amount and kind of detail about user actions is limited by the HTTP protocol and the HTML model built on it. Interbooks addresses these problems by tracking what the users have seen, rather than what they have done, and using that to infer what the users know.

ORIMUHS [8] -- An adaptive hypermedia help system that supports context-sensitive and user-adaptive presentation of hypermedia help, providing user-controlled help adaptation and agent-based retrieval of additional information. It incorporates a sophisticated user model with stereotypes (levels of expertise), as well as agent-based retrieval of help information. ORIMUHS has been implemented in medical imaging and CAD systems.

Lumière [14] -- Uses a Bayesian user model to infer a user's needs based on the user's background, actions and queries. Lumière prototypes served as the basis for the  Office Assistant (a.k.a. Clippy) in Microsoft Office '97, which provides guidance and tips to the user.

HyperAudio [16] -- An adaptive and portable electronic guide for museum visitors. As users walk through the museum, their physical location is used to implicitly navigate a virtual network of exhibit information. Audio, text and graphic information is then presented on the palmtop computer. Users are initially categorized (stereotyped) by attributes entered by an attendant at the start of the visit. It forms the basis of a larger project that explores the combination of physical and virtual spaces [13].

Observations

Recent work has focused on applying variations of user models to adaptive strategies for specific domains. Content filtering and presentation on the World Wide Web has been implemented by early adopters (notably advertisers) and is beginning to make its way into less aggressive organizations. Commercial organizations that can afford to amortize the cost over many users are implementing profiling systems to provide adaptive content and filtering. Interface adaptation is still mostly seen in research systems. A few examples of production systems are highlighted above.

A limited amount of empirical evaluation of adaptive systems has been performed. More will be needed to determine whether an adaptive interface is measurably better than a non-adaptive interface, and under what conditions the benefit outweighs the perceived loss of control due to unannounced adaptations or the interruption from the interface component as it interacts with the user to adapt or offer advice.

Guidelines and Recommendations

1) Development of adaptive systems reinforces the need to "know thy user". It requires development of explicit user, domain, task and other models. Traditional user interface development can be somewhat informal, since the interface is set at design time. Adaptive systems may require more up-front user analysis, since not only does the system designer need to know the user, that knowledge also must be embedded into the system. Moreover, the system needs to known when and how to act on that knowledge.

2) Don't forsake good HCI design principles such as the "eight golden rules" [17], comprehensive online help, etc. Adaptive systems techniques are built on the foundation provided by these HCI principles. If these underpinnings are missing, the adaptive interface will not be of much use.

3) Use user centered design techniques and evaluate the design early and often. This is critical because the cost of misapprehending user requirements and characteristics is potentially higher than in traditional user interface development.

4) Adaptive interfaces, if not implemented carefully, run the risk of reducing a user's sense of control by making seemingly arbitrary changes. To avoid this, always present the adaptation choice to the user with a description of the proposed change, allow the user to request more information from the online help system, then allow the user to accept or decline the proposed change. Make the user model available and understandable to the user in a "preferences" dialog, and allow the user to adjust attribute values at any time.

5) When adapting an interface to a user with advancing skills, build on the functions and metaphors with which the user is already familiar. Do not require them to abandon their current skills or strategies.

6) The minimalist approach described in [21] is appealing until more fully developed packages are available (either commercial or open source). These packages will need to provide pre-built sets of rules to serve as a starting point for developers who don't want to recreate the wheel.

7) Designing the models, rule sets, action graphs or other algorithms that drive the analysis engine is a significant task in the development of an adaptive system. Designs should be evaluated and tested with users prior to full implementation, perhaps using paper models as in [16].

8) Production systems based on user modeling and adaptive systems are still rare. These systems present the usual risk factors inherent in the adoption of new technology. Organizations considering them need to evaluate the risks, costs and benefits to make sure the payoff is worth the implementation effort for their specific circumstances. Organizations that can amortize the cost over large number of users may find it easier to justify such a project.

9) Expect testing and support challenges due to the additional degree of freedom introduced by the adaptive interface. The techniques for testing and supporting software may need to be revised to handle adaptive systems. In particular, help desk support technicians will need to determine the state of the interface when diagnosing problems. Making the user model easily accessible and adjustible will simplify this task.

Conclusion

References