A Transversal Analysis of Different Learning Design Approaches

: The goal of the ICALT workshop “Comparing Educational Modelling* Languages on a Case Study” was to compare different Learning Design approaches. Various teams were asked to design and implement a common case study and to answer common given challenges. Then, a special issue on “Comparing Educational Modelling Languages on the “Planet Game Case Study” was proposed to give the workshop challengers the opportunity to describe their solution in more detail. It is now time to make the comparison. Based on an in-depth analysis and many exchanges with the teams involved, this paper introduces the approaches and highlights current challenges in the Learning Design field in connection with the pitfalls included in the case study and the given challenges.


Introduction
The teams invited in this special issue initially participated in the workshop "Comparing Educational Modeling Languages on a Case Study" which was organised during ICALT in 2006 in Heerlen, The Netherlands.The organisers of this workshop proposed a case study and methodological steps the challengers had to follow while describing their "solution" i.e. by using their methodology, language(s) and tool(s).The first step covers the modeling, operationalisation and execution (Martel and Vignollet 2008) of the case study, while the second one addresses the observation, traces, re-use and adaptation facilities of the activity.The description of both the case study and the proposed steps has been made in the introduction paper of this special issue (Vignollet, Martel and Ferraris 2008).
The proposed case study and the associated stages include several "pitfalls".
For the first step, the main difficulties are: the creation and management of the two teams, the means to be given to the teams to negotiate, the possibility for the teacher to add clues while the activity is underway, the means put at the teacher's disposal to stop the learning activity and thus, automatically start the assessment activity.
Moreover, other difficulties are inherent to the second step: observation, traces, re-use and adaptation of the activity are usually hard to model and implement.
The objective of this special issue is to go deeper into the comparison of the approaches, keeping the same case study and the same steps as the ones proposed in the workshop.Since the workshop, the teams have naturally made significant progress.Most of the papers in this special issue take into account these evolutions in their new answer to the case study or, at least, describe the desirable evolutions with respect to the shortcomings which had appeared during the resolution of the case study.
Of course, the purpose of this synthesis is not to elect the best approach.First of all, it contributes to knowing each of them better and to understanding their specificities.Furthermore, it stresses the evolutions of these approaches, from the first solutions proposed in 2006 to what is being done today.Finally, it emphasizes the main issues of the learning design field, stemming from difficulties encountered during the resolution of the case study.
The structure of the paper follows the steps proposed for solving the case study.More precisely, each phase of the two steps proposed is analysed, focusing on the main pitfalls and emphasing the main related issues.For the first step, the modelling of the proposed activity is followed by the operationalisation/execution phase; for the second step, the observation/traces and re-use/adaptation purposes are successively studied.Finally, the conclusion is a synthesis of all the issues in the field of learning design highlighted by all the participating teams.

