An Interactive WWW Interface to an Adaptive Information System

Fredrik Espinoza and Kristina Höök

SICS, Box 1263, S-164 28 Kista, Sweden, E-mail: espinoza@sics.se kia@sics.se


Java, HotJava, and Sun are trademarks of Sun Microsystems, Inc.
All other product names mentioned herein are the trademarks of their respective owners.

(Submitted to the workshop "User Modelling for Information Filtering on the World Wide Web", a mini-workshop at the Fifth International Conference on User Modeling.)

Keywords: WWW, user modeling, multi-modality, information filtering

Abstract

We tackle information overflow in an on-line manual through integrating an interactive, multi-modal, World Wide Web (WWW) interface with an adaptive, information filtering system.

In order to make the interface interactive we stretch the limits of html and the WWW. We generate an answer page consisting of graphs and text which the user is allowed to manipulate. The users can navigate in the information space by clicking in the graphs or by posing questions via menus. They can manipulate the answer generated by the system by closing or opening parts of the text. They can also pose follow-up questions on 'hot-words' in the text.

The choice of which information is made available is based on the users information seeking task, which we infer from their interaction with the system. The user can also actively change the assumed task, and thereby control the adaptive behavior of the system.

We stress the point that it is the combination of the multi-modal interface with adaptive information filtering that meets the individual users needs.

Our realization of the interactive WWW interface and adaptive information filtering is based on a separation of the database and the interface. The database is implemented in SICStus Prolog Objects and serves the remote Netscape clients. The interface is realized using dynamically generated html-pages, and graphs which are generated at the site of the Netscape client using a transferred Java applet.

1 Introduction

Information overflow can be tackled through adapting the information to a particular user or a group of users. We have studied the information overflow problem in one particular domain, the documentation of an object-oriented software development method (SDP), and designed an interactive, adaptive hyper-media system which utilizes WWW as its interface.

Until now, the WWW potential for interactivity has been very limited: the user can choose to follow or not follow links to other pages of information. We claim that it is of uttermost importance that the adaptive system is integrated with a highly interactive interface. The demands on interactivity posed by our target domain, have forced us to design new ways of interaction that stretch the original hypertext metaphor.

When realizing the system, our goal has been to create a modular solution. We separate the user model and information in the database which is necessary since the information in the database is changed over time. In our target domain, a number of authors work with recurrent releases of the information database. It would be impossible to require that they would mingle the target domain information with user modeling control sequences.

We also separate the database from the generation of html-formatted code, which allows us to update our interface as the page viewers and html-standards are enhanced.

We describe our approach to interactivity and adaptivity in section 3. In section 4 we describe the system architecture. The system is named PUSH (Plan- and User Sensitive Help). In order to make our reasoning concrete we start by describing the interface through an example in section 2. For a short background of the target domain turn to: SDP.

2 The WWW Interface

In figure 1 we see a screen dump of our interface. It describes one process, 'iom,' in the SDP method. The answer page page is divided into three frames (frames are subparts of the Navigator application window that can be scrolled and resized independently of each other and that each contain a web page):

GUI SCREEN DUMP

Figure 1. A screen-dump from the PUSH system.

3 Interactivity on several levels

The issue of trust is crucial when we design adaptive systems that alter their behavior in response to the users' actions. As pointed out by Judy Kay, (1994), no matter how clever inferences we make about the user characteristica, they will never be anything but a guess. One way of increasing the trust in the system, is to place some of the control over the system in the hands of the user and make the system interactive.

Our system is interactive on several levels. It is interactive at the interface level, allowing the user to manipulate the output from the system. It is also interactive in terms of allowing the user to control the adaptivity.

A second design goal is to utilize the hypertext metaphor and de facto standard interaction with the WWW. It will be easier to learn our interface if it does not divert too much from the prevailing web style of interaction. This goal conflicts with the interactivity goal since WWW offers few possibilities for interaction. Still, we wanted to rely on the basic metaphor of pages and links as a means for moving between pages. The basic structure of our prototype is therefore that every object in the target domain will be presented in one answer page each. This page contains all the relevant information about the object, even if some of the information is hidden from the users immediate view.

By limiting the nodes to be the whole description of an object, we also limit the number of nodes in the hyper-space. An alternative would have been to divide the information into small, stand-alone units, presented in one page each. This would have meant thousands of potential pages in this particular domain. Clearly that is infeasible given the goal of users trying to learn the structure of the whole method, not only tiny pieces of information about certain aspects.

The problem with our approach is that each page might, if fully expanded, contain too much information. It is therefore crucial to structure the information within the page, and to have means for navigation within that page.

3.1 Interactivity at the interface level

Graphs

