M. Spaniol et al. (Eds.): ICWL 2009, LNCS 5686, pp. 245–254, 2009.
© Springer-Verlag Berlin Heidelberg 2009
Sharing Good Practice through Mash-Up Personal
Learning Environments
Felix Mödritscher1 and Fridolin Wild2
1
Vienna University of Economics and Business,
Augasse 2-6, 1090 Vienna, Austria
felix.moedritscher@wu.ac.at
2
Knowledge Media Institute, The Open University,
Walton Hall, Milton Keynes, MK7 6AA, United Kingdom
f.wild@open.ac.uk
Abstract. Personal learning environments (PLEs) require new ways to motivate
and scaffold learners. In particular, practice sharing is of importance for learner-
centric approaches in the scope of (technology-enhanced) lifelong learning, as it
is an enabler for community building and sustaining. In this paper we elaborate
prerequisites for ‘good practice sharing’ and explain how we realized these as-
pects in our PLE solution named Mash-Up Personal Learning Environments
(MUPPLE.org). Finally, we argue for the utility of our MUPPLE approach by
highlighting two different strategies of good practice sharing and their benefits
for learning and community building.
Keywords: Personal Learning Environments, Practice Sharing, Environment
Design, Learner Interactions.
1 Introduction
Learner-centric solution approaches to technology-enhanced learning, like personal
learning environments (PLEs), tend to have the problem that learners must cope with
competencies beyond the professional ones, e.g. with certain skills to handle technol-
ogy or with social competencies to connect to and collaborate in learner networks.
Such pre-requisites, however, hinder learners from using PLEs and related solutions
and justify the necessity to realize mechanisms to support and motivate learners,
amongst others through practice sharing. In this paper we clarify our view on PLEs,
discuss necessary components of PLE-based learning, and introduce a good practice
sharing approach for this specific context. Hereby, ‘good’ constitutes that the prac-
tices to be shared are created by learners and not experts (cf. best practices).
PLEs [1] comprise a technological infrastructure which empowers learners to de-
sign their learning environments to achieve own goals, i.e. to work on digital artifacts
and collaborate with facilitators and peers in networked communities. Therefore, [2]
outlines the importance of a pedagogical model which is centering the learner and not
the organization. Additionally, [1] highlights relevant technological and pedagogical
requirements for PLEs, like a certain degree of openness, controllability, system

246 F. Mödritscher and F. Wild

Fig. 1. Conceptual Diagram of an Action Flow within a Collaborative Activity
interoperability, personalizability, and so forth. In general, PLEs refer to any kind of
environment, even the operating system and the software programs running on one’s
computer, but we use PLE as a synonym for web-based tool landscapes as we focus
on networked collaboration.
To illustrate what PLEs look like, Fig. 1 describes a scenario, a so-called learning
activity, which includes three actors who collaboratively write a paper. Each actor
performs certain interactions with the learning environment, whereby they use differ-
ent tools (search engine, email client, bookmarking tool, a Wiki) and work on differ-
ent artifacts (mail, paper, review) to achieve their overall goal. Furthermore, each
actor has a specific role within this learning activity. Thus, the reviewer uses only one
tool (the Wiki) to accomplish her reviewing tasks, while the other learners need to
cope with several tools for writing the paper, which is what we called a Mash-UP
Personal Learning Environment (MUPPLE, cf. [3]).
Approaching technology-enhanced learning through personal learning environ-
ments requires the consideration of certain issues. The following section addresses
typical prerequisites for practice sharing in PLE-based activities and points to related
work in this field. Thereafter, we present our prototypical solution and explain how
we have realized practice sharing for PLE-based activities. Finally, we give two ex-
amples for practice sharing, before the paper is concluded and next steps are
indicated.
2 Ingredients for Practice Sharing in PLE-Based Activities
Practice sharing in personal learning environments is based on certain pre-requisites –
technical and non-technical ones – which are explained in the following subsections.

