The IMS Learning Design Specification can be viewed at http://www.imsglobal.org/learningdesign/ldv1p0/imsld_infov1p0.html. This specification describes how learning activities can be described and ordered to represent both specific and generic approaches to learning.

This project explores how LD might be implemented to support new pegagogical use of Sakai and leverage it's existing services and tools. Ideally, this would be done by leveraging existing code, such as the Coppercore Implementation. Unfortunately, Coppercore is licensed under GPL, making it impractical to include in Sakai. Too bad since it already supports Hypersonic and MySQL. I have sent a message to the Coppercore people informing them of this licensing difficulty to potentially explore other possibilities.

Another approach is to embed LD into a work flow system.

See also a Simple LD Design.
See also Temble: A Template Based Learning tool.

From IMS-LD:

The core concept of the Learning Design Specification ... is that regardless of pedagogical approach, a person gets a role in the teaching-learning process, typically a learner or a staff role. In this role he or she works toward certain outcomes by performing more or less structured learning and/or support activities within an environment. The environment consists of the appropriate learning objects and services to be used during the performance of the activities. Which role gets which activities at what moment in the process, is determined by the method or by a notification. Note: most of the concepts mentioned above are reflected in the information model, but some only exist at the conceptual level (person, outcome).

The method is designed to meet learning objectives (specification of the outcomes for learners), and presupposes certain prerequisites (specification of the entry level for learners). The method consists of one or more concurrent play(s); a play consists of one or more sequential act(s) and an act is related to one or more concurrent role-part(s), each role-part associates exactly one role with one activity or activity-structure. The teaching-learning process is modelled in the method on the notion of a theatrical play. A play has acts, and in each act has one or more role-parts. The acts in a play follow each other in a sequence (although more complex sequencing behavior can take place within an act). The role-parts within an act associate each role with an activity. The activity in turn describes what that role is to do and what environment is available to it within the act. In the analogy, the assigned activity is the equivalent of the script for the part that the role plays in the act, although less prescriptive. Where there is more than one role-part within an act, these are run in parallel.

Sakai has some of these concepts already in place. Users are well-modeled by the UserDirectoryService. Support for roles is included in AuthZGroups, would need to be a part of this implementation. Sakai has some support for date/times that could be expanded to support scheduling (something that Course Management needs, too). Also, content hosting provides powerful support for some kinds of resources, though other need to be represented as well.

Runtime User Interface

Displaying information associated with LD is challenging. Activities have several states:

To be done
In progress
Completed

Activities may be nested with sub-activities or grouped into modules (etc).
Learning objectives may be associated with an activity at any level.
Actvities may have pre-requisites.
Activities may be time-based and revealed as appropriate.
Screen real estate is desparately needed to convey content properly.

My thought is to use an interface simlar to the one used by the SCORM player, with a collapsable tree structure of activities on the left, and content on the right. Ideally, the whole activity tree could be hidden via a toggle button of some kind (perhaps AJAX can help here).

Authoring User Interface

While it would be possible to create a complex graphical sequencing environment, instructors aren't very likely to use it. Instead, I think certain kinds of sequencing strategies are very common and can be realized in an optimized user interface. Of these, linear sequencing is likely to capture 90% of what's needed.

The interface would allow activities to be added, removed, and ordered. Optional outcomes can be attached to an activity to provide for notification, grading, etc.

An Experimental Platform

A Simple LD Design is described in order to create an experimental platform for learning design in Sakai. This design is a simplification of the IMS LD system, but defined in a manner that allows it to be expanded to a full implementation including import and export of IMS-LD compliant units of learning.

The design describes a basic containment hierarchy consisting of a single method with one or more plays, with one or more acts. Each act may contain activities to be associated with a particular role. Further restrictions are added to simplify implementation:

Only one play will be allowed.
Sub-roles are not supported. Only staff and learner.
Pre-requisites and learning objectives are deferred.
Conditions on acts (Level B) is not supported.

Participation

Send mail to pedagogy@collab.sakaiproject.org if you are interested in participating in learning design. A confluence page for pedagogy can be found at Teaching and Learning (T&L) Group. Direct comments about personal projects can be sent to me at markjnorton@earthlink.net

Browser not supported