Int. J. Man-Machine Studies (1984) 21, 283-292

The role of context and adaptation in user interfaces

W. BRUCE CROFT

Computer and Information Science Department, University of Massachusetts, Amherst, Massachusetts 01003, U.S.A.

A user interface can be viewed as a means of mapping user tasks to system tools. Context and adaptation are important features of a user/system interaction that can be used to simplify the task to tool mapping and thereby improve the interface. A system based on these features would be able to adapt its actions to be appropriate for a given context. Two systems are used as examples of the use of context and adaptation. The POISE system provides assistance to the users of an office system based on models of office tasks. The adaptive document-retrieval system chooses the most effective search strategy for retrieving relevant documents in a given context. The techniques used to implement context and adaptation in these systems are considerably different, but in both systems the user interface is made more effective.

1. Introduction

Designers o f user interfaces have, in general, concentrated on issues such as presentat ion and the mechanics o f interaction. For example, the interfaces o f the Xerox Star (Smith et al.; 1982) and the Apple Lisa are based on features that include windows, icons, pop-up menus and the mouse pointing device. Appl ica t ion-dependent components o f the user interface, such as the functionali ty o f a part icular tool, have taken a less important role. However , if we take the view that a computer system consists of a set o f tools that enable users to accomplish tasks, the tool functionali ty will inevitably be considered an impor tant part o f the interface. This is a consequence o f users evaluating the interface according to how it facilitates the specification and execution o f their tasks. A definition that would follow from this approach is that a user interface is the means by which the users map their tasks onto the available set o f tools. Many of the traditional design criteria, such as ease o f use and learnability, can readily be applied to interfaces defined in this way. As an example, consider the task o f finding information using a database system. The tool in this case is the search facility. The query language can, according to our definition, be considered part of the interface since it is the means by which the informat ion to be found is specified to the search facility. Therefore, we can compare query languages and make statements like "query language A provides a better interface than query language B because users find it s impler to specify their queries in that language" . The use o f windows and graphics may also make the query (or task) specification easier, but presentat ion features will not have as significant an effect as the choice o f query language.

Context and adaptation are two important features of the user /system interaction that directly affect the interface goal o f mapping tasks to tools. The context o f a user /sys tem interaction defines features o f the environment that are important in determining the flow of the interaction. The main components o f the context are an identification o f the user, a description o f the task (or tasks) being carried out, and a history o f the interaction. The context o f an interaction has always been available to

283

0020-7373/84/100283+ 10503.00/0 (6) 1984 Academic Press Inc. (London) Limited

284 w.B. CROFT

the users but typical systems view users' activities as unconnected tool invocations. In order to provide an effective interface in terms of mapping tasks onto tools, the system should also have access to the context information.

The simplest case of adaptation is when a system changes its interface or mode of operation to suit a particular user's preferences. In general, adaptation refers to the ability of the system to act appropriately in a given context. Given this ability, the system could provide a better interface by, for example, only making available those tools which are relevant to the current task and changing their functionality to suit individual preferences. Figure l illustrates the difference between the two styles of user/system interaction. Figure l(a) shows a conventional system in which the users, with particular tasks in mind, interact with the system to use the tools. In Fig. l(b), the system has access to descriptions of the user's tasks and can adapt to the defined context in order to present different views of the system to different users. The aim of the design shown in Fig. l(b) is to provide better support for users' tasks.

(a) Tasks ( ) Users ~ .~r SystemtTools)

