Forming and maintaining an accurate "image" of the user ...

Forming and maintaining an accurate “image” of the user within adaptive
educational hypermedia systems

D. Vogiatzis1 , A. Tzanavari, S. Retalis, A. Papasalouros, P. Avgeriou

Dimitrios Vogiatzis Aimilia Tzanavari
Department of Computer Science Department of Computer Science
University of Cyprus University of Cyprus
75 Kallipoleos St. P.O Box 20537 75 Kallipoleos St. P.O Box 20537
CY-1678, Nicosia Cyprus CY-1678, Nicosia Cyprus
Tel:+357-22892749 Tel:+357-22892747
Fax¨+357 22892707 Fax¨+357 22892707
Email: dimitrv@cs.ucy.ac.cy Email: aimilia@cs.ucy.ac.cy

Andreas Papasalouros Symeon Retalis

National Technical University of Athens Department of Computer Science
Department of Electrical and Computer University of Cyprus
Engineering 75 Kallipoleos St., P.O. Box 20537
Software Engineering Laboratory CY-1678 Nicosia, Cyprus
15780 Zografou, Athens, Greece Tel: +357-22892246, Fax:
Tel: ++301 7722487, Fax: ++301 7722519 +357-22-339062
Email: andpapas@softlab.ntua.gr Email: retal@ucy.ac.cy

Abstract

Adaptive hypermedia Educational Systems represent an emerging technology that provides a
unique advantage over traditional Web-based Educational Systems; that is the ability to adapt to the
user's needs, goals, preferences etc. Adaptive hypermedia Educational Systems (AHES) are
increasingly becoming part of the mainstream education, yet there does not exist a disciplined way
of designing them - most of the development is ad-hoc. This paper aims to fill this void, which is
the absence of disciplined design, by recording the expertise of existing Adaptive Web-based
Educational Systems in the form of design patterns. We present a categorization of the patterns
according to an established paradigm in Adaptive Hypermedia, we examine the patterns in one of
these categories and provide exemplary patterns for user modeling.

1. Introduction

An Adaptive hypermedia Educational System (AHES) is a dynamic web-based application, which
provides a tailored learning environment to its users, by adapting both the presentation and the
navigation through the content. Such a system is comprised of learning resources, as well as a set of
tools that facilitate the process of studying, such as exams/questionnaires, glossaries,
communication tools, etc. The learning content is dynamically generated based on some
pedagogical rules that combine the (domain) model of the content with the model of the user.
AHES are currently a ‘hot’ topic of research in the broader field of adaptive hypermedia
applications and several AHES systems have been built during the past years [Brusilovsky 2001].

1
Corresponding author

1

Several educational institutions are nowadays designing and developing their own AHES due to the
fact that AHES leverage the shortcomings of non-adaptive web-based educational systems, also
known as Learning Management Systems or Virtual Learning Environments. In contrast to the
latter, AHES can provide tailored, one-to-one tutoring, according to the specific characteristics of
each individual learner rather than serve the same content massively to all the learners.
Furthermore, some educational or research institutions tend to develop their own AHES in order to
implement and test their own learning theories or instructional design methods.
However, the design and implementation of Adaptive Web-based Educational Systems (AHES) is a
complex, if not overwhelming, task. This is due to the fact that it involves people from diverse
backgrounds, such as software developers, web application experts, content developers, domain
experts, instructional designers, user modeling experts and pedagogues, to name just a few.
Moreover, these systems have presentational, behavioral, pedagogical and architectural aspects that
need to be taken into account. To make matters worse, most AHES are designed and developed
from scratch, without taking advantage of the experience from previously developed Adaptive
Web-based Educational Systems, because the latter’s design is not codified or documented. As a
result, development teams are forced to ‘re-invent the wheel’.

Therefore, systematic and disciplined approaches must be devised in order to overcome the
complexity and assortment of AHES and achieve overall product quality within specific time and
budget limits. One such approach is the use of design patterns [Alexander et al. 1977], so that
these systems are not designed and implemented from scratch, but based on reusable design
experience gained over several years of trial-and-error attempts. Therefore good design can be made
explicit, and available to the whole community of designers, so that it becomes common practice. In
this way, designers of new or existing AHES, especially inexperienced designers, can take
advantage of previous design expertise and save precious time and resources.