In the screen dump in figure 1, we can see that the page is divided into different parts. The graphics frame serves two purposes. Firstly, it provides a comprehensive view of the information space at the current position; the graphs display all objects related to the current query as well as their relative positions. This gives the user an overview of the domain and also a means for navigation. Secondly, the graphs allow the user to navigate in the information space by clicking on objects in the graph. As the user clicks on an object the view changes to portray the new object and it's neighbors, and at the same time the appropriate textual information is retrieved and presented.

The presentation in the graphs meets the needs of users who are not so knowledgeable in SDP. They need to see how the objects are related to one another.

Text

When the user has clicked on an object, they can also get a textual description of it. There are many aspects that may be described: how to produce the object, how to work in the process, examples of objects, etc. The user can either ask for a general summary, or just one specific aspect. In the figure above, the user has asked for a general summary of the process 'iom'. A set of 'information entities' are made available to the user. In the figure we see the 'summary' and the underlying 'purpose' of the process.

An 'information entity' is a stand-alone piece of information about one particular aspect of an object. It is not necessary to read one information entity before another - there are no references between the entities. Our studies of the domain, and studies of similar domains [Svenberg 1995], show that this is not an impossible requirement on technical documentation: it is often written as a set of stand-alone pieces of information.

The user can be dissatisfied with the provided information in the answer page, and is therefore allowed to manipulate the text frame. They can close or open the information entities through clicking in the guide frame next to the textual frame, and thereby create an answer page that is better fitted to their needs.

Hot-words

We also allow the user to pose follow-up questions on concepts that are crucial to the understanding of SDP. In the figure we can see that the concept 'object-oriented analysis' is marked as bold, and next to it we see a list of alternative follow-up questions that can be asked about this hot-word. (We have borrowed the term hot-word from [Kobsa et al. 1994] who use it to denote a marked word in the text that is a link to another piece of hypertext.) If the user chooses to follow one of these links, an explanation of the concept is inserted into the text frame below the current information entity.

The hot-words and their associated follow-up questions allow the users to increase their knowledge of SDP. If they are already knowledgeable in SDP, they do not have to read irrelevant information about these basic concepts.

Menus

Finally, the user can also navigate by composing questions via menus, which is an important alternative to navigation in the graphs. A typical question can be 'describe process iom' which would render the answer page in figure 1. A more specific question could be 'provide an example of iom', which would result in an answer page with only one information entity open: the example text.

Allowing the user to pose questions is crucial if we want to meet the needs of experienced users. They do not want to spend time navigating to a particular piece of information, but instead just 'jump' to it.

3.2 Interactivity with the adaptivity

Even if the interactive WWW interface outlined above will be a powerful tool for information retrieval in this domain, we still have the problem of information overload. One answer page might turn out to be several pages long, and we know both form our own studies [Bladh and Höök 1995] and from studies of WWW usage [Nielsen 1995], that users tend not to read more than the first page of information.

This has caused us to try to find characteristics of the users that can be used as a basis for information filtering. We found that the user's information seeking task was a good tool for determining which information entities would be most relevant to the user in a specific situation [Höök 1995, Höök et al. 1995a]. We constructed a hierarchy of information seeking tasks as a result of a task analysis on user's behavior in their daily work situation. Examples of tasks are: 'project planning', 'learning the structure of SDP', etc.

Our approach to knowing about the users current task is one of combining a user-controlled and a self-adaptive approach [Höök et al. 1995a, Höök et al 1995b]. (A self-adaptive approach is one in which the whole adaptive process is done by the system alone: the system initiates, proposes, decides, and executes the adaptive behavior [Kuhme et al. 1992]). According to Oppermann (1994) this middle route is to be preferred since the users must have control over the adaptivity but cannot be bothered with controlling it continuously.