(b) / ~ Userl ( ~Systeml % System

Tasks ~ User2 ~ System; >

FIG. 1. Adaptation and context in the interface. (a) Conventional interfaces; (b) interface including context and adaptation.

In this article, we shall elaborate on the concepts of context and adaptation and show how they can be supported in actual systems. This will be done by using examples from two research projects in the areas of office systems and document retrieval. In both cases, the users are assumed to be, in general, unfamiliar with the detailed operation of the system. The users of the office system are carrying out tasks related to the functions of the office. Typical tools that are available in these systems are editors, forms packages, calendars and mail. The function of a document retrieval system is to retrieve relevant text documents in response to the users' queries. In this system, therefore, there is one main task but the users have a variety of needs that will determine the type of documents they wish to see. The tools that are available in this system are the various search strategies that are provided. In order to make the task to tool mapping easier, both systems incorporate context and adaptation in the user/system interaction. However, they use very different techniques for implementing these concepts. For example, the adaptation process is automatic in the document retrieval system, but in the office system it relies on user input via special tools. By comparing the approaches used in these two systems, we shall make general observa- tions about the use of context and adaptation in user interfaces.

In the next section, we describe the office system and document retrieval projects and the mechanisms they use for context and adaptation. The treatment of some aspects of these projects will necessarily be brief, but the examples should give sufficient information about the overall operation of the systems. In section 3, we compare the

CONTEXT AND ADAPTATION IN INTERFACES 285

two projects and summarize the implications they have for user interace design. This section also contains an example of the integration of techniques from both projects.

2. Examples of context and adaptation

2.1. TASK SUPPORT IN AN OFFICE SYSTEM

Current office systems consist of a set of tools designed to carry out simple tasks that are common to most offices. It has been recognized that for these systems to be truly effective in increasing office productivity, they should provide support for office-specific tasks (Zisman, 1977; Hammer & Zisman, 1979; Barber, 1983). Office tasks vary considerably in the degree of problem-solving required. Some simple tasks may be directly implemented with an office tool and the user has only to provide the correct parameters for the tool invocation. An example is the communication task carried out with electronic mail. More complex tasks will involve sequences of tool invocations as well as a considerable amount of decision-making. The POISE system at the University of Massachusetts is designed to act as an intelligent assistant to users of an office system (McCue & Lesser, 1983; Croft & Lefkowitz, 1984). The assistance that is provided is based on models of user tasks in a particular environment. The type of assistance can vary from automation of simple tasks to agenda maintenance and error checking in the case of complex tasks. In terms of the discussion of the previous section, the POISE system provides assistance based on the current context. Since the goal of the POISE system is to simplify the process of users carrying out their tasks in an office system with a particular set of tools, it can be considered a major component of the office system interface. Figure 2 shows the general architecture of the POISE system.

Database

Current state i Environment specification i (Tasks, Objects, Tools, Users) i

Users ,( ==: > Tools

FIG. 2. The POISE system.

In order to provide appropriate assistance in a given context, POISE maintains a database containing descriptions of the user/system environment and the current state of the user's activities. The environment specification includes a library of task descrip- tions, some of which are for individuals while others are for groups and organizations. The formalism used describes high-level tasks in terms of lower-level tasks and tool invocations. Another feature of this formalism is that it contains a goal-based and a procedure-based description of the tasks. More details about the formalism are given in the next section. The other components of the environment specification used in POISE are a description of the objects used in the tasks (forms, messages, etc.) and

286 w.B. c g o v r

a description of the available tool set. Information about the roles that different users play in carrying out the tasks could also be included. The current state section of POISE's database contains instantiations of the task descriptions and objects for the current activities. For example, in the task library there could be a description for filling out a partiular type of form. There would also be in the database a description of this form, the fields in it and the relationships to other forms and fields used in the system. After a user had started to fill in one of these forms, the current state section of the database would contain a partial instantiation of the "fil l_out_form" task with values derived from the actual values filled in by the user. It would also contain an instantiation of the database object for that type of form.

Given the information in the database, POISE can both recognize the context of a user's actions and plan activities given a particular context. For example, a user's invocation of a forms package could be recognized as being part of a higher-level task such as processing customer orders. Based on this information, assistance such as filling in certain fields of the form could be provided. I f the user specifies a particular task (such as the order processing example), the POISE system can plan the steps and tool invocations involved, asking the user for input where necessary. The following list summarizes the features of the POISE system.

Planning used for task automation. By using the goals and sequences of actions specified in the task descriptions, POISE can automate routine tasks. It can also provide default values for incompletely specified actions.

Planning used to propose actions. The same planning techniques can be used to describe alternative courses of action to a user when decision points are reached.

Using goals to recognize actions. By checking the goals of task steps (Specified in terms of the state of the objects in the database), POISE can recognize tasks performed in nonstandard ways.

Propagating constraints to correct local and global errors. Specific user actions apply constraints to the general task descriptions. By following the implications of a user 's actions through a task description, the system can recognize actions that, though syntactically correct, appear inappropriate in the context of what the user is trying to do.

Abstracting user actions. Since the tasks represented in POISE are specified hierarchi- cally (i.e. task descriptions located higher up in a hierarchy represent more abstract tasks), the system is able to interpret a user's action as being part of some higher level task and thus understand the action at a more abstract level. This capability is used in summarizing and predicting activities, recognizing task invocations, and for com- municating between nodes performing a distributed task.

Interrogation and explanation using natural language. A natural language interface is used for user requests to POISE and for generating natural language descriptions of the current state (McDonald, 1983).

2. I. 1. The task description formalism The formalism used to describe the office tasks must be able to represent sequences of concurrent activities. Figure 3 gives an example of the formalism used in the POISE system. The IS clause of the task definition uses a regular grammar for describing the standard algorithm for accomplishing a task in terms of other task descriptions and

C O N T E X T A N D A D A P T A T I O N I N I N T E R F A C E S 287

PROC

DESC

IS

COND

WITH ((Purchase (Amount (Items (Vendor

PRECONDITIONS

SATISFACTION

Purchase_items

(Procedure for purchasing items with non-state funds.)

(Receive_purchase_request (Process_purchase_order 1 Process_purchase_requisition) Complete_purchase)

(and (or (eq Process_purchase_order. Amount Receive_purchase_request. Amount) (eq Process_purchase_requistion. Amount Receive_purchase_request. Amount))

= Receive_purchase_request. Purchase) = Receive_purchase_request. Amount) = Receive_purchase_request. Items) = Receive_purchase_request. Vendor))

(and (eq items, received_status True) (eq items, paid_paid_status True))

FIG. 3. An example task specification.

primitive operations (tool invocations). In this task, the IS clause specifies that after a purchase request has been received, either a purchase requisition or a purchase order is processed. The task is completed by the steps involved in the complete_purchase task. To get the details of the steps involved in the complete_purchase task, we would have to examine the corresponding descriptions. The more detailed (or less abstract) tasks contain links to the tools available in the system. The mapping of these "primit ive" tasks to tools is table-driven.

Constraints may be placed upon the values and relationships of attributes of tasks. These constraints are specified by conditions that must be met in order to have a valid instantiation of the task. The C O N D clause is used to describe these constraints. The simplified C O N D clause in the example specifies that either the purchase order amount or the purchase requisition amount must be the same as the amount receives in the purchase request.

Attributes of a task are defined in terms of attributes of its constituent tasks or attributes of database objects. This information, in turn, may be used by (or provided by) higher-level tasks. These attributes of a task are defined by the WITH clause. For example, the purchaser in the purchase_items task is the same as that in the receive_pur- chase_request task.

The POISE formalism also contains a description of the state of the environment that must exist in order for the task to begin. The P R E C O N D I T I O N clause specifies the set of conditions that must be true to start a task.

Upon completion of a task, certain conditions must be satisfied. This information serves both as an aid to the planner and as an alternate means of recognizing the completion of a task. The SATISFACTION clause specifies these conditions. The example task specifies that all items ordered must be received and paid for before the purchase_items task can finish. Both the P R E C O N D I T I O N and SATISFACTION clauses refer to database objects.

The formalism described combines a goal-based and a procedure-based description of the tasks. This combination allows POISE to use a variety of planning and recognition

288 w.a . CRoFr

techniques. The task descriptions written in this language are mapped into an internal representation by the POISE task description reader. The language is adequate for a systems analyst, but is obviously unacceptable for presentation to the users of an office system. User specification and modification of tasks is a vital part of the POISE system and the current developments in this area are described in the next section.

2.1.2. Adaptation in the POISE system The POISE system adapts to individual user needs by providing assistance based on task descriptions. Each user will have an environment specified by the available set of task descriptions. These task descriptions will customize the system for a particular user in that they may be unique or they may specify preferred methods for handling common tasks. This approach to adaptation is possible only if the users are provided with a simple means of specifying and modifying task descriptions. This is also the principal method in POISE for dealing with the dynamic nature of office work.

We are currently investigating two approaches to user specification and modification of task descriptions. The simplest of these will provide a graphical interface that will display tasks using pictorial conventions rather than the formalism described in the previous section. This interface will include a graphical representation of the IS clause, a method of moving up and down the levels of the task hierarchy in order to view the task at different levels of abstraction, and an emphasis on a "building block" approach to procedure specification. The aim of the building block approach is to simplify specification by providing a menu of frequently used tasks that can be used to build up more complex tasks. This should encourage " top-down" development of specfica- tions and insulate the user from much of the detail of tool invocations.

The other approach, which is used for user modification of task descriptions, is based on natural language dialogue and automated knowledge acuisition. Using the tools developed for this project, the system interacts with the user during the process of task modification. A natural language dialogue is possible because of the constrained application and the detailed knowledge of the tasks and the possible modifications.

2.2. SELECTING SEARCH STRATEGIES IN DOCUMENT RETRIEVAL SYSTEMS

A document retrieval system retrieves text documents by comparing their content to the users' queries. When documents are loaded into the system, representatives of their content are created using statistical techniques (Salton & McGill, 1983). Typical document representatives contain numbers corresponding to important word stems and their frequency of occurrence in the text. Retrieval can be carried out with a variety of search strategies, many of which estimate the probability of relevance for each doument given a particular query (Van Rijsbergen, 1979). This type of strategy produces a list of documents ranked according to probable relevance.

Numerous experiments with test collections of documents and queries have estab- lished that statistical techniques are an efficient and effective way of locating relevant information. However, one of the limitations of these systems is that all users and queries are treated in the same manner. This means that one particular search strategy is used to retrieve documents regardless of the information need of the users. The search strategy used will have the best average performance over a large number of queries, but it will not always have the best performance for individual queries. Experiments have shown that search strategies do perform differently for different

CONTEXT AND ADAPTATION IN INTERFACES 289

types of queries (Croft & Harper, 1979; Croft & Thompson, 1984). The aim of our research is to improve the effectiveness of a document retrieval system by giving it the ability to select an appropriate search strategy based on the context of the query. The context of the query includes the same type of information described in the first section; an identification of the user, a description of the user's needs, a description of the query, and a history of the current search. An example of the description of user needs would be whether they require as many relevant documents as possible, regardless of the number of non-relevant documents that appear in the output (known as a high recall search), or a few highly relevant documents with as little irrelevant material as possible (a high precision search).

There are two major problems with designing a document retrieval system to operate in this way. The first is that the search strategies are, in general, not visible to the users. The only cases where it will be appropriate for a user to specify a preference for a particular search strategy is when this choice will affect the way in which the query is specified. For example, an exact match search strategy requires the query to be formulated as a Boolean expression. In most cases, the users would not be able to determine which search strategy will be the most effective for a given context. The other main problem is that to determine exactly which strategy should be used in every possible context would require an extremely large number of experiments using a variety of test collections. Even if these experiments were carried out, the particular choices decided upon may still not be the appropriate ones in a different environment.

For these reasons, an adaptive mechanism is being used to learn the correct strategy for a given context on the basis of user feedback. A similar process currently used in some document retrieval systems is known as relevance feedback (Salton & McGill, 1983). Given user relevance judgements from an initial retrieved set of documents (e.g. the top 10 ranked documents), the system uses this information to re-estimate the probabilities of relevance for the other documents. The adaptive document retreival system extends this idea by giving the system a wider variety of possible actions and a more powerful mechanism for learning which action is appropriate.

2.2.1. The adaptive mechanism The relationship of the adaptive mechanism to the document retrieval system and users is shown in Fig. 4. The adaptive mechanism, on the basis of user feedback information and the current context, chooses an appropriate action (or search strategy) and informs the retrieval system. The context consists of specified features of the environment of the system and users. The particular mechanism chosen for the preliminary experiments was the Associative Search Net work (ASN)(Barto, Sutton & Brouwer, 1981). For each particular context, the ASN is a type of learning automata (Glorioso & Osorio, 1980).

User feedbock

mechonism > (System, Users) -:)

t A c t i o n s I

Context

FIG. 4. The adaptive document retrieval system.

290 w.B. CROl-q-

By combining these different automata into one mechanism, the ASN has the ability to respond to a large variety of contexts. It is also worth noting that the ASN does not require a training period during which it is told the "'correct" action for a particular context. Instead, it responds to "criticism" of its choice of actions in the form of a payoff function which, in the case of the document retrieval system, relies on user feedback.

The ASN is made up of a network of adaptive elements. The simplest ASN, consisting of one of these elements, is shown in Fig. 5. The context is made up of a number of features (x~). Associated with each of these features is a weight (w,). The weights change iteratively with time and are a function of the previous weights, previous context, previous action and the payoff function. A simplified view of this process that a weight is decreased if the action it caused to be chosen receives a low payoff. The action that is chosen is determined by the weighted sum of the context features and a random component.

Payoff

"r j

( Context __.3

FIG. 5. A simple ASN.

Preliminary experiments using the ASN for search selection have produced encourag- ing results (Croft & Thompson, 1984). By comparing the results obtained using the ASN and simple contexts to results established from previous experiments with a variety of search strategies, we have determined that the ASN reliably learns to select the appropriate strategy. These results were obtained using very simple payoff functions and a test set of 225 queries. Experiments with more complicated contexts are currently being carried out.

3. Comparisons and conclusions

In this section we shall compare the example systems discussed and come to some general conclusions about the use of context and adaptat ion in the user interface.

The first comparison is between the uses of context in the two systems. In the office system the context is defined mainly by the current task. The tasks are specified using the formalism described and stored in a task library. The role of the POISE system is to determine the appropriate task descriptions for a user 's actions and to provide assistance based on these descriptions. In contrast to this situation, the task in the document retrieval system is already identified. The context is defined by a set of features that identify interesting details about the search task. Some of these features (such as the emphasis on recall or precision) will he determined by interaction with the user whereas others (such as whether the query contains many common words)

C O N T E X T A N D A D A P T A T I O N I N I N T E R F A C E S 291

can be calculated by the system. In both systems, the context includes an identification of the current user to help identify individual preferences and a history of the interaction. In the POISE system, the history is recorded as partial instantiations of task descrip- tions, whereas in the document retrieval system, the history is recorded explicitly as a feature (or features) in the predefined context.

Adaptation is a vital part of the POISE system and it is carried out manually by the users. This means that the system must provide a simple means of specifying and modifying task descriptions. In the document retrieval system, adaptation is carried out automatically by the adaptive mechanism on the basis of user feedback. This approach puts less of a burden on the users but it is also not as transparent to them. When users modify POISE task descriptions, the new system's actions will be clear to them. However, the process of user feedback changing weights in the adaptive mechan- ism and causing a new strategy to be selected is not immediately obvious to the user. The adaptive mechanism's choices can be explained to the user in general terms such as "search strategy X is the best choice for a query with an emphasis on recall".

To summarize, the POISE system has a more powerful and flexible means of determining the context through task descriptions, whereas the document retrieval system has a more sophisticated method for implementing adaptation. This adaptation technique seems best suited to environments where it is difficult for users to express their preferences directly. In both systems, the use of context and adaptation has simplified the process of mapping user tasks onto system tools.

An example of how these two approaches to context and adaptation can be combined is the document retrieval task in the office. Users often retrieve text documents such as memos and letters as part of some higher-level task. In an office system using POISE, this higher-level task would be known to the system and this could provide additional context for the document retrieval step. The additional information could be used to enhance the user's query and to provide additional features for the ASN context. For example, a user may request a list of memos about "orders for left-handed gnurling wheels". The POISE system knows that this step is part of processing unpaid orders and that in the current context we are dealing with a particular person's orders. The orginal query could be augmented with the person's name and words like "unpaid". The ASN context could also be told that a high recall search is required since it is important to locate all relevant documents in this particular task. The result of this process of identifying the context and providing the document retrieval system with additional information will be more effective retrieval and a better user interface.

This research was supported in part by a Digital Equipment Corporation External Research Grant and by NSF grant IST-8111108. The design of the POISE system was done in cooperation with Victor Lesser, Larry Lefkowitz, Dan McCue and Norman Carver.

References

BARBER, G. (1983). Supporting organizational problem solving with a work station. A C M Transactions on Office Information Systems, l, 45-67.

BARTO, A. G., SUTTON, R. S. & BROUWER, P. S. (1981). Associative Search Network: A reinforcement learning associative memory. Biological Cybernetics, 40, 201-21 I.

CROFT, W. B. & HARPER, D. J. (1979). Using probabilistic models of document retrieval without relevance information. Journal of Documentation, 35, 285-295.

292 w.B. CROFT

CROFT, W. B. & LEFKOWITZ, L. (to appear). Task support in office systems. ACM Transactions on Office Information Systems.

CROFT, W. B. & THOMPSON, R. (1984). The use of adaptive mechanisms for search selection in document retrieval systems. In VAN RIJSBERGEN, C. J., Ed. Proceedings of the 3rd AC M/ BCS Conference on Research and Development in Information Retrieval. Cambridge, England, 98-100.

GLORIOSO, R. M. & OSORIO, F. C. C. (1980). Engineering Intelligent Systems: Concepts, Theory, and Applications. Bedford, Massachusetts: Digital Press.

HAMMER, M. & ZISMAN, M. (1979). Design and implementation of office information systems. Proceedings of the NYU Symposium on Automated Office Systems.

MCCUE, D. & LESSER, V. (1983). Focus and constraint management in intelligent interface design. Technical Report 83-36, Computer and Information Science Department, University of Massachusetts.

MCDONALD, O. D. (1983). Natural language generation as a computational problem: an introduction. In Computational Models of Discourse. Cambridge, Massachusetts: M.I.T. Press.

SALTON, G. & McGILL, M. 1. (1983). Introduction to Modern Information Retrieval. New York: McGraw-Hill.

SMITH, D. C., IRBY, C., KIMBALL, R., VERPLANK, B. & HARSLEM, E. (1982). Designing the Star user interface. Byte (April).

VAN RIJSBERGEN, C. J. (1979). Information Retrieval, 2nd Edition. London: Butterworths. ZISMAN, M. D. (1977). Representation, specification and automation of 9ffice procedures, Ph.D.

Dissertation, Wharton School, University of Pennsylvania.