Till now, the most systematic design approach for AHES is the AHAM design model [De Bra et al.
1999]. AHAM is based on the Dexter Model reference model for hypermedia systems. In order to
address the adoption issues of an AH system, AHAM proposes three models, as shown in Figure 1:
the Hypertext Domain Model, the User Model and the Teaching Model. The Hypertext Domain
Model provides a conceptual view of the AH application defining the concepts and their
relationships that form the hypermedia content as they are considered by the author. The User
Model defines users’ personal characteristics as well as his/her history of interaction with the
content that is conceptually described by the Domain Model. Thus, the User Model is closely tight
with the previous model. The Teaching Model contains rules that transform the previous two
models into hypermedia content presented to the user and control the evolution of the user model
during the user’s navigation into the hypermedia content [Papasalouros & Retalis 2002].

2

Learner Model Teaching Model

Hypertext Domain Model

Conceptual Navigation Presentation
Model Model Model

Figure 1 Overview of the AHES conceptual Model according to AHAM

This paper aims to initiate a pattern language in the domain of AHES for the user model
component. The structure of the rest of this paper is as follows: the second section presents the
overview conceptual model of the patterns for the user model component, where a categorization of
the patterns into 2 main layers (design oriented and implementation oriented). The third section
presents portrays an exemplary patterns. Finally, the fourth section wraps up with conclusions and
ideas for future work.

2. The map of the user model patterns

This section presents an initial set of design patterns for user model component of the AHES. The
organization of these patterns can be achieved according to how they reference each other in the
‘related patterns’ field of their description. Figure 2 depicts the relationships between the proposed
AHES user model design patterns. The semantics of the arrows between the patterns is that the
pattern at the beginning of the arrow is a prerequisite of the pattern at the end of the arrow. The
diagram also depicts the sequencing of the patterns, i.e. in what order they should be applied. Figure
3 depicts an expanded version of the patterns for the AWES.

The user model component plays a pivotal role in the adaptation that takes place as part of an
AHES. It is responsible for forming and maintaining an accurate “image” of the user, which at the
same time has to be meaningful and useful to the system. This is subsequently used in the
adaptation phase, where primarily content and presentation are tailored to the user’s needs [Kavčič
1999]. The patterns presented here attempt to cover the entire user modelling process (both at
design and run time). More specifically, the patterns will try to capture the decisions that should be
made for:
i) the user model definition which shows what information a user model should have.
Information about the user can be regarded as domain–independent and domain–
dependent; or divided into knowledge component (user’s knowledge) and interfaces
component (user’s preferences); or as static (constant through the learning process) and
dynamic (changes during the learning process).
ii) the user model initialisation addresses the problem of deriving the user model at the
beginning of the learning process. Most of the times users fill in a short questionnaire
with questions that refer to a selection of the element of the user model and then well–
known methods from artificial intelligence and machine learning can be used for
determining about his/her user model characteristics, in full. Such methods include
Bayesian networks, rule learning, instance–based learning, learning of probabilities,
logic–based, decision–theoretic, heuristic etc., as well as other general techniques and
principles (plan recognition), and pecifically developed computational, or specifically

3

developed qualitative rules and procedures (rules for selecting and evaluating examples,
rules for choosing adaptation type, rules for choosing questions) [Jameson 1999].
iii) the user model maintenance addresses the problem of maintaining an accurate user
model. Inputs for this part of the user model are gathered directly from user (willingness
to change his/her preferences), through tests and practice (test results, user history of
responses and problem solving behaviour), or user’s actions (browsing behaviour,
number of nodes visited, visited concepts, time spent on page, total session time,
selection of links, searching for further info, queries to the help system). This
information is constantly being collected during the learning process and is also used for
updating the user model.
iv) the user model representation that contains definite design decisions for the
implementation of the user model in an AWES. These are depicted in the lower part of
figure 3. In particular the user representation is divided into three patterns,
corresponding to the three patterns of the upper level of figure 3. That is, there is
description representation, initialisation representation and maintenance
implementation that correspond to user model definition, user model initialisation and
user model maintenance respectively. In particular the user model representation solves
the problem of choosing among the data types that can be used for representing the
various elements the user model (e.g. triggers for knowledge level) as well as methods
for maintaining the user model. In practice, the elements of user model can be
represented as trees, lists, hash tables, etc. Concerning the methods, a combination of
two or more is frequently applied, especially when different methods are used for
initialising and maintaining the user model. This assures more accurate modelling and
allows better exploitation of gathered information. These methods include Bayesian
methods, machine learning methods (rule learning, learning of probabilities, instance–
based learning), logic–based methods (first order predicate calculus), specifically
developed computational procedures (user’s expertise is calculated from their
navigational actions or time spent on documents), etc.