We allow the users to set which task they are working with initially, and then we use plan inference (i.e. inferring the users' underlying goal from their actions at the system) to update their assumed current task continuously [Waern 1994]. The user can at any time change the inferred task to some other task.

Given that we know of the information seeking task, we utilize a set of simple rules that connect a question plus a task with the most relevant information entities. Examples of such rules can be found in figure 2.

Learning structure ->
Basic introduction, Purpose, List of activities, Input objects, Output objects, Relations to other processes, Simple example
Project planning ->
Project planning information, What is done in this process, Information model, Simple example
Performing an activity ->
Summary, How to work in this process, Release information, Input objects, Output objects, Relations to other processes, Entry criteria, Exit criteria, Information model, Advanced example, Frequently asked questions
Producing a product ->
Information model, What is done in this process, Release information
Figure 2. Four rules for the question 'Describe process X'. The information entities are only described by their name in this figure - no full example can be included due to a secrecy agreement with Ellemtel Utvecklings AB (which has developed the target domain SDP).

3.3 Meeting users' needs

Since users differ in many respects, our approach has been to find a mix of non-adaptive and adaptive techniques that together meet the individual user. In our studies, we found that both the users knowledge and their spatial ability influenced their understanding of the domain and the documentation of it [Bladh and Höök 1995, Dahlbäck et al. 1995]. By allowing manipulation of the answer page, and in particular by the follow-up questions on concepts crucial to the understanding of SDP, we cater for the difference in knowledge held by the users. With the two ways of navigation in the information space, menus and graphs, and by presenting information both in graphical and textual form we attempt to cater for differences in spatial cognition [Dahlbäck et al. 1995].

4 System Architecture

To make the more or less non-interactive WWW environment as interactive as possible, several methods have been used: a Java program for client side graphics handling, a CGI program for dynamic generation of web pages, as well as an underlying adaptive database, implemented in SICStus Prolog objects. See figure 3. The result is a platform independent, highly interactive, adaptive system for filtered information retrieval on the WWW. This whole architecture is transparent to the user, who only sees Netscape.

Push Pic.
Figure 3. The architecture of the PUSH system.

4.1 Generating Web pages on the fly

There are several reason why the dynamic generation of web pages is preferable to keeping static pages on disk. For one there is the aspect of presenting information that is tailored to a specific user. Furthermore, if the information can be put together in a multitude of ways, the sheer number of possible variants can make static pages impractical.

In the PUSH system, pages are created in two distinct ways. One is for presenting the results of a new query to POP (the database part of the PUSH system) and the other is for filtering or modifying the currently displayed page. As a query is made to POP, certain data that is tailored to the current user is retrieved. This data is in the form of plain text containing tags signifying hot-words that lead to further queries. The data is channeled to the Page Generator, a CGI program, via a socket. The Page Generator parses the information and builds the finished page by incorporating HTML code into the textual data to construct interface tools such as clickable buttons and menus. When finished, the complete page is piped to the Netscape browser and displayed. The page is also cached to disk. It contains hidden formatting instructions that make it possible to alter the appearance of the page without accessing the database.

4.2 Generating the graphs

A graphics engine implemented as a Java applet takes care of the graphics functionality. At the onset of a query session when the initial page is served to the Netscape browser, the Java code is loaded. (Code written in the Java language runs on a virtual machine inside the web-browser. The same applet code can therefore be loaded into Netscape regardless of platform.) Throughout the query session, the Java program then receives and displays the graph data in it's frame in the Netscape browser. The graph data is read each time it is updated. This happens when the view of the information space changes, i.e. when a new object is viewed. Since there are follow-up questions in the text that do not result in a change of the object that is being viewed, but rather in an insertion of the answer into the existing text, the graphs serve to reinforce the sense of a current object.

4.3 Putting it all together - an interactive web application

The PUSH system is accessed remotely using the Netscape Navigator. A typical session starts with a user retrieving the initial PUSH page, which is the only page that is stored on disk. This is a template page that contains the interactive controls for choosing a query, as well as the Java applet displaying an initial overview of the information space. At this point the user is issued a session id that distinguishes the session from other potential simultaneous sessions, and an individual Prolog process is started. Each user communicates with their own Prolog process via a dedicated socket and both socket and prolog process exist as long as the session lasts. At the end of a session the user's prolog process is terminated so as not to hog the server system.

Each query starts the Page Generator CGI which sends the query parameters to the POP Prolog program. Since each query changes the state of the POP program to allow different follow up questions depending on the current context, and since the Page Generator is a CGI program that lives until the current query answer has been presented to the user, a scheme for saving the current state is needed. For example, the Page Generator must have a way of knowing to which of perhaps several different POP prolog processes to talk to, so the socket name is saved in each presented HTML page as a hidden input field.

4.4 Advantages of remote access to the database

Remote access to a system such as PUSH, using the WWW, has a number of advantages:
  1. The Netscape Navigator and the Java language enables users on a number of different platforms to access common data using a common interface.
  2. The application software only needs to be implemented in one place, thus sparing users from the sometimes difficult task of down-loading and installing the software locally.
  3. All software and data updates are done at the server site. This means that the remote users can be assured that they have access to the latest information as soon as it is available. It also means that all users have access to the same information which is important when users are collaborating remotely.
  4. Adapting to new and improved protocols and standards such as HTML 3 or new versions of Java, is easier.
Our approach here may be compared with Kay and Kummerfeld's, that mingle the html-format and user modeling instructions with the information in the target domain (1994). In [Rice et al. 1995] much the same argument about WWW and its availability across platforms is made.

5 Summary

By stretching the limits for what can be seen as a standard WWW-interaction, we have been able to implement a multi-modal interface to our adaptive information filtering system. It should be noted that we regard the combination of the interactive interface and navigation in the information space as part of the solution of how to meet the individual users needs. The adaptive parts of our system is an integral part of this solution.

We have also shown that it is possible to realize our interactive solution by using the Netscape Navigator and Java applets to communicate with a server-side database which generates the information needed.

Future work includes both testing the system with users, and improving the implementation.

Acknowledgements

The work reported here was done within the PUSH (Plan- and User Sensitive Help) project. It has been financed jointly by Ellemtel Utvecklings AB, NUTEK and SICS.

References

Bladh, Malin and Höök, Kristina (1995) Satisfying User Needs Through a Combination of Interface Design Techniques, In: K. Nordby, P.H. Helmersen, D.J. Gilmore and S.A. Arnesen (eds.), Human-Computer Interaction INTERACT'95, Chapman & Hall, Oxford.

The Common Gateway Interface

Dahlbäck, Nils, Höök, Kristina, and Sjölinder, Marie (1995) Spatial Cognition and Hypermedia Navigation, submitted to Stanford Spring Symposium to be held during spring-96, available from SICS.

HTML3 Specification

Höök, Kristina (1995) Adaptation to the User's Task (.ps), SICS Research Report, SICS, Sweden.

Höök, Kristina, Karlgren, Jussi and Waern Annika (1995) A Glass Box Approach to Intelligent Help (.ps.gz), IMMI-1 (First workshop on Intelligent Multi-Modal Interaction), Edinburgh, U.K.

Höök, K., Karlgren, J., Waern, A., Dahlbäck, N., Jansson, C-G., Karlgren, K., and Lemaire, B. (1995b).A Glass Box Approach to Adaptive Hypermedia (.ps.Z), Journal of User Modeling and User-Adapted Interaction, special issue on Adaptive Hypermedia, forthcoming.

Java, the language, the Java home-page.

Kay, Judy (1994) Lies, damned lies, and stereotypes: pragmatic approximations of users, Fourth International Conference on User Modeling, Hyannis, Massachusetts, the MITRE corporation.

Kay, Judy, and Kummerfeld, R.J. (1994) An Individual Course for the C Programming Language , Proceedings of the Second Internation WWW conference'94 Mosaic and the Web. Kobsa, A., Muller, D. & Nill, A. (1994) KN-AHS: An Adaptive Hypertext Client of the User Modeling System BGP-MS, Fourth Int. Conference on UM Hyannis, MA, 1994.

Kuhme,T., Dieterich, H., Malinowski, U., and Schneider-Hufschmidt, M. (1992) Approaches to Adaptivity in User Interface Technology: Survey and Taxonomy. In: C. Unger and J. A. Larson (eds.): Proceedings of the IFIP TC2/WG2.7 Working Conference on Engineering for Human-Computer Interaction, Elsevier, North-Holland, 1992.

Netscape home-page.

Nielsen, Jacob (1995) Interface Design for Sun's WWW Site, invited talk at the Interact'95 conference in Lillehammer.

Oppermann, Reinhard (1994) Adaptively supported adaptability, International Journal of Human-Computer Studies 40:455-472.

Rice, James, Farquhar, Adam, Piernot, Philippe, and Gruber, Thomas (1995) Lessons Learned Using the Web as an Application Interface, Knowledge Systems Laboratory, KSL-95-69, September 1995, http://www-ksl.stanford.edu/.

SICStus Prolog User's Manual (Release #3). Swedish Institute of Computer Science, Box 1263, S-164 28 Kista, Sweden, ISBN 91-630-3648-7.

Svenberg, Stefan (1995) Structure-Driven Derivation of Inter-Lingual Functor-Argument Trees for Multi-Lingual Generation, Licentiate thesis 498, Department of Computer and Information Sciences, Linköping University, Sweden.

Waern, A. (1994) Cooperative Enrichment and Reactive Plan Inference - applying plan inference outside Natural Language Dialog, SIG meeting at Fourth Int. Conference on UM, Hyannis, 1994.

Author details

Fredrik Espinoza is a researcher at SICS. He is completing his MSc work on the WWW interface implementation described in here.

Fredriks main interests lie within the design of interfaces, both implementation and in understanding how to meet users needs.

Kristina Höök is a licentiate doctorate and researcher at SICS.

Her main interest lie within design of adaptive interfaces, design of explanation and in general Human-Computer Interaction. A special interest is in the role of individual differences, as spatial ability, in their effect on the design of interface.

Address SICS, Box 1263, S-164 28 Kista, Sweden
Tel +46 8 752 1500, Fax +46 8 751 7230
E-mail espinoza@sics.se E-mail kia@sics.se