TY - JOUR
AU - Macredie,, R.D
AB - Abstract The development of ‘intelligent’ or ‘adaptive’ user interfaces has been a strong research theme in Human–Computer Interaction for many years, with the terms often used interchangeably. In this article we will argue that seeing these terms as interchangeable can be misleading and can have implications for the expectations of systems both from the designer’s and user’s perspectives. We will suggest that the emphasis at the interface should be on adaptation, leaving intelligent behaviour to the user. The article argues that realistic expectations of available interaction information must be maintained when specifying the behaviour of an adaptive interface, such as the one containing agents. This article illustrates the process of the design and implementation of a set of software agents which act as Web Assistants, aiding the user in browsing the world wide web (WWW): issues in specifying the agents’ functionality and adaptation characteristics; issues in designing the adaptation and inference rules required for each agent and implementing and integrating them within a user interface. The process raises both architectural and implementation issues which lead to conclusions drawn at the end of the article, concerning adaptivity versus intelligence and considering specifically the quality of interaction information available and the need to maintain realistic expectations on the part of the designers of adaptive systems. 1 Introduction Research literature in user interface design tends to use the terms ‘intelligent’ and ‘adaptive’ to mean essentially the same thing. In this article we argue that this practice can be misleading, especially when applied to user interfaces. We believe that the emphasis at the interface should be on the adaptation, leaving the intelligent behaviour to the user. To this end, the article argues that realistic expectations of available interaction information must be maintained when specifying the behaviour of an adaptive interface. Adaptation in the interface should only be triggered when the system has strong reason to suggest that subsequent interactions will benefit from it. If this is not the case, adaptation may make the interface less usable, rather than enhancing the interaction by supporting the user in their tasks. An alternative to the automatic interface adaptation is to leave the final control with the user, offering suggestions for adaptation, which may be ignored by the user if she so wishes. This approach has the advantage that information regarding the user’s interactions with the system’s suggestions can be utilised to evaluate whether the system’s suggestions are being exploited by the user. This, in turn, might then act as the basis for further adaptation. These issues are explored through the design and implementation of a set of software agents, which act as Web Assistants, aiding a user in browsing the world wide web (WWW), through an adaptive user interface. The article discusses the design and development process for these agents: specifying the agents’ functionality and adaptation characteristics; designing the adaptation and inference rules required for each agent and implementing and integrating them within an interface. The design and implementation stages are undertaken within a theoretical framework, which supports the abstractions made in specifying the characteristics of the interface as containing agents. An existing methodology for the design of intelligent interfaces is used in this article to decompose the complex behaviour of the agents into simple components, which can then be implemented directly. Other practical issues, such as the means by which a set of agents may be integrated into existing interface software, are also raised. The underlying adaptive interface architecture to be used is particularly relevant here, and a current architecture is evaluated in the light of the requirements of this system. The issues raised concerning both architectural and implementation issues are then analysed. The results suggest the need for a rigorous, methodological approach which covers not only the design and implementation of adaptive user interfaces, but which can also be applied to the specification of the system in terms of the user’s working requirements. Finally, the article returns to the key issue concerning adaptivity versus intelligence, considering specifically the quality of interaction information available and the need to maintain realistic expectations on the part of the designers of adaptive systems. 2 User interfaces, adaptivity and Web browsing To introduce the central issues in the article, we first discuss broad issues in adaptive user interface design. This provides the general context for the rest of the article. The article then goes on to consider how adaptivity may be employed in user interfaces in order to ease a user’s interactions with such a system, and in particular how such adaptive aspects may be designed effectively. This is explored by considering how a user’s interaction with a Web browsing system can be enhanced by embedding simple software agents in the user interface to adapt it in response to the user’s actions. The browsing task has certain characteristics, which recommend solutions employing adaptivity within the user interface, and these are examined. At the same time, the use of any adaptive elements in a user interface raises questions about the usability of the system—the more flexible a system is in terms of its adaptive capability, the less usable it will potentially be—so the justification for adaptivity in the interface must also be considered. 3 Adaptive user interfaces Classical user interfaces ([1–2]) are static in nature, embodying a design which (it is hoped) will accommodate the vast majority of the future users of that system. The fact that a system is designed and then fixed when implemented at some point means that it must be adapted to by its users where any mismatch in a user’s conceptualisation of the system occurs. Similarly, as the system’s design springs from the designers’ perceptions of the system users, certain classes of users may be catered for poorly. Customisable or ‘adaptable’ systems can provide a partial solution to this problem, by allowing users to express their preferences as to the function or appearance of a user interface, yet this still places the burden of change upon the user. A central tenet of this class of systems is that the interface works purely as a tool, manipulated directly by its users. In contrast, an adaptive or ‘intelligent’ user interface [3–5] is one where the appearance, function or content of the interface can be changed by the interface (or the underlying application) itself in response to the user’s interactions with it. The system will typically contain some component, which receives signals or events from the interface as the interaction progresses, and uses some rules to effect adaptation of the interface based on a set of criteria. In order to be able to do this, the system must possess certain models: a model of the user, a model of the system (or interface) itself, and a model of the interaction between the two. The exact contents of these models and the processes involved in constructing them are covered later in this article. 4 Adaptivity, flexibility and ease of use The justification for having adaptivity in an interface is an important question for the designer, as adaptivity should only be used where it is appropriate. [6] proposes three criteria—built around the ‘changing user’, ‘a priori’ and ‘usability’ arguments—which can act as a guide in this situation. The changing user argument is based on the fact that people do not remain the same over time, and change according to their knowledge and experiences. Consequently, an initial perfect fit between user and interface will deteriorate over time, necessitating some change on the part of one or other. The a priori argument states that for certain tasks, such as natural language processing, a fixed interface will simply not work, and adaptivity is required from first principles. The usability argument applies if it can be shown simply that the interface can be made easier or more effective to use if adaptivity is included in it. The use of adaptivity within a user interface should be driven by the needs of the user(s) of the interface, but must also consider the impact that the introduction of adaptivity has on the usability of the resulting interface [7]. The reader might have noticed that we favour the term ‘adaptive’ over ‘intelligent’, as applied to user interfaces. Our reasons for this are pragmatic in nature, and stem from our belief that the components of these systems should play to their strengths: human users are suited to intelligent behaviour, whilst machines are generally not. We share the views of others in the field (such as [8]) that there is a theoretical spectrum of interactive systems which range from the totally fixed ‘designed’ system to the totally flexible ‘adaptive’ system, and a parallel spectrum of varying requirements in terms of ‘intelligence’. [8] argues that there is a direct trade-off between flexibility and useability, and the key aim of designing adaptive systems in is essence to pick the correct point on the spectrum between the two. There is no (non-trivial) absolutely usable (and therefore highly specialised in design) system which has much flexibility, and the ultimately flexible system, applicable to a wide range of situations and users, would be difficult to use. Our stance on this issue is that the simpler the desired adaptivity of the interface, the easier it should be to quantify and implement. A central principle of usability is that the user of a system should feel in control of it. Any adaptation that occurs ought, therefore, to be obvious from two perspectives: both obvious that it has occurred, and obvious why it has occurred. Much of the scepticism attracted by adaptive user interfaces-and agent technology as an approach to supporting adaptation springs from the fact this has not always been the case: the inclusion of adaptivity or ‘intelligence’ in an interface has sometimes been seen as either an abdication of the responsibility on the part of the designer(s) to make the interface usable in the first place [9], or as an attempt to ‘replace’ the user’s intelligence in some way [10,11]. 5 Using software agents to aid web browsing One means of incorporating adaptive behaviour into a user interface is to use the concept of ‘software agents’: autonomous processes, which act in concert with a user as they carry out some task. The term ‘agent’ means many different things to different groups of people: for an overview of the variety of work currently being pursued under the umbrella term ‘agent’, see [12]; for a more informal discussion of agents, and agents as elements of user interfaces, see [13–16]; [17] gives a more technical HCI perspective on the use of agents as intelligent interfaces; and [18] provides an AI-based characterisation of software agent technology. The common element in these different views is that agent systems can assist users as they work. In this article we use agents as simple ‘reactive’ systems to look at issues of adaptation at the user interface and to consider the design and development issues that are of importance. For a basic view of agents as simple reactive systems, see [19,20]. Having chosen agents to suit our adaptation mechanism, we need to define a context in which to apply them. 5.1 Related Work Although different views exist of precisely what constitutes an ‘agent’, a common element in the majority of these different views is that agent systems can assist users as they work. Our proposed framework will need to accommodate this requirement (and others) if it is to be useful. A brief review of current systems will illustrate these requirements, so we can be sure that characteristics exhibited by these systems can be adequately specified and implemented in terms of our framework. This section provides an illustration of some current systems, with a view to drawing some conclusions about the form and function of adaptive Web browsing systems. With a knowledge of these, it is possible to isolate a core of functionality which is required of adaptive in general. This information is then used in the development work later in the paper. 5.2 Alexa Internet The Alexa Internet assistant [21] acts as a kind of associative memory for people as they browse the Web. The Alexa Internet service maintains a large database of Web page addresses (URLs), together with summaries of the pages, and associations between pages with similar content. As the user browses the Web, the Alexa Internet assistant performs background retrieval from the parent site. At any time, the user can then retrieve comprehensive information about the page they are currently looking at, plus suggestions for related pages together with descriptions. Alexa works in parallel with the Web browsing application, utilising interfaces to receive event information from specific browsers. 5.3 BASAR The BASAR system [22] allows users to explicitly set up multiple bookmark lists or ‘hotlists’ which can then be maintained by the system. These multiple ‘views’ are presented as a set of separate Web pages, containing hierarchical lists of bookmarks. Each view has keywords associated with it, which define the subset of Web documents that are deemed to be of interest within each category. As the user browses, BASAR monitors how the links on these pages are used, and the information is recorded by each page's ‘monitor’ agent. The user can also define criteria for when links should be ‘retired’—i.e., moved to less prominent positions,—or ‘expired’, in which case they are removed from the page. The BASAR agent is implemented as a Web ‘proxy’—an intermediate process which sits in between the browser and the Web—to allow it to access to the requests transmitted as the result of the user's actions. 5.4 WebWatcher and WebMate These two systems provide complementary support for different parts of the Web ‘experience’. WebWatcher [23] is the simpler of the two, and is set up with a list of URLs of interest – presumably gleaned from the user's existing hotlists or ‘favourites’ lists. The system performs periodic re-fetches of these documents in order to keep the user informed of any changes which occur. The protocol used to transfer Web pages permits a Web browser to request only document ‘meta-information’—which includes such details as the size of the document and the date of the last modification—so this can be accomplished very efficiently. The WebMate [24] personal assistant records browsing behaviour and uses machine learning techniques to group visited pages into keyword-driven clusters based on common content. 5.5 HyperSpace The HyperSpace system [25] is a tool for visualising the ‘distance’ between Web pages visited by the user. It monitors a user's behaviour and the structure of clusters of related pages that the user refers to frequently. This information is used to build a three-dimensional map of portions of the Web's space – a frequently-used index node (e.g., a site's contents page) is represented by a sizeable sphere, and local pages referenced from it appear as satellites. These maps can then be used by individuals to acquire a more concrete grasp of the relationships between sites visited. In essence this provides an automatic site map generator, with each of the nodes annotated with information about the page title. 5.6 Letizia The Letizia system [26] acts as an assistant which provides suggestions of Web pages that may be of interest, based on the current page and knowledge of a user's interest. In addition, other more subtle indicators are taken account of – for example, since users generally read Web pages from top to bottom, a link which is ‘skipped over’ (i.e., not selected, when other links further down the same page are selected) is inferred to be proportionately less interesting. Suggestions appear in a separate window in a similar manner to a browser displaying an index page, so that the user is entirely free to ignore any and all of them, ensuring that no overt interference takes place. 5.7 Summary These systems all share certain characteristics – most prominently, they work in parallel with the user, carrying out work to respond to the user's behaviour and support the user's activities. These systems provide hints and suggestions rather than explicitly influencing the user's behaviour. At a more technical level, they are all integrated to a certain degree within the operating system, exchanging information with the user's other applications. Some are presented explicitly, while others may appear to be virtually invisible, appearing only when invoked by the user. All, however, need to be catered for within an operating system environment. 5.8 Focus of the study The task of searching for information on the Web has several key characteristics that make it suitable for solutions involving agents and leading to adaptive user interfaces: the great volume of the information ‘set’ to be searched; the mechanistic way manual searches are accomplished; the time this takes and the consequent ease of distraction; and the phenomenon of disorientation or becoming ‘lost in hyperspace’ – following a sequence of links of interest, then wishing to backtrack to an interesting item of information, and forgetting where that item was. For a more detailed exposition of the key issues involved, see [27]. The basic processes underlying Web searches are highly suitable to the application of agent technology, as there are substantial routine, mechanistic aspects which can be supported by software agents allowing the user to concentrate on the more intellectually demanding aspects of the task (or issues arising from the task). The underlying document representations used on the Web provide machine-readable meta-information that can be used to assist the searching processes (discussed in more detail in a later section). 6 Scenario: browsing the web The task domain which acts as the context for this development, is that of navigating the World Wide Web [28], searching for information. The article considers a user operating an adaptive Web browser, which utilises some simple agents, which can react to the user’s actions and adapt according to the user’s behaviour. Fig. 1 gives a high-level view of how such a system might be structured, using a Web browser and ‘assistant’ system interacting with the software Web agents, which in turn interact with the Web. Fig. 1 Open in new tabDownload slide A schematic representation of an adaptive Web browsing system. Fig. 1 Open in new tabDownload slide A schematic representation of an adaptive Web browsing system. The adaptive Web browsing system works in parallel with the user, monitoring the events occurring as the user loads Web pages and clicks on hyperlinks. This scenario assumes that the agent system has access to the events occurring within the browser, and the content of the pages viewed by the user. In itself this seems reasonable, but (as will be seen later) it does have a considerable impact on the eventual design and implementation of a system meant to work in this way. The ‘assistant’ system also has a user interface, which might present information to the user or be used to control the assistant, or a combination of both. 7 Basic elements of web use This section examines the sorts of activities which users carry out when browsing the web, searching for information. As well as the activities users do, we can also consider some tasks that the agents could proactively trigger and follow up (keeping in line with the fact than many of the definitions for the term ‘agency’ rely on qualities of proactiveness in agents). It is important to bear in mind what types of information are available about the interaction as it proceeds: Fig. 2 characterises the different communication ‘channels’ that are active between the components present in an adaptive browsing system, together with the different sorts of events and information available within the system as a whole, as detailed in Table 1. Table 1 Possible events in the browsing system Channel Event label Event description Browser→Agent Link-selected Notifies the agent that the user has selected a hyperlink. Page-loaded Notifies the agent that the contents of a given URL has been retrieved and are available to be parsed and analysed (perhaps for keywords or further links). Page-bookmarked Notifies the agent that the user has requested that a page be added to the bookmarks list for future reference. Agent→Browser Load-page Instructs the browser to load a given URL as if the user had done so. Add-bookmark Instructs the browser to add a URL to the bookmarks list. Delete-bookmark Instructs the browser to remove a URL from the bookmarks list. Move-bookmark Instructs the browser to alter the position of a URL within the bookmarks list. User→Agent Accept-suggestion Notifies the agent that the user has expressed interest in a page recommended by the agent. Decline-suggestion Notifies the agent that the user has expressed disinterest in a page recommended by the agent. Find-page Notifies the agent that the user wishes to search for a page within the bookmarks list. Agent→User Add-suggestion Adds to a list of pages that the agent suggests the user may wish to visit. Remove-suggestion Removes from a list of pages that the agent suggests the user may wish to visit. Channel Event label Event description Browser→Agent Link-selected Notifies the agent that the user has selected a hyperlink. Page-loaded Notifies the agent that the contents of a given URL has been retrieved and are available to be parsed and analysed (perhaps for keywords or further links). Page-bookmarked Notifies the agent that the user has requested that a page be added to the bookmarks list for future reference. Agent→Browser Load-page Instructs the browser to load a given URL as if the user had done so. Add-bookmark Instructs the browser to add a URL to the bookmarks list. Delete-bookmark Instructs the browser to remove a URL from the bookmarks list. Move-bookmark Instructs the browser to alter the position of a URL within the bookmarks list. User→Agent Accept-suggestion Notifies the agent that the user has expressed interest in a page recommended by the agent. Decline-suggestion Notifies the agent that the user has expressed disinterest in a page recommended by the agent. Find-page Notifies the agent that the user wishes to search for a page within the bookmarks list. Agent→User Add-suggestion Adds to a list of pages that the agent suggests the user may wish to visit. Remove-suggestion Removes from a list of pages that the agent suggests the user may wish to visit. Open in new tab Table 1 Possible events in the browsing system Channel Event label Event description Browser→Agent Link-selected Notifies the agent that the user has selected a hyperlink. Page-loaded Notifies the agent that the contents of a given URL has been retrieved and are available to be parsed and analysed (perhaps for keywords or further links). Page-bookmarked Notifies the agent that the user has requested that a page be added to the bookmarks list for future reference. Agent→Browser Load-page Instructs the browser to load a given URL as if the user had done so. Add-bookmark Instructs the browser to add a URL to the bookmarks list. Delete-bookmark Instructs the browser to remove a URL from the bookmarks list. Move-bookmark Instructs the browser to alter the position of a URL within the bookmarks list. User→Agent Accept-suggestion Notifies the agent that the user has expressed interest in a page recommended by the agent. Decline-suggestion Notifies the agent that the user has expressed disinterest in a page recommended by the agent. Find-page Notifies the agent that the user wishes to search for a page within the bookmarks list. Agent→User Add-suggestion Adds to a list of pages that the agent suggests the user may wish to visit. Remove-suggestion Removes from a list of pages that the agent suggests the user may wish to visit. Channel Event label Event description Browser→Agent Link-selected Notifies the agent that the user has selected a hyperlink. Page-loaded Notifies the agent that the contents of a given URL has been retrieved and are available to be parsed and analysed (perhaps for keywords or further links). Page-bookmarked Notifies the agent that the user has requested that a page be added to the bookmarks list for future reference. Agent→Browser Load-page Instructs the browser to load a given URL as if the user had done so. Add-bookmark Instructs the browser to add a URL to the bookmarks list. Delete-bookmark Instructs the browser to remove a URL from the bookmarks list. Move-bookmark Instructs the browser to alter the position of a URL within the bookmarks list. User→Agent Accept-suggestion Notifies the agent that the user has expressed interest in a page recommended by the agent. Decline-suggestion Notifies the agent that the user has expressed disinterest in a page recommended by the agent. Find-page Notifies the agent that the user wishes to search for a page within the bookmarks list. Agent→User Add-suggestion Adds to a list of pages that the agent suggests the user may wish to visit. Remove-suggestion Removes from a list of pages that the agent suggests the user may wish to visit. Open in new tab Fig. 2 Open in new tabDownload slide Communication channels in an adaptive browsing system. Fig. 2 Open in new tabDownload slide Communication channels in an adaptive browsing system. Various events may be transmitted over the six channels shown in Fig. 2. Table 1 presents a taxonomy of these events and describes them in more detail. There are no events listed for the two channels “User → Browser” and “Browser → User”, as these are effectively the device and operating system channels through which the user controls the browser and we cannot therefore gain direct access to them. 7.1 User actions These are the events triggered directly by the user of an interactive browsing session. As such they constitute the ‘original’ input to the adaptive Web browsing system, providing the sum total of information available to the adaptive system. Any adaptation decisions made by the system must be based entirely on information gleaned from them. Here are some of the events we may be interested in: Visiting pages: The fundamental action in a browsing system, of loading a page. The user’s browser makes a request to a Web server, which then returns the contents of the requested document to the user’s machine. Following ‘hyperlinks’: The most common way of visiting a Web page is to click on a ‘hyperlink’ (or just ‘link’). A link is a small portion of a Web document which references another Web document (or possibly a file or image – in any case, another ‘thing’ of some kind). Clicking on the link instructs the browser to visit the page linked to. This information can be passed to the assistant system to allow it to monitor the sites visited by the user. Bookmarking pages: Most browsers retain information about pages, which the users have marked for future reference. (The exact terminology varies across different browser applications: some browsers refer to ‘hotlists’ or ‘favourites’.) The act of a user bookmarking a page could be interpreted in several ways. The simplest would be to treat a bookmarked page as indicative of a user’s interest in the contents of that page. The page could be summarised (into a small list of keywords) which would then be stored by the assistant along with the page URL. If a set of bookmarked pages has overlaps in terms of keyword content, the browser might infer ‘interest’ in terms of a subject area, rather than just the page itself. A bookmarked page could also be monitored, and the user informed when it changes. Explicit searches: When the user invokes a search engine of some kind (characterised, for example, by a form containing an entry field and a ‘search’ button on it), the browsing system might make use of some of this information. 7.2 System actions Based on observation of the user, the system may take a ‘decision’ to carry out tasks using its ‘initiative’: that is, it may be proactive. Some typical proactive ‘system’ actions are as follows: As well as actions on the part of both the user and the system, it may be desirable (or even necessary) to introduce new user interface elements to take better advantage of the facilities offered by including adaptation in the interface. These issues are examined in the next section. Speculative retrieval and caching: The system might decide that some links on a page being viewed merit special attention. Based on a link’s contents (that is, the text the user would have to click on in order to load it), and perhaps a document meta-information retrieval,1 1 It is possible to request that a web server returns just the document heading and the title information, often used by authors of web pages to include summarised information about the document’s viewable contents. Fetching this meta-information is faster than a full retrieval. the contents of a page could be retrieved before the user actually selects them and placed in a cache of some kind. If the links were subsequently selected, they would then load more quickly, resulting in a reduction in apparent network delays. While not strictly a functional aspect of the interface, the time taken for Web pages to load does have an impact on the perceived effectiveness of the browsing task ([29]). Even if such pages were not immediately selected, their contents would still be useful as input to a page suggestion system (as detailed in the following section). Page suggestions: The system might decide to recommend certain pages for viewing, based on content. If a page is speculatively retrieved which matches some sort of interest criteria, such as an overlap with an existing group of bookmarked pages, its URL and title could be displayed in a list or separate window, for the user to select if they so wish. [26] took this approach with the ‘Letizia’ Web page suggestion system, as a passive suggestion does not interfere with the user as they work, but may provide alternative leads if the user runs out of ideas. Reordering/regrouping of bookmarks: Frequent Web users tend to accumulate long lists of bookmarked sites. Finding a site can then be difficult, particularly if all one has to go on is the name of the page. Grouping bookmarks by content and frequency of use can help users in maintaining their bookmark lists, as [30] have shown with their BASAR system. An extension of this principle might be a two-level hierarchical structure of grouped bookmarks based on associations between bookmarks pointing at closely related information, which could help a user quickly find the section of the bookmarks list containing the desired bookmark. Background searches: If a user bookmarks several pages which are similar in content this could form a trigger for a query to one of the many Web search engines for other related pages. This could be carried out in the background and the results presented as a ‘suggested’ page, so that the user can again choose to ignore irrelevant searches. This would need to be based on some kind of heuristic keyword extraction algorithm, such as that used in the InfoFinder project [31]. Jumping-off points: A user may often select one of a small set of pages at the start of a browsing session, termed ‘jumping-off points’. For example, the author has organised her bookmarks to have, right at the top, a couple of Web search engines, some miscellaneous publications including two on-line crosswords (for coffee breaks) and some other often-used resources. To place pages in this classification would require information about the time (relative to the start of a browsing session) at which particular links were selected. Repeated periodic fetches: It may be that a user routinely checks certain pages, or performs the same viewing cycle almost every day at a particular time. If the system spots such routine, repeated behaviour on the user’s part, the system might suggest that it could take over and perform the routine itself. 7.3 Tuning the interface for adaptation Using adaptive interface technology opens up some opportunities for providing interface elements, which would not otherwise be useful. The list of suggested pages mentioned earlier might be used simply ‘as-is’, or perhaps with a hidden agenda. For example, when should a bookmark be removed? The interface might present some existing bookmarks in amongst other suggested pages, and if the suggestions are not taken up within some time limit, this could be taken as an indication that the bookmark could be removed. An alternative would be to ‘age’ bookmarks. As well as using this information to rearrange the bookmarks, if a bookmark is not selected for a ‘reasonable’ amount of time the assistant might wish to directly ask the user if the bookmark should be removed. 8 Scope for adaptivity We have identified several opportunities for adding adaptive aspects to the Web browsing system. This section continues by examining how adaptation may occur, and whether it is profitable, or indeed feasible, given the context in which it must take place. In terms of the interface as it is presented to the user, there are two obvious candidates for elements, which may be dynamically adapted: a list of suggested pages, and the user’s collection of bookmarks. 8.1 Page suggestions A powerful mechanism for aiding a user’s browsing is to offer suggestions for pages which are likely to be of interest. As mentioned earlier, this is a non-intrusive way of introducing adaptive behaviour as the user is not required to accept any suggestions made. The user may choose one of the suggested pages at any time – they might be momentarily unsure of which link they should choose next, in which case the suggestions may help them regain their train of thought or find an alternative line of enquiry. The simplest mechanism to use would be to have a window with a list of page suggestions in it, presented as a title, accompanied perhaps by some annotation which describes the system’s reason for recommending the page. If a keyword-based heuristic approach were to be used, as in the InfoFinder agent [32], the system could display the keyword or combination of keywords that caused the page to be suggested in the first place. Other justifications for suggesting a page might be that it is the target of a link on a page that the user spends a lot of time browsing, and that it has a similar profile (in terms of keywords) to the interesting page. A suggestion that is not taken up after a certain amount of time could be ‘expired’, in much the same way as the ‘link expiry’ feature common in browsers. As noted by [26], suggestions offered by a assistant system such as this do not need to be absolutely accurate, just better than no guesses at all, so that expiring suggestions should not be very dangerous. 8.2 Bookmark list manipulations The bookmark list facilities provided by many browsers are reasonably basic in nature. The minimum is a simple linear list of page locations that the user has requested be stored for later reference. There are more sophisticated variants of this system, where a hierarchical ‘directory structure’ using folders can be set up. A hierarchical system can help users maintain their bookmark lists more effectively as the bookmarks can be grouped according to the content in successively more focused groupings as the structure is descended. However, all these systems require the user to directly manage their bookmarks, grouping and organising them as required. At a simplistic level, it would be good if bookmarks that were accessed often were closer to the top of the bookmarks list, which may reduce the time taken to find a particular bookmark. ‘Jumping-off points’, or particular pages which are often loaded right at the start of a browsing session, should similarly be placed near the top of a prioritised list. If a particular bookmark is accessed often in any case, this should also result in it moving up the list. The hierarchically structured bookmark collections introduce the possibility for content-based grouping, where keywords in bookmarked documents could be used to find overlaps between document contents, and recommend a suitable bookmark position. This is a tedious aspect of regular Web browsing: maintaining an ordered list of several hundred bookmarks takes a lot of time, and seems an excellent candidate for automation. 8.3 Evaluating adaptation Adaptive systems as described form an element in a ‘feedback loop’ of sorts – the user interacts with the system, and based on information derived from monitoring this interaction, the system changes itself either in appearance or content. We can see that in order for any adaptation that occurs to be controlled properly, some means needs to exist so that the effectiveness of the change in the interface can be measured somehow. For the aforementioned adaptation areas, several measures are obvious. For suggested pages, the act of the user accepting a suggestion might be taken as a positive indication that the adaptation was beneficial, and the ‘expiry’ of a suggestion would tend to imply the opposite. Of course this may just indicate that the user was busy doing something else, so such measures cannot always be taken at face value. For linear bookmark list manipulations, calculating some measure that depends upon the bookmark’s place in the list versus its frequency of selection would gauge the effectiveness of the organisation. Hierarchical organisation would require a more complex measure that took account of the aggregation of the measures scored by each group or item. The list of suggested pages could be used in order to judge if a particular bookmark ought to be removed altogether – some seldom-visited bookmarks could be put forward as suggestions, and if the user did not choose them for some while, they could be demoted further down the list. 9 Design process Having provided an analysis of the scenario, we will now move on to provide a design for a system which can handle the events noted in the scenario and perform the required adaptation. An existing intelligent interface technology (IIT) architecture is used to derive a design for the adaptive interface as a whole, the requirements placed upon the system and user models, dialogue record and interaction knowledge base. Following the hierarchical structure of the IIT architecture (as shown in Fig. 3), this section examines the Web browsing task and fills in the detail of the model. Once the elements of the model are in place, the active components of the model are arranged into a set of component agents, which then implement the required behaviour of the system as a whole. Fig. 3 Open in new tabDownload slide A reference architecture for intelligent interface technology (from [6]). Fig. 3 Open in new tabDownload slide A reference architecture for intelligent interface technology (from [6]). 10 User model The user model, as its name suggests, encapsulates a model of the user to which the system is intended to adapt. Different types of information about the user are stored in this mode, related to details of the user’s abilities, preferences and knowledge of the task in hand. 10.1 Psychological/cognitive data To browse the web effectively, users need to have good ‘spatial ability’—the ability to maintain a mental picture of the information space they are traversing. The so-called ‘lost in hyperspace’ phenomenon is closely related to this ability, and solutions to this for both users [25,32,33] and designers [34] of web systems have been proposed. For our purposes, we should note that there is scope for the addition of such a system to this one, and recognise that a user’s spatial ability is one attribute which should be recorded. For example, if a browsing history visualisation system were to be added to the Web assistant, the user’s spatial ability would need to be taken into account when deciding how to present the history data to the user and how to provide support for navigating around it. 10.2 Profile data A straightforward example of a component of a Web user’s profile is their list of bookmarks (sometimes termed ‘hotlist’, or ‘favourites’), showing pages that users have expressed interest in returning to at a later time. Areas of interest, as inferred from the user’s browsing habits, would also be stored here. Other measures, such as the amount of time spent browsing by a particular user, would also be held as profile data. 10.3 The Student model The student model records the extent of the knowledge about the domain possessed by the user. This element of the user model is primarily found in tutoring systems, where the final goal of the interaction is to aid and monitor a user’s learning. As such, unless this system was supposed to help a user learn about the World Wide Web, it has limited applicability in this situation. 11 Domain model The domain model defines the scope of the system, encapsulating information about the system’s application area. It effectively defines the boundaries of the system – what the system can ‘know’, or at least, make inferences about. The elements of the user and interaction models are constrained by what is included in the domain model, and the domain model is often expressed implicitly in adaptive systems, as is the case in this system. 11.1 The intentional level In the intentional level of the domain model, we are concerned with inferences about the user’s goals. Questions typical of those that the intentional level would seek to answer might be: These questions are of a sufficient level of difficulty that even an intelligent human would have difficulty answering. We stated earlier that we believe that the place for intelligence is with people as the users of these systems. We would prefer to have systems that can adapt well, but we would not then class these as ‘intelligent’ in any human sense of the word. Bearing in mind the amount and quality of information available to the system, we choose not to consider the intentional level for our application. Why is the user browsing? What does the user hope to achieve? Is the user browsing for pleasure, or actively seeking information on a particular topic? 11.2 The conceptual level The conceptual model is concerned with logical aspects of the system – what a Web page or hyperlink ‘actually is’, and how they are related to each other. The user must have an adequate model at this level in order to use the system effectively, and the system needs to have modelled them (at the program design level) in order to function at all. 11.3 The physical level The physical level defines the nuts-and-bolts mechanisms through which the interaction between system and user actually occurs. Objects at this level include things like menus, buttons and hyperlinks as ‘clickable things’. These objects form the basic visual components of the interface and occur as part of the user’s ‘common sense knowledge’, gained from the past use of computers. The system conforms to models of these at the program’s implementation and application programming interface levels. The physical level, in common with the conceptual level, is coded implicitly in many systems and is represented likewise in this system. To enable these models to be stored, displayed and changed would pose several significant problems in itself: how the model should be represented to the user; how the system could elicit useful information about the user (as users are not always the best source of information about themselves); and at a practical level, how to implement such a radically open and reconfigurable system. Our focus in this study lies at a more basic and pragmatic level, so these issues are not the focus here but might be considered as future work. 12 Interaction model The interaction model forms the ‘active’ part of the adaptive system. The domain and user models are passive collections of data and information describing internal and external elements of the system and its environment. The interaction model uses ‘live’ information resulting from the user’s interactions with the system to manipulate elements of the interface and the user model according to some predefined rules. 12.1 The dialogue record The dialogue record contains a kind of ‘history list’ or journal of the user’s interactions with the system. Events about which the system may later need information are recorded in it, possibly with the times at which they occurred. The information in the dialogue record is gained by transforming the raw input events obtained from the interface with which the user is interacting: for example the mouse clicks and key presses. The user-originated events that form the bases for the adaptations noted earlier are as follows (all events are recorded with the time at which they occur). Pages visited: When the user visits a page, the page’s name and location are stored. Links selected: When the user clicks on a link, details of both the referencing page and the referenced page are stored. Pages bookmarked: When the user bookmarks a page, the page name and location are stored with the time at which it was bookmarked. Browsing session startup times: This event is caused by a user doing anything (that is, an occurrence of any of the three preceding events) after a significant amount of ‘idle time’ has elapsed as the last recorded event occurred. 12.2 Adaptation mechanisms From the user’s point of view, there are two areas where the system can carry out adaptation. The list of suggested pages may be changed in response to the user’s behaviour, and the collection of bookmarks may be rearranged in some way. Page suggestions, based on perceived areas of user interest, can be added to or removed from the list. Additions could be ranked according to relevance, given the magnitude of their overlap with previously identified areas of interest. Removals would occur as a result of the user explicitly declining a suggestion, an event which would indicate negative interest in what the system might have proposed. This in turn could be used to modify the supposed areas of interest. The collection of bookmarks has a more complex set of possible adaptive behaviours: as well as simple addition or removal operations, individual bookmarks can be moved and sets of bookmarks can be grouped according to the content of their referred-to pages. The introduction of a hierarchical layout for the collection of bookmarks introduces further possibilities – a sizeable group of related bookmarks could be heuristically partitioned into subgroups if the group reaches a particular size. 12.3 Inference mechanisms The main inferencing effort of this system is to try to ascertain areas of interest on the part of the user, in order to increase the accuracy of the page-suggestion system, and to act as a basis for grouping of bookmarks. This works by using a simple heuristic page-summarisation system, which extracts keywords from pages, visited. Inferences can also be made about whether a new bookmark coincides with an existing area of interest and so should therefore be added to a group, rather than being placed alone. Disinterest in a link could be inferred from a user selecting another link, which occurs later in the same document (assuming the user is reading the page from top-to-bottom). Other, more tenuous inferences might include an indication of disinterest by the user: for example, if a page is selected but viewed for a shorter time than might be expected (based on length of content), the page may be inferred to be not of interest. This could be counteracted if the user has a record of interest in an area in which the page scores highly, in which case the user might be checking a subset of some information which changes regularly. In any case, the reliability of such inferences is low and should not form the sole basis for adaptation. 12.4 Evaluation mechanisms This system does not perform complex evaluation of the adaptations it carries out, as this would necessitate another level of abstraction in the domain model (that is, the system would need to possess a model of itself in order to evaluate the future impact of any proposed adaptation). Instead, simpler evaluations are carried out, such as gauging the effectiveness of the page suggestions and bookmark arrangements. The system uses measures such as how often the user views a page suggested by the system, and whether the arrangement of bookmarks mirrors their frequency of selection by, and distribution of interest of, the user. As always, a sense of realism must be maintained: the simpler the evaluations performed, the more likely they are to be reliable. The quality of data available upon which to perform evaluations make complex analyses susceptible to various errors. 13 Implementation/execution environment issues At this stage, moving from an abstract set of requirements derived from the elements of the IIT architecture, it is necessary to begin considering exactly how the system may be implemented, as well as the environment in which it has to function. The system clearly has to be event-driven in nature, as it has to perform in real-time in response to a user’s actions. It also needs to be able to handle information from a variety of sources: a Web browser, the Web itself, and a user interface attached directly to the system. Although consideration of these practical issues might seem somewhat premature, neglecting them could lead to a design for a system which would be impossible or impractical to implement at all. 13.1 System requirements The final system needs to run in parallel with a Web browsing program of some kind. This can be accomplished in one of several ways. A new Web browser could be written which implements the assistant system as a component, or an existing application could be adapted to suit the purpose. As with any software project, it is desirable to reduce the amount of novel development to the absolute minimum by using existing software wherever possible, although this obviously introduces a trade-off: if more control is desired, more original development work must be carried out to accommodate this. The solution adopted in this project is to use an existing browser application (with some slight modifications) with a remote control and data collection system. The National Centre for Supercomputing Applications (NCSA) at Urbana-Champaign developed a Web browser called Mosaic. The source code for this application is freely available for educational uses, and also supports a remote-control protocol called the Common Client Interface (CCI). This allows a remote program to connect to an instance of the browser over TCP/IP (a common networking protocol), control the actions of the browser, and obtain information about the user’s interactions with it. The CCI protocol can be accessed from within applications using a pre-written library of routines linked into the application, as shown in Fig. 4. Both the browser and CCI have been extended for this system to handle some additional user actions (as the original versions do not respond to the user bookmarking pages). Fig. 4 Open in new tabDownload slide Implementing browser communication using Mosaic and CCI. Fig. 4 Open in new tabDownload slide Implementing browser communication using Mosaic and CCI. These components run under the X Window System and a variant of the Unix operating system. Newer environments and toolkits do exist and were considered, but it was felt that this combination would offer the largest collection of existing technology which could be adapted for the application. More fashionable languages such as Java could possibly have been used, but integrating the various components would then have been much more difficult. Recent publications have highlighted the fact that although one of the design goals of Java was to provide absolute isolation from the underlying operating system—the so-called ‘write once, run anywhere’ approach—this has not yet been widely achieved, due to various commercial and technical factors [35]. Although the situation is improving, the authors felt unable to completely endorse such an environment for this development effort. 14 System design overview A detailed design for the system was arrived at by examining the adaptive aspects identified earlier in the article, and partitioning major functions into separate component agents. The event-driven nature of the system and the fact that it would be required to simultaneously handle input from the different sources noted earlier meant that the final design would need to emulate a multithreaded environment. From an implementation viewpoint, this is reasonably involved under almost any operating system but particularly so under Unix, where lightweight threads are not widely available and the inter-process communication can impose penalties in terms of performance and increased complexity. The technique finally used is to have a central event-handling entity responsible for dealing with all interactions external to the system, and to have events handled by inter-object method invocations. In this way, a single thread of control can ‘appear’ to be multi-threaded in nature, but without any of the complexity that often accompanies it. The other entities in the system can then be designed as self-contained objects that interact with the event handler, providing a neat solution to the problem. The system has four main types of element: the event handler as described; some ‘link’ handlers which translate between external events and the internal event format used by the system; the agents responsible for the adaptive behaviour of the system; and finally the user, domain and interaction models as defined in the IIT architecture. 14.1 Link handlers Three link handlers are required in this system. One is required to encapsulate the link between the agent system and the browser, one links the agent system and the user interface which controls it, and the final one handles the process of requesting and receiving information from Web servers. 14.2 The Adaptive agents The following agents were selected to be implemented as prototypes for this study. Page agent: Processes pages visited by the user, compiling simple keyword summaries of pages and storing these for later access. Bookmark agent: Maintains the assistant system’s collection of bookmarks, providing mechanisms to add, delete, move or group bookmarks. Also uses information about the bookmarks’ frequency of selection to control rearrangement of the bookmarks. Interest agent: Reacts to overlaps between bookmarked pages in terms of keyword content, and cross-references pages according to these overlaps. In addition, generates events, which indicate that a potential area of interest has been identified. Suggestion agent: Maintains the list of page suggestions, responding to the user accepting or declining suggestions, or requests from other agents to modify the list, also handles requests from other agents for pages to be considered as suggestions. Search agent: Performs background searching for pages of interest: when an area of interest has been identified, submits a query to a search engine for processing and passes the results to the suggestion agent. 14.3 The intelligent interface technology architecture models As mentioned earlier, and shown in Fig. 5, certain portions of the various models developed earlier in this section are implicitly represented in the system. For example, the adaptation and inference mechanisms are part of the individual agents in the system. However, the dialogue record and the user model database do exist as entities in the system, available to the agents as required. Fig. 5 Open in new tabDownload slide Generic software architecture of the web assistant system. Fig. 5 Open in new tabDownload slide Generic software architecture of the web assistant system. 15 Implementation details This section gives a technical overview of how the system is actually implemented in software and how the components resulting from the earlier analysis are realised as a set of communicating objects. Fig. 5 shows the software architecture used to implement the prototype for this system. 15.1 System overview The system is implemented as a set of classes, which echo the various components of the IIT architecture and the environment as mentioned earlier in the article. Examples of the classes used to reflect individual agents and internal events follow. A CCILink represents the CCI protocol link to the instance of the Mosaic Web browser associated with the agent system, and translates CCI protocol messages into events and vice versa. A WebLink encapsulates the means for the assistant system to obtain information from the web without having to acquire it through the browser (which can interrupt the user’s interactions with it). A UILink embodies the link between the user interface and the assistant system and is responsible for translating raw user interface events into events, which can be handled by the system. A Dispatcher handles incoming events, notifying agent instances of them. Also contains methods to be called by the agent instances, which result in new events being distributed within the system. An instance of an Agent handles events supplied by the Dispatcher, possibly generating new events which feed back to the Dispatcher, allowing for different levels (physical, syntactic or semantic) of events. An Event reflects the various occurrences that elements of the system may need to be notified about. Events may be at different levels of abstraction. For example, events representing the selection of a hyperlink or the bookmarking of a page are at the ‘physical’ signal level, whereas the inference level. A ModelSet is an aggregation of the elements in the IIT architecture, including the user, domain and interaction models. As mentioned earlier, portions of the models discussed are implemented implicitly as code, rather than explicitly as data members. A ModelSet contains the dialogue record for the system. 15.2 The agent class The Agent class is an abstract base class which defines a functional template for a general agent which can then be subclassed to implement the particular details of any given agent. An agent is constructed with parameters that determine which model set (corresponding to the aggregation of information in the IIT architecture) along with a dispatcher, which is responsible for distributing information coming in to the system. Events are propagated to instances of agents by the dispatcher via the HandleEvent method (Fig. 6). Fig. 6 Open in new tabDownload slide A skeleton definition of the agent class. Fig. 6 Open in new tabDownload slide A skeleton definition of the agent class. 15.3 The event class The Event class defines the event types that can be handled by the system. As additional signal levels are added to the system, so the list of event types can be extended (Fig. 7). Fig. 7 Open in new tabDownload slide A skeleton definition of the event class. Fig. 7 Open in new tabDownload slide A skeleton definition of the event class. 15.4 Evaluation The process of developing this system highlighted several issues, which influenced the design and implementation stages in different ways. These issues identify some general, current shortcomings and also point a way out for the future work in this area, as discussed in the next section. The key consideration within this study was to provide a way for the functionality exhibited by several existing systems to be realised within a common theoretical and practical framework. To this end, much of the evaluation is undertaken from a technical viewpoint, although some non-technical coverage is also provided. From a purely developmental perspective, the IIT architecture as discussed provides a useful tool for the development of adaptive systems. It lays out a framework for specification and analysis of the adaptive characteristics of the system, rather than using ad-hoc techniques, which may prove to be unreliable. However, a direct implementation of the output of the IIT architecture is difficult. In practice, elements of the various models end up distributed around components of the system, unless a lot of effort is expended to make the models open and modifiable. Incorporating visible models of the system's internals is difficult from both implementation and user interfacing angles, and may not be useful anyway. There is no point in making the adaptive system applicable to any task domain if it will only ever be used for Web browsing: this returns to the ‘usable’ versus ‘flexible’ argument in the second section. As well as offering useful input to the design and specification stages of systems involving adaptive user interfaces, the proposed framework also contains the ability to accommodate the integration of these systems into the final operating system environment. The vast majority of these applications need to acquire and interpret information from multiple sources (both the user and the Web, in this instance), and this requirement places additional constraints on the final form of the software – in terms of event-driven programming, for example. The proposed framework offers support for explicitly modelling the interactions between the system and its environment, allowing the implementors to concentrate more fully on the system's characteristics. In software engineering terms, re-using existing technology is difficult: software is most often written with specific applications in mind, and without much attention to generalisability or code re-use. This will hopefully change in the future with the increased use of extensible and re-usable languages such as Java, but does require quite a fundamental change in attitude on the part of those developing software systems. In fact, the proposed framework could be taken further along the component-oriented development path, and re-cast in terms of components and ‘interfaces’ – the explicit connections between component parts of a system. A direct implementation of most of the class hierarchy presented in the paper could be undertaken using a technology such as the Component Object Model or COM [36], resulting in a fully platform-independent framework for adaptive systems development. From the user's viewpoint, the key benefit ought to be that the tasks like Web browsing should be made less tedious, as routine elements of tasks such as these are subjected to increasing automation, but more extensive user trials would be necessary to quantify any improvement. Larger volumes of interaction data are also required to make any informed judgements about this. At the same time, the available information constrains the adaptive capabilities of the system. Common sense would dictate that complex adaptive behaviour requires access to detailed information about the user. Perhaps in some systems, suitable data may be available, but for a system such as this, the paucity of interaction data means that the adaptive behaviour must be kept to a realistic level. In any case, from a philosophical standpoint, we would argue that complex adaptive behaviour for systems (which we would term ‘intelligent’, in the human sense of the word) is not perhaps desirable anyway – intelligence belongs with the user, not the machine. 16 Future work The issues raised in the previous section indicate several directions for future work in the area. As noted, the IIT architecture as discussed earlier provides a useful tool for the specification and analysis of the adaptive characteristics of a system, but direct implementation of the output of the architecture can be difficult. To support this fully would require the development of a more comprehensive framework with the application of the IIT architecture as a component part. More practical guidelines are also required concerning constraints placed upon the adaptive capabilities of systems, as dependent upon the amount and quality of data available to the adaptive system, and the effects this would have on the usability of the resulting systems. The question of how to make the internal models used by adaptive systems more open and modifiable is also difficult, and from a realistic point of view, the reasons for wanting to do so should be clear. Ways of making these models explicit and editable would be required, as well as a sufficiently clear and expressive means of conveying them to the user and allowing them to be changed. Whether this information needs to be available to the user, and whether any modifications they make can be relied upon, are also points which are very much open to debate. At a practical level, although sizeable chunks of software were re-used in this project (albeit with some modifications), this is as yet an exception rather than the rule as far as the software industry is concerned. To ease the situation would require the development and widespread adoption of open toolkits for adaptive systems such as these. The fact that this has not happened is probably an indication of the relative infancy of the field of adaptive systems and of the lack of re-use of software in general. As mentioned in the evaluation, technologies such as COM are could provide a way forward in this situation – component-based development is gaining in popularity and will become far more widespread in the future. 17 Conclusions In this article we have demonstrated the design and development of an adaptive system from first principles. The task domain in question was that of a user browsing the World Wide Web, and the aim was to provide an adaptive system which could assist the user by taking over routine tasks that do not require much (if any) mental effort. In doing so we have shown that realistic expectations of available interaction information must be maintained when specifying the behaviour of an adaptive interface, as complex adaptation based on insufficient data can only result in unpredictable behaviour. This illustrates our central argument that adaptive interfaces should not attempt to exhibit truly intelligent behaviour, as it is, arguably, impossible to obtain the amount and quality of data needed. Even if this problem could be solved by itself, the issue remains as to whether it could be processed in a timely manner needed in a real-time application such as a user interface. We feel that it is important that the research community focuses on appropriate use of terminology in this area, and carefully considers its use of the term ‘intelligent’ applied to user interfaces. ‘Adaptive’ is certainly more closely aligned with the practical and positional stance that we have taken in this article and that much of the work in the field represents. References [1] D.A. Norman, S.W. Draper (Eds.), User-Centred System Design: New Perspectives in Human–Computer Interaction, Lawrence Erlbaum, New Jersey, 198, pp. 31–62. [2] Shneiderman B. , Designing the User Interface: Strategies for Effective Human Computer Interaction 1987 Addison-Wesley , Reading, MA [3] Benyon D.R. , Adaptive systems: a solution to usability problems , User modelling and user-adapted interaction 3 ( 1 ) 1993 ) 43 – 69 OpenURL Placeholder Text WorldCat [4] Browne D.P. Totterdell P.A. Norman M.A. , Adaptive User Interfaces 1990 Academic Press , New York [5] J.W. Sullivan, S.W. Tyler (Eds.), Intelligent User Interfaces, ACM Press, New York, 1989. [6] Benyon D.R. Murray D.M. , Applying user modelling to human-computer interaction design. Artificial Intelligence Review 6 ( 1993 ) 43 – 69 [7] K. Höök, Steps to take before IUI becomes real, Proceedings of the 1997 Workshop on The Reality of Intelligent Interface Technology, Edinburgh, UK, 1997. [8] Lieberman H. Maulsby D. , Instructible agents: software that just keeps getting better , IBM Systems Journal 35 ( 3,4 ) 1996 ) 539 – 556 Google Scholar Crossref Search ADS WorldCat [9] B. Shneiderman, Direct Manipulation for comprehensible, predictable and controllable user interfaces, Proceedings of the 1997 Conference on Intelligent User Interfaces, ACM, Orlando, Florida, 1997. [10] J. Lanier, Agents of Alienation. Hotwired (WWW) URL: http://www.voyagerco.com/misc/jaron.html 1996. [11] J. Lanier, My problems with agents, Wired, 1996. [12] Nwana H. , Software agents: an overview , Knowledge Engineering Review 11 ( 3 ) 1997 ) 1 – 40 OpenURL Placeholder Text WorldCat [13] Jennings N.R. Wooldridge M.J. , Software agents , IEE Review 1996 ) 17 – 20 OpenURL Placeholder Text WorldCat [14] Laurel B. , Interface agents: metaphors with character Laurel B. The Art of Human-Computer Interface Design 1990 Addison-Wesley , Reading, MA 355 OpenURL Placeholder Text WorldCat [15] Maes P. , Agents that reduce work and information overload , Communications of the ACM 37 ( 7 ) 1994 ) 31 – 40 Google Scholar Crossref Search ADS WorldCat [16] P. Maes, Intelligent software: programs that can act independently will ease the burdens that computers put on people, Scientific American, 1995. [17] D. Chin, J.W. Sullivan, S.W. Tyler (Eds.), Intelligent interfaces as agents, Intelligent User Interfaces, ACM Press, New York. [18] Wooldridge M.J. Jennings N.R. , Intelligent agents: theory and practice. Knowledge Engineering Review 10 ( 2 ) 1995 ) 115 – 152 Crossref Search ADS [19] Brooks R.A. , Elephants do not play chess Maes P. Designing Autonomous Agents: Theory and Practice from Biology to Engineering and Back 1990 MIT Press , London OpenURL Placeholder Text WorldCat [20] R.A. Brooks, Intelligence without reason, Proceedings of the 12th International Joint Conference on Artificial Intelligence (IJCAI’91), Sydney, Australia, 1991, pp. 569–595. [21] Alexa, The Alexa Internet Assistant. URL: http://www.alexa.com, 1998. [22] C. Thomas, G. Fischer, Using agents to personalise the web. In: Proceedings of the 1997 Conference on Intelligent User Interfaces, ACM, Orlando, Florida, 1997. [23] K. Patfield, WebWatcher. URL: http://www.xroads.com/∼Patfield/WebWatcher.html, 1997. [24] L. Chen, K. Sycara, WebMate – a personal agent for browsing and searching. In: Proceedings of the Second International Conference on Autonomous Agents, 1998. [25] A.M. Wood, N.S. Drew, R. Beale, R.J. Hendley, HyperSpace: web browsing with visualisation, Proceedings of the Third International World Wide Web Conference, Darmstadt, Germany, 1995, pp. 21–25. [26] H. Lieberman, Letizia: an agent that assists web browsing, Proceedings of the International Joint Conference on Artificial Intelligence, Montreal, 1995. [27] Macredie R. Keeble R. , Software agents and agency: a personal information management perspective , Personal Technologies 1 ( 2 ) 1997 ) 88 – 100 Google Scholar Crossref Search ADS WorldCat [28] Berners-Lee T. Cailliau R. Luotonen A. Nielsen H.-F. Secret A , The World Wide Web , Communications of the ACM 37 ( 8 ) 1994 ) 76 – 82 Google Scholar Crossref Search ADS WorldCat [29] C. Johnson, The impact of marginal utility and time on distributed information retrieval, People and Computers XII-Proceedings of HCI’97, Bristol, UK, 1997, pp. 191–204. [30] T. Fischer, BASAR: a bookmark organiser for browsing the web, Proceedings of the 1997 Conference on Intelligent User Interfaces, ACM, Orlando, Florida, 1997. [31] Krulwich B. Burkey C , The infofinder agent: learning user interests through heuristic phrase extraction , IEEE Expert (Special Issue on Intelligent Systems and Their Applications) 12 ( 5 ) 1997 ) 22 – 27 OpenURL Placeholder Text WorldCat [32] P. Dömel, WebMap-a graphical hypertext navigation tool, Proceedings of the Second Inter-national World Wide Web Conference, Chicago, USA, 1994. [33] R.J. Hendley, N.S. Drew, A.M. Wood, R. Beale, Narcissus: visualising information, Proceedings of the IEEE Symposium on Information Visualisation, Atlanta, Georgia, USA, 1995, pp. 90–96. [34] Y.L. Theng, C. Rigny, H. Thimbleby, M. Jones, HyperAT: HCI and web authoring, People and Computers XII — Proceedings of HCI’97, Bristol, UK, 1997, pp. 359–378. [35] Tyma P. , Why are we using Java again? , Communications of the ACM 41 ( 6 ) 1998 ) 38 – 41 Google Scholar Crossref Search ADS WorldCat [36] D. Rogerson, Inside COM, Microsoft Press, 1997. © 2000 Elsevier B.V. All rights reserved.
TI - Assistant agents for the world wide web intelligent interface design challenges
JF - Interacting with Computers
DO - 10.1016/S0953-5438(99)00004-1
DA - 2000-02-01
UR - https://www.deepdyve.com/lp/oxford-university-press/assistant-agents-for-the-world-wide-web-intelligent-interface-design-jK4eu4UfJQ
SP - 357
EP - 381
VL - 12
IS - 4
DP - DeepDyve
ER -