This paper will deal with all the above categories of patterns for the user model component except
from the user model representation. The main reason is that no firm results from evaluation studies
exist, as yet that could help us in deriving design patterns that hold the distilled knowledge of
implementers.

User Model Component

User Model Definition User Model Representation User Model Initialisation User Model Maintenance

Figure 2. The patterns for user modelling

4

Figure 3 The expanded pattern language for the AHES
3. Some Patterns

5

Pattern Name: User model Definition
Problem
A user model in an AHES is essentially the information the system holds about the
user and is mainly related to the learning process. This information has to be such that
the system can better adapt to the user’s individual needs. When observing the learner
computer interaction, several adaptations can take place, some of which do so
explicitly and some implicitly, based on the interactive events, the path that the
learner has taken, the performance concerning some learning tasks, etc [Kobsa 2001].
An adaptive or adaptable educational hypermedia enriches the application
functionality by maintaining a “representation of the user” (or “user model”) and
providing customization mechanisms to modify application features in response to
user model updates. For adaptive educational hypermedia, user model updates are
automatically generated by the system (by monitoring and interpreting the user’s
interactions); for adaptable hypermedia, user model updates are under the user
control. The adaptivity/adaptability feedback could be related to the organizational
and presentational issues of the learning resources (permission to move forward,
encouragement to read specific sections, undertake some tasks, etc.). The information
related to learner’s profile and interaction based on which the AHES can take
decisions for adaptivity and adaptability, should be standardised. Such a
standardisation will greatly enhance the portability of the user model description as
well as the interoperability of AHES that utilize such descriptions of learners.
The problem is which elements should be chosen in order to have a well defined user
model that could allow the AHES to know who the user is and to keep track of the
learning activities.
Analysis
Data about a user serves for deriving contextual structures in an adaptive
environment. There have been attempts to standardize a learner profile such as the
IEEE Personal and Private Information (PAPI) [IEEE PAPI] and the IMS Learner
Information Package (LIP) [IMS LIP]. These standards have been developed from
different points of view. The PAPI standard reflects ideas from intelligent tutoring
systems where the performance information is considered as the most important
information about a learner. The PAPI standard also stresses the importance of inter-
personal relationships discussed also in [Vassileva et al, 2002]. On the other hand the
LIP standard is based on the classical notion of a CV and inter-personal relationships
are not considered at all.
PAPI distinguishes personal, relations, security, preference, performance, and
portfolio information. The personal category contains information about names,
contacts and addresses of a learner. Relations serve as a category for relationships of a
specific learner to other persons (e.g. classmate, teacheris, teacherof, instructoris,
instructorof, belongsto, belongswith). Security aims to provide slots for credentials
and access rights. Preference indicates the types of devices and objects, which the
learner is able to recognize. Performance is for storing information about measured
performance of a learner through learning material (i.e. what does a learner know).
Portfolio is for accessing previous experience of a user.
Similarly the IMS LIP standard contains several categories for data about a user.
The identification category represents demographic and biographic data about a
learner. The goal category represents learning, career and other objectives of a
learner. The QCL category is used for identification of qualifications, certifications,
and licenses from recognized authorities. The activity category can contain any
learning related activity in any state of completion. The interest category can be any
6

Pattern Name: User model Initialisation

Problem

