Relating IMS Learning Design to web 2.0 technologies

Last week I attended the “relating IMS Learning Design to web 2.0 technologies” workshop at the EC-TEL conference. The objectives of the workshop were to to explore what has happened in the six years since the release of specification both in terms of developments in technology and pedagogy and to discuss how (and indeed if/can) the specification keep up with these changes.

After some of the discussions at the recent IMS meeting, I felt this was a really useful opportunity to redress the balance and spend some time reflecting on what the the spec was actually intended for and how web 2.0 technologies are now actually enabling some of the more challenging parts of its implementation – particularly the integration of services.

Rob Koper (OUNL) gave the first keynote presentation of the day staring by taking us all back to basics and reminding of the original intentions of the specification i.e. to create a standardized description of adaptive learning and teaching processes that take place in a computer managed course (the LD manages the course, not the teacher). Learning and support activities and not content are central to the experience.

The spec was intentionally designed to be as device neutral as possible and to provide an integrative framework for a large number of standards and technologies and to allow a course to be “designed” once (in advance of the actual course) and run many times with minimal changes. The spec was never intended to handle just in time learning scenarios, or in situations where there is little automation necessary of online components such as time based activities.

However as Rob pointed out many people have tried to use the spec for things it was really never intended to do. It wasn’t build to manage highly adaptive courses. It wasn’t intended for courses where teachers were in expected to “manage” every aspect of the course.

These misunderstanding are, in part, responsible for some of the negative feelings for the spec from some sectors of the community. However, it’s not quite as simple as that. Lack of usable tools, technical issues with integrating existing services (such as forums), the lack meaningful use-cases, political shenanigans in IMS, and actually the enthusiasm from potential users to extend the spec for their learning and teaching contexts have all played a part in initial enthusiasm being replaced by frustration, disappointment and eventual disillusionment.

It should be pointed out that Rob wasn’t suggesting that the specification was perfect and that there had just been a huge mis-interpretation by swathes of potential users. He was merely pointing out that some critisism has been unfair. He did suggest some potential changes to the specification including incorporating dynamic group functionality (however it isn’t really clear if that is a spec or run-time issue), and minor changes to some of the elements particularly moving some to the attribution elements from properties to method. However at this point in time there doesn’t seem to be a huge amount of enthusiasm from IMS to set up an LD working group.

Bill Olivier gave the second keynote of the day where reflecting on “where are we now and what next?”. Using various models including the Garner hype cycle, Bill explored reflected on the uptake of IMS LD and explored if it was possible to get it out of the infamous trough of disillusionment and onto the plateau of productivity.

Bill gave a useful summary of his analysis of the strengths and weaknesses of the spec. Strengths included:
*learning flow management,
*multiple roles for multiple management,
*powerful event driven declarative programming facilities.
Weaknesses included:
*limited services,
*the spec is large and monolithic,
*it is hard to learn and hard to implement
*it doesn’t define data exchange mechanism, doesn’t define an engine output XML schema,
*no spec for service instantiation and set up,
* hard to ensure interoperability
*run time services are difficult to set up.

Quite a list! So, is there a need to modularize the spec or add a series speclets to allow for a greater range of interoperable tools and services? Would this solve the “server paradox” where if you have maximum interoperability you are likely to have few services, whereas for maximum utility you need many services.

Bill then outlined where he saw web 2.0 technologies as being able to contribute to greater use of the specification. Primarily this would involve making IMS LD appear to be less like programming through easier/better integration of authoring and runtime environments. Bill highlighted the work that the 10Competence team at the University of Bolton have been doing around widget integration and the development of the wookie widget server in particular. In some ways this does begin to address the service paradox in that it is a good example of how to instantiate once and run many services. Bill also highlighted that alongside technological innovations more (market) research really needs to be done in terms of the institutional/human constraints around implementing what is still a high risk technological innovation into existing processes. There is still no clear consensus around where an IMS LD approach would be most effective. Bill also pointed out the need for more relevant use cases and player views. Something which I commented on at almost a year ago too.

During the technical breakout session in the afternoon, participants had a chance to discuss in more detail some of the emerging models for service integration and how IMS LD could integrate with other specifications such as course information related ones such as XCRI. Scott Wilson also raised the point that more business workflow management systems might actually be more appropriate than our current LD tools in an HE context. as they have developed more around document workflow. I’m not very familiar with these types of systems so I can’t really comment,but I do have a sneaky suspicion that we’d probably face a similar set of issues with user engagement and the “but it doesn’t do exactly what I want it to do” syndrome.

I think what was valuable about the end of the discussion was that were were able to see that significant progress has been made in terms of allow service integration to become significantly simpler for IMS LD systems. The wookie widget approach is one way forward as is the service integration that Abelardo Pardo, Luis de la Fuente Valentin and colleagues at the University of Madrid have been undertaking. However there is still a long way to go to make the transition out of “that” trough.

What I think what we always need to remember that teaching and learning is complex and although technology can undoubtedly help, it can only do so if used appropriately. As Rob said “there’s no point trying to use a coffee machine to make pancakes” which is what some people have tried to do with IMS LD. We’ll probably never have the perfect learning design specification for every context, and in some ways we shouldn’t get too hung up about that – we probably never will – we probably don’t really need to. However integrating services based on web 2.0 approaches can allow for a far greater choice of tools. What is crucial is that we keep sharing our experiences, integrations and real experiences with each other.

3 thoughts on “Relating IMS Learning Design to web 2.0 technologies

  1. Thank you Sheila for this very interesting summary.
    I would like to comment Rob’s statement:
    “there’s no point trying to use a coffee machine to make pancakes”
    This statement would make sense if the coffee machine wasn’t sold as a fry pan, a toaster, a bathroom, a space shuttle, etc…

    In the “IMS Learning Design Information Model” (http://www.imsglobal.org/learningdesign/ldv1p0/imsld_infov1p0.html) we can read in the section 2.1:

    Objective of Learning Design Specification

    ” R1. Completeness: The specification must be able to fully describe the teaching-learning process in a unit of learning, including references to the digital and non-digital learning objects and services needed during the process. This includes:

    * Integration of the activities of both learners and staff members.
    * Integration of resources and services used during learning.
    * Support for a wide variety of approaches to learning.
    * Support for both single and multiple user models of learning.
    * Support mixed mode (blended learning) as well as pure online learning.

    R2. Pedagogical Flexibility: The specification must be able to express the pedagogical meaning and functionality of the different data elements within the context of a unit of learning. It must be flexible in the description of all different kinds of pedagogies and not prescribe any specific pedagogical approach.

    R3. Personalization: The specification must be able to describe personalization aspects within a learning design, so that the content and activities within a unit of learning can be adapted based on the preferences, portfolio, pre-knowledge, educational needs, and situational circumstances of users. In addition, the control over the adaptation process must be given, as desired, to the student, a staff member, the computer, and/or the designer.

    R4. Formalization: The specification must describe a learning design in the context of a unit of learning in a formal way, so that automatic processing is possible.

    R5. Reproducibility: The specification must describe the learning design abstracted in such a way that repeated execution in different settings with different persons is possible.

    R6. Interoperability: The specification must support interoperability of learning designs.

    R7. Compatibility: The specification uses available standards and specifications where possible, mainly IMS Content Packaging, IMS Question and Test Interoperability, IMS/LOM Meta-Data and IMS Simple Sequencing.

    R8. Reusability: The specification must make it possible to identify, isolate, de-contextualize and exchange useful learning artefacts, and to re-use these in other contexts. “

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>