Recommending Activities in Collaborative M-Learning

1

Estefana Martn, Nuria Andueza, Rosa M. Carro, Pilar Rodrguez
Escuela Politcnica Superior, Universidad Autnoma de Madrid
28049 Madrid, Spain
Estefania.Martin@uam.es, Nuria.Andueza@estudiante.uam.es,
{Rosa.Carro, Pilar.Rodriguez}@uam.es
Abstract. In this paper, the recommendation process carried out in a collabora-
tive mobile learning environment is presented. Its main aim is to recommend
the most suitable activities to be proposed to a specific user at a certain time de-
pending on his/her personal features, previous actions and current context (loca-
tion, spare time, available devices). The recommendation process also decides
whether it is appropriate to alert the user about the availability of the recom-
mended activities or, otherwise, the user should not be disturbed at that time.
This process is based on rule processing and log analysis. Its basis, illustrated
by an example of a specific scenario, is presented.
1 Motivation
The widespread development of mobile and wireless technologies is leading to the
creation of systems to support the realization of activities from any place at any time.
People spend a lot of time working and travelling nowadays and time has become a
valuable good. These facts motivate the appearance of web-based applications that
facilitate an agile and flexible realization of activities in different situations. In the
context of learning, mobile learning (m-learning) applications have also been devel-
oped. M-learning has been defined as e-learning through mobile and handheld devices
using wireless transmission [1]. The fact that different learners have distinct needs,
preferences or personal features has been considered with adaptation [2][3] and rec-
ommendation [4] purposes. In the context of m-learning, the contents also need to be
adapted to different devices [5]. A classification of the characteristics that can be used
with adaptation purposes in mobile learning environments is presented in [6].
In this framework, we aim to recommend users with the most suitable activities to
be tackled at a certain time, depending on their personal features, previous actions and
current context (location, spare time, available devices). The recommendation process
should also decide whether it is appropriate to alert the user about the availability of
recommended activities or, otherwise, the user should not be disturbed at that time.
The rest of the paper is organised as follows: Section 2 presents the main goals of
this work and a sample scenario. Section 3 describes the recommendation process and
its functioning for that scenario, and section 4 describes conclusions and future work.

