IMS Learning Design Best Practice and Implementation Guide
Version 1.0 Final Specification
|
IMS Learning Design Best Practice and Implementation Guide Version 1.0 Final Specification |
Copyright © 2003 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name: IMS Learning Design Best Practice and Implementation Guide
Revision: 20 January 2003
IPR and Distribution Notices
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.
IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.
Copyright © IMS Global Learning Consortium 2006. All Rights Reserved.
If you wish to distribute this document or use this document to implement a product or service, you must complete a valid license registration with IMS and receive an email from IMS granting the license. To register, follow the instructions on the IMS website: http://www.imsglobal.org/specificationdownload.cfm.
This document may be copied and furnished to others by Licensee organizations registered on the IMS website provided that the above copyright notice and this paragraph are included on all such copies. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to IMS, except as needed for the purpose of developing IMS specifications, under the auspices of a chartered IMS work group.
Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/learningdesign/ldv1p0/ldv1p0speclicense.html.
The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns.
THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.
The development of a framework that supports pedagogical diversity and innovation, while promoting the exchange and interoperability of e-learning materials, is one of the key challenges in the e-learning industry today. The absence of agreed and compatible ways to describe teaching strategies (pedagogical approaches) and educational goals is a constraint that will hold back the development of the industry. As best practice evolves in systems that support e-learning, it follows that some of these pedagogical approaches will be codified, leading to the presentation of opportunities that facilitate successful learning experiences.
There are consequences of not delivering such a framework. Creators of teaching materials and their organizations will continue to experience unnecessary difficulty in:
The end result is to raise the cost of using content and services from elsewhere. This situation will occur, not because of any technical problems, but because outside content and services have different approaches to learning that do not meet the prescribed needs of the organization.
Associating each element of content with information describing its instructional strategy in a consistent and machine-interpretable way, is one solution to these problems. This information, if properly encoded, could then be used to adapt or interpret content under an instructional strategy that is different from the one for which it was designed. By labelling the strategy and the components of the strategy in a common, machine-readable manner, the context of a learning opportunity can be managed separately from the content itself.
This same information would have substantial benefits for many e-learning communities. For example, it would allow university instructors to describe the instructional approach associated with their content, thus allowing them to more easily share and reuse with their colleagues content that is designed for their particular instructional strategy and discipline.
This information would also facilitate the adaptation of particular content between learning management systems (LMSs). As institutions re-evaluate their original investments in these systems, perhaps deciding to support different or additional systems, this facility would minimize disruption to course delivery.
The scope of this work was described in the IMS Learning Design Scope document. The high level objectives defined where the following:
The IMS Learning Design workgroup's (LDWG) goal is to work towards establishing specifications for describing the elements and structure of any unit of learning, including:
The specifications, which describe this framework, need to:
The goal is to enable many kinds of educational designs to be created, using a consistent notation, which can be implemented uniformly in multiple courses or learning programs.
Providing conceptual models for problem-based and other types of learning would seem a large task requiring the development of a Topic Mapping capability or some equivalent and is not supported in this document.
Similarly, assessment tools and strategies are not explicitly included in this document, although these can be included by reference to content elements that are assessments. The structure of assessments is described by the QTI Specification. The Type field of the <resource> element in Content Packaging has an agreed set of terms for including instances of other IMS specifications and can be used to identify content elements that are assessments.
The LDWG will explore with the QTI WG how best to integrate the QTI Specifications into the Learning Design Specification.
While the Learning Design approach allows different kinds of learning strategies to be supported, there is currently no vocabulary provided for describing different kinds of learning approaches, in part because the runtime system does not need to have such a vocabulary in order to correctly interpret learning designs - it just has to be able to interpret the meta-language. This provides a means of expressing many different pedagogical approaches in a relatively succinct language as set out in this document. This language in itself must be pedagogically neutral. In consequence, a system that has to interpret this language does not need to know the pedagogical approach underlying the design: it only needs to be able to instantiate the design, allocate activities and their associated resources to participants playing the various roles, and coordinate the runtime flow.
Similarly, while the specification, as outlined in this document, allows the interchange of units of learning between systems, it does not support 'access', in the sense of 'searching by learning approaches', to these units of learning across systems (other than by supporting a GUIDs on each unit of learning). However, the LDWG may, at some point before the Final specification, introduce a taxonomy of pedagogies, or some examples of such taxonomies, which can be used with the IMS Meta-Data <classification> element. These may be separate documents that are not part of the specification as they are likely to be contentious if put forward as normative, and are not central to the rest of the specification.
The IMS Meta-Data Specification already provides a level of description and potential access to units of learning using its existing fields and vocabularies. However, it does not include elements for either Learning Objectives or Prerequisites, which are explicitly included in the Learning Design model. In essence, these take the same form as IMS Reusable Definition of Competency or Educational Objective (RDCEO), in as far as they consist of a text description associated with a GUID that enables the description to be referenced without the need to parse and interpret the text.
Going beyond this to establish a vocabulary of learning objectives is a significant task in its own right (although something along the lines of Topic Maps using RDF to align with the emerging Semantic web would be a research program of relevance to future versions of Learning Design).
The need for a vocabulary of pedagogical approaches therefore lies outside the requirements for the runtime implementation of the designs, and the task then is to elaborate this need more clearly, identifying the actors and their use-cases. An example might be a learning designer looking for content, not just in a particular subject area, but exemplifying a particular learning approach; or a learning provider with a similar need. Another might be a system that provides units of learning for learners on the fly where one of the criteria for selection is the pedagogical approach used. For these kinds of purpose, a taxonomy of learning approaches or pedagogies would be needed for use in the IMS/IEEE Meta-Data <classification> field.
The LDWG has determined the following to be out of scope for this effort:
Going beyond the out-of-scope restriction 2) "the impact of user preferences on the design and delivery of a unit of learning", this is supported in Learning Design Level B, which supports properties and conditions and hence indirectly learner dossiers. There are two possible types of properties:
Type one is not difficult to support and needs no widespread agreements, yet adds considerably more capability for the learning designer. It has already been developed and implemented in EML and makes a valuable addition.
Type two is probably the reason why it was put forward for exclusion because of the difficulty of defining properties. But where they have already been defined in other IMS specifications, it also makes sense to support them as properties in Learning Design (in fact the exclusion of properties was questioned at the time but never properly discussed).
Going beyond the out-of-scope restriction 3) "specification of the technical mechanics of delivering a unit of learning (e.g., content packaging models, client-server information transfer, etc.)", given the decision to build on Content Packaging, the Learning Design Specification inherits this part of the mechanics of delivering a unit of learning.
Going beyond the out-of-scope restriction 5) "specification of the mechanics of the process of interpreting content from one model to another", as was found in the Simple Sequencing WG, the specification also has to provide a Behavioral Model explaining the dynamics of a learning design. This could be taken as meaning a specification of the (high level) mechanics of the process of interpreting content. Otherwise this scope restriction is observed in this document.
The LDWG takes into account existing IMS specifications and tries to build on them where possible, producing extended variants if necessary. It therefore is relevant to ask what value the Learning Design Specification adds to the existing and concurrently developing IMS specifications.
This can be done in three parts, reflecting the three different learning design schemas provided by this specification. To facilitate both the production of the specification and its subsequent implementation, Learning Design has been divided into three parts, known as Level A, Level B, and Level C. Separate XML schemas are provided for each level, with Levels B and C each integrating with and extending the previous Level.
In general, Learning Design supports the use of a wide range of pedagogies in online learning. Rather than attempting to capture the specifics of each of many pedagogies in equally many specific schemas, each requiring specialized implementation of both design and runtime systems, Learning Design provides a generic and flexible language. This language, a version of which is set out in this specification, is designed to enable many different pedagogies to be expressed. The approach has the advantage over alternatives that only one set of learning design and runtime tools then need to be implemented in order to support the desired wide range of pedagogies. The language was originally developed at the Open University of the Netherlands (OUNL), after extensive examination and comparison of a wide range of pedagogical approaches and their associated learning activities, and several iterations of the developing language to obtain a good balance between generality and pedagogic expressiveness.
The current IMS specifications reflect a model of a single user, as a lone learner, interacting with content and being tested. Learning Design provides the capability of designing units of learning that simultaneously include several roles, each of which can be played by several actors. It enables their activities to be specified in coordinated "learning flows" that are analogous to groupware workflows. It thus supports both group and collaborative learning of many different kinds, the importance of which is increasingly recognized in both the commercial training and educational spheres. It can still be used to support the single learner model through the creation of a unit of learning with a single role and no interactions defined between learners. If multiple learners are assigned to the role, they each work with the assigned resources in isolation.
The same mechanism also enables support staff roles to be included in a design, as well as those of learners.
Because Learning Design separates Activities from Activity Structures and these from Roles and Resources, they all become reusable components. They are brought together under the concept of a Method which uses the familiar structure of a Play with Acts and Role-parts in each Act.
Certain Services are also specified in the Learning Design Specification. A Service provides a general function such as an email, conferencing, or announcement service which cannot be specified using a URL at design time, but instead can only be bound by the runtime system when the learning design is instantiated and actual people have been assigned to the various roles. The concept of a Service is not currently supported in Content Packaging where a fixed URL has to be specified at design time. This part of the specification has a separate XML binding so that it can also be used independently of the rest of Learning Design, for example as an extension to Simple Sequencing.
Learning Design Level B provides for the inclusion of generic properties and conditions. There are two types of property proposed: "Internal" and "External". Internal properties have names and value ranges that are defined at design time and govern the flow of events in a pre-determined manner. External properties and their vocabularies have to be agreed more widely ('globally'). Examples of these are the fields and terms established by the Accessibility specification extensions. Others may be developed in a future version of the IMS LIP Specification.
To the single learner model, Level B adds learner personalization, supporting pre-knowledge, preferences, and accessibility, enabling these to be taken account of in a learning design.
It also supports the learning approach based on "portfolio assessment", increasingly being used in certain types of commercial training, which is based on qualitative assessment of the learner's productions or "portfolio" rather than quantitative or test-based assessments.
Learning Design Level C introduces notification or "messaging" both between system components and between roles. This adds a new dimension by supporting real-time event-driven work/learning flow.
Activities can then be set as a consequence of dynamic changes to the learner's profiles and/or of events generated in the course of the learning activities. It can also be used to trigger messages being dynamically sent to participants.
More generally, it enables the automation of learning flow activities, which are triggered by the completion of tasks, rather than the learning flows being pre-planned. Collaborative events can be supported where the activities of roles are dependent on the state of the activities of others. These can therefore be designed as a network of event rules rather than as a pre-planned order of events. A consequence of this dependence on runtime events is that the activities set to learners are no longer wholly predictable, they depend on the course of the collaboration. At Levels A and B, the ordering of learners' activities is predictable, although of course at level B through the use of properties and conditions the learning flow may become conditional.
Level C also allows role-play / game-play and event-driven simulations.
The following are descriptions of use cases representing the diverse needs of the IMS LDWG membership, including academic, corporate, content, and publisher. From the Conceptual Model, the fundamental concepts behind a Unit of Learning include Role, Resource, Activity, and Method. Additionally, Units of Learning have various meta-data which include Objectives, Title, etc. Since use case development and conceptual model development iterate at the project level, the use cases below have been chosen to validate the conceptual model.
Narrative: One model of learning has an instructor initiate the learning process by identifying desired outcomes for a particular learner. By pre-assessing that individual's prior knowledge and understanding the student's strengths and special needs, the instructor is able to identify relevant activities and pull them together into an individualized unit of learning, which is then delivered to the learner. This use case addresses how a software system could automate parts of this process, bringing value to both instructors and learners.
Primary Actors: Learner, Instructor
Preconditions: The instructor and learner are logged onto the system.
Trigger: The instructor identifies a desired outcome for a student.
5a. Pre-assessment results show that student does not meet criteria for beginning activities matched to desired outcomes.
5a1. System notifies educator and displays pre-assessment result.
5a2. Educator identifies new desired outcome and returns to Scenario Step 1.
Narrative: In a Grade 6 Social Studies unit, aboriginal students would not use "Canadian" parliamentary procedures to debate an issue; they would use "First Nation" governance procedures. Similarly, responsible citizenship may be defined quite differently for certain situations in First Nation communities. The LMS used by Alberta Distance Learning Center (ADLC) must be able to provide the culturally appropriate content based on the learner's profile, without the human tutor having to literally deconstruct a packaged resource by inserting links, changing questions, adding activities, replacing assignments or processes with others-in other words, physically individualizing the learning environment for each student. Although content (cases, illustrations, examples, etc.) may be personalized, students must be able to work in cross-cultural groups to create an argument for an upcoming online debate.
Primary Actor: Learner, Instructor (Tutor)
Trigger: The Learner logs onto the System and identifies module in Grade 6 Social Studies unit: "Canadian Governance".
1a. Submitted user data is incorrect or incomplete.
1a1. System prompts for data and is satisfied
1a2. System does not recognize student and he/she is locked out.
2a. System cannot match learner profile to student's ID.
2a1. Student has not completed a profile; is prompted to do so.
2a2. Student is not registered in course. System advises student to contact ADLC.
4a. Module is not available to student.
4a1. Student has not completed prerequisites; System posts advisement.
4a2. Student is not on class list; tutor may override system and add.
4a3. No tutor is available; System advises student and message is sent to administrator.
5a. Student neither receives question nor is assigned to a group.
5a1. Student notifies tutor; tutor assigns mechanically.
5a2. Tutor advises system administrator of system error.
6a. Tutor does not receive email message.
7a. Student email does not contain URL of problematic page.
8a. Tutor does not respond to email.
8b. Email has not been received. Student sends error message to system administrator.
9a. Culturally relevant content is not found.
9a1. There is no available content of this nature.
9a2. The content is not properly linked to system; tutor assigns mechanically. Notification is sent to system administrator.
Narrative: One common instructional model at the tertiary level combines large, 1-hour, large-lecture class meetings taught by a professor with smaller, weekly sessions, run by teaching assistants, which focus on clarifying points of the lectures or facilitating completion of student homework. In an effort to optimize this model, pre-assessments are given to individual students in order to identify missing pre-requisite knowledge and skills, followed by self-paced tutorials meant to address any deficiencies uncovered by the pre-assessment. These self-paced tutorials are assembled from existing materials, based on both their relevance in addressing the specific knowledge and skills identified, and their conformance to the individual student's learning needs. This use case addresses how a software system can effectively automate parts of this process.
Trigger: The Learner attempts to log in to the qualifying course for the first time.
1a. System may not recognize the student id and/or password.
4a. Learner may opt to take the pre-assessment at another time.
9a. System nay not locate any activity-structures that match the learner's deficits or learning profile.
10a. Learner may not complete an activity-structure in a single session.
10b. Learner may not take or complete the post-test.
11a. Learner may fall below criteria on the post-test.
Narrative: At Penn State, students in Information Sciences and Technologies are involved in courses which emphasize problem-based learning. In any given course, a number of problem-based learning activities are completed. Preparation for these problems includes an introduction to course objectives, policy and structure, principles of problem-based learning, and sample group problem-solving activities. For any given problem-based learning activity, students are assigned to teams and presented with a problem description, objectives, document and presentation requirements, an outline of associated topics, and evaluation rubrics. Students are then assigned a number of discrete learning tasks which address all areas of the overall problem. These tasks include participation in discussion activities, access to subject matter experts, reviewing online content and resources, and online quizzing. Once students have completed all of the discrete tasks, students are evaluated by delivering their problem solution in the form of an in-class presentation and a response document, together with discussion activity participation, self- and peer-assessment, and online low-stakes quizzes.
Trigger: Provision of ill-structured problem description with rubric for successful completion of problem.
4a. Students complete weekly discussion activities.
Narrative: One common instructional model for K-12 education has students placed in groups of 2-5 members, in which each member has a role. These roles are associated with an activity, based on a set of resources, one of which is a form that is used to record each student's role-artifact. These role artifacts are then aggregated into a group artifact. The group discusses the group artifact and then submits it as a record of their best group work. The system aggregates the artifacts as they are submitted, analyzes the data therein, and displays the results in a way that is meaningful to the teacher. As the evidence accumulates, the teacher may initiate a class discussion, send one or more of the artifacts back for correction or clarification, or move a group on to another activity, with the same or rotated roles. This use case examines how a software system may automate one or more steps in this process.
1a. The instructor may assign a time limit for the activity, view alternate activities, check that all students present are logged in, etc.
4a. Each group may get the same or different activities.
5a. The system may make the state of the role-artifacts of each learner available for the instructor to view.
6a. The system may make the state of each group-artifact available for the instructor to view.
8a. The groups may vote to submit the form, or the form may be submitted as is, after a timelimit set by the instructor.
8b. The instructor may return a group form for correction or clarification. Forms returned to groups are removed from the aggregate and are not used in the analysis.
Narrative: Multiple groups within Microsoft develop content on the same technology domain and need to reduce the duplication of efforts in order to provide deeper and richer learning objects. This content is currently saved in separate data repositories. Authors need the ability to query disparate repositories, determine when content has already been developed or is in the process of being developed for a particular learning activity and then include this object as part of their reuse design. During the early stages of development the "content" is only an outline of the intended units of learning for the user experience, objectives, roles, activities, and methods to be used. Once the content is to be packaged, the referenced objects are imported as required.
Trigger: Author queries object repositories on meta-data elements.
1a1. Metadata elements not present.
1a2. Database connection not available.
Narrative: Customers are asking for (demanding) the ability to solve business problems in less time. The time to take a traditional sequenced course over 3-5 working days is no longer possible for many. And at times the content may cover objectives the learner has completed in previous courses, a pre-assessment covering multiple content organizations or through on-the-job experience.
Primary Actor: System, Learner, (Instructor)
Trigger: Learner launches link to content on a particular domain of knowledge.
1a.Instructor looks to provide shortened course and teach just what needs to be taught (async activity).
1a1. Instructor creates item bank covering multiple knowledge domains.
1a2. Instructor sends link to pre-assessment to enrolled students.
1a3. Student(s) take pre-assessment.
1a4. System scores results and adds mastery scores to learner profile.
1a5. Instructor creates new learning path for bulk of content and assigns pre-work to individual student(s).
8a.Learner has taken previous courses covering overlapping objectives (i.e., Windows 2000 Server has similar functionality repeated in Windows XP course content).
8a1. System maps learner profile to current content and provides alternate learning path.
Narrative: Learning designers want to take advantage of labs, chat, mentoring, and other functionality provided in many current learning delivery systems with some assurance that a call to such a service will not result in a "broken link" and that some alternate experience can be created.
Primary Actor: System, Learner, Tutor
Trigger: Content includes a virtual lab reference.
2a. System does not have resources available.
2a1. Content provides option if lab capabilities do not exist.
2a2. System displays alternative content.
3a. Learner leaves lab session in incomplete state.
3a1. Learner closes lab activity.
3a2. System preserves lab environment.
3a3. Learner continues with other activities within the learning path.
3a4. Learner returns to lab activity.
3a5. System recalls and opens previous lab state.
3b. Learner requires assistance during lab activity (synch).
3b1. Learner requests mentoring assistance.
3b2. System opens a chat window and points to lab in question.
3b3. Tutor in particular domain responds and inquires about learner's problems.
3b4. Learner inputs problem, referring to dialog box in lab activity.
3b5. Tutor lists procedural steps for learner to try.
3b6. Learner attempts steps (success) in lab activity.
3b7. Learner responds to Tutor that the steps worked.
3b8. Learner closes chat window and requests to save chat transcript for future reference.
3b9. System saves transcript in note section associated with lab activity for the learning object and closes chat window.
3b10. Learner completes lab activity.
3c. Learner requires assistance during lab activity (asynch).
3c1. Learner requests mentoring assistance.
3c2. System opens an email window with a subject referencing the lab activity.
3c3. Learner inputs question into email dialog, referring to dialog box in lab activity, and sends email.
3c4. Learner closes lab activity.
3c5. System preserves lab environment.
3c6. Learner continues with other activities within the learning path.
3c7. Tutor in particular domain responds and lists procedural steps for learner to try.
3c8. System notifies Learner of response from Tutor.
3c9. Learner opens email response.
3c10. Learner opens lab activity.
3c11. Learner attempts steps (success) in lab activity.
3c12. Learner completes lab activity.
Narrative: Blended Learning is a NETg feature by which a course includes components that do not fall into the traditional mold of 'sequenced content'; a FAQ, a glossary, references, resource documents for the student to work with, etc. Alternately, in a Blended Learning environment, the role of learning objects themselves may be different than in a traditional course; the learning objects may simply be instructions for the student to perform some real-world task in an application other than the learning content. The performance of this task may also require a different scoring paradigm than the standard "learning object reports a score" paradigm; there may need to be a human in the loop or other scoring options may need to be explored.
Further, in a Blended Learning environment, the role of assessment may be different from that described in the adaptive pre-assessment environment. The assessment may be integrated with the individual content objects, or there may be a single task object that provides an assessment in an authentic context over a set of content objects. These task assessments may also exist multiple times, and there may be relationships between these multiple assessments; for example, one may be an assessment with a high degree of scaffolding and assistance for the learner, and another may be an assessment where there is virtually no scaffolding or assistance. These relationships must be explicit so that the role of each object is clear.
Scope: The system under discussion in this use case is the Learning Content.
Trigger: Learner launches an instance of NETg Blended Learning content under a 3rd party LMS.
2a. It may be that the content contains reference objects, such as a glossary or FAQ. In this case, the content should indicate the 'scope' of these reference objects, and the LMS should make them available at the appropriate time, as defined by the content. It may be that the definition of 'available' is determined by LMS policy, or it may be specified in the content (i.e., whether 'make available' means 'provide a link' or 'automatically deliver' or something else entirely).
2b. It may be that the content is in the form of an external task, and everything that would normally be standard content is actually reference material for that external task. In this case, the delivery system should make the task available to the learner, and make all of the reference material available at the appropriate time, as defined by the content.
2c. It may be that the content is in the form of multiple task-based assessments, each of which has a different set of reference material and operational guidelines related to it. In this case, the delivery system should present the assessments according to the rules presented in the content, and the relevant reference material should be made available along with each assessment.
2d. It may be that the content is actually a set of instructions to use a real world application to perform some specific task. In this case, there will need to be an association between the task and the support material (both reference material and standard content), and the support material will need to be available to the learner at the appropriate time.
Narrative: NETg wishes to be able to deliver content in an adaptive manner based on characteristics of the learner (for example, those found in NETg's Learner Profile project). There are many possible adaptive interventions that can be taken based on learner characteristics. For purposes of illustration, consider that learners with high inductive reasoning generally benefit from seeing concrete examples before conceptual material in a learning presentation, while learners with lower inductive reasoning generally benefit from seeing the conceptual material first, then the concrete examples. Alternatively, consider that learners with high social skills may benefit more from synchronous interaction with their peers, while those with lower social skills may benefit more from asynchronous interaction. These are merely two ways in which adaptive delivery might benefit a learner, and are presented as examples for the purpose of illustration, not as an exhaustive list.
Interoperability of such adaptive delivery would be enabled by a specification that identified the individual components of any given bit of content. Such a specification should clearly describe the educational role played by each piece of content, and how they relate to each other. Further, the specification should allow for the creation of rules embedded in the content that would allow content authors to describe how the presentation of the content should be adapted for the needs of the individual learner.
Primary Actor: Learning Delivery System
Scope: The system under discussion in this use case is the Learning Content.
Trigger: Learner launches an instance of NETg Adaptive Learning content under a 3rd party LMS.
2e. It may be that the characteristics of the particular learner are unknown. In this case, the LMS should follow any rules that are learner independent, whether those rules are embedded in the content or local to the LMS.
2f. It may be that the rules embedded in the content contradict the rules that are local to the LMS. Proper behavior in this case is outside of the scope of this use case.
The question of how one may use Learning Design to accommodate different pedagogies has been discussed throughout this guide. Section 1.3.4 for instance, contains such a discussion. More importantly, the use cases and examples presented, cover a variety of different pedagogies, thus underscoring Learning Design's capability to support multiple pedagogies. Finally, the Telestia use case features a double play, that each may be conceived of as a different pedagogical approach towards designing patterns.
The design and development of education is an incremental process that systematically follows the stages of analysis, design, development, implementation, and evaluation. Instrumentation differs for each stage, depending on specific goals, settings, and actors that play a role during that stage. The LD Specification is a notation system, enabling flexible, personalized, interactive education, based on a variety of pedagogical views. Although it shows its strengths mainly during the design and development phases, in real life one, of course, cannot dispense with the other phases.
This section provides some guidelines for the design phase. It assumes the availability of a narrative, although it discusses the kind of information one should include in a narrative in order to be suitable for our purposes. The development and testing phases, as we well as the analysis phase proper are out of scope. This does in no way imply that they are of lesser importance. Their discussion would, however, make us stray from our present purpose, which is to illustrate how one may work with and implement the Learning Design Specification.
In the remaining sections, we will first discuss the general framework for Learning Design, in particular the Levels A, B, and C at which it operates (section 2). In section 3 we will give a run down of the elements in the method element, paying particular attention to the way they are related to each other (this is of course, formally specified in the Information Model). Section 4 is devoted to a detailed examination of the analysis and design phases of the development of educational experiences. Section 5, finally, discusses in detail an example use case. Here, we'll see how a story (narrative) of what the educational experiences should be like results in kind of work flow diagram, which, in its turn, gives rise to the actual XML code as specified in the binding document. The discussion is divided in two parts. First we'll use a simplified version of the use case example to illustrate how one creates a design for level A only, then we'll use the original, more complex version to illustrate the design of learning designs that require levels B and C.
At Level A, Learning Design specifies a time ordered series of activities to be performed by learners and teachers (role), within the context of an environment consisting of learning objects or services (see Fig. 4.2.1 for a UML diagram that shows how the various terms used here hang together). Analysis of existing design approaches (see e.g., Koper, 2000, 2001, 2002) revealed that this was the common model behind all the different behaviorist, cognitive, and (social) constructivist approaches to learning and instruction.
Most formal learning design strategies start reasoning from learning objectives, but one may also start from the learning activities, the support activities (usually provided by the teacher), or the environment. Often, a lot of design variables are already fixed and thus are constants in the design process. For instance, in most situations the roles are predetermined (student, teacher, mentor, assessor, etc.), and so is the global time schedule (e.g., semesters). Focusing on the knowledge transfer tradition, it is implicit that the learning activities always are variants on the theme: 'learn the knowledge provided'. In this case, one may concentrate on the question what knowledge and what test resources one should provide. In classroom teaching teacher activities are constrained by the possibilities the classroom affords.
For more advanced learning purposes, properties and conditions, and notifications are required. Levels B and C of the Learning Design Specification provide these. Properties, specified at Level B, are needed to store information about a person or a group of persons (role). So for a student its progress may be stored, perhaps in a dossier; for a teacher information on papers graded may be stored. Conditions, also part of Level B, constrain the actual evolution of the didactic scenario. They are set in response to specific circumstances, preferences, or the characteristics of specific learners (e.g., prior knowledge). An example of a condition would be 'when the learner has learning style X, present the activities in random order'. The idea is of course that randomness allows the student to freely explore the materials. Notifications, specified in addition to the properties and conditions of Level B at Level C, are mechanisms to trigger new activities, based on an event during the learning process. For instance: the teacher is triggered to answer a question when a question of a student occurs; or the teacher should grade a report, once it has been submitted.
From the point of view of the Learning Design Specification, the learning-design element is the top level element. However, a learning design is typically (though not necessarily) embedded in an IMS Content Package, where it is placed with the Organizations element:
manifest
metadata
organizations
learning-design
resources
manifests (submanifests of included packages)
It can therefore be seen as a more sophisticated alternative to the original Organization and item, which provides a hierarchy of tree-structure for the underlying content. Note that as content packages can be nested using embedded sub-manifests, when Learning Design is embedded in a content package, existing content packages can be reused and referenced from within the learning-design element. Learning Design can thus be seen as a higher level 'wrapper' for learning content and services that supports the coordination of multiple users and adds a number of other features. The information model illustrates in very general terms how to prepare a Content Package that contains a learning design.
The following list shows the way the major elements of the Learning Design Specification are hierarchically ordered (an asterisk * means that an element may occur more than once):
learning-design
title
learning-objectives
prerequisites
components
roles
learner*
staff*
activities
learning-activity*
environment-ref*
activity-description
support-activity*
environment-ref*
activity-description
activity-structures*
environment-ref*
environments
environment*
title
learning objects*
services*
environment-ref*
metadata
method
play*
act*
role-parts*
role-ref
activity-ref
metadata
We will now discuss the individual elements in some detail. For a more detailed discussion, consult the Information Model.
If you want to design a learning scenario, the element to start with is the method element. It is to be found towards the end of a learning design XML document. So the method element contains a nested structure of play, act, and role-part elements. The play element (often only one) contains a number act elements. These acts will be run in sequence, each one being triggered by the end of the preceding one. The play is complete when the last act is completed. The transitions between acts thus form a set of synchronization points for all the participating roles.
Note that if there is more than one play element, these will be run in parallel (this was found necessary to accommodate certain situations such as when a teacher activity has to run across all the act sequences of the learners).
Within an act there is a set of role-parts. These are run in together in parallel. This enables different roles to do different things at the same time. The most common use is for different activities to be given to learners and teachers, but it also allows different tasks for different subsets of learners to be managed, as for example in role-plays.
role-parts are the element that links the method section to the components. A role-part contains a reference to a role and a reference to an activity (typically an activity-structure but this can be by-passed and reference may be made directly to a learning-activity or a support-activity or even directly to an environment). This effectively assigns the activity to the role for this act. (Think of the activities as the scripts for the different roles that will be on stage together in an act in a theatre play.)
The significance of this is that an activity-structure is always something that is assigned to a role at a particular point in the learning process. It is particularly important to understand this when translating from a human description into a learning design. The hardest part of this process is determining what should go in the sequence of acts and what should go into activity-structures, and some paper-based going back and forth is often needed in the design stages, especially if it is a complex design.
While a role often has multiple players (e.g. individual learners) assigned to it, at runtime each player in that role gets separately presented with and separately uses the assigned activities and its associated learning objects and services. Therefore, activity-structures cannot be used to coordinate multiple individuals. If they are to collaborate or work together at the same time, this has to be through a service in their assigned environment which supports this, such as a conferencing system. Also notifications may be used to trigger activities across roles. Coordinating the activities of different roles across time, and getting different roles to do different things at the same time, requires acts.
The elements role, activity-structure, learning-activity, support-activity, and environment are all included in the components section. Think of this as the collection of parts that are reusable within a learning design. As mentioned above, the role-part provides the link into this collection by specifying a role and an activity. An activity in turn references an environment which contains the learning-objects and services that are to be used by someone when they engage with the activity.
An activity-structure contains either simple activities (a learning-activity or a support-activity) or other activity-structures. Referencing other activity-structures means that you can form an arbitrarily complex structure of activities. Typically this forms a tree hierarchy, but other types of structure are also possible.
From the point of view of modeling a learning design, an important feature to note is that activity-structures have an attribute called structure-type, which can have one of two values, sequence or selection. The default, if it is not included, is set to selection. This means that when it is presented to the user, all the lower level activities must be presented as some kind of menu or navigation aid for the user to select which activity to carry out, when and in what order. If the structure-type is set to sequence, then it means that the lower level elements must be presented to the user in sequence. It is quite possible for a sequence activity structure to contain a selection activity structure and vice versa. Thus for example, there might be a sequence of beginning, middle and end, but the middle consists of a user-selectable activity structure.
Again, it is important to bear in mind that each user will be tracked and presented individually with the sequence and/or individually make their selections from the activity structure.
An activity (learning-activity or support-activity) has a number of parts. They can have their own learning-objectives, prerequisites, and meta-data. Typically, they also have a reference to an environment which will contain the learning objects and/or services to be used in that activity. They also have an activity-description which is typically a reference to Web page which provides information, description, instructions about what the user should do in this activity. In some cases this is sufficient, and may be all that is needed for example to describe offline activities that are to be carried out. However, it typically tells the user what they should be doing with the resources contained in the associated environment. By tagging it separately from the resources in its environment, the runtime system can treat it differently, perhaps always keeping it available on a tab or menu for the duration of the activity.
Most links between elements in a learning design XML document instance are made by using references. XML supports a special attribute called an identifier. When given to an element, this attribute must be unique within the document (and have no spaces in it).
This unique name allows an element to be referenced from elsewhere in the document and again XML provides a special attribute which references the identifiers. Many Learning Design elements contain such references. These generally start with the name of the element type and always ending with "-ref".
In order to track a reference you have to go to where the types are included in the documents and then search through the identifiers of the elements to find the one being referenced. These in turn often contain references to other elements and so on. This multiple referencing can make manually tracking through a large design quite difficult. Some editors keep track of the names of identifiers and show them in a specific window. This saves you a lot of searching work. Naming your identifiers in a clever way, helps too. It is a good practice to preface a name of an activity-structure with, say, the label 'AS' and an act with the label 'ACT', etc. (see the worked out example below). An activity-structure may then look as follows:
<activity-structure identifier="AS-introduction" structure-type="sequence">
This helps you to identify quickly the kind of element you want to refer to.
It might be asked why references are so extensively used in learning design: why not just nest things inside each other which would make them easier to find? The answer is that referencing makes the elements reusable in different places: the same roles occur in different acts, the same activities can be part of more than one activity structure, and so on. If they were actually nested, they would have to be replicated (copied) everywhere they were used more than once. Apart from making the document much larger, the biggest problem comes in maintenance: a change or correction in one place means that it has to be changed in every occurrence with greater likelihood of errors and inconsistency. Referencing also makes the elements more reusable between learning designs. They can be more easily identified, extracted, classified and made available for re-assembly on other learning designs.
The starting point for the creation of a design is a use case narrative. For the narrative to contain sufficient detail, it should conform to the following document structure, which is derived from Alistair Cockburn's use case template:
Title - a very short description.
Narrative - a general description of the use case in educational terms (see below).
Primary Actor - student in student led learning, teacher in teacher led situations.
Scope - runtime systems involved in the delivery.
Level - description of the level of complexity.
Stakeholders and Interests - a discussion of the roles and their respective responsibilities.
Preconditions - a specification of what is needed in order to provide the student with learning experiences.
Minimal Guarantees - role specific preconditions.
Success Guarantees - role specific demands for the learning experience to be successful.
Main Success Scenario - relate to the runtime systems involved.
Extensions - various failure scenarios.
The narrative should be structured in the following way
Title - a very short description.
Provided by - author, institution, etc.
Pedagogy/Type of learning - case based, problem based, individualized linear, etc.
Roles: - the various participants, such as student, tutor, assessor, etc.
Different types of learning content used - local texts, internet pages, multimedia DVDs.
Different types of learning services/facilities/tools used - external expert, groupware.
Different types of collaborative activities - among students, between students and tutors, etc.
Learning activity workflow - how Actors / Content / Services interact.
Scenarios - e.g., the same content may be used for face-to-face and distance learning.
Other needs / Specific requirements - e.g. accessibility, specific target groups, etc.
The following steps are to be taken in order to proceed from a description of an educational problem to a learning scenario, captured as an XML document instance to conforms to the Learning Design Specification. Step 1 coincides mostly with the analysis phase, steps 2 and 3 with the design phase:
The XML document instance forms the basis for developing the actual content (phase 3). This final steps, which involve creating the physical resource files, linking them to the design and packaging all of them into a content package, will not be considered here. This obviously is an important step as it is required to create actual educational experiences. However, here we shall rest content discussing the learning design only.
The above advice on the sequence of steps to be taken is valid for creating XML document instances from narratives. When it comes to 'reading' existing document instances, one had better start with the method and work one's way down starting with the play element and then on to act, role-part, activity-structure elements all the way to the individual learning-activity or support-activity elements.
Since the Learning Design Specification may be considered a special kind of organization in the Content Packaging's Organizations element, we will not duplicate discussions that really belong to the Content Packaging Specification. Thus resources, nor meta-data or possible submanifests will be discussed here. The use cases are confined to the Learning Design Specification only.
We will now carry out the above steps in the context of an actual use case.
The example use case has been provided by Travis Carlton of the Boeing Corporation, and discusses the replacement of a fuel valve in an aircraft's wing. The use case description has been put in the format the LD group agreed on using. The example use case has been split into two parts. The original use case contains a complicated testing procedure which demands the use of conditions and properties. In the first part, we have therefore left this procedure out, in order to be able to illustrate the design of a Level A instance document. In the second part, the full use case will be dealt with. Finally, where information was lacking, we've added comments [in square brackets].
3.2.5.1.1 Step 1: The use case description
The first step is to provide a description of the use case in the form of a narrative. Only the narrative has been detailed here, as this is most needed to perform steps 2 and 3 (required field names underlined). This means that, relative to the original formulation of the use case, the order of paragraphs has changed, but the text itself has remained intact with the exception of one paragraph.
Title: Boeing Fuel Valve Removal
Provided by: Travis Carlton (Boeing); simplified to fit LD level A and cast in the LD format by Peter Sloep and Hans Hummel (OUNL)
Pedagogy/type of learning: Not discussed in original; the description shows that we're dealing with a kind of individual, self-guided learning.
Description/context: The Fuel Valve Removal course is a fictitious example representing part of a maintenance technician's curriculum. It is assumed that the student will have completed courses that familiarize the student with the vehicle and its systems prior to taking this course. The fuel valve removal course teaches how to remove a fuel valve from a fictitious aircraft's wing in order to service the valve. To enable access to valve, the proper door and the fuel quantity transmitter must be removed.
Learning objectives: Clearly, the objective is that the student should be able to competently remove a fuel valve from a fictitious aircraft's wing.
Roles: From the description, it is clear that there is only one kind of actor and role: the student.
Different types of learning content used: Although this discussion uses the term 'course' the term is meant only as a convenient way to describe the group of instruction in the example. The example may also be considered in terms of an AICC's conceptual notion of a 'Learning Object'.
This discussion refers to the first block and its instructional modules as an introduction. The second block is referred to as the lesson block and the modules are called lessons. The lesson and exam blocks also allow the student to view the Interactive Electronic Technical Manual (IETM). The final block is the test block with the first two tests grouped so that the student only sees them as a unit called the knowledge test. The last test in the test block is a simulation-based test called a performance test.
Different types of learning services/facilities/tools used: [The IETM is the only facility offered.]
Different types of collaborative activities: None
Learning activity workflow (how actors/content/services interact): The course is comprised of three blocks. The first block serves as an introduction, the second block contains the actual lessons, and the third block consists of tests.
Block 1: Fuel Valve Introduction
Fuel Valve Theory of Operation
Fuel Valve and Quantity Transmitter Components
Removal Simulation (Prep, Remove Door, Remove Transmitter, Remove Fuel Valve)
The overall course is ordered sequentially where each block must be completed before proceeding to the next block.
The first block is taken as a whole, started when the student chooses the Fuel Valve Introduction menu item.
The second block is displayed as three choices. When the student has completed the introduction block, only the first two lessons in the second block are enabled, allowing the student to take either of the first two lessons in any order. Although he may take these two lessons in any order, he must complete both before proceeding to the third lesson (i.e., the first two lessons, which may be taken in any order, are prerequisites to the third lesson). The third lesson teaches the actual steps needed to perform the fuel valve removal procedure in the required order. At any step in the lesson, he may view the IETM job performance aid for that step in the procedure.
The tests are not enabled until all three lessons have been completed. The first test is a standard question/answer knowledge test consisting of two sections. After the knowledge tests are completed, the student may take the performance-based test. This test consists of a 'simulation' of the environment in which the student must 'perform' the correct steps in the correct order within a certain time limit. During the simulation, the user may launch and use the IETM much like an open book exam. This example use case in this paragraph has been simplified compared to the original to fit LD Level A.
Other needs/Specific requirements: None
Constructing a UML activity diagram for a learning design on the basis of a use case narrative typically entails a number of steps. Obviously, the order in which the steps are taken here is only a suggested order, not a mandatory one. The creation of a learning design typically is an iterative process, in which one leaps forward and back tracks according to ones personal preferences, the specifics of the use case and one's experience. For the inexperienced, the order suggested here will at least work. UML diagrams primarily are meant to provide an overview and a shared visual insight into complex flows of activities, and secondarily they are an exact way to formally model these flows. Formalization takes place in step 3.
UML activity diagrams place activities in a sequential or parallel order. Choices are allowed and activities may be nested. Also, responsibilities for activities may be indicated by the use of swim lanes. This suggests the following series of steps.
3.2.5.1.3 Step 3: The XML Document Instance
In a way similar to the steps taken to move from the narrative to the UML diagram, a number of steps are now needed to proceed from the UML activity diagram to the XML document instance. Also, similar qualifying remarks apply to the order in which the steps have to be taken.
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XML Spy v4.4 U (http://www.xmlspy.com) by Peter Sloep and Hans Hummel -->
<learning-design identifier="LD-boeing-simplified" uri="URI" level="A">
<title>Boeing Fuel Valve Removal simplified</title>
<learning-objectives>
<item identifierref="" identifier="LOB-learning-objectives"/>
</learning-objectives>
<prerequisites>
<item identifierref="" identifier="PREQ-prerequisites"/>
</prerequisites>
<components>
<!-- to be detailed in step 2 -->
</components>
<method>
<!-- to be detailed in step 3 -->
</method>
</learning-design>