Before a user starts interacting with the Adaptive Web based Educational System
(AWES), her user model must be initialised. It is the designer’s job is to define the
techniques that initialise the user model. Various aspects need to be taken into account
in the initalisation phase. For instance, what is the minimum amount of information to
kick start the system, or what kind of information and what amount is the user capable
or willing to provide? Naturally, the information stemming from initialisation should
conform to the user model definition specifications.

Analysis

Not all elements of the UM description have to be acquired in order for the user to start
interacting with the AWES. There are two reasons for that. In the beginning of an
interaction session, users do not like spending a lot of time providing information about
them, answering long questionnaires for instance. Second, it is not necessary to have a
complete model of the user; a partial model (with proper selection of a subset of UM
elements) will be acceptable.

There are UM elements that can be acquired directly from the user and data that can be
acquired through the AWES. For instance, demographic data can only provided by the
user. On the other hand, user knowledge can also be derived by the system e.g. via the
prehistory of user’s learning activities in other educational environments.

It is also important to initialise the user stereotype, because according to the various
groups of users based on their stereotypes the learning tasks will be specified for each
group separately.

There are two options for the UM, it will be identified with certainty, or it will be
speculated. The first option is not usually the case in practical AWES systems.

Solution

The AWES designer should create fill-in forms with questions that refer to a desired
subset of UM elements. The desired subset is required to form an initial view of the
user model so as to kick start the AWES. There are a number of ways whereby the
desired elements can be derived. Below we provide a list of plausible choices
stemming from real AWES systems that a designer should take into account:

The desired UM elements could be obtained explicitly, by presenting to the user a
questionnaire, which she has to fill in. Typically, the user provides data, such as
demographic data, user preferences, and possibly other sorts of data that are compatible
with the user model description specification.

Another option is to assume values for the desired user model elements from previous
training sessions/learning activities of the user. For instance, a user having followed the
prerequisites of the current course is considered to have enough knowledge to follow it.

Yet another option is to assume certain values (with nothing to backup this choice apart
from being plausible) for the desired user model elements, and then to proceed with the
interaction, expecting that the user model will be corrected during the running time of
the AWES. This is essentially a trial and error approach.

8

Deriving the applicable stereotype requires that a minimum amount of knowledge and
specifically a minimum number of user model definition elements is available. The
derivation of the applicable stereotype can be performed in a number of ways (the
following list is to be considered as indicative rather than complete):

It can be user driven: For instance the user specifies explicitly that she belongs in the
novices’ stereotype.

Inferred by rules: Stereotypes are equipped with triggers, which activate them. Rules
tell which UM elements and with what values can activate a stereotype.

Speculated by rules: If it is the case that there is absolutely no information which can
suggest a certain stereotype, then the AWES designer should have some rules to allow
selection of the stereotype. For instance, a rule of this kind might be: if user does not
specify her knowledge level, then assume it is average.

Related Patterns: UM Definition.

Know uses
In Inspire [Grigoriadou et al. 2001] the user model is initialised, through a questionnaire filled in by
the user at the beginning, or by explicitly selecting the category she fits in according to some
general characteristics. ELM-ART II [Weber et al. 1997] , requests from the users to declare
knowledge units, which are already known to them. In DCG [Vassileva. 1997], the user model,
called student model, is initialized with a preliminary test. ACE [Specht et al. 2000] follows a
somewhat mixed approach . The user model is initialised by explicit and implicit elicitation from
the users. The former is performed, by the user, which specifies her learning strategies and
stereotype; whereas the latter is done by a dynamically generated test.

Pattern name: user model maintenance

Problem
With this pattern we provide a solution to the problem of how to maintain an accurate user model.
We assume that a user model description and the relevant representation have been provided as well
as the user model has been initialised. The user is interacting with the AWES with a purpose of
learning something, during this process various aspects concerning the user change; the general idea
is to capture the changes so as to maintain the user model.