Sharing Good Practice through Mash-Up Personal Learning Environments 247
2.1 Consideration of Transcompetences
While technology-enhanced learning driven by organizational needs primarily address
professional competences, PLE-based approaches build upon certain additional skills
beyond a certain domain, i.e. social, self, and methodological competences
(transcompetences). Addressing social networking for lifelong learning, [4] outline
the importance of self-organizing and knowledge sharing capabilities of learners,
which can be supported by visualizing the social network, games for promoting dis-
covery, socialization, and collaborative behavior, stimulus agents, or policies for
managing the network. Furthermore, [5] argue for the necessity of self-directed com-
petence management in ad-hoc transient learning communities. Finally, [3] states that
learning environment design capabilities, e.g. hands-on skills to design and use one’s
learning environment, are required. All these transcompetences need to be considered
and supported when dealing with learner-centric TEL approaches.
2.2 Activity-Oriented Model of Learning
Closely related to competences necessary for PLEs, practice sharing within PLE-
based activities has to be grounded on a simple, domain-independent, action-oriented
pedagogical model to structure the learning context and formalize learner interactions.
In [3] we argue for a semantic model based on the Activity Theory which defines an
activity as a set of user-defined statements (action-outcome-tool triplets), each one
representing a learner interaction. With the action we refer to a term describing what
the PLE user (subject) is doing (predicate). The outcome (object) stands for what is
being achieved with the action. An outcome can be either abstract (e.g. a goal) or
concrete (e.g. a shared artifact). A tool or even a tool combination is considered to be
the instrument necessary to complete an action. Examples for such statements are
‘publish self-description using VideoWiki’ or ‘bookmark search results using Scut-
tle’. Overall, this simple language allows describing how a learner is utilizing soft-
ware tools while acting and trying to achieve the outcomes. Hereby, the activity itself
serves as a container for a set of learner actions related to a specific purpose. Exam-
ples for typical activities are ‘Collaborative paper writing’ (cf. Fig. 1) or ‘Getting to
know each other’. However, it has to be stated that this model of a learning activity
describes the view of one learner only and, therefore, allows multiple versions of an
activity, e.g. one for each specific user role or even one for users having the same role
and personalizing their PLE to their very own needs.
2.3 Materialization of Environment Design and Learner Interactions
In addition to modeling learning activities, learner-centric approaches are closely
related to relatively new ideas such as end-user development and opportunistic de-
sign. According to [6], end-user development is one emerging paradigm observable in
many application areas and evolving systems from being ‘easy to use’ to being ‘easy
to design’. Similarly, [7] report about opportunistic design and development (mash-up
design) as a new software engineering methods, i.e. mashing up pieces of source code
for new purposes. Considering these two streams, PLE solutions tend to shift the
locus of control from expert designers to end-users. Formerly, we identified the need
for materializing environment design and learner interactions and, consequently,

