A glass Box Approach to Adaptive Hypermedia
Summary of the Knowledge Acquisition Phase
Download 0.88 Mb.
|
- Navigate this page:
- Design
- Example Scenario
- Non-Adaptive Scenario
- Adaptive Scenario
Summary of the Knowledge Acquisition PhaseLet us briefly summarise the results from the four studies done during the problem formulation and knowledge acquisition phase of PUSH. After limiting our analysis to the information seeking situation and not to the whole project development situation, we could see that there were three interrelated problems that prevented users from utilising the on-line manual efficiently: • There was too much information in the on-line manual, users suffered from an information overflow situation. • The navigation in the on-line manual was difficult for two reasons: the domain itself was structured in an intricate structure which was hard to penetrate, and the on-line manual presented this structure through another information organisation with graphs as the main navigational tool. The graphs proved to be difficult to use for some users. Also the mere fact that there were two different structures to learn added to the learning difficulties. • Once information was found, users would have a difficult time understanding the explanations provided. This seemed to be emanating from the domain itself which is an abstract structure, not grounded anywhere, and also from the fact that these texts were not written with any particular user and task in mind. As we studied the user population more closely, we saw that there were several different aspects of users characteristics which influenced their ability to cope with the three outline problems. These user characteristics included: • the user’s knowledge of the domain, of telecommunications application development, and of software development in general • the user’s spatial ability and previous experience of the on-line manual • the user’s role in the project and the connected information needs • the user’s information seeking task, which to some extent subsumes some of the differences in terms of knowledge possessed by the user and the role they take on in the project From these studies we could also extract a corpus of queries and an initial stab at the problem of which answers would have been most helpful and relevant to users in their actual work situation. We structured the answers into information entities, and constructed a set of standard queries from the corpus of user questions.
DesignAs mentioned in the introduction, the design of POP was done in parallel with the knowledge acquisition and user analysis in the PUSH project. Here it is described it as if we first did the studies of users and then designed and implemented our system. Instead, what we did was to develop a first prototype already during the first year of the project. This prototype was shown to users, and their comments and our further studies of their information seeking behaviour were used as input to the development of a second prototype and later on, the WWW interface to this second prototype. The POP system as described here is a description of the second prototype. In order to make the description of our system comprehensible, we start by showing two example interactions, one non-adaptive, and one with adaptivity. Hopefully, this will aid the reader in understanding the rest of the description of the design of POP. After the examples we provide a quite extensive motivation for the design basis for the POP system that we arrived at, the glass box model, in section . The intention of the glass box model is to offer users a means to understand the system’s internal workings, but without overloading them with details of the adaptive mechanism. We then go on to describe why the system actively adapts to users’ tasks and not to any other characteristics, and how this can be done, in section . Section is devoted to explaining the relation between the glass box model and our design.
She formulates an unspecified, quite general, question about the process subD:iom: ”describe process subD:iom”, hoping that this will help her in getting a first grip of what she needs to do. The question is posed through using the pull-down menu named Pose Query in the graphics window, see Figure J, where the question is one of the menu alternatives. In reply, the system provides her with some information about process subD:iom in what we shall call an answer page. The answer page consists of both some graphics and also some text under different headings.      
Figure J. The interface of the current version of POP: the Netscape window with two frames, one guide frame and one text frame, and the Java applet with the graphs. The graphics window contains two graphs, the process graph and the object type graph. The process graphs presents the process currently in focus with its relation to input and output object types, which subprocesses it consists of and which super-process it inherits from. The object type graph (below) presents any object type in focus (or previously in focus) with its relations to other object types, its super class and potentially any sub classes. In this particular example, the top graph is the process graph with the process subD:iom in the middle, its super process, sdp:subD above, its sub activities below (due to space limitations15 of the graphs we cannot see all the subactivities, we only see two of the seven subactivities: iom:IdentCandObjTyp, and iom:EvalReuseIss), input object types (NodeF, MO, MONB, CRM, NIRP, RP) and output object types (IOM, IOT). The other graph, the object type graphs, contains the object type IOT, with its relations to other object types, MO, NodeUC, RP, IOT, OTS. IOT also has a super-class object type above it, SPI. The object type IOT is in the middle of this window since our user has previously asked some questions about this object type – otherwise the top object type in the object type hierarchy would be displayed (constituting a starting point for search among the object types). The text in the text-window describes the process, subD:iom in the SDP method. The answer page is divided into two frames16: • a textual description (on the right) of the process consisting of a summary, a basic introduction, a purpose description, and some other information entities not visible on the screen, but available further down in the page. • a guide to the textual description (on the left), consisting of the headers to the information pieces. The ones marked as bold are those currently available in the textual description. In the textual description we see two information entities: the summary entity and purpose entity describing the reasons behind process subD:iom. There are also some headers without associated texts, as basic introduction. These headers can ‘opened’: if the user clicks on the triangle symbol next to the header, the associated text will be inserted into the page. This is our variant of stretchtext. The guide frame shows all the headers of the information entities, and the user can use these to jump within the page. By clicking on the header in the guide frame, the textual frame will be scrolled so that the header that was clicked upon is shown on the top of the frame (the information entities are never reordered, the system will just scroll within the page). The user can also see in the guide frame which information entities are open and which are closed. By clicking on the triangle, the user can also cause the system to open the information entity just as in the textual window. When reading through the text some terms are quite unfamiliar to our software developer, she gets confused by: …perform and document an object-oriented analysis… The concept object-oriented analysis is displayed in bold style, indicating that it is possible to ask follow-up questions on that concepts. This is what we name a hotlist. By clicking on the button next to the word object-oriented analysis, the user causes the system to show a list of alternative follow-up queries (as shown in Figure J). She decides to ask the system to compare object-oriented analysis to object-oriented design. The answer to this question is also inserted into the page, see Figure K – it is inserted below the summary introduction, before the basic introduction. The software designer also decides to open the basic introduction (also shown in Figure K). 
Figure K. The interface after ”opening” the basic introduction description and posing a follow-up query comparing object-oriented analysis and object-oriented design. The follow-up questions are currently available through first ”opening” the hotlist (i.e. clicking on the icon next to the hotword), which makes a set of alternative follow-up questions available as links17. As our software developer is getting a first grip of what she should do, she understands that she shall be producing object models of the subsystem and that those has to be documented in instantiations of the object types IOM and IOT marked as output from subD:iom. She navigates to these object types through clicking on their symbols in the upper graphics window. She then re-enters the description of subD:iom through clicking on the subD:iom symbol in the upper graph. When our user feels satisfied with the information about the process subD:iom, she can turn to other processes in SDP-TA, or gain information about the object types. The new object type or process is then presented in its own, dynamically generated, answer page in WWW.
In our non-adaptive scenario above, the user was presented with a textual description, which may turn out to be several pages long. In the screendump in Figure J, only the first page of information was visible – if all the stretchtext-headings had been stretched, the page would have been in the order of twenty A4 pages. POP uses the user’s current information seeking task as the basis for reducing that textual description. When the user first enters the adaptive POP system, the system will assume that the user is performing any task (an unspecified task that only provides the most basic information about each process or object type on the database). The user can immediately change this to some particular task, chosen from a list of tasks displayed in a menu (named Change task in the graphs window), or just allow the system to try to infer a task that better describes his or her needs from his or her interactions with the system. The inferred or chosen task then affects the answer page, making certain information entities open and others closed, and affecting the order of the follow-up questions (on hotwords). A third effect is that POP either writes the whole name of SDP-concepts or just the acronyms, i.e. either Ideal Object Modelling (IOM) or just IOM. It should be observed that the system does not stop the user from getting at all the information – all it does is hide some of the information from the user’s immediate view. By clicking on the headings of information that is closed or ask follow-up questions the user can change a given answer. As the user starts manipulating the answer page, opening and closing stretchtext, and asking follow-up questions, the adaptive system might decide to alter the assumed current task of the user, and this in turn affects the answer page. In order not to confuse the user, the user’s choice of which information entities should be opened and which should be closed will always override what an adaptation to the user’s task would render. This override rule can be seen as a dialogue history; what the user has once chosen to open or close during a session will stay opened or closed. As the task is changed the user may disagree with the task the system has inferred and decide to change the task back to what it was originally or to some other task. This can be done through clicking on the hotlist in the answer page which displays which task the system has inferred that the user is trying to complete – the chosen task is always visible in the top of the page in the sentence: The system has generated this answer assuming that the user is learning the structure of SDP (the word in bold corresponds is a clickable hotlist). Only those alternative tasks that actually will alter the presentation will then be shown to the user in an ordered list according to what the system believes to be the most probable alternatives. The user can also change the task through the Change task menu mentioned above – in this menu all the alternative tasks will be displayed. In other words, the adaptivity will try to make the answer page as short as possible given the demands that follow from the specification of the information seeking task. Going back to our example with the system designer who wanted to know about the process subD:iom. When entering the adaptive system, she did not specify her intended task, instead the system inferred the task from her interactions with the system. So, when she came to the subD:iom answer page, it only showed information relevant to the inferred task Learning details about SDP. This means that the system will immediately have opened the summary, the purpose description, and further down the page some other information entities relevant to this particular task. The system reinforces it’s choice of what should be opened by colouring (in red) the headers of those information entities that were deemed relevant. Those headers are also preceded by a (red) dot in the guide frame. (The red colours appear as grey in Figure J). The text will also show the full names of SDP concepts (plus the acronym in a parenthesis following the concept) rather than only the acronyms normally used by the experts in SDP. Directory: ~kia -> papers ~kia -> Usability and fun An overview of relevant research in the hci community papers -> Comparing Two Approaches to Context: Realism and Constructivism ~kia -> B. Cahour (1), P. Salembier (1), Ch. Brassac (2), J. L. Bouraoui (1), B. Pachoud (3), P. Vermersch Download 0.88 Mb. Share with your friends:
|