Learning Design and Moodle: the Process of Integrating Specifications
Total Page：16
File Type：pdf, Size：1020Kb
Fourth draft: 28 May 2005
Learning Design and Moodle: The Process of Integrating Specifications
Anders Berggren, Daniel Burgos, Josep Fontana, Don Hinkelman, Vu Hung, Anthony Hursh, Ger Tielemans* Moodle Community Learning Design Book Study Group
(*Authors listed alphabetically. Recent changes colored in blue)
Abstract: Integrating the specifications for IMS-Learning Design into Moodle, an open-source LMS, is not just a technological question, but also contains philosophical and pedagogical issues. This study documents the discussions and experiments of a team of practitioners active in the Moodle community who are concerned with the development of international standards in future versions of Moodle. In the course of studying the book, Learning Design (Koper and Tattersall, 2005), participants analysed the essential differences of the LD specifications with current versions of Moodle and tested the operation of various LD tools (Coppercore, Reload) and related tools (LAMS) within the Moodle environment. These differences were then summarized into technological and pedagogical implications for future versions of both Moodle and Learning Design. It concludes that open dialogue and core changes in both the LD specification and the Moodle LMS may be necessary before transparent integration is achieved.
I. Introduction
The creation of any international standard is a complex endeavor, and most particularly in a practice-based craft such as teaching and learning. Educational stakeholders have an interest in a common method of exchange across borders, languages, codes, venues, methods, philosophies, and interfaces, but until now been limited to exchange of printed materials, a costly and physically limiting media. Early attempts at digital standards have focused on narrow areas such as quiz question packaging or sequenced content. Yet, teachers in particular are hungry to share full courses and learning scenarios, complete with content and processes that they have found useful. The IMS-Learning Design specification (LD) is one attempt to bring that fuller picture to electronic exchange that can theoretically include all forms of highly complex and flexible learning for both online and face-to-face learning venues.
One important stakeholder involved in the discussion and application of standards are the communities of educators and developers of open source learning software. These communities are growing as the ability to design open source software is becoming increasingly a domain of teachers and even students with easy-to-program languages and pluggable/configurable modules becoming the norm. Therefore, we see other stakeholders such as engineers, academics, developers and IT professionals playing a comparatively less directive, but more supportive role in the co-creation of these standards. Educators active in the Moodle community are especially pleased to join in this dialogue with the LD community. [expanded from Gabriela’s suggestion]
Moodle is an open source learning management system (LMS) that has maintained interest in the IMS-LD specifications over the past two years since community discussions began on this topic (Moodle, 2003; 2004a). At that time, it was noted that the Learning Design specification was most the most congruent standard for Moodle, due to its focus on a sequence of learning activities rather than a sequence of learning content. Although Moodle can be used for many kinds of educational applications, it is based on socio-constructivist principles (Dougiamas, 1998; 2000) and most suited for an educational approach involving interaction amongst people rather than transmission of content. In February of 2005, concurrent with the publication of the first book on Learning Design (Koper & Tatersall, 2005), the Moodle community began an online study of this book using a chapter-per-week format facilitated by ten members of the community (Moodle, 2005a). This paper represents a summary of those discussions, and represents a view not from Moodle programmer/developers, but from the teacher/users who actively influence the application and pedagogical directions of Moodle. These values are best illustrated by one forum participant who commented, "teachers are arrangers, not composers of good educational music". In the same way, values of flexibility and configurability will appear in this paper more than structured and systematic values of engineering perspectives. The overarching presumption we hold is that any learning design process must be intuitive and empowering for teachers, and not intended solely as the professional realm of instructional designers.
This facilitation team decided to focus this summary and critique on four points: a) the essential differences of LD and Moodle concepts, b) testing of LD and LD-related tools in a Moodle environment, c) implications for future Moodle versions, and d) implications for future Learning Design versions.
II. Essential Differences of Moodle and LD Concepts
Our group has identified several areas of potential conflict between Moodle and LD. This section discusses four areas where philosophical or structural differences may exist: 1) Units of Learning, 2) Bricolage, 3) Expressiveness, and 4) Topology.
Units of Learning: The meaning and construction of a unit of learning (UOL) is fundamentally different in Learning Design than in Moodle. A unit of learning in LD is multi-dimensional (Olivier & Tattersall, 2005), including a collection of activities that can be forced-sequenced, conditionally- sequenced, or non-sequenced. Content can be embedded within the unit of learning, not just separated in a simple sequence. In Moodle, activities are separated, and only visually “connected” in a vertical column of the main interface. Content is also separated as individual, unattached links or resources. It is one-dimensional in the sense that each resource and activity is totally independent and arranged under topic-labels, not formal UOL structures. This is an advantage in terms of ease of design, but a disadvantage when a particular learning unit needs to be containerized and component dependencies described. Yet, it appears that LD UOL structures cannot be altered or complexified in real-time, as operations progress. In Moodle, there is almost no structure “out-of-the-box”, but an arbitrarily complex structure can evolve over time. Users experience maximum control because they can visualise the whole structure and are given full access for free inspection, skipping, jumping back anywhere on the main course page. Teachers, as well, as they edit in Moodle, are often given a start with a set of preformatted choices, but with freedom to reconfigure. If you start an LD editor, a teacher starts with an empty canvas and can decide to design anything, but without the initial prompts to spur/constrain creativity. Yet IMS LD allows the learning designer to decide what parts of a learning flow control are "automated", what parts shall follow hard coded sequencing rules ("conditions", defined by the learning designer), and what parts are just containers for more or less free negotiated social interactions.
In addition, there are differences in the meaning of roles in Moodle and LD. In an LD “play”, actors assume roles and sub-roles around the generic types of “learner” and “staff”, concepts that have no direct equivalent in Moodle. While Moodle does allow the assignment of students to learning groups, and draws distinctions between “teachers”, “students”, “course creators”, and “administrators” (which are arguably "roles"), these Moodle concepts do not map well to roles as specified by LD. Current implementation plans (Moodle, 2004b) outline definable roles within Moodle, but these plans are only in conceptual stages, and do not specify whether multiple roles and conditional roles will be also possible. The eventual aim is to allow instructor/facilitators to assign virtually any non-administrative role to a learner. Learners will become tutors of other learners and need powers to assess, plan, and manage their groups.
In both the specifications of LD and the operation of many LD tools, users may assume different roles in different parts of the Unit of Learning, while Moodle tacitly assumes that the learner's role will remain the same throughout the course. While a learner can be switched to a teacher role in Moodle, only one role can be played at a time and reassignment requires manual intervention by a course instructor.
Finally, the composition of groups within Moodle and LD are evolving. Student-centred, project- based, and socio-collaborative learning practices place greater emphasis on group-based configurations of learners (Jonasson & Land, 2000). The act of group formation may include self- organised, teacher-assigned, or automated assignment according to project interests. Multiple, simultaneous groupings are a necessary requirement as each learning unit has its own collection of groups, each of which may overlap in time. Moodle’s group function is for a course-wide, single configuration, useful for defining cohorts which do not change during the term of course. In the LD specifications as well, the group functionality may need further development. This has led some LD tool designers, such as LAMS and elive LD Suite, to extend the current LD specification on groups.
Bricolage: One of the most striking features of Moodle is the ease with which course materials can be developed and refined in an iterative fashion. This strategy of course development is very much in keeping with the notion of bricolage (Papert, 1980; Turkle & Papert, 1992). By contrast, the LD tools such as Coppercore and Reload appear to assume that the Unit of Learning will be distributed in a fixed form, and not altered while instruction is in process. This may be related to two differing approaches to software development in learning design: top-down and bottom-up (Britain, 2004). Software designers should follow top-down to be IMS LD compliant so that LD systems can exchange UOLs. However, with a bottom-up approach, software designers have a chance to do more creative things and may help refine the specification.
The “engineered” LD UOL runs and “evolved” Moodle real-time editable configurations represent a major difference in design philosophy. Moodle allows technically-naïve instructors to create useful learning scenarios almost immediately, then progressively refine them as their skills improve. We believe that this is a critical factor in Moodle's success. The results of our group’s ability to operate LD tools was mixed. One group member found LD tools such as Coppercore require much more front-loading of skills before useful results can be achieved, and iterative development was inconvenient at best. However, another group member found he was able to produce units using the LD tool, Reload, with 30 minutes of instruction. ASK LDT is another tool that may provide an easy-to-build approach that is focused more on the author’s perspective, than the raw specification. Yet it is not very likely that the average teacher will be very comfortable going outside the familiar Moodle environment to author a unit of learning with a separate LD tool. On- the-fly creation within Moodle with the subsequent generation of the LD specified format via an internal Moodle process seems like a more appealing option. Thus for a Moodle course/UOL to be LD compliant, this way of “capturing” an end state (and stripping the user data) will need to be developed.
We are also concerned that the fixed nature of an LD UOL may make it difficult to adapt the UOL to handle unforeseen circumstances (either emergencies or unanticipated pedagogic opportunities), particularly when they occur after instruction has begun. For example, in (Ching, Hursh, & Scagnoli), the authors discuss their discovery that the students in an introductory educational technology class had a strong interest in weblogs, and the ease with which Moodle allowed them to adapt the in-progress course to place more emphasis on weblogs. In addition, many instructors who use an LMS to accompany their face-to-face class build their course week- by-week, redesigning the plan both during and after the class. These kind of “bricoleur-teachers” seek to continually capture their learning design after-the-fact and then share these specific iterations in a wider community of teachers.
Expressiveness: Moving to the effects of internal programming languages, there is a potentially significant difference in terms of expressive power between Moodle and LD (or between LD and any other LMS for that matter) that could have non-trivial consequences for the proper integration of the LD standard within this platform. Thus, LD is specified by a collection of XML schemata (Tattersall and Koper, 2005), and can be implemented as a collection of Moore machines, a particular type of finite state machine (Vogtens, et al). It is well-known that there are classes of formal languages (Chomsky, 1956) that cannot be generated or parsed by Moore machines, or any other type of discrete finite automaton. Instead, these languages require more powerful computational models, such as push-down automata or Turing machines (Hopcroft, Motwani, and Ullman, 2000).
By contrast, Moodle is implemented in a Turing-equivalent language (PHP), and thus offers (in a theoretical sense) as much expressive power as any computation-driven environment. Users are permitted (and encouraged) to extend Moodle at will. While Moodle does store its backup data as XML files, this is just a convenient way of writing things down and saving them on disk. The LD XML schemata, on the other hand, place actual semantic value on the position of items in the tree. Moodle's XML has one quasi-hierarchical level (the section), the meaning of which is not necessarily specified ahead of time. LD, by contrast, has multiple levels of hierarchy (play, role, act, etc.).
Due to these theoretical considerations, it appears that some configurations and operations that can be expressed by Moodle may be difficult to be expressed by LD. While we are not prepared to demonstrate at this time that such higher-order computation is a necessity for some forms of pedagogy, we do believe that this is a serious issue that warrants further study. [In discussion, Tony and Josep are saying to delete this section above on expressiveness]
Topology: The structure of an LD manifest can be represented by the specific type of directed acyclic graph known as a tree. The mathematician and architect Christopher Alexander (Alexander, 1965) has argued that socially constructed artifacts, such as cities, cannot be adequately represented by trees, but instead are better represented as a semi-lattices. La Porte, et al (1975) suggest that this phenomenon may hold true for other types of social organization, not just cities.
LD UOLS are distributed as fixed tree structures, limiting transitions and relations to only those paths that were anticipated when the UOL was designed. By contrast, the relationship between Moodle objects is fluid (which, of course, has its own set of advantages and disadvantages). In addition, we must consider non-structured situations (such as in a face-to-face class or in social chat/forum) where functions have been carried out through “unofficial channels”. Indeed some have argued that more effective learning can take place this way than through the formal curriculum. See (Orr, 1996) for extensive discussion of this phenomenon. In the LD concept, itineraries and conditions can be set up to use the same resources in different ways depending on an individual learner’s profile, path, and decisions made throughout the course. Still it is unclear how unstructured group negotiation will be modeled in the LD specificiation.
The topology and expressive power of LD appear to represent a major impedance mismatch with the current design of Moodle. It will be a challenge to see how these issues can be compensated for without drastically altering either Moodle (to force compliance) or LD (to allow richer topologies, a greater degree of interconnectivity, and a more expressive underlying computational model). This is extremely problematic for tight integration of Moodle and LD; it may force any Moodle support for LD to be as a sub-module, rather than LD becoming an integrated function of the Moodle core.
A Moodle course author has a high degree of freedom in organizing course materials, activities and resources. Also, the power and flexibility of the programming language underlying Moodle, PHP, allows instructors and developers to continuously extend the capabilities of this system in unexpected and creative ways. It is unlikely that they will give up these advantages solely for the sake of standardization.
III. Testing LD tools with Moodle Related to IMS LD, there are several tools available nowadays: a) engine, b) editors and c) players. In addition, there are LD-related graphical editors. How each of these could relate to Moodle is discussed in this section.
LD Engines: First of all, CopperCore (Vogten and Martens, 2004) is an engine capable of running all the levels (A, B and C) of the Spec. In fact, it is the only one engine available. CopperCore has been extensively tested with a set of examples on Levels A and B (LN4LD, 2005) and is performing the LD specification perfectly. CopperCore provides three API’s: CourseManager, that provides administrative functions (users, runs, roles, publications), LDEngine, that provides run-time behavior (activity trees, environment trees, content, completions) and Timer, providing triggers timed events (various timed completions). CopperCore also provides one library for validating routines and LD manifest. It is worthy to say that CopperCore is an engine, not a Learning Environment nor a Management System, so it is not a stand alone product and does not provide any user interface. With CopperCore, IMS LD packages can be run, but not designed. Lastly, CopperCore also provides a basic WebPlayer to run the Units of Learning and check their funcionalities One of the main goals for this section was to run a test between Moodle and CopperCore to check whether is possible to integrate both systems in a simple manner. After several basics attempts, we conclude that Moodle can be run inside CopperCore directly, by just including the right weblink. The other way around, CopperCore into Moodle, can be run as a Resource-Weblink but was not able be run directly as a Resource-Webpage, embedded into the system. Both cases were tested, by calling the generic WebPlayer and by calling one specific instance but with no success. Probably, some minor change can be made concerning ports or frames dependency to skip this problem. Further tests are needed to determine the extent of interoperability.
LD Editors: Regarding the editors, there are five examples that are available and running (see Table 1)
Table 1: LD-Compiant Editors Currently Available (May 2005)
Nr. Tool Name Link Author Levels 1 CopperAuthor www.copperauthor.org OUNL A 2 Reload LD http://www.reload.ac.uk/ldeditor.html Reload A,B,C Editor 3 ASK LDT http://www.ask.iti.gr/ University of A,B Piraeus 4 Mot+ http://www.licef.teluq.uquebec.ca/gp/eng/producti University of A ons/mot.htm Quebec 5 Cosmos http://www.unfold- University of A,B project.net:8085/UNFOLD/general_resources_folde Duisburg r/cosmos_tool.zip
With CopperAuthor and Reload LD Editor, Moodle files can be opened modifying the namespace reference but there is no match between the fixed structure of the editors, ready to interpret IMS LD manifests, and a RSS file from Moodle. All these tools are in a very preliminary phase of development and all of them are Beta releases, so it is expected them to be so much compliant to IMS LD. There is no need for them to support other specifications or notations because their need is to run 100% IMS LD and to get the maximum interoperability between UOL’s. Besides, they can be integrated in Moodle as external editors of IMS LD files, as any other editor not related to the specification. With the other tested applications, ASK LDT, Mot+ and Cosmos, Moodle files could not be opened and a way to do it could not be found. If it is possible, there is no clear clue to do it. Also, all of them can be included as external editors, as any other executable file.
LD Players: In terms of players, two are available at this moment: CopperCore Player and Reload LD Player (Bolton, 2005). The first one is just a working prototype to show how the UOL’s run and to check internal functionalities, publishing results and playing instances, roles and users. Everything that can be published with the engine can be played here, although the user interface is not friendly at all. As it’s full dependent of CopperCore engine, it can be run in Moodle in the same way described above. The second one (Reload’s) has been just updated and supports much better several elements and learning structures of IMS LD. It’s not full running all the Levels and features but it’s being improved so fast and there is no doubt of a full conformance very soon. As an external web player can be used inside Moodle, integrated as a Resource in both ways, as a web link and as a web page with no further error.
In general, assuming at least two levels of integration, a primary level with just links between the applications and a secondary one with embedded running, the first one is quite easy to do in terms of players and engine. A player can be launched from Moodle or a player can be launched a Moodle course itself. Specific arrangements have to be done depending on the player, though, but not major ones. The second level of integration, embedded, is currently not so close to achieve. Because of the current state of the several developments the full integration of both worlds keep blurred. It is needed to run a larger test among all the possible tools/platforms to find or create the bridge to link them. Moreover, one special weak issue is the communication between them. This means that variables and fields can be shared and distributed between several different tools under the same running instance. It is the same problem that CopperCore has with other fully integrated applications running inside it. This issue is actually being researched to find out a satisfactory solution.
Lastly, and concerning the IMS LD editors, a further use of them to edit Moodle structures is not directly supported yet but it is currently not expected until tools can run integrated IMS LD Units of Learning/Moodle Courses. Then this issue will be approached.
LD-Related Graphic Editor/Players: There are two graphic editor environments that were discussed: LAMS and elive LD Suite. LAMS has been publically released and examined for this report. LAMS is an LD-related tool for designing, managing, and delivery online collaborative learning activities. It is not a competing learning management system, but sees itself as an activity/UOL authoring tool that could be used with many LMS. It has an intuitive interface with a visual authoring environment for creating sequences of learning activities (LAMS International, 2004). Although it is not LD compliant, it is based on LD principles and intends to be LD Level A compliant by next year. Table 2 shows a summary of the capabilities of all tools mentioned in this section.
Table 2: Roles and Capabilities of LD and LD-related Tools
Package Name LD engine LD editor Non-LD Drag/drop LD Player Administratio Interface editor editor n CopperCore O X X X O O (API) X CopperAuthor X O X X X X O Reload X O X X O X O ASK LDT X O X X X X O MOT+ X O X X X X O Cosmos X O X X X X O LAMS X X O O X X O Moodle X X O X X O O
Integration with Moodle: At the moment, LAMS is one of the most influential LD tools for the Moodle community because of its ease-of-use and the willingness of the developers to adapt it into the Moodle environment. According to recently published development roadmap projections, Moodle (2005b) intends to integrate some distinguished features of LAMS as either a new course format, a new activity module or both in version 1.6. This will lead to eventual LD compliancy for Moodle in version 1.7. In this section, we describe some main points of LAMS. Then, we point out the similarities and differences between Moodle and LAMS. We also try interacting between two systems. In the end, we draw implications of LAMS for future versions of Moodle. LAMS and LD: To make LD easier to understand, LD can be conceptualised at three levels: theory, standards, and software (Dalziel, 2005). LD theory is based on the general idea of people doing activities with resources/environments. LD theoretical framework does two contributions to current theories of e-learning. It is not only able to describe both individual and group e-learning task, but also allows for sequences of activities to be formally described. LD standard is migrating from the theory of Learning Design into a machine-readable technical standard. LD software are tools in use or in development that are based on Learning Design theory. Some of these software tools are based on the IMS LD specification (in Level A, Level B or Level C). LAMS (the Learning Activity Management System) is a software system based on the concept of LD theory which has been in use with real teachers and students since mid 2003 (Dalziel, 2003) . LAMS is ‘inspired’ by IMS LD specification. However, LAMS was not designed to be a reference implementation of the specification. LAMS is intended to be IMS LD compliant in July 2005. The LAMS team has pointed out some problems with IMS LD that made it difficult for them they to implement an intuitive system under (Dalziel, 2005).
Moodle activities vs. LAMS activities: Activities are similar in function and play a very important role in both Moodle and LAMS. Moodle 1.5 activities include forum, chat, survey, choice, assignment (including journal), resources, grouping, glossary, lesson, wiki, messaging, and optional modules such as book, database, questionnaire. LAMS 1.0.1’s activities are similar, including forum, chat, journal, survey, voting, submit files, share resources, grouping, resource and forum, Q&A+Journal, Voting+Journal, Chat&Subscribe, and Chat&Subscribe+Journal.
Moodle has many other activities in development (for example: blog, database, project, document management). The number of activities in Moodle is greater than LAMS and both activities are capable of building a rich collaborative learning environment. The main difference is that a LAMS activity was built to be “Learning Design aware”, while a Moodle activity is not.
With LAMS, you can create a sequence of activities and set the order of activities. Then the created sequence is saved in a private or public repository. If author needs to modify something, he can reload it from the repository and does some changes. In addition, there is a special kind of activity of LAMS called Parallel Activity (Ghiglione & Takayama, 2005) which allow a single person to do two streams of activities concurrently on a single screen. We list such activities here: Resource and Forum, Q&A + Journal, Voting + Journal, Chat & Scribe, Chat & Scribe + Journal.
LAMS Design Screen (for illustrative purposes—to be removed in final version) Interaction between Moodle and LAMS: The case of embedded resources was the easiet for Moodle/LAMS interaction. We put LAMS inside Moodle as a resource (link to a URL). Of course, LAMS and Moodle must have the same session so that we have no login problem. Interoperability interaction was more difficult because Moodle 1.x was designed with no “Learning Design” ideas in mind. Thererore, it is hard for Moodle to interact with any UOLs. At the moment, LAMS exports/imports a sequence of learning activities under its own format. Obviously, LAMS cannot use the course data of Moodle and Moodle cannot understand a sequence of LAMS. Finally, in the case of activities interaction, we found that activities of Moodle and activities of LAMS can not exchange data or re-use one another because they do not have a common interface for interaction.
In its next version, LAMS 1.1 will have a “learning design tools interface”, which provides the basis for creating new tools to interact with the LAMS core (called “LD engine”). It will be useful if future versions of Moodle have a similarly modeled interface. It can help developers create new activities for Moodle more easily and as a result, Moodle will be a richer online learning environment based on LD. Finally, the Tools Integration Project (TIP) of JISC has been focusing on integrating some popular open source softwares (Bodington, LAMS, AMSTOIA) using a WebAuth single sign-on mechanism (Noble, 2005). In this project, LAMS will be able to interact with other systems easily. Moodle should consider adopting this kind of capability. [This LAMS section may need to be condensed for this paper, however, it is useful separately in its entirety for Moodle users to understand it (Don) ]
IV. Implications for Future Versions of Moodle
Moodle has begun an ambitious effort to integrate Learning Design standards into its future versions. Currently, version 1.5 is not compatible with IMS-LD specifications. However, according to a May 2005 future roadmap projection (Moodle, 2005b), Version 1.6 will move toward integration with LAMS as an activity or a course format. Version 1.7 will aim for “preliminary support for IMS-LD Level A, allowing import and export” and integration with some repositories. Finally, version 2.0 is intended to provide complete support for the IMS-LD standard, conditional activities, and groups/roles customization at site, course, and activity level. In addition, this book study group wishes to emphasize several further points on this pathway: 1) bricoleur tooling, 2) UOL-style authoring, 3) XML code output, 4) roles/conditions/paths, 5) Ajax/Sajax incorporation, and 6) goals for LD levels.
[Note: the comments posted by Ger on this forum will also need to be incorporated see http://moodle.org/mod/forum/discuss.php?d=24217]
1. Maintain bricoleur tooling The first implication is for Moodle to maintain its bricoleur mode of design and operation as it incorporates the LD specification. The French word bricoleur is normally translated as "handyman" or "tinkerer". The pedagogic sense of the word was introduced by Turkle and Papert (1992) which grew out of an earlier use by Levi-Strauss (1962). The idea here is that there two fundamentally different ways of approaching a problem. The "engineer" way involves making careful plans and writing everything down in full detail ahead of time. The "bricoleur" way is more of an organic process of iterative design and refinement. While each approach is useful, the advantage of software designed with bricolage in mind is that the users can start producing useful results immediately. If the software requires lengthy training before worthwhile results can be produced, most teachers will not use it unless forced to do so. Moodle is an excellent example of software designed for bricolage. A naive (or even technophobic) instructor can start doing useful things in Moodle with five minutes of instruction. Seeing an immediate positive result is a powerful motivating factor. There seems however to be no fundamental reason why LD could not support bricolage by altering the LD XML tree while the code was running, similar to the way you can use DHTML to alter web pages that have already been loaded. Consequently, if it is technically possible, we would favor the development of LD tools (preferrably internal to Moodle so that the environment users are familiar with can be preserved) that support this work style. [paragraph above slightly condensed, if more is to be removed, it should go in Section II]
2. Add structured UOL-style of “card” authoring Moodle’s interface is presently organised like a stack of cards laid out vertically down the screen. Each card is a square box that represents a week or a topic. A card contains a title, some activities and some resources. It is almost self-contained and represents a piece of learning. Divide the card into its bits, and the bits are almost meaningless. In the LD specification (Koper & Tattersal, 2005), Units of Learning (UOL) are used as a central concept. This UOL is the most fundamental difference in LD because all parts of that “card” are formally structured, connected in paths, and often layers deep of non-visible activities and resources. In Moodle, the unit is flat, with no hidden activities behind a title. The title itself is just a label, it cannot pull along the associated parts with it by dragging and dropping. Thus, an instructor cannot swap cards/units in Moodle. Moodle needs to structure its card as a building block of a learning, but linked to parts of the specification behind. An LD Unit of Learning is part of the specification itself, how it is used depends on the tool. However, we propose that future Moodle versions develop movable, swappable cards adding a LAMS-like, PHP/Flash graphic card-design tool. These Cards/Units will then be the core objects exchanged in a Moodle Respository or an LD Repository. This new structure we think will make Moodle more LD-cohesive than any other single change. [paragraph above condensed]
3. Generate XML code from Moodle designs after-the-fact We need an 'after-the-fact' tool that builds an XML model after a teacher designs and implements a course,. This would 'capture' a model/scenario after or while the learning has taken place. In other words, we would imagine that as a course progresses, the LD tool analyzes the online patterns and produces an XML model. In addition, a manual editor could then add the face-to-face aspects to the model. Currently in Moodle, there is a basic process happening like this already. Behind the mask of the zip-backup is a non-documented XML-tree. Moodle will need work in areas such as automated updating of resources to become fully compatible with LD. Moodle tends more toward what the authors characterize as 'server-centered' rather than 'manifest-centered', though there are some aspects of Moodle that are reminiscent of a manifest-based approach, in particular the XML format used for backups. It may be that the backup format could migrate toward a more LD-friendly structure without too much difficulty (perhaps through an XSL transformation). [paragraph above condensed]
4. Add multiple, definable, conditional roles Moodle needs definable roles, and should move toward a capability to do multiple roles and conditional roles and temporary roles. As outlined in the Implementation Plan for Roles (Moodle, 2004b), the goal is to create an intermediary role between teacher and student--say "tutor" with limited teaching permissions. We can also define roles such as mentor and mentee. These roles would then be defined at the site level, course level, and activity level, possibly allowing multiple roles within the same course. However, it appears that the LD concept can go further with "multiple" roles. We assume this means that someone could have several simultaneous roles in a course. For example, within the project area B, John is tutor, but in project area C, he is a novice student. This would be very appealing to instructors who would very much like to take a single activity and assign all of our students to be "teachers" in that activity alone. For example, teachers often ask students to create quizzes on paper, then assign one to a teacher role to input the questions into Moodle. However, it would work more smoothly if it could become a configuration option inside Moodle. Another concept is conditional roles. A student would automatically be given a different role when certain conditions are triggered. This operation is much like moving up to Level 2 in a game.
5. Incorporate LD into Moodle with Ajax/Sajax We discussed how it might be possible to incorporate LD editing and playing functionality into Moodle as a course format or activity module. Any LD implementation in Moodle must be as straightforward for teachers to use as possible for a multitude of reasons (high adoption rate, greater system approval rating, technophobic teachers). Ajax (Garrett, 2005) is a collection of technologies that make web-based applications nearly as responsive as desktop applications. There is a PHP library for Ajax, called Sajax (”Sajax, simple Ajax toolkit”, 2005) that might work well for adding LD functionality to Moodle. An example of Ajax in action is provided by a map of Switzerland from Karte: Schweiz (2005). [paragraph above condensed]
6. Aim for simultaneous LD Levels A, B, C At least two points should be considered regarding LD levels. First, LD levels are a distinction for implementers, not users. They are levels of the effort to implement the related functionality, not levels of the complexity of the LDs that are created with a tool. This is not always the same. This can result in situations where you have absolute simple scenarios (from a teachers point of view), but you can not realize them on Level A, because you need, for instance, some properties. Second, when someone decides to start with a Level A implementation, this should be done with Level B and C "in mind". The implementation of the sequencing mechanism "acts" for instance will most likely be another one when you plan to extend it in the future with sequencing triggered by properties and conditions. Furthermore seems as if Level C (notifications) is necessary if an LD UOL is to be able to communicate with Moodle's database (e.g. for Gradebook purposes). It should also be considered that teaching, managing learning processes, learning etc is complex regardless of the setting (conventional or digital) and teachers are (need to be) familiar with this.
There is also a limit as to how far you can get reducing the complexity in the views of various stakeholders. So, we cannot exclude the possibility of Level B and C or some other complexity enhancing solutions becoming very feasible. Consequently we think it necessary to have a strategy to support, train and encourage teachers to make this transition into the new digital world. This will no doubt require time, resources and patience. Spreading the news and the facilities is an important additional task. We need a way to establish relations among activities and attach them with roles. Then we can export learning design elements under IMS Content Package called Unit of Learning (UOL = IMS Content Package + IMS Learning Design). Moving to Level B, with the Lesson activity module, we can employ conditions and direct learning by students' answers. Moodle should support IMS Simple Sequencing. The instructor will be able to set conditions and give appropriate learning activities based on learner portfolios. Looking at Level C, at the present, we cannot find any activities that supports notification. In Moodle, when someone completes an activity (with a certain outcome), another student or a teacher may be notified and start another activity (based on the previous outcome). [paragraphs need further editing]
V. Implications for Learning Design: Future versions Creating a universal learning design protocol called "Learning Design" is now and will continue to be in a process of development. Teacher practitioners such as those in the Moodle community are eager to contribute to this development because of their enthusiasm to share and exchange materials and designs. In this section, we shall outline some implications for the further development of Learning Design from this teacher-developer perspective as LD moves to become more widely accepted as a language of exchange. We will distinguish our discussion on three levels: 1) the concept or theory of LD, 2) the specifications of LD, and 3) the implementation of LD tools. Our apologies for misunderstandings or immature understandings as we try to grapple with the intentions and concretions of LD.
LD Theory: The conceptual framework of Learning Design is powerful and appears to hold the core requirements that users of Moodle value and require. It goes beyond single-learner-in- isolation standards, such as SCORM, to include collaborative modes of learning with flexible roles. The core principles or requirements are all in alignment with the principles that Moodle users would generally agree on. These eight principles defined by Koper (2005, p. 19) can be summarised as: * LD must be comprehensive: including objects, services, activities, roles, solitary/group models. * LD must support blended learning: face-to-face integration as well as pure online learning. * LD must be flexible: supporting all theories of learning, pedagogically neutral. * LD must describe conditions of learning: tailoring the design to specific learners or situations. * LD must stimulate reuse: portability, arrangibility, addition/subtraction of parts. * LD must be standardised: operate with other standard notations (i.e.: IMS-QTI) * LD must be automatised: provide a language for automatic processing * LD must be abstracted: for repeated execution in different settings and people.
While these core requirements provide an excellent framework for exchange of learning, questions have been raised as to the framework of LD's design methodology. Is LD not only pedagogically- neutral, but also design-process-neutral? Implicit in design of any learning activity is a epistemological question about the nature of design. The nature of design has been classically conceived in a pre-engineer and run paradigm. Diffusion models of innovation (Rogers, 2003) operate in a similar way. First, an innovator constructs a new design, and then the design is disseminated. Contrary to this is a translation/transformation model of innovation, that designs are co-created by environments and actors in a way that continually transforms the network of actions. The properties of the design itself are actually less important than the reconfigured network of actions in a learning community. This community-based, ecological paradigm of learning may be a theoretical concern that LD will need to wrestle with. The most common concern that facilitators in the Moodle community expressed was the pre-engineering mentality that they felt they were being forced into when working with Learning Design. The design-on-the- fly ability of the Moodle LMS was a critical attribute that no one was willing to part with. One commenter said he preferred "freedom from design" over "freedom in design". In other words, it might be productive to distinguish between to different types of 'design'--a conscious/explicit process of design and an unconscious/non-explicit mode of designing. The ability to design unconsciously is an inherent and useful practice that is embedded in the daily routine of teaching. In some ways, Moodle emulates this non-explicit design. It is still a debate as to whether this a theoretical problem in an LD paradigm or simply a practical issue shown in particular tools or specifications of LD.
LD Specifications: One question was raised about whether LD was sufficiently developed to handle all the social dimensions of learning in Moodle. For example, we noticed that two LD- related tools, LAMS and elive LD-Suite, had found it necessary to extend the specifications of LD to handle the complexity of groups in learning. However, in some cases we found LD to be very ambitious in some aspects of social learning. In Halm, Olivier, Farooq & Hoadley, 2005) we found the peer-to-peer model of collaborative learning to be beyond the boundaries of our current thought. If LD can accommodate that decentralised kind of learning, it should have little problem with the issues surrounding group organisation and operation. Another issue is that it is not clear where administration ends and learning services begin. Moodle has a rich set of student- monitoring services such as Gradebook, Activity Reports, Block Reports, Logs, and Portfolios that are an essential part of the learning environment. The configuration of these components leads to ultimate success of any UOL. Those configurations need to “travel” or be described with the UOL when it is packaged for exchange. Finally, in the book we found no chapters dealing with the question of exchange of UOL and specifications for repositories. Presumably, this issue was relegated outside the formal specifications of IMS-LD to the Digital Repository Specification (IMS, 2003). However, for teachers, the exchange of units, objects, and courses is the whole reason for moving to an international standard. It is imperative to outline the course/UOL metadata used for searching and define minimum standards that repositories can operate under. Thus IMS-LD and IMS-DRS need be presented and implemented concurrently for this specification to be welcomed by the teaching community.
LD Tools: The number of LD and LD related tools is growing rapidly. For Moodle users, LAMS is one of the most intuitive tools. With LAMS, teachers create a sequence of learning activities by dragging and dropping. Most other tools (i.e. Coppercore, Reload) are designed for users who know IMS LD concepts (play, act, role-part, etc) and may be more suitable for developers and designers than for normal teachers. LD tools should be more intuitive and easy-to-use so that non- technicians can use them to create and exchange UOLs. In addition, LD seems not to have a specific way to handle forums, but just makes a reference to it, perhaps so the LD package itself is not tied to any specific forum setup. Moodle allows a number of definable properties to forums, and the varieties of group process produced by these configurable rules can and should be modeled. In addition, Moodle has numerous ways of unstructured communication, not just of discourse text (wiki, blogs, instant messenger), but also structured data (glossary, blocks, database). New code may need to be written in LD players to make them operate smoothly with any forum-oriented LMS such as Moodle. Finally, tools for extracting, exchanging, and reconfiguring UOL and course files need to be developed quickly, because those kinds of tools will create a demand among teachers for exchange within the LD standard. [this section needs to be reorganized like Section IV—numbered implications, not categories]
VI. Conclusions This paper has been a practitioner review of the complexities of integrating the Learning Design concept, specification, and tools with an open source LMS, Moodle. We have attempted to view the two from an outsider perspective , though that may be impossible to avoid our Moodle-insider presumptions. The second section analysed essential differences, ....
[add numbered points of both implication sections]
VII. Acknowledgements Our sincere thanks for the following contributors and facilitators that made the Learning Design Book Study (March – May 2005) such a success. Gabriela Díaz Antón (Academia Interactiva) Bernhard Zech (elive LD Suite Project) Ernie Ghiglione (LAMS Project) Chris Kew (Reload Project) Dan Fleming (LD Book Study Facilitator) James Phillips (LD Book Study Facilitator) Dean Shankle (LD Book Study Facilitator) Martin Dougiamas (Moodle Lead Developer)
VIII. References Ajax (2005). retrieved May 24, 2005 from http://www.modernmethod.com/sajax/ Alexander, C. (1965) A city is not a tree”, Architectural Forum, Vol. 122, No. 1, April 1965, pp 58- 62 (Part I), Vol. 122, No. 2, May 1965, pp 58-62 (Part II). http://www.rudi.net/bookshelf/classics/city/alexander/alexander1.shtml Britain, S. (2004) A review of Learning Design: Concept, Specification and Tools. A report for the JISC E-learning Pedagogy Programme. Downloaded May, 2004. Bolton University (2005) The reload LD Player. Retrieved online on May 22nd, 2005 [http://www.reload.ac.uk/ldplayer.html] Ching, C. C., Hursh, A., & Scagnoli, N. (in progress) “Users and Producers: Constructivist Experiences with Open-source Courseware for Post-graduate Teacher Education” (contact Hursh for information). Chomsky, N. (1956). “Three models for the description of language”, IRE Transactions on Information Theory, 2 (1956), pages 113-124. Dalziel, J. (2005) From resuable e-learning content to reusable learning designs: Lessons from LAMS, retrieved May 7, 2005 from http://www.lamsfoundation.org/CD/html/resources/whitepapers/Dalziel.LAMS.doc. Dalziel, J. (2003) Implementing Learning Design: The Learning Activity Management System (LAMS) retreived May 7, 2005 from http://www.lamsfoundation.org/CD/html/resources/whitepapers/ASCILITE2003%20Dalzie %20Final.pdf. Dougiamas, M. (1998) A journey into constructivism. http://dougiamas.com/writing/constructivism.html accessed 14 May 2005? Dougiamas, M. (2000) Improving the effectiveness of tools for Internet based education Garrett, J. (2005) ”Ajax: A New Approach to Web Applications”. retrieved May 24, 2005 from http://www.adaptivepath.com/publications/essays/archives/000385.php Ghiglione E. and Takayama, Y. (2005) LAMS Foundation: IMS Learning Design, retrieved May 7, 2005 from http://users.ox.ac.uk/~jiscpub/JISC_TIP/documents/LAMS%20-%20IMS%20LD.doc. Graham, P. (2003). “Beating the Averages”, http://paulgraham.com/avg.html Halm, M., Olivier, B., Farooq, U., & Hoadley, C. (2005) Chapter 11. Collaboration in Learning Design Using Peer-to-Peer Technologies. In Koper & Tattersal (Eds.) Learning Design. Pp. 203-213. Berlin: Springer-Verlag. Hopcroft, J., Motwani, R., & Ullman, J. (2000). Introduction to Automata Theory, Languages, and Computation (2nd Edition). New York: Addison Wesley. IMS (2003) Digital Repositories Specification. http://www.imsglobal.org/digitalrepositories/index.html Jonassen, D. and Land, S. (eds.) (2000) Theoretical foundations of learning environments. Mahweh, NJ: Lawrence Erlbaum. Karte: Schweiz (2005). retrieved May 24, 2005 from http://map.search.ch/ Koper, R. (2005) Chapter 1. An introduction to Learning Design. In Koper & Tattersal (Eds.) Learning Design. Pp. 3-20. Berlin: Springer-Verlag. Koper, R. & Tattersal, C. (2005) Preface In Koper, Rob & Tattersal, Colin (Eds.) Learning Design. pp. v-xxvii. Berlin: Springer-Verlag. Koper, R. & Tatersall, C. (eds.) (2005) Learning Design: A handbook on modeling and delivering networked education and training. Berlin: Springer. LAMS International (2004) LAMS Brochure, retrieved May 7, 2005 from http://www.lamsfoundation.org/CD/html/resources/summaries/LAMS.Brochure.pdf. La Porte, T. (ed.) (1975) Organized social complexity: Challenges to politics and society. Princeton, NJ: Princeton University Press. Lévi-Strauss, C. (1962) ”The Savage Mind” Chicago, IL: University of Chicago Press. Moodle (2003) IMS Learning Design. http://moodle.org/mod/forum/discuss.php?d=3758 Moodle (2004a) SCORM content packages. http://moodle.org/mod/forum/discuss.php?d=1926 Moodle (2004b) Implementation plan for roles. http://moodle.com/development/plans/roles.html Moodle (2005a) Learning Design book study. http://moodle.org/course/view.php?id=44 Moodle (2005b) Future Versions of Moodle. http://moodle.org/mod/resource/view.php?id=3853 Noble, H. (2005) JISC: Tools Integration Project, retrieved May 7, 2005 from http://users.ox.ac.uk/~jiscpub/JISC_TIP/Index.htm. Olivier, B. and Tattersall, C. (2005) The Learning Design specification. In Koper & Tattersall (Eds.) Learning Design. Pp. 21-40. Orr, J. (1996) Talking about machines: An ethnography of a modern job. Ithaca, NY: Cornell University Press. Papert, S. (1980) Mindstorms: Children, computers, and powerful ideas. New York: Basic Books. Sloep, P., Hummel, H. & Manderveld, J. (2005) Chapter 8. Basic Procedures for E-learning. In Koper & Tattersal (Eds.) Learning Design. Pp. 139-160. Berlin: Springer-Verlag. Towle, B. & Halm, M. (2005) Chapter 12. Designing Adaptive Learning Environments with Learning Design. In Koper & Tattersal (Eds.) Learning Design. Pp. 215-226. Berlin: Springer-Verlag. Turkle, S. & Papert, S. (1992) Epistemological pluralism and the revaluation of the concrete. Retrieved 28 May 2005 from http://www.papert.org/articles/EpistemologicalPluralism.html Vogten, H., Tattersall, C., Koper, R., van Rosmalen, P., Brouns, F., van Bruggen, J., Sloep, P., & Martens, H. (2004) Implementing a Learning Design engine as a collection of finite state machines”. Preprint available at: http://hdl.handle.net/1820/96 Vogten, H. & Martens. H. (2004) CopperCore. Retrieved online on March 14, 2005 [http://www.coppercore.org]