Analysis
The assumption that the user model will remain the same as when it was acquired originally is in
most cases incorrect. As in tutoring between a human tutor and a student, where the student
constantly demonstrates changes, the user of an AWES also changes and as a result his model has to
reflect this. During the course of interaction, there is a leverage of user’s knowledge develops and
the usage data builds up. Since the adaptation is to a large extent based on user knowledge and
usage data, changes should definitely be recorded and be related to a cause-result effect if the
system is to function effectively.
In fact, information such as “demographic data” does not change with a high frequency. There is
also, information like “topics covered” (part of user knowledge) that changes continuously.

9

It is also important for users to be in control (to a degree acceptable to the AWES) of their model
for several reasons. They need to be able to modify information in their model if they feel that it is
inaccurate or incorrect. Also, being in control builds up their trust in the system.
Solution
• The maintenance of an accurate UM can be user driven or system driven. In the former case
it the user who provides explicit information about changes in his/her UM. In the latter case,
the AWES derives information by closely watching the user.
• The AWES designer should define the conditions that govern the maintenance of the user
model. In particular the designer should define the scope of the maintenance changes. The
scope defines the reason for updates. The reason is then quantified in terms of choice of
elements to undergo change. For instance, if the scope says that only a minimal update of
the user knowledge is going to occur, then choice of elements is bound to user knowledge
only. On the other hand a wider choice for the scope would allow updates of user knowledge
and user preferences (e.g. to read theory and having links to examples). Finally, the
frequency of UM description elements updates should be defined.
• The UM maintenance module elicits data to update the UM description. Elicitation of data
could take many forms; next we provide some characteristic examples. The user is presented
with a form to fill in, whereby the update UM is derived. UM description update can also be
interactive, when the AWES opens for instance a pop-up form requesting the user to
explicitly answer a question. Finally, another option for UM update is through filtering the
stream of data that are produced through user interaction. A typical example is the browsing
strategy which can be reduced to a small number of primitives, like ringiness, spikiness,
loopiness, pathiness. The raw data constitute the actual path that the user has followed, but
they must be filtered, process, or summarized to be translated to the predefined number of
primitives.

Related patterns:
User model representation, user model description, user model initialisation.

Known users:

In [Grigoriadou et al. 2001] there is an Interaction Monitoring Module, which collects information
and updates the learner model accordingly. The system allows the users to intervene, expressing
their perspective. A similar approach is followed in [Weber et al. 1997], where the update of the
user model is driven by the system. It is also possible to inspect and to edit the user model. Yet
another similar approach is followed in [Vassileva 1997]. Student model changes are performed
according to student progress. Students can also explicitly modify their Personal Traits and
Preferences. In [Specht et al. 2000] there is a diagnostic module for automated updates of the user
module. Learners can also modify their model anytime.

Conclusions

In this paper we proposed a disciplined approach for designing AHES which takes advandage of the
notion of design patterns that capture the expertise, know-how and tacit knowledge of the
developers of such systems. This approach can be beneficial to inexperienced designers of AWES.
We have introduced a conceptual schema and some patterns for the user modeling component of the
AHES. The proposed set of patterns structured as a hierarchy will help an AWES designer to have a

10