1
This work is funded by the Spanish Ministry of Science and Education, proj. TIN2004-03140
2 Sample Scenario and Main Goals
In order to illustrate the functioning of the recommendation process, a sample sce-
nario is provided. In this scenario, two users are considered: Ann and John. Both of
them are students of Informatics and partners for laboratory work. Both are novice
students (they have no previous knowledge). Regarding the active/passive dimension
[7], Anns learning style is active while Johns is passive. They both use to connect to
a learning system. Some activities defined in this system are:
A: Lab work to be done collaboratively. It is composed by different subactivities.
B: Meeting between the members of a group to plan collaborative work.
C: Collaborative elaboration of a solution for a given problem.
D: Writing a report.
E: Solving a free text answer exercise individually.
F: Reviewing already studied materials.
G: Sending messages.
The relationships between these activities have been established in different ways
depending on the users the activities are intended to. In the case of the composed
activity A, it will be split in different ways for novice and advanced students. When
accessing A, novice students will be presented with activities B, C and D, in this order
(direct guidance). Advanced students will be presented only with C and D, and they
will be allowed to tackle them in any order (free guidance).
Today, John is sat on the grass at the university campus and sends a message to
Ann through his PDA 15 minutes before going to the laboratory. The system recom-
mends him to review some contents, but John disconnects. Ann is travelling to the
university. Her trip is around 45 minutes long. She switches her laptop on to check
what she can do during the trip. The system sends Johns message to her and also
recommends her to review already learned contents (activity F). As her partner John is
not connected now, she is not proposed with the synchronous collaborative activity B.
Afterwards, when Ann and John connect to the system from different laboratories,
they are informed about the possibility of accomplishing the synchronous activity B.
Our main goal is to recommend the most suitable activities to be tackled by each
user in an m-learning environment according to their specific context (physical loca-
tion, spare time and available devices), personal features (learning style, expertise,
etc.) and previous actions (activities done, results obtained, etc.). The recommending
system should also be able to decide whether the users should be alerted intrusively
about the availability of a new recommendation. More specifically, we aim to:
Provide general recommendations related to the suitability of certain types of ac-
tivities in specific contexts.
Include/exclude activities for different types of students and propose each activity
at the most appropriate time for each of them.
Adapt the navigational guidance offered (direct, free or alternative) to different
types of students when tackling a set of related activities.
Exclude activities with specific requirements related to the users context or per-
sonal features in case that these conditions are not satisfied.
Manage groups and collaborative activities, so that collaborative synchronous
activities are proposed to users only if they are connected at the same time.
Alert the users about new recommended activities intrusively only when it is con-
sidered convenient to interrupt them, according to their context.
Use information about previous interactions of the students in case that no instruc-
tions are given about a certain activity, in order to decide whether the student
should be interrupted to be informed about new recommendations.
3 The Recommendation Process
The recommendation process is divided in two phases: i) selection of the most suit-
able activities to be accomplished by a user in a specific context, and ii) decision
about the convenience of alerting him intrusively. In the first phase, information about
the activities, the relationships between them, the suitability of some types of them in
certain contexts and the specific requirements of specific activities (if any) is proc-
essed. This information is represented by means of rules, which are described in sec-
tion 3.2.
Concerning the types of activities to be supported, users can accomplish both indi-
vidual and collaborative activities such as studying theory, learning from exam-
ples/simulations, solving exercises, doing lab work, or discussing about topics. Other
types of activities are generated on the fly, such as sending/receiving messages or
files, or asking/receiving tutoring. Each activity may include conditions about its
availability depending on any information about users and groups.
The information about the users to be considered with recommendation purposes
(the users features, actions and context) constitutes the user model. The information
about the groups is stored in the group model and contains, for each group, data about
its members, the activities in which they are involved, the results of the activities
accomplished, and the users opinions about previous collaborations. The information
about the users actions is also used for giving recommendations according to the
users previous behaviour in similar situations. In cases where not enough previous
information about a user is available, information about similar users can be used.
During the recommendation process, each activity has a state, which is updated
during the process: recommended (all conditions are satisfied), available but not rec-
ommended (conditions related to the users context are not satisfied) and unavailable
(non-contextual conditions are not satisfied). An annotated list of activities is gener-
ated dynamically. Annotations are made according to the traffic light metaphor [8]:
the recommended activities are marked in green colour; yellow is used for available
but not recommended activities; and red is used for unavailable activities.
Once the activities have been annotated, the alerting module is in charge of decid-
ing whether the user should be intrusively alerted about the recommendations or,
otherwise, the recommendations should be stored and made available for the user
when he/she asks for it. In order to make this decision, alerting rules are processed
and, in case that no rule is triggered, a statistical analysis is done to obtain information
about what resulted better for the same or similar users in similar contexts. The phases
of the process mentioned above are described in detail next.
3.1 Main Phases of the Recommendation Process
With the aim of exemplifying each phase of the recommendation process, Ann and
Johns example will be used. Recommendations will be done to Ann when travelling
by train, and to John when having a rest outside of the university.
The Activity Recommendation Phase
During this phase, the availability and suitability of activities for a certain user in a
particular context is decided according to the characteristics and context of the user.
This phase is structured in three steps: initial recommendations based on structural
rules, context-based recommendations, based on a filtering process, and recommenda-
tion refinement, based on specific activity conditions (see figure 1).
ACTIVITY RECOMMENDATION
Individual
recommendation
Context-based
recommendation
Structure-based
recommendation
G E F
D
C
B A
Initial
recommend.
G E F
D
C
B A
Filtered
recommend.
G E F
D
C
B A
Final
recommend.
USER MODEL
ACTIVITIES
STRUCTURAL RULES
GENERAL FILTERS
INDIVIDUAL
CONDITIONS
B D E A F C G
Cond Cond
D
C
B A A B
D
Novice Advanced
AND ANY
B E
GROUP MODEL

Fig. 1. Activity recommendation
Initial recommendations.
The first step concerns the selection of activities depending on their relationships, as
well as on their requirements and on the navigational guidance for each set of activi-
ties (direct guidance, free navigation or alternative paths), which can be different for
each type of student. For this initial selection, structural rules [9] are processed. They
indicate the way in which each activity is split in sub-activities for each type of user,
and contains information about the curricula adaptation. The relationships between
activities and the navigational guidance to be offered can be established in different
ways for different types of users, by means of rules with distinct activation conditions.
During this phase, the rule conditions are compared to the information about the user,
and if a rule has no conditions or its conditions are satisfied, it is triggered and the
corresponding activities are added to the list of available activities. After this phase, a
first set of available activities is obtained. It constitutes the initial recommendation.
In our example, A is split in different ways for novice and advanced students, as
shown in (1). When accessing A, novice students will be presented with B, C and D,
in this order, as indicated by R
1
. Therefore, they will be guided directly to B. How-
ever, R
2
indicates that the advanced students will be presented only with activities C
and D, and they will be allowed to tackle them in any order (free guidance).