The authoring tools: a Domain Specific Language approach
In 2006, not all the teams put forward specific authoring tools.Generally, the tools proposed to manipulate the concepts of the underlying meta-models and for the most part, required the design to be completed using an XML-editor.
At the date of this publication (end of 2008) all the teams offer an authoring tool, generally graphic and, for half of them, on-line.This evolution reflects the maturity of the field of learning design: dissemination is the next step after the proof of the validity of the approach, and thus, authoring tools dedicated to end-users (mainly teachers and instructional designers) have to be developed.These tools have to be simple, i.e. not linked to the technology or to the concepts of the complex meta-languages (like IMS LD (Koper 2002) or LDL (Martel, Vignollet, Ferraris and Durand 2006)).
To achieve this goal, the current tendency is the development of more abstract languages, called Domain Specific Languages (DSL), by using a Domain Specific Modelling (DSM) approach, as presented by Kelly and Tolvanen (2008), to obtain, by successive transformations, the scenario expressed in an execution language.
The MOT+LD (Paquette and Leonard (2006)) and the pattern approach in COLLAGE (Hernández-Leo, Villasclaras-Fernández, Asensio-Pérez, Dimitriadis, Bote-Lorenzo and Marcos-García ( 2006)), could in 2006 already be considered as precursors.However, in both approaches, the transfomation of the designs in an execution language required support from an "instructional designer" so that the scenario is operationalisable and executable (in those cases, to specify levels B and C of the IMS LD language).This method is currently used by OUNL (see Miao, Sodhi, Brouns, Sloep, and Koper (2008)), by the LDL team (see Martel, Villiot-Leclercq, Vignollet, Despont and Ferraris (2008)), by the TELOS team (see Paquette and Leonard (2008)), by the WebLD team (see Sánchez, Lama, Amorim, Vidal J.C. and Novegil (2008)), and by the CPM team in collaboration with the NOCE team (see Nodenot, Caron, Le Pallec and Laforcade (2008)).Associated with the DSL, user-friendly tools are developed, using a graphical view of the concepts and nice drag-and-drop functionalities.This tendency is also well described in Botturi and Stubbs' (2008) handbook.
An issue now could be the standardization of these DSL.However, the use of a DSM approach could allow several languages to cohabit, encouraging the definition, if necessary, of transformations from one to another.
The LAMS approach is a different one.At the very beginning of their project, the LAMS Team chose a pragmatic approach: a scenario, called a LAMS sequence, is a flow of predefined tools the learners will have to use in the specified order.The expressiveness of the underlying language is more limited than IMS LD or LDL.However, the LAMS sequences are easy to design, to operationalise and to execute for non-IT people.This is proved by the dynamism of the LAMS educational communities who regularly produce open-source scenarios (http://www.lamscommunity.org/dotlrn/clubs/educationalcommunity/).The issue is thus, as in many domains, to reconcile the rich but complex learning design approaches with the pragmatic ones.The DSM approach seems to be a promising response to this challenge.

The design itself
All the teams started from the « informal » description of the case study given in the introductory paper of this special issue.They adapted parts of this case study, depending on their language or tools, or they explained it when necessary (for the group initialisation for instance).However, the main phases were taken into account by all the teams: this allows them to be compared significantly.

The management of the roles and teams
Considering the roles, only LAMS does not integrate them in its language.With LAMS V2, an implicit "Teacher" role is defined which did not exist in LAMS V1.Those who have access to the activity as "Teacher" can see everything; the others, only the activity through the tools they can use.This is not a real role-based approach.Considering the teams, the second version of LAMS includes a "group branching" tool that allows activities for the groups to be defined.
Considering the four IMS LD-based solutions (Burgos and Tattersall (2008), Hernández-Leo, Villasclaras-Fernández, Asensio-Pérez, Dimitriadis, Bote-Lorenzo, and Jorrín-Abellán, I. ( 2008), Sanchez, Lama, Amorim, Vidal and Novegil (2008), Paquette and Leonard (2008)), they differ significantly in the definition of the teams.This is nicely summarised by the Gridcole Team (see Hernández-Leo et al (2008)): « The Collage and Gridcole solutions do not follow the approach adopted by the other participants using IMS LD that consists of defining a role for each team at design time.[…]In effect, only one role (expert-group) is defined in the UoL created with Collage and the two occurrences of the role (Team A and Team B) are determined when the script is instantiated.".This is also known as "the group modelling problem", mentioned in (Miao et al. (2005)).Defining in the scenario one role per team means that the number of teams is fixed in advance.Designing with LAMS also requires that the number of teams should be stated during the design.
Thus, for the "Planet Game" case study, in the IMS LD approaches (except Collage) and LAMS approach, the designer has to write twice the part of the scenario dedicated to the activity of the teams.
This addresses the problem of the genericity of the design.
For instance, if a modification of the activity of the teams needs to be made, the designer should modify as many parts of the scenario as there are teams.Also, if a teacher wants to carry out the case study with more than two teams, s/he should modify the scenario, reproducing the description of the activity of the teams as often as there are teams.
The Collage Team (see Hernández-Leo et al. (2008)) avoids this duplication as the number of teams is defined during the operationalisation phase.The LDL Team (see Ferraris et al. (2008a)) also avoids it, but in a different way.The design results in the creation of four scenarios.The learning one is "generic": the future learning activity is described for "Learners".The number of teams is defined in the organisation scenario.Indeed, taking into account the number of groups is an organisational objective, as described in the following part.

Spliting the concerns
All the approaches propose to split the scenario into several scenarios or acts.For many of them, the distinctive criterion concerns the individual or collaborative nature of the activity.
The LDL team already used another criterion in 2006.They considered every learning activity as a composition of four types of activity: learning, organisation, observation, assessment.This is fully described in (Ferraris, Martel and Vignollet (2008b)).The advantage of considering these four kinds of activity is threefold.First, it reduces the complexity of the overall situation to be modelled as the designer can focus on one kind of problem at a time.Second, it provides the designer with guidance.Third, as it leads to a componential approach, it facilitates the reuse and the adaptation of the scenarios produced.For example, the planet game could be easily extended to involve more than two teams: it is simply a question of creating as many activities corresponding to the same learning scenario as the number of teams.
The overall learning activity results from the combination and the interrelations of these activities.Being activities per se, they can be modelled as independent scenarios.Building the formal scenario of a learning activity is thus no longer a matter of defining a unique scenario, which encapsulates everything.It becomes a matter of defining at least four scenarios, corresponding to the four different kinds of activity identified.As a consequence, it becomes a matter of describing each scenario in terms of the concepts of the design language chosen, and defining the relationships between these scenarios.This approach is followed by the TELOS Team (see Paquette and Leonard (2008)) in a different way, as the proposed scenario contains four acts: one for the organisation, one for the learning, one for the assessment and one for the evaluation.This has the advantage to focus and simplify activity descriptions.
This issue induces another one: are the four types of activity so different that four languages would be necessary to describe them?This meets the domain-specific language issue set out in section 2.1.

What to control in the scenario?
The structure of the scenario may be varied, depending on what the designer wants to be controlled by the scenario.For instance, considering the « teacher adds a clue » action, in the proposed designs, it is generally possible for the participant with the teacher role to have access permissions to the clue repository and to add a clue by uploading it.However, in this way, this activity is not managed by the scenario.Two teams propose to explicitly specify this "activity": • The TELOS Team has added a property which allows branching in a "teacher activity" (for example, activity 2.3.A for team A, (Paquette and Leonard (2008))), consisting in selecting and uploading a new document which includes the new clue.
• The LDL Team has created a specific interaction included in the observation scenario, allowing the participant with the teacher role to add a new quiz associated with a new clue in the quiz repository.
The open issue here addresses the problem of controlling what is going on in the services associated with the scenarios.This is particularly strategic when the activity is collaborative and requires the use of a service.
On the one hand, Martel and Vignollet (2008) call that issue "the learning design paradox" in the sense that in a scenario, the activity mediated by services is neither prescribed nor observed.They propose to use LD languages to model an activity supported by a service.On the other hand, the Personal Learning Environments approach (see PLE blog) supports a non-controlled approach.
Controlling or not, in the scenario, the activity supported by the services is thus both a social and a technical issue.

Operationalisation and Execution of the Learning Design
In 2006, for the workshop organisers, the scenario life cycle consisted of a design phase in which the activity model is built, followed by an operationalisation phase in which the learning environment is deployed, and then an execution phase in which the activity takes place.More precisely, the operationalisation consists in choosing the participants and giving them the roles intended by the scenario, selecting the services and contents required by the scenario and then deploying the participants and the resources in the targeted learning environement.

A "non linear" life-cycle?
The life-cycle proposed by the workshop organisers is not always the one adopted in the field of learning design.For instance, GSIC (Bote-Lorenzo et al. ( 2008)) proposes three phases: "Design -Enactment -Evaluation".In this life-cycle, the operationalisation is part of the enactment phase, considering a sub-phase that they call the "initialisation phase".This sub-phase consists in choosing the resources (services and contents), the participants and the number of groups, and in attributing the participants to the groups.
LAMS is another example.At the very beginning of LAMS, an LAMS sequence was composed of "actual" services.This is still the case in the current version.For instance, a Moodle Forum, or an LRN Wiki can be included in the scenarios (LAMS sequences) during the design phase (Dalziel, 2008).That is to say that the LAMS team already integrates the design and operationalisation phases.
Also, a study carried out within the LORNET (Learning Objects Repositories Network) project (http://www.lornet.org/)by Henri, Teja, Lundgren, Ruelland, Maina, Basque and Cano (2007) establishes that during the design phase, designers first start to collect the contents and services, and then try to build the scenario which will organise the learning using these resources.
Thus, the vision of a linear scenario life-cycle seems to be obsolete.This point of view is shared by Burgos and Tattersall (2008).They point out that « any authoring tool should allow for an integrated modelling process, working within the manifest, the resources and the required external XHTML files with a common, single interface.It should allow for dependencies and ease setting of properties.».
This is also what Recourse (http://www.tencompetence.org/ldauthor/),the recent Ten Competence (http://www.tencompetence.org/)editor supporting IMS LD, takes into account.For the authors of this tool, this means that the designer, i.e. the teacher, has to be able to describe, with the same tool, the general organization of the work and the details of the proposed activities: « When a teacher plans the activities which their learners will carry out, they think in terms of both the specific (e.g."Karen needs to practice that aspect because she didn't seem to understand it last week"), and the general (e.g."We need to look at this topic before that one, or it won't make any sense.If they are going to understand it then I'll need to split them into groups and get them to discuss it...").».
In conclusion, all the life-cycle phases have to be taken into account, but in a more flexible way than the sequential one previously proposed by most of the approaches in the field of learning design.
This issue highlights another one: how to consider the re-use and sharing issues of such "hybrid" scenarios i.e. scenarios which already include operationalized contents and services.
Finally, Burgos and Tattersall (2008) also suggest a related issue: "A tighter integration of design-time and run-time perspectives on IMS LD will occur, so that designs can be critiqued and improved on the basis of log data".

Which tool to support the operationalisation?
In almost all the approaches detailed in this special issue, the operationalisation phase was not instrumented.TELOS, LAMS and LDL teams offer a user-friendly tool to perform this task.TELOS includes a form-based interface that links the graphic objects in the learning design to ontology classes that drive the system.This is done throught the "Resource Manager".Other IMS LD-based approaches use a script "command line" interface.
Today, this lack seems to have been taken into account.For instance, the Collage team has developed a graphical tool, instance Collage (iCollage), dedicated to the initialisation of the roles, groups and contents (see Hernandez-Gonzalo, Villasclaras-Fernandez, Hernandez-Leo, Asensio-Perez and Dimitriadis, Y. (2008)).Another example is the Recourse tool which supports both the design and the operationalisation.Indeed, when authoring a scenario, Recourse allows the selection of the contents, the services and the participants, and the assignment of roles to the participants.

Integration of external services
For the operationalisation of the scenario, the choice of actual services corresponding to the ones specified in the scenario is generally limited to a short list, and sometimes, there is no choice at all: only one implementation is associated with the selected tool type.This is in no way a trivial problem as it addresses implementation issues.Thus, it impacts the infrastructures associated with the design languages.More precisely, associating a real service with a specified one requires the definition of the links between the roles specified in the scenario and the ones implemented in the service, and the links between the data consumed/produced by the services and the data produced/consumed by the activity when the scenario is executed.This last problem is known as the "data-flow" problem and has already been referenced -in 2005 by Miao et al.
This limitation could have a big impact on the expressiveness of the scenarios.This is highlighted by the Collage Team in Hernandez- Leo & al. (2008):"having a limited set of tools constrains the teacher when designing the educational scenario".To solve it, they propose to define in the IMS content package the links between the specified services and the actual ones.Then GridCole (see Bote-Lorenzo, Gómez-Sánchez, Vega-Gorgojo, Dimitriadis, Asensio-Pérez and Jorrín-Abellán ( 2008)) is able to interpret the IMS content package file and to manage the operationalisation and execution of the selected services.
In LAMS, existing services from some LMS such as Moodle (http://moodle.org/)or .LRN (http://dotlrn.org/)can be referenced in LAMS scenarios.However, the list of available services is closed, even if new services are regularly added in the new versions of LAMS or could be "manually" added by the LAMS server administrator.This is also what TELOS proposes.
The challenge here is to provide the right abstraction level, thanks to the learning design approaches, while offering a variety of actual services to be used in the learning activities.While the serviceoriented architectures may be part of the answer to this issue, questions on the execution and observation/monitoring of the activities remain open.They are addressed in the following subsections.

New players
In the field of learning design, the players associated with the engines try to give an integrated view of the activity and of what the user has to do.These players also integrate some supervision facilities.
Considering Recourse (one of the most recent tools), whilst naturally, its authors identify the execution phase, currently, it does not allow the execution of the scenario to be followed, nor for it to be adapted during its execution.
The authors of Recourse, and other teams in the field of learning design, are now aware of the necessity of supplying the teachers, in an integrated environment, with tools covering the whole lifecycle of a scenario.This is like a learning design IDE (Integrated Development Environment).LAMS could be considered as a precursor here as all the stages were supported by the same environment at the very beginning of their project.However, the classes of scenario supported by LAMS are limited in number.Indeed, for complex scenarios, integrating various services and contents, and considering the monitoring facilities such an environment should include to adapt and regulate the scenario, induce technical issues that are still difficult to tackle.
Another issue concerns the capability of these environments to support the nomadism of the participants in a collaborative learning activity.As Burgos and Tattersall say: "New IMS LD-aware players will emerge, including micro-players allowing learning processes to be coordinated across mobile devices.".

Which execution language?
In view of the necessary evolutions of the languages, of the services offered, etc., the infrastructure associated with these languages in the field of learning design should be flexible enough to evolve easily.The Domain-Specific Modelling approach would certainly help, offering mechanisms to generate some of the infrastructure modules.Moreover, this could allow the use of various execution languages.
Such an approach has already been proposed by some teams, among them the Web LD team.In this approach, the IMS LD scenarios are transformed using a Petri-Net formalism so that an existing engine capable of dealing with this formalism could be re-used (see Sanchez et al. (2008)).
This means that a modularisation of the infrastructure would indubitably help to decrease the costs of development and maintainability of the execution engines and would facilitate the support to the evolution of the learning design approach.
Finally the scalability of the approaches and the off-line execution possibilities also constitute crucial challenges in the field of learning design, and have a link to the execution languages and associated infrastructure.However, these were not addressed by the case study.

How and by whom could the activity be observed during its performance?
This issue was addressed in the Planet Game case study by "The game finishes when a winner is nominated".In the approaches described in this special issue, the nomination is generally made in the common forum, by the teacher her/himself.However, the nomination should be automated as it could be deduced from the observation of the learners' answers to the assessment questionnaire.This is the solution developed by the LDL team.Indeed, in LDL, a specific concept called observable allows the specification of what can be observed (see Martel and Vignollet (2008)).In the case study, the answer to the questionnaire is defined as an observable.During the activity, the corresponding observations will be stored in the trace repository.A specific interaction is also defined which gives access to the list of results.This list consists of a request to the trace repository, asking for these observations to be classified and viewed chronologically.
In the other approaches, the observer is generally the teacher, and what s/he is able to observe is predefined in simple monitoring interfaces.

Visualisation/Monitoring tools
These tools are supposed to reflect what is going on, that is providing meaningful and tailorable interfaces to the traces being stored during the performance of the activity.Except for LAMS, the tools proposed by the participants in this special issue offer few facilities to help the visualisation of those data.Except also for LAMS, only basic means are available to monitor the activity.
Nevertheless, this is a major challenge considering the regulation and the adaptation of the activity.In 2006, Colin Tattersall (Tattersall, 2006) also suggested that "A tighter integration of design-time and run-time perspectives on IMS LD will occur, so that designs can be critiqued and improved on the basis of log data ".
Actually, in the e-learning field, this seems to be generally addressed by teams distinct from the ones involved in learning design language development.

Re-use/Adaptation
Naturally, in all the approaches, the scenario designed could be re-used, wholly or in parts.For example, a new assessment activity could be added at the beginning, which consists in giving a questionnaire to the learners to evaluate their skill level in the astronomy domain.The results could then be used to compose the groups.In that case, the structure of the scenario requires adaptions.This could be done in all the approaches re-using the existing scenario through the authoring tools.
However, the adaptation addresses other issues that were proposed associated with the "Planet Game" case study challenge and which are developed in the following subsections.

Could observations be used to modify the activity's progress during its performance?
All the design languages proposed allow the conditional flow to be defined, so that the activity can be adapted to what is going on.For instance, in the planet game case study, the scenario could specify that if the answer to the final questionnaire is wrong, the learner has to go through a new learning activity.
In that case, the learning flow depends on the learner's answer, as for the ones whose anwer is correct, the activity would stop after the assessment activity.
In IMS LD, this answer could set the value of a property (Burgos, Tattersall, and Koper (2007)); in LDL, this could set the value of an observed position (Lejeune, David, Martel, Michelet and Vezian ( 2007)).
However, the adaptation of the activity "on the fly" could also concern the adaptation of the structure of the scenario even if it was not predicted.It could be for instance, the addition of a new activity during the scenario execution or a change in the participants' assignation to groups or roles, etc.
LAMS, from the version 2.0, instruments changes during the scenario execution with the Live Edit Tool.The teacher can easily add, modify or delete any step not already started.This consists of adding a "break point" just after the current step and modifying the following steps.This is possible as the scenario is interpreted and not compiled.However, this is still an issue when the scenarios are complex, and when re-use issues are also taken into account.

How could the case study be adapted to a different topic, keeping the same general structure?
Of course, in all the approaches, the resources (services and contents) could be changed to be adapted to a different topic.The difference between the approaches is when the change could occur.Indeed, in some of them, the scenario itself has to be modified (when the resources are defined within the design phase).For the Collage team or LDL team, the choice of resources is made during the operationalisation phase: the scenario itself does not need to be modified.
The whole scenario could be re-used, or only parts of it.For instance, G. Paquette and M. Leonard note that « We could also decompose the scenario into four acts and store them in the "Aggregates" section of the Resource Manager for future retrieval and recombination in a different order, or with other "nuggets" extracted from other scenarios ».

Could the scenario be adapted to more than two teams or could the composition of the group be modified?
This addresses the genericity issue.It is detailed more particularly in section 2.2.1, as it concerns mainly the way the team is taken into account in the scenario at the design stage.

Conclusion
An international workshop is usually the opportunity for the participants to confront their solutions and verify their respective advances.The ICALT'06 Workshop on "Comparing the Education Modelling Languages on a case study" was no exception, but its form was unusual.Indeed, it was a kind of benchmarking of several approaches in the learning design field.This specific form has contributed to a better identification of the problems, a better understanding of them, and a higher level of exchange and interaction between the participants.
Furthermore, it can be observed that the exchanges to which the workshop gave rise continue to this day.Indeed, henceforth a kind of informal cooperation seems to exist between the participants to the advantage of the whole Learning Design community.This special issue can be seen as attesting to this.Ideas circulate freely between the researchers and the solutions discovered in 2006 during the workshop have for the most part considerably progressed.
So today, all the teams who have presented their work in this special issue offer solutions which cover the complete life-cycle of the scenario, with one exception who are close to getting there.In 2006, only three of them proposed a complete solution (Dalziel 2006, Tattersall 2006, Martel & al. 2006).
Some of the teams involved have also improved the power of expression of their languages: the LAMS team with the consideration of the groups and the branchings in LAMS V2 and the TELOS Team with the graphic representation of all the levels of IMS LD (A, B, C).
The challenge set in 2006 was difficult, particularly in step 2, on the question of observation and the use of the traces of activity.Today these concerns have become central, and each team is attempting to provide a satisfactory solution to them.
On a whole set of questions relative to the life-cycle of the scenario, to the observation of the activities and to their educational regulation, to the collaborative work, to the selection of the services and to their easy and fast integration into the educational activities, to the adaptation of the scenarios and to the various concerns of the designers, this workshop has apparently contributed to stimulating the teams involved.
Finally, as Hernández-Leo and al writes, "All these works are part of an ongoing effort devoted to the development of educator-friendly and tailorable technological settings covering the whole lifecycle of flexible scripted collaborative learning scenarios".
In parallel, efforts to help the dissemination of the solutions have been made by many researchers.
Considering the bridges a DSM approach could offer, it is now time to share as much as possible effective scenarios, teaching experiences and evaluation ones.This would contribute to the dynamism of the learning design field.An initiative such as Cloudwords (http://cloudworks.ac.uk/), which enables the location and the creation of communities of practise in the learning design fields, in order to share and find help, is going in the right direction.
For instance, in the Kaleidoscope Network of Excellence.(http://www.noekaleidoscope.org/.),these issues are addressed by teams from the Interaction Analysis field, such as the ones involved in the ICALTS (Interaction & Collaboration Analysis supporting Teachers' & Students' Self-regulation), IA (Interaction Analysis supporting Teachers' & Students' Self-regulation), and by the European Research Team CAViCoLA (Computerbased Analysis and Visualisation of Collaborative Learning Activities).Only the GSIC (http://gsic.tel.uva.es/ ) seems to be historically involved in both domains.