248 F. Mödritscher and F. Wild
introduced a scripting language [3]. Such ‘learner interactions scripts’ comprise the
learner-defined action statements introduced in the last subsection as well as ‘support’
statements which are pre-defined and based on the possibilities of the PLE solution
and its presentation layer. E.g. for our PLE approach we built upon web application
mash-ups visualizing all learning tools next to each other within the browser and
providing drag-and-drop functionality to arrange and use the windowed tools (more
details are given in section 3). More independently of the presentation layer, our PLE
prototype also tracks if a learner selects, minimizes or maximizes a tool, combines
tools, completes or resumes an action, etc. Overall, the (open, learner-given) set of
action statements describes for which actions and outcomes the tools are used within
her PLE, while the support statements are necessary to materialize learner interac-
tions, i.e. how learners arrange the tools on their screen (for MUPPLE: on their mash-
up space) and how they interact with them.
2.4 Facilities for Initiating and Regulating Networked Collaboration
So far, we highlighted the components enabling PLE-based learning activities from
the perspective of a single learner. The next step towards the scenario visualized in
Fig. 1 concerns aspects of networked collaboration. Extending our view on PLEs,
learners should be empowered to connect to networks of actors, artifacts, and activi-
ties. Historically, the concept of learning networks has evolved from applying com-
munication over computer networks to bring together educators and learners and
enable networked learning with the aim of creating and sustaining communities [8].
Similarly, research on computer-supported collaborative learning (CSCL) addresses
networked collaboration, e.g. through scripting such activities [9]. The earlier-
mentioned ‘learner interaction scripts’ which describes how a learner has designed
and used her PLE can be synchronized with the scripts of the collaborators to receive
a model of the action flow within an activity. Synchronization points are, in fact, the
outcomes, e.g. shared artifacts, and the tools used. The soundness of this approach has
to be shown similar to workflow mining approaches [10] and runtime behavior
problems of executing concurrent workflows [11]. At this time, fault prevention is
considered to be future work; in our current prototype the most prominent problem,
concurrent editing of artifacts, is left to the tool utilized by the collaborators.
2.5 Technical Requirements for Tools Used
At last, there are (of course) also technical requirements which partially depend on the
PLE front-end. Hereby, the presentation layer of our MUPPLE prototype (the web
application mash-up solution) requires certain restrictions of HTML code of the learn-
ing tools. Amongst others, a web application to be applied within MUPPLE has to
provide a REST interface, so that learners can use different urls for their specific
actions. Furthermore, these tools are not allowed to provide redirect mechanisms or
links which destroy the MUPPLE page including the application – a rather insignifi-
cant restraint. Independently of the technological framework, tools for learner-centric
TEL approaches also needs to support a certain degree of interoperability – beginning
from data interoperability over PLE design up to a widget communication API –, so
that learners can combine two or more applications for real-life scenarios. For

Sharing Good Practice through Mash-Up Personal Learning Environments 249
instance, an action ‘bookmarking’ might be realized through one tool that allows
users selecting entries (like a search engine) and another tool for managing the entries
(like a social bookmarking tool). Therefore, these tools require an interoperability
mechanism, like the OpenSocial API, enabling data exchange between tools. For our
MUPPLE approach we built upon distributed feed networks slightly extended by a
mechanism for active management of subscriptions (cf. [12]).
3 Mash-Up Personal Learning Environments (MUPPLE.org)
Following the ideas of learner-centered TEL, we developed an infrastructure called
Mash-Up Personal Learning Environments which stands for a learning environment
designed by the learner and consisting of several tools to be used within one activity.
3.1 Conceptual Approach
In [3] we looked back at the history of instructional design and personalized, adaptive
learning and formulated a critique on contemporary models and theories. In particular,
we came to the conclusion that learning environment design is the missing link for
personalized learning, and is even able to avoid the flaws of prior adaptation theories
in technology-enhanced learning. This is strongly based on three assumptions:

− First of all, we prefer the idea of ‘learning to learn’ while at the same time learning
content, to just (re-)constructing domain-specific knowledge. Thus, we emphasize
the acquisition of transcompetences (i.e. social, self, and methodological
competence) in addition to content competence (see subsection 2.1). Furthermore,
we build upon the model of learning activities introduced in subsection 2.2.
− Second and consequently, we consider the learning environment an important part
of the learning outcome as opposed to an instructional condition. Therefore,
personalization does not take place within a certain learning platform and driven by
the system, but through learners designing their learning environments (see also
subsection 2.3) and establishing a network of people, artifacts, and tools (manually
or with the support of personalization services) and interacting with that
environment (cf. subsection 2.4).
− Third and finally, we consider emergence of behavior as an unavoidable and natu-
ral phenomena of interacting with complex socio-technical systems. By emergent
behavior we mean that the observable dynamics show unanticipated activity, sur-
prising in so far as the participating systems have not been instructed to do so spe-
cifically (they may even not have intended it). Designing for emergence is in our
view more powerful than rules-based personalization, as the models involved are
simpler while achieving the same effect.