R
1
: [knowledge = novice] A B + C + D (direct)
R
2
: [knowledge = advanced] A C + D (free)
(1)
In the scenario, as Ann and John are novice students, R
1
is triggered and B is anno-
tated in green and added to the initial list of recommended activities for both of them.
Since no structural rules are given for E, F and G, they are also added to the list.
Context-based filtering
In this second phase, the initial list of recommended activities is filtered according to
the information about the suitability of each type of activity for the context in which
the user is. This information is made explicit in context-based rules, which indicate
which types of activities are recommended (or not) for certain types of users accord-
ing to their context. Context-based filtering consists of triggering the corresponding
rules for each user and updating the annotated list of activities accordingly.
In our example, it was considered desirable to propose review, theory and individ-
ual exercise activities to active students if they have more than 15 minutes left and are
outside the university or home. However, it is considered inappropriate to propose an
individual exercise to passive students if they are outside but have less than 20 min-
utes left. These decisions are specified by the rules presented in (2).

R
3
: [lstyle=active, time>15, place=outside] review, theory, ind_exercise
R
4
: [lstyle=passive, time<20, place=outside] NOT ind_exercise
(2)

In our sample scenario, R
3
is triggered for Ann, since she is travelling, she has got
more than 15 minutes available and her learning style is active. Consequently, activi-
ties E (individual exercise) and F (review) are annotated as recommended now (green
colour). However, in the case of John, as he is passive and has only 15 minutes left,
R
4
is triggered and activity E is coloured in yellow in his list (not recommended).
Recommendation refinement
Finally, requirements for specific activities can be expressed by means of individual-
adaptation rules. The recommendation refinement step consists of checking, for each
activity in the list of recommended activities, whether specific requirements should be
fulfilled for its recommendation and, in this case, whether they are satisfied. Apart
from these rules, specific implicit requirements are also considered. For example, in
the case of synchronous activities, it is checked whether all the members of the group
are connected. The list of recommended activities is updated accordingly and the
output of the activity recommendation phase is used as input in the alerting phase.
In our example, it has been stated that novice students will need more than one
hour to accomplish the individual exercise E, while advanced students would be able
to tackle it if they have al least half an hour left (see (3)).

R
5
: [knowledge=novice, time>60] E
R
6
: [knowledge=advanced, time>30] E
(3)
Therefore, according to R
5
, the activity E is not recommended to Ann in her current
context (she has not enough available time). Therefore, E is annotated in yellow, as
available but not recommended at that time. Concerning implicit conditions, as B
requires the members of the same group to be connected synchronously and John is
not connected when Ann enters the system, B is marked in red for Ann. The final list
of recommended activities for Ann when travelling by train contains: B, C and D in
red, since they are not available now; E in yellow, since it is available but not recom-
mended; and F and G in green, to be recommended to Ann. Regarding John, he is
recommended to get involved in F (rules R
1
, R
4
and R
5
).
The Alerting Phase
At this phase it is decided, for each activity of the annotated list generated during the
previous phase, if the user should be immediately informed about the recommenda-
tion or, otherwise, if the activity should be stored in the list of pending activities, so
that the user is not disturbed at that time but can access this information afterwards.
This phase consists of two steps: rule-based alerting and log analysis (see figure 2).

ALERTING
Rule
processing
Log
analysis
HISTORICAL LOG
Features
Actions
Context
Alerts Checking
F G
ALERTING
USER MODEL
GROUP MODEL
G E F
D
C
B A Alerts
Pending
activities
F
G
E B

Fig. 2. The alerting phase
Rule-based Alerting
In this step, decisions about the convenience of interrupting a user to inform him/her
about the recommended activities are taken. With the aim of configuring the alerting
service, alerting rules must be specified. They may have conditions related to users or
activities and they can be grouped according to the nature of their activation condi-
tion, which gives rise to different sets of rules. Each set constitutes an alerting filter.
Therefore, it is possible to establish different types of filters by means of different sets
of rules. Regarding the rule processing, for each recommended activity, if a rule gives
information about the (un)convenience of alerting the user about it, the activity is
added to the list of alerts or directly kept in the list of pending activities, respectively.
The result of this phase is the annotated list of activities obtained during the rec-
ommending-activity phase, along with information about the convenience (or incon-
venience) of alerting the user intrusively about each of them. The Log Analysis mod-
ule takes the decision if no information is found about it in the alerting rules.
Some of the rules that give rise to the configuration of the alerting service for our
example are presented in (4). As it can be seen, in our example the users will be
alerted about the availability of urgent activities, messages or reminding. On the con-
trary, users will not be alerted intrusively if they do not want anyone to disturb them,
if they are at the university attending a lecture of if they are taking a practical class in
the lab. In these cases, the activity must be stored in the list of pending activities.

R
7
: C_Conection [state = not_connected or state = not_disturb] STORE
R
8
: C_Conection [urgency = urgent] ALERT
R
9
: C_Type [type = message or type = remind_later] ALERT
R
10
: C_Location [location = uni_class] STORE
R
11
: C_Location [location = uni_labo AND agenda = class] STORE

