This is the second of two posts on current use of standards and specifications for practical eLearning.
Practical work with IMS-LD
As we have indicated in Part 1 (posted on September 20th), IMS-LD helps to define the pedagogical processes; that is why we focus on IMS-LD. The pedagogical processes will usually be based on resources. A teacher will usually create a lesson plan (on paper, or mentally), which can be synonimous of a path for the students, using some readings, images (in general, resources), putting some questions, …
When this is clear and settled, the practical work usually takes the inverse order. First, the resources are individually gathered; and then integrated in the path.
Let us start then with the resources.
General indications for learning resources
- Documents used in learning resources should open in a Web browser
- The best format to use is HTML, as
- it is simple to edit with free tools (such as Mozilla)
- it will open in freely available browsers
- it is very compact
- An alternative is PDF, this is
- useful if you want your document to be read only
- easy to open in a web browser
- Sound
- Compression in order to have small files is always an issue which is important to consider.
- While wav/aiff is a standard, it is usually not compressed, and, perhaps, it is recommended to use mp3 (which is a part of an audiovisual standard called MPEG), as it is currently widely used; other formats which open in most browsers could be an alternative.
- Graphics/Still images
- Compression in order to have small files is always an issue which is important to consider even more than for sound.
- The best format to use is JPG / JPEG, as it is both a standard and widely used; according to the quality required, the size of of the image will be big (for highest quality) or small (for lowest quality). Gif is also widely used on the web for graphics, although it is a proprietary format; SVG has been recently proposed by W3C, the Web consortium.
- Video
- Compression is even more important for video, in order to have small files.
- The recommended format is mpeg, which is standard (although there are different mpegs), although Real, QuickTime, Windows Media usually open in most browsers - these are formats, and can use different compressors, which sometimes is difficult to deal with.
In summary resources should be created in the most standard format, which can usually done with free tools; the way to check this flexibility is that resources should open in different Web browsers.
General indications about creating UoLs
Once the resources are around, a UoL can be created, according to the lesson plan envisaged. This requires an IMS-LD editor. As we have indicated, Reload is the reference editor for IMS-LD. Let us mention that there are other editors, which are special for IMS-LD such as ASK-LDT; or modified to use LD (MOT+, and current work for the well known Moodle …). Some of the editors that are appearing are more user friendly than others (for instance, ASK-LDT is a graphical one, although it does not cover the whole specification, as Reload does). As we indicated in our previous post, current Pompeu Fabra University work about to be released includes an easy to use IMS-LD editor based on templates, Edubat. Let us mention the related work Collage.
Other aspects to be considered are:
- Packaging of files
- Units of Learning developed using IMS-LD have to be distributed using IMS Content Packaging, which is a zip file with a manifest describing the contents.
- Tests and assessments
- If you want to include a test or assessment in your Unit of Learning to be run by the computer, it is convenient to use QTI, which is the corresponding IMS specification; the alternative being tests or assessments that open on browsers.
- Services such as e-mail, chat, forums … are part of the IMS-LD environments
- They are very useful for the pedagogical path in e-Learning.
- You can include some of them using the IMS-LD editor.
- Metadata is ‘data which describes other data’
- There are standards for general document metadata, , such as the author, the subject …, the main one being Dublin Core or eLearning specific: IMS Learning Object Metadata.
- Availability of metadata can be very useful in locating resources, but it can also be time consuming for users to provide the necessary information to describe the learning resources.
- One can (and should) add basic metadata about the UoL created, by means of the editor; the metadata is kept inside the IMS-LD xml document itself (the manifest)
- It is also a good idea to use Dublin Core in the HTML of theresources (there is a metadata tag, which, again, remains hidden when browsing)
- One could optionally add more metadata using LOM, either in the IMS-LD manifest, or in the Content Package.
Running eLearning
This is not very user-friendly now.
Before a UoL run, one has to assign the users the different roles that might have been defined in the UoL (and to this UoL, of course). Currently, there is a DOS command line tool (CLICC) provided by OUNL. Pompeu Fabra University is close to release a friendlier tool.
The e-learning running needs a Web server with the addition of CopperCore, an alternative being SLED (which includes CopperCore); where of course the UoLs should be stored and managed - as the tracking of the run. Again, Pompeu Fabra University is working on a tool for this management.
The OpenDock project is establishing a repository of UoLs which can be run easily.
September 25th, 2006
This is the first of two posts on current use of standards and specifications for practical eLearning.
Introduction
Our previous post Building user friendly software for interoperability specifications was taking the point of view of addressing developers of interoperable eLearning software.
In this post we address a teacher’s perspective: what if a teacher wants to use some interoperable tools and create some interoperable learning?
We provide a short and basic introduction to eLearning standards and specifications; and we indicate basic things on creating or reusing resources and their integration into interoperable eLearning, specifically, Learning Design.
What are “standards” and “specifications” for interoperability
A specification for interoperability defines a format which enables different applications to import and export documents (this capability of importing and exporting is interoperability). The best known specification is HTML, which is a format for documents on websites which can be opened in any browser, in any computer. HTML was developed by Tim Berners-Lee, and it has been used by nearly everyone who wants to exchange documents on the Web; this makes it a de-facto standard. HTML is also now a standard, because it has been approved by the International Organization for Standardisation, one of the bodies which is authorised by national governments to create official standards.
Are eLearning interoperability specifications useful?
The Web has shown the advantages of interoperability: when somebody creates a web document s/he knows that everybody will be able to browse it with whatever computer at home, at an internet café, on a mobile phone, … The value is in the document and it is very reusable. The interoperability specifications which the Web is built with are a great help in eLearning, but there is also a need for additional specifications focused on eLearning, which give the same advantages to the users. This will avoid that a change of eLearning software will require the change of the content, which will be very painful for teachers or students.
On the other hand, there are quite a few eLearning aspects which might require specifications. For example, eLearning content providers want to be able to send packages of content which can check that all the materials are present in a directory structure. This is the purpose of IMS Content Packaging. Other specifications are used to define tests, or learning activities. Some of them are discussed below, mainly, Learning Design.
Who defines eLearning interoperability specifications?
Anyone can define an eLearning interoperability specification. The difficult part is getting agreement from the eLearning community to adopt the specification. The organisation which has had most success in persuading users to adopt their specifications is IMS, who have developed a series of specifications. These have been adopted by developers and users to varying extents. Some of them are very recent, and this might be a reason for not being yet widely adopted.
Currently, the documents which conform to these specifications are mostly written in XML, which is a somewhat more evolved HTML. These documents are usually hidden from the user, just as the user does not usually see HTML when surfing the Web. Special tools should be provided in order for end users to create/edit eLearning documents (just as a range of applications is available to edit HTML documents).
What is SCORM?
SCORM is the best known application profile in eLearning, and was defined by ADL (and funded by the American Department of Defence). An application profile does not specify a document format, but rather the functionality which an application must have if it is to conform to the profile. In this way content and course developers can be sure that target systems will be able to run their products.
SCORM stands for Sharable Content Object Reference Model. SCORM is a collection of standards and specifications adapted from different sources. Many of the specifications were developed by IMS, for example Simple Sequencing (SS), Question and Test Interoperability (QTI), and Learning Object Metadata (LOM). SCORM was originally intended for use by single learners working without a teacher, but it can of course be used as the basis for other activities too.
What is “Learning Design”; editing and running Units of Learning
The general concept of learning design refers to the way in which a teacher plans the flow of activities to be carried out by learners in the educational process. IMS has developed a specification called IMS Learning Design (IMS-LD) which provides a formal language modelling these pedagogic processes. It aims to be able to model any pedagogy, and is able to represent the activities to be carried out by the teacher and learners. It does this by setting out how people in roles carrying out activities with resources in an environment composed of learning resources and services.
Using IMS-LD authors can develop Units of Learning (UoL), which should be educational processes meaningful in themselves. A UoL is created (by a teacher) by means of an editor. Reload is the reference editor for IMS-LD. These UoLs are, technically, IMS Content Packages, which means they are zip files containing a directory structure of files, which follow the specification IMS-Content Packaging. The parallel with the HTML documents of the web, is that the documents are created with an editor such as FrontPage, or Mozilla, …
Students can follow UoLs, and teachers can keep track of what students are doing in a UoL: the UoL is said to be running when this happens. The UoL will be run in a player application, in a similar way as we need a browser (such as Explorer, or Firefox) for viewing HTML documents created with an editor. This player application can coordinate the learning activities, ensuring that the right resources and instructions are sent to the right people at the right time, and that their interactions are synchronised (besides keeping track of the interactions). The reference player application of IMS-LD is CopperCore.
Part 2 will be published next week.
September 20th, 2006