Technologically, we built upon a flexible architecture, i.e. a 3-layered framework for
distributed systems as an enabler for end-user development of learning environments.
The backend layer deals with data-interoperability, for instance in the form of RSS
feeds or Simple Query Interfaces (SQI). The middle-ware layer includes typical ser-
vice APIs between the different systems, e.g. in the form of mediation, retrieval, or

250 F. Mödritscher and F. Wild
feed management services (see also [12]), while the presentation layer on top com-
prises the user interfaces of the involved learning tools in the form of a mash-up.
3.2 The Learner Interaction Scripting Language
We have developed a domain-specific language named ‘Learner Interaction Scripting
Language’ (LISL) to be able to materialize user-driven environment design. Fig. 2
gives an example of such a script in which the statements comprise exemplary learner
interactions for designing and using the environment. The language per se is kept
simple, i.e. allows the definition of action-outcome-tool triplets, starting and complet-
ing these actions, connecting tools with each other, and interacting with the windowed
tools (earlier referred as support statements). Furthermore, networked learning can be
identified by synchronizing the scripts of the learners involved in one activity, e.g.
according to the shared artifacts.
Specialties of LISL are its lazy definition mechanism for action-outcome-tool triples
and the placeholder mechanism for urls. Hereby, lazy definition refers to the idea that
the entities of an action statement (action, outcome, or tool) does not need to be pre-
defined, but will be defined on executing the statement. Thus, LISL can be also used to
describe non-computerized activities, such as ‘(I) sign a contract by using a pen’. On
the other hand, placeholders in urls allow de-personalization and personalization of
LISL scripts. If a url is assigned to one action statement, parts of it can be replaced by a
‘variable’; on executing this action (i.e. launching the url within a window on the web
application mash-up space) the value is either pre-defined or requested from the learner.
Placeholders are of particular interest for practice sharing, as shown later on.´
Overall, LISL is considered to be the underlying model of environment design and
learner interactions with MUPPLE. Thus, it is useful to materialize the interactions of
a learner. However, in the sense of end-user development [6], learners do not need to
script their environment manually but can use web-based widgets, which creates the
script in the background. Similarly to AppleScript or VBScript, LISL can be utilized
by ‘power users’ to be more efficient in designing environments, for instance if they
prepare MUPPLE pages for others. Normally, learners are expected to use the web-
based widgets and the tools started by them to achieve their activities successfully.


Fig. 2. Example LISL Script including three learner interactions (lines 10 to 12) and several
supportive statements (define, connect, and drag)

Sharing Good Practice through Mash-Up Personal Learning Environments 251
3.3 The MUPPLE Prototype
On executing a LISL script, the web application mash-up for the chosen activity is
built up and provided to the learner. Fig. 3 displays an exemplary MUPPLE page
consisting of a header at the top, navigation and creation facilities on the left hand
side, and the content area (the mash-up of tools) in the center.
The header simply presents the type (e.g. an activity) and the title of the current
page. Navigational elements comprise a list of own activities. Clicking on one activity
folds out the list of actions contained and loads the MUPPLE page into the content
area, restoring the state in which the learner left it previously. Furthermore, creation
facilities enable users to create new activities or add action statements (action-
outcome-tool triplets with recommended values and urls) to the page opened. The
content area consists of three tabs: The tab ‘preview’ displays the mash-up of the
windowed learning tools involved into the current activity. Here, learners can arrange
the windows to their needs and preferences, i.e. drag and drop them along a grid-
based layout, minimize, maximize, or close them. The tab ‘code’ allows in-code edit-
ing of the LISL script of the current MUPPLE page. The tab ‘log’ shows the results of
the web-based LISL interpreter (including error messages and warnings for single
statements) and enables power users to test their own LISL statements.