broad view of this component, the problems that he/she has to solve as well as their
interdependencies. However, we have not tackled the difficult problem of user model
representation, which means that we have not proposed solid solutions for the developers. As
mentioned in [Borchers 2001], for the design of interactive systems (and in our case educational
systems) instructional designers, human computer interaction specialist, software engineers, and
subject domain experts, all in a project team, should express their expertise in the form of a pattern
language.
The future direction of our work is to propose software design patterns for AHES which will be
considered a useful language for communication among software developers, and a practical
vehicle for introducing less experienced developers into the field. However, we will continue
towards creating patterns for the design of AHES, since we agree with Borchers that there is “a
good chance to push the concept of participatory design forward by introducing patterns”. This is
what we are trying with a European funded project called ELEN (http://www.tisip.no/ELEN). We
are involving user representatives, instructional designers, elearning specialists, domain experts, in
the design process to evaluate prototypes of elearning systems, and participate in design
discussions.

Acknowledgement

This work was supported by the “ELEN: A Network of elearning centers” project which is
partly sponsored by the European Commission under Socrates Minerva programme (ref nums:
101421-CP-1-2002-1-CY-MINERVA-M).

References

[Alexander et al. 1977] Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I.
and Angel, S. A Pattern Language (Oxford University Press, 1977).
[Borchers 2001] Jan Borchers. A Pattern Approach to Interaction Design, John Wiley & Sons,
ISBN: 0471498289, 2001
[Brusilovsky 2001] Peter Brusilovsky. Adaptive hypermedia. User Modeling and User Adapted
Interaction, Ten Year Anniversary Issue (Alfred Kobsa, ed.) 11 (1/2), 87-110
[De Bra et al. 1999]. Paul De Bra, Geert-Jan Houben, and Hongjing Wu. AHAM: A Dexter-based
Reference Model for Adaptive Hypermedia. Proc. of ACM Hypertext '99, Darmstadt, Germany,
147-156, February 1999
[Dolog et al., 2003] Peter Dolog, Rita Gavriloaie, Wolfgang Nejdl, and Jan Brase. Integrating
adaptive hypermedia techniques and open rdf-based environments. In Proc. of 12th International
World Wide Web Conference, Budapest, Hungary, May 2003.
[Grigoriadou et al. 2001] Grigoriadou, M., Papanikolaou, K., Kornilakis, H. and Magoulas, G.
(2001). INSPIRE: An Intelligent System for Personalized Instruction in a Remote Environment. In:
Proc. of the 3rd Workshop on Adaptive Hypertext and Hypermedia, in User Modeling 2001, LNCS,
Springer
[Dolog & Nejdl 2003] Peter Dolog and Wolfgang Nejdl. Personalisation in Elena: How to cope
with personalisation in distributed eLearning Networks. In Proceedings of the Conference on
Worldwide Coherent Workforce, Satisfied Users - New Services For Scientific Information,
Oldenburg, Germany, September 2003.

11

[IEEE PAPI 2002] IEEE. IEEE P1484.2/D7, 2000-11-28. draft standard for learning technology.
public and private information (papi) for learners (papi learner). Available at:
http://ltsc.ieee.org/wg2/. Accessed on October 25, 2002.
[IMS LIP 2002] IMS. IMS learner information package specification. Available at:
http://www.imsproject.org/profiles/index.cfm. Accessed on October 25, 2002.
A. Jameson, “What Can the Rest of Us Learn From Research on Adaptive Hypermedia – and Vice–
Versa?”, Comments on “Adaptive Hypertext and Hypermedia”, 1999, http://w5.cs.uni-
sb.de/~jameson/ahh/ahh-comments.html.
[Jameson 1999]. A. Jameson, “User–Adaptive Systems: An Integrative Overview”, Tutorial
presented at UM99, 7th International Conference on User Modeling, Banff, Canada, 1999
[Kavčič 1999]. Alenka Kavčič, "Adaptive Hypermedia Learning System on the Web",
EUROMEDIA'99, München, Germany, April 1999.
[Kobsa 2001] Alfred Kobsa. Generic user modeling systems. User Modeling and User-Adapted
Interaction, 11(49):49–63, 2001.
[Papasalouros & Retalis 2002]. Papasalouros, A. & Retalis, S. (2002). Ob-AHEM: A UML-enabled
model for Adaptive Educational Hypermedia Applications. Interactive Educational Multimedia, 4,
76-88.
[Specht et al. 2000] Specht, M., Oppermann, R. (2000) ACE: Adaptive Courseware Environment,
Lecture Notes in Computer Science, Vol. 1892
[Vassileva. 1997] Vassileva J. Dynamic Courseware Generation, Communication and Information
Technologies, Vol. 5, Issue 2, pp. 87-102
[Vassileva et al, 2002] Julita Vassileva, Gordon McCalla, and Jim Greer. Multi-agent multi-user
modelling in I-Help. User Modeling and User-Adapted Interaction, 2002.
[Weber et al. 1997] Weber, G. and Specht M. (1997) User Modeling and Adaptive Navigation
Support in WWW-Based Tutoring Systems. In: Proc. of User Modeling 1997.

12

Forming and maintaining an accurate "image" of the user ...

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Forming and maintaining an accurate "image" of the user ... (20)

More from butest (20)

Forming and maintaining an accurate "image" of the user ...