1 / 47

Using Adaptive Hypermedia for Web-based Education

Using Adaptive Hypermedia for Web-based Education. Paul De Bra Eindhoven Univ. of Technology Peter Brusilovsky Carnegie Mellon University. Topics. Why adaptive hypermedia systems (AHS)? Adaptive hypermedia design Implementation issues for AH on the Web The AHA system Authoring for AHA

ona
Download Presentation

Using Adaptive Hypermedia for Web-based Education

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Using Adaptive Hypermedia for Web-based Education Paul De Bra Eindhoven Univ. of Technology Peter Brusilovsky Carnegie Mellon University

  2. Topics • Why adaptive hypermedia systems (AHS)? • Adaptive hypermedia design • Implementation issues for AH on the Web • The AHA system • Authoring for AHA • AHA demo • Authoring for Interbook • Interbook demo

  3. Why Adaptive Hypermedia? • Adaptive hypermedia has two purposes: • prevent users from getting lost by means of individualized navigation and orientation support. • adapt the information on the pages to each user, depending on the order in which pages are read. • Adaptive hypermedia systems therefore offer: • adaptive maps (fish-eye views) of the overall link structure (and indication where the user is). • manipulation of the links (annotation, hiding, ...) • conditional inclusion (or emphasis or modification) of parts of a page’s contents.

  4. Adaptive hypermedia design We follow the AHAM reference model: • domain model: describes the subject domain at the conceptual level. • user model: describes the user’s knowledge, preferences, background, experience, etc. • teaching model: describes how adaptation should be done, depending on the domain model and the user model.

  5. Domain model • It describes the subject domain in terms of concepts. • atomic concept: fragment of information, that cannot be changed by the AHS. • page (concept): a collection of atomic concepts (or fragments), structured in some way (e.g. a sequence); fragments are conditionally included in a presentation. • composite concept: a collection of other composite concepts and/or pages, structured in some way.

  6. Structure of a composite concept WWW HTML HTTP (set of pages) what tags specials request response (sequence of fragments) (sequence of fragments)

  7. Constraints for concepts • A concept may not contain itself (directly or indirectly). • A composite concept may only contain other composite concepts or pages, not atomic concepts. • A page may contain only fragments. • A concept may occur in different composites. • A fragment (atomic concept) may appear on different pages.

  8. Concept relationships Concepts relate to each other in different ways: • link relationship: there may be a hypertext link from a concept to another concept. • prerequisite relationship:the user should read (or learn about) some concept(s) before starting on some other concept(s). • inhibitor relationship: once a user has read (or learnt about) some concept(s) some other concept(s) become irrelevant. • there may be many more relationship types...

  9. Constraints for concept relationships For each type of concept relationship there are different constraints: • A link must have at least one source and one destination. • A concept must never be a prerequisite for itself, either directly or indirectly. • A concept must never inhibit itself, either directly or indirectly. • There may be many more constraints for these or other relationship types.

  10. Notes about domain model • Composite concepts must have a structure: when the concept is the destination of a link the structure is used to determine a sub-concept as the actual destination. • Pages must also have a structure: when presenting a page the structure determines in which order to present the fragments. • Concept relationships do not indicate how they influence the adaptation; the teaching model expresses the adaptation.

  11. User Modeling • An adaptive hypermedia system is usually also adaptable: some aspects of the user model can be explicitly set by the user (through a form or questionnaire). • The adaptive features normally concentrate on the knowledge about concepts. An AHS monitors the user’s actions: • requests for pages • reading time per page • results for (multiple-choice) tests

  12. User Modeling (cont.) A user model is more or less a table: for each user and each concept a number of attribute values are stored. Example: ... name knowledge read ready-to-read WWW learned false false HTML well-learned true true HTTP not-known false true ... ...

  13. User modeling (cont.) • There are three common ways to represent the user’s knowledge about a concept: • Boolean model: a concept is known or not-known. • Discrete model: there are a few values, e.g. well-known, well-learned, learned, not-known. • Continuous model: there is a range of values, e.g. the interval [0..1], or a percentage (values between 0 and 100) as an approximation. • Beware of too much detail: the source of user-model information is not reliable.

  14. User modeling (cont.) • The representation of knowledge influences the granularity of the domain model: • With the Boolean model every page is associated with a domain model concept; there is little use for composite concepts. • With the discrete model there is limited use for composite concepts. • With the continuous model pages may contribute a different amount of knowledge to a composite concept. The reading time (per page) may be taken into account as well.

  15. User modeling (cont.) • other attributes in a user model: • read: this stores information about what was read by the user. For a composite concept nothing is read. For a page read may be • Boolean: read or not read. • access times: as in a log file. • reading time: actually “display” time. • ready-to-read: stores information about whether the user is “ready” to learn about this concept. May be Boolean, discrete or continuous ([0..1]).

  16. The teaching model • an AHS performs adaptation based on the domain model and the user model. It follows certain rules, e.g.: • When there is a link from C1 to C2 then there must be a link anchor in C1 for a link to C2. • When C1 is a prerequisite for C2 then links to C2 are not desirable until enough knowledge about C1 is acquired. • When a page is read that is desirable more knowledge is acquired than when reading an undesirable page.

  17. The teaching model (cont.) • there are two kinds of rules: • Some rules are executed before the presentation of the next page. They can be used for: • determining which page to display. • selecting and ordering fragments to display. • selecting how to present anchors to which concepts. • Some rules are executed after the presentation of the next page. They are used for: • updating the user model.

  18. The teaching model (cont.) • Selecting a link destination involves: • When the destination is a composite concept one or more sub-concepts must be chosen to be the “actual destination” to presented. • This process is repeated until the actual destination is a page. • When the (actual) destination is a page the content of the page is constructed by selecting fragments and possibly sorting them (if the page structure is not already a sequence).

  19. The teaching model (cont.) • Constructing a page is done by: • For each fragment it is decided whether or not it is desirable. This is done by checking prerequisite, inhibitor and possibly other requirements. • The selected fragments are sorted. If the page has a sequence structure then the order of the fragments is fixed. But other structures are possible which require the order of fragments to be computed in some way.

  20. The teaching model (cont.) • Whether or not a concept is desirable is determined by rules like: • if C1.knowledge < 0.8 and C1 is prerequisite for C2 then C2 is not desirable. • if C1.knowledge > 0.8 and C1 is inhibitor for C2 then C2 is not desirable. • There are propagating (transitive) effects: • if C1 is prerequisite for C2 and C2 is prerequisite for C3 then C1 is prerequisite for C3. So when C1 is not known then C3 is not desirable.

  21. The teaching model (cont.) • There are four ways to deal with anchors for links leading to undesirable concepts: • hiding: the anchor is hidden by making it indistinguishable from normal content (text). • annotation: the anchor is presented differently from anchors of links to desirable concepts. (The color may be different for instance.) • removal: the anchor is removed from the content of the page. (May disrupt the content.) • disabling: the anchor does not activate a link, but it may still look like a link anchor.

  22. The teaching model (cont.) • Link manipulation (annotation) can be expressed by rules, e.g.: if A1 is anchor of link from C1 to C2 and C2 is desirable then if C2 was not read then A1.color := green else A1.color := yellow else A1.color := red • Link hiding is like link annotation, but the “undesired” color is black (or whatever the color of normal text is).

  23. The teaching model (cont.) • The rules for updating the user model are executed after generating a page. Example (for concept C of page P): if P is just read then if C is desirable then C.knowledge := 0.8 else C.knowledge := 0.5 else C.knowledge remains unchanged • There may be other rules for changing / storing “read”, “desirable” and other values.

  24. The teaching model (cont.) • Rules may be built into the AHS or written by the author. • Rules may be generic for all relationships of a certain type, or specific for some specific concepts. Specific rules may be intended to create exceptions to generic rules.

  25. Implementing AH on WWW • There are three well-known and general server-side technologies: • CGI-scripts: a process is executed for each HTTP-request; it generates one HTML page. There is process and communication overhead. • Fast-CGI: a “script-server” process handles each HTTP-request; it generates the HTML pages. There is only communication overhead. • Servlets: some Java code is added to the Web-server; it generates the HTML pages. Programming for these technologies is similar.

  26. Implementing AH on WWW (cont.) • An adaptive engine works as follows: 1. First the stored user model is retrieved from disk (from a file or database). 2. Other “attributes” used in rules are initialized. 3. The requested concept is “resolved” to a page. 4. Rules are executed to select the fragments to be presented (and possibly to sort them). 5. Rules are executed to “manipulate” the link anchors (like annotate or hide them). 6. Rules are executed to update the user model. 7. The user model is saved (in file or database).

  27. Dealing with adaptive content • A generated HTML page (containing the information and the links) may be different each time it is requested. • The browser must request the page (from the server) each time the user requests it. • Intermediate proxies must not cache the page. • One solution is to use a different URL each time the page is requested. This makes it impossible to bookmark a page. • A better solution is to “force” browser and proxies to not do caching.

  28. Link manipulation in HTML • Different links on the same page need to be displayed in a different way (to indicate whether the destination is desirable. • Interbook annotates anchors with colored dots and arrows . • AHA uses colored link anchors. It uses cascading style sheets (CSS) to color links depending on a link class. • Links can be hidden by removing the anchor tag <A...>.

  29. Working with Frames: Interbook table of content naviga-tion help pre-requisite concepts infor-mation page generated concepts

  30. Working with Frames: Interbook • Interbook uses a fixed layout with five frames; four are generated by Interbook and one is (mostly) written by the author. The automatic generation of auxiliary frames makes authoring easy. • Each time a request is made from one frame four frames must be updated, through four HTTP (almost simultaneous) requests to the server. This puts a heavy load on the server.

  31. Working with Frames: AHA • AHA does not enforce any frames structure. • AHA does not offer automatic generation of frames (structure or content). • In each frame one can display a generated header and footer, or omit them. • JavaScript (or VBscript) code is used to synchronize updates to frames. Updating different frames puts a heavy load on the server.

  32. The AHA system • Each concept corresponds to a page. • For each page there is a precondition which is expressed in terms of concepts. • Each page generates knowledge about one or more concepts. • Fragments of content (text) are included based upon preconditions per fragment. • Conditional links are hidden when the precondition for their destination is not fulfilled. This can be changed to annotation.

  33. The AHA system (cont.) • Content is authored as HTML files with “special” comments: <!-- requires readme and intro but not www --> <!-- generates html --> <!-- header --> This page becomes desirable when the readme and intro have been read and www has not. The page generates knowledge about html. The text appears between a header and a footer. <!-- footer -->

  34. The AHA system (cont.) • Text fragments are conditionally included: <!-- if www and not (html or http) --> This text sometimes appears <!-- elseif www and not (html and http) --> and sometimes this <!-- else --> and otherwise this <!-- endif --> • These “if statements” can be nested.

  35. The AHA system (cont.) • AHA generates a CSS style sheet for links: <style type=“text/css”> A.good { color : 0000ff } A.bad { color: 202020 } A.neutral { color: 7c007c } </style> • The HTML contains conditional links: <a class=“conditional” href=“...”>anchor text</a> • This is turned into (in case of a desired link): <a class=“good” href=“...”>anchor text</a>

  36. AHA components • The AHA system + document consists of: • a Makefile to generate concept and dependency lists. • a “welcome file” with registration form. • a header file with references to progress report and adaptable features. • a footer file with reference to the “Stop applet”. • a html directory containing the pages. • an icons directory containing standard images. • an images directory containing other images. • an applets directory containing the “Stop applet”. • a reference to the servlet doing the adaptation.

  37. AHA components (cont.) • The welcome file must contain (something like): Welcome to this AHA document.<br> <form method=post action=“servlet-name”> name <input type=“text” name=“name” size=40><br> email <input type=“text” name=“email” size=40><br> id <input type=“text” name=“id” size=10><br> password <input type=“password” name=“passwd” size=10><br> <input type=“submit” value=“go!”> </form>

  38. AHA components (cont.) • The header file looks like: <a href=“...”><img src=“/.../icons/smalltue.gif”></a> <a href=“/.../cgi/get/ID/config/generate”> <img src=“/2M350/icons/config.gif”></a><br> • AHA adds references to a progress report: <b>John Doe has read 47/159 pages.</b> (<a href=“__done__”> these read</a>, <a href=“__todo__”>these still to do</a>.)

  39. AHA components (cont.) • The footer file can contain anything. • AHA adds a “Stop applet”: <applet code=“Stop.class” codebase=“/.../applets” width=2 height=2> <param name=stopurl value=“/.../stop/pagename”> <param name=host value=“127.0.0.1”> <param name=port value=“8001”> </applet> • The Stop applet sends a request to the server when the user leaves the page.

  40. AHA components (cont.) Example of what a header may look like: Example of what a footer may look like: Note that the Stop applet does not show.

  41. AHA components (cont.) • How the Stop applet works: • A Java applet is initialized when its page is loaded. This is done through the init method. • The applet is started each time its page is displayed. This is done through the start method. • The applet is stopped each time its page is replaced by another one. The applet can still do something before really stopping: the stop method is called. • In the AHA Stop applet the stop method sends a request to the server, with the name of the page the user has stopped reading.

  42. AHA components (cont.) • The AHA servlet uses the following files to generate file “x.html” for user “doe”: • The set of existing concepts is read from a file “knowlist”. • The set of concept relationships (dependencies) is read from a file “doclist”. • The user’s knowledge is read from “doe_model”. • The user’s logfile (with all access and stop times) is read from “doe_log”. • The html file “x.html”, icons, images, etc. are read and turned into an html file for presentation.

  43. Authoring for AHA • Authoring requires the following steps: • Creating (copying and modifying) a welcome page, header, footer, and possibly an index page with the frameset. • Writing the content, using any html editor or generator. The editor must support html comments and link classes. • Removing possible html headers, and adding the <!-- requires --> <!-- generates -->, <!-- header --> and <!-- footer --> tags where appropriate.

  44. Configuring the Servlet • The servlet needs six parameters: • HTDOCS: path of the documentroot of the Web-server. • LOGS: path of the log directory of the Web-server. • TITLE: the title for the whole adaptive hyperdocument. It is added to every page. • COURSE: the name of the directory (relative to documentroot) which holds the adaptive document. • BACKGROUND: the name of a background image. • LANGUAGE: for progress report (default English).

  45. Setting up the browser • In order to use AHA the browser must be configured as follows: • The browser must accept text colors and link colors specified in the html pages. (Some browsers let you disable this.) • The browser must not underline links. (AHA hides links by making the text almost black, but underlining links would make them visible.) • You must ensure that the browser requests a page each time it is needed. (AHA generates “expired” pages, but a browser may sometimes ignore this.)

  46. Example page from course 2L690

  47. Example page from course 2M350

More Related