Fig. 3. MUPPLE Page for an Activity ‘Getting To Know Each Other’

252 F. Mödritscher and F. Wild
According to [3], this three-tabbed content area for MUPPLE pages is justified by
various principles for end-user development. This infrastructure is considered to be an
enabling technology for practice sharing, as shown in the upcoming section. Prelimi-
nary evaluation studies showed that the usability of MUPPLE and the learning tools is
crucial, so we improved the user interface of the prototype iteratively and added sev-
eral fancy functions like auto-completing recommendations (similarly to the Google
search field) or the Ajaxian dialog boxes (both shown in Fig. 3).
4 Two Examples of Sharing Good Practice
Basically, a PLE can include ‘automated’ and ‘user-driven’ practice sharing strategies
(or hybrids). Our MUPPLE prototype realizes both through different features.
4.1 Practice Sharing through Activity Templates
User-driven practice sharing is achievable by using LISL scripts. This scripting lan-
guage does not only materialize how learners design and use their learning environ-
ment, but can also be used for practice sharing. In this context, we call LISL scripts
‘activity patterns’ which users can instantiate as a new MUPPLE page, as they make
it easier to reuse successful environment designs and user interaction sequences for an
activity. Patterns can be created by a learner whenever she thinks that one activity is
qualified as a pattern and thus is ‘good’ enough to be shared with peers. For these
patterns, the earlier-mentioned placeholder mechanism is of importance, e.g. for de-
personalizing one’s activity (e.g. remove parts of a url for privacy reasons) or to en-
force learners to initiate and customize the derived activity appropriately.
As an example, the activity ‘Collaborative Paper Writing’ (visualized in Fig. 1)
might be described by three role-dependent patterns including different sets of action
statements. For instance, the main author has to take care of several administrative
tasks, like assigning the chapters to co-authors, requesting the (internal) reviews, and
submitting the paper. Furthermore, she has the same duties like the co-authors, i.e.,
finding and collecting relevant literature, summarizing related work, and elaborating
the paper. On the other hand, reviewers only need to check the collected literature and
comment the paper. In our example, they use the commenting features of a Wiki to
give feedback on the paper. The urls of these patterns could include placeholders (e.g.
‘http://%%my_host%%/%%my_path%%’ instead of the full url). Consequently, this
user-driven practice sharing allows initializing the MUPPLE platform with meaning-
ful patterns for specific target groups, which might be a strong reason for learners to
join a community or, at least, to register and log in.
4.2 Automated Generation of Recommendations
Another possibility to support learners in designing their environment deals with
providing recommendations for their activities and actions. On creating a new activity
from a pattern, MUPPLE displays a learner the list of all patterns available, ranked
according to the number of activities derived from each pattern (left-hand side of Fig.
4). Moreover, inexperienced learners have an overview of the five most popular pat-
terns at the entry page of MUPPLE (right-hand side of Fig. 4).

Sharing Good Practice through Mash-Up Personal Learning Environments 253

Fig. 4. Recommendation of Activity Patterns According to Usage Frequency
Therefore, all activities are analyzed automatically in order to extract recommenda-
tions for patterns, actions, outcomes, and tools (including their urls). So far, actions,
outcomes and tools are also ranked according to the number of their occurrences,
whereby this ranking is improvable by considering the semantic structure, i.e. the
closeness to an activity or the action-outcome-tool bindings. Automated approaches
like our recommendation services are of particular interest to support learners in de-
signing and using their PLEs, e.g. to empower design capabilities. However, for both
kind of practice sharing and the MUPPLE pages itself it is important to leave the
control over the system to the learner, so that she can adapt the tools and mash-up
space according to her need and preferences.
5 Conclusions and Outlook
Summarizing this paper, we have shown that there are five important prerequisites for
practice sharing in learner-centered environments: (1) the consideration and support
of transcompetences, (2) an activity-oriented model of learning, (3,4) a formalism to
describe environment design and networked collaboration, and (5) specific technical
requirements. Considering these issues for a PLE solution, it is possible to provide
valuable facilities for good practice sharing, so that learners are supported in design-
ing their environments and tools to succeed in their activities. Most importantly, prac-
tice sharing is considered to be necessary to avoid the cold-start problem of PLEs, i.e.
to provide starting points and scaffolds from which users’ can adapt further. Evalua-
tion studies in the scope of higher education evidenced that inexperienced PLE users
(learners and educators) normally do not use Web 2.0 tools. Thus, it is necessary to
provide a mechanism for automated identification of users at the different tools in
order to not annoy them. Furthermore, those learners not being familiar with web-
based applications rather reused activity patterns while technology-skilled users
started to play around with MUPPLE and create own activities from the scratch.

254 F. Mödritscher and F. Wild
Consequently, we assume that PLE-based TEL approaches highly focus on transfer-
ring good practices from experienced, high-skilled learners to the rest. Finally, we are
aware of specific shortcomings of MUPPLE, e.g. a lack of interoperability or widgeti-
zation of existing tools.
Acknowledgments
The ROLE project is funded by the European Union under the ICT programme of the
7th Framework Programme (Contract number: 231396).
References
1. Van Harmelen, M.: Personal Learning Environments. In: 6th IEEE International Confer-
ence on Advanced Learning Technologies (ICALT), pp. 815–816 (2006)
2. Wilson, S.: Architecture of virtual spaces and the future of VLEs. Scott’s Workblog (2005),
http://zope.cetis.ac.uk/members/scott/
blogview?entry=20051004162747 (2009-02-24)
3. Wild, F. (ed.): Mash-Up Personal Learning Environments. Technical report, iCamp (2009),
http://www.icamp.eu/wp-content/uploads/2009/01/
d34_icamp_final.pdf (2009-02-24)
4. Cheak, A.M., Angehrn, A.A., Sloep, P.: Enhancing Lifelong Competence Development
and Management Systems with Social Network-based Concepts and Tools. In: 6th IEEE
International Conference on Advanced Learning Technologies (ICALT), pp. 487–488
(2006)
5. Berlanga, A., Sloep, P., Kester, L., Brouns, F., Van Rosmalen, P., Koper, R.: Ad hoc tran-
sient communities: towards fostering knowledge sharing in Learning Networks. Interna-
tional Journal of Learning Technology 3(4), 443–458 (2007)
6. Lieberman, H., Paterno, F., Wulf, V. (eds.): End-User Development. LNCS, vol. 4321.
Springer, Dordrecht (2006)
7. Hartmann, B., Doorley, S., Klemmer, S.: Hacking, Mashing, Gluing: Understanding Op-
portunistic Design. Pervasive Computing 7(3), 46–54 (2008)
8. Hiltz, S.R.: Collaborative Learning In Asynchronous Learning Networks: Building Learn-
ing Communities. In: 3rd World Conference of the WWW, Internet, and Intranet (1998)
9. Dillenbourg, P., Jermann, P.: Designing integrative scripts. In: Fischer, F., Mandl, H., Ha-
ake, J., Kollar, I. (eds.) Scripting computer-supported collaborative learning: Cognitive,
computational and educational perspectives, pp. 277–302. Springer, New York (2007)
10. Van der Aalst, W., Weijters, T., Maruster, L.: Workflow Mining: Discovering Process
Models from Event Logs. IEEE Transactions on Knowledge and Data Engineering 16(9),
1128–1142 (2004)
11. Kamath, M., Ramamritham, K.: Failure Handling and Coordinated Execution of Concur-
rent Workflows. In: 14th International Conference on Data Engineering, pp. 334–341
(1998)
12. Wild, F., Sigurdarson, S.E.: Distributed Feed Networks for Learning. European Journal for
the Informatics Professional (UPGRADE) 9(3), 51–56 (2008)