(4)

In our scenario, the recommended activities for Ann are F and G. As G is a mes-
sage, rule R
9
is activated, and the message is sent directly to her. Given that no infor-
mation is provided for F (review activity), the log analysis module can take charge of
the final decision for both Ann and John.
Log Analysis.
Finally, the previous actions of the users are analysed in order to decide whether, in a
specific situation, it is appropriate to alert the user about the availability of certain
activities. The actions of the user in similar previous situations are considered in order
to take the decision about the convenience of interrupting the user. If this information
is not enough or does not exist (the user was not in similar situations before), the
analysis is done with respect to what similar users did in these cases.
In our example, no decision has been taken concerning the recommendation of F to
Ann. Therefore, F is processed. Let us suppose that Ann uses to use her spare time for
reviewing already learned topics when travelling. The result of the statistical analysis
says that more than 60% of the times when Ann was proposed to review topics in
similar situations she did it. Therefore, Ann is informed about the recommendation of
activity F. With respect to John, no information is available, so he is suggested this
activity too. He does not engage in the activity, what is stored for future decisions.
4 Conclusions and Future Work
We have developed a recommendation process that i) selects the most suitable learn-
ing activities for each user taken into account his/her personal features, characteristics
of groups and the current context and ii) informs the user about new recommendations
either intrusively or non intrusively.
The modularization of the recommended process makes it possible the specifica-
tion of adaptation capabilities in a flexible and configurable way. It is possible to give
suggestions at a general level (based on the relationships between activities or on their
type) and at an activity level (based on their specific requirements), by means of dif-
ferent types of rules. Thus, it is possible to decide which type of recommendations
will be supported, by providing the corresponding type of rules.
The alerting mechanism is also configurable: instructions about in which cases the
users should be disturbed to be informed about new recommendations can be given.
Alerting rules support the specification of these criteria, which can be different for the
same type of users depending on their context and also for distinct types of users in
the same context. If no instructions are given (which is also feasible), a log analysis
will help to determine the convenience of alerting the user intrusively or not, based on
the previous actions of the users (or similar users) in analogous contexts. This log
analysis could be applied not only for deciding about the convenience of alerting the
users about the availability of activities, but also for recommending activities depend-
ing on what the users did in previous similar situations. In such a way, the recommen-
dation process would be enriched. Future work concerns testing the recommendation
process to check its suitability and exploring the possible use of log analysis in the
activity recommendation phase.
References
1. Ktoridou, D., Eteokleous, N.: Adaptive m-learning: technological and pedagogical aspects to
be considered in Cyprus tertiary education. In: Recent Research Developments in Learning
Technologies. Badajoz, Spain, (2005) 676-683
2. Brusilovsky, P.: Adaptive hypermedia. In: Kobsa, A. (eds.): User Modelling and User
Adapted Interaction, Vol. 11, 1/2 (2001) 87-110
3. Alfonseca, E., Carro, R.M., Martn, E., Ortigosa, A., Paredes, P.: The Impact of Learning
Styles on Student Grouping for Collaborative Learning: A case study. User Modeling and
User-Adapted Interaction. Special Issue: User Modelling to Support Groups, Communities
and Collaboration. Kluwer Academic Publishers. Accepted for publication.
4. Zaine, O.R.: Building a Recommender Agent for e-Learning Systems. Proceedings of Inter-
national Conference on Computers in Education (ICCE02), (2002)
5. Zimmermann, A., Specht, M., Lorenz, A.: Personalization and Context Management. User
Modeling and User-Adapted Interaction, 15, Springer-Verlag, (2005), 275-302
6. Jppinen, A., Nummela, J., Vainio, T., Ahonen, M.: Adaptive Mobile Learning Systems -
The Essential Questions from the Design Perspective. Proceedings of MLearn 2004, Roma,
Italy, (2004), 109-112
7. Felder, R.M., Silverman, L.K.: Learning Styles and Teaching Styles in Engineering Educa-
tion. Engineering Education, 78 (1988).
8. Schwarz E., Brusilovsky P., Weber G.: World-wide intelligent textbooks. In: Carlson, P.,
and Makedon, F. (eds.): Proceedings of ED-TELEKOM 96 - World Conference on Educa-
tional Telecommunications, AACE, (1996), 302-307
9. Carro, R.M., Ortigosa, A., Schlichter, J.: A Rule-based Formalism for Describing Collabora-
tive Adaptive Courses. In: Palade, V., Howlett, R.J. and Jai, L.C. (eds.): Knowledge-Based
Intelligent Information and Engineering Systems. Lecture Notes in Artificial Intelligence
2774, Springer-Verlag (2003), 252259.