|[ ASCILITE ]
[ 2004 Proceedings Contents ] |
This paper discusses a project which used investigated use of the SCORM model within the design and development process of high quality learning materials to explore its capability for supporting the reusability and interoperability of digital resources within the Australian VET sector. The paper describes SCORM and its potential advantages and discusses its retrospective implementation to the redevelopment of learning materials in the National Flexible Toolbox Project. The paper describes the process of applying SCORM to the development of an inquiry based set of learning resources and discusses implications for the design of reusable quality e-learning resources and learning objects using the SCORM model.
The prospect of the reusability of digital resources is very enticing for many stakeholders in education and despite the difficulties, interest and enthusiasm still abounds for this. In fact there has been a huge amount of work undertaken by a number of large organisations and groups to facilitate the reusability and interoperability of digital learning resources and this work has appeared to have removed many of the barriers which previously limited reuse of learning resources. The work being done to develop the Sharable Content Object Reference Model (SCORM) is a strong case in point. SCORM has been developed by the Advanced Distributed Learning (ADL) initiative and provides a design and development model for learning resources which strongly supports reusability and interoperability.
How does SCORM support these capabilities? The answer is in the way it has been developed. SCORM (the model) describes two main elements: a content aggregation model (CAM) and a run time environment. The CAM describes the ways in which SCORM materials are organised, described, and packaged so that they can be seamlessly exchanged between different learning systems. The run time environment provides the means for the learning materials to communicate with the LMS and for the collection of data to track and monitor learners.
Assets and SCOs are intended for reuse and are the building blocks of a Content Aggregation Package. They should be independent of learning context and intended to be subjectively small units, such that potential reuse across multiple learning objectives is feasible. The SCORM does not impose any particular constraints on the exact size of a SCO.
Given its characteristics, the term SCO is often used to mean learning object. There is not a universally accepted definition for learning objects, however there are a number of common themes.
Within the confines of this paper we refer to a learning object as "any digital resource that can be reused to support learning." (Wiley, 2000). This definition includes anything that can be delivered to a learner, be it large or small.
The adoption of the SCORM standard across the VET sector appears to offer the possibility to create, store, and disseminate reusable LOs in the form of SCOs. These SCOs could provide content developers and teachers access to existing learning content via digital repositories.
In this context Content Aggregation Packages comprise one or more SCOs or assets, that is one or more learning objects. They need to be structured in such a way that they are ready for delivery to a learner. This implies that Content Packages are not necessarily as reusable as SCOs, because they are associated with specific learning context information. They can still, however, be delivered via a SCORM compliant Learning Management System.
Having discovered these limitations, the team gave serious thought to exploring the prospect of increasing the reusability and interoperability of the future Toolbox products by using SCORM. The team was aware that while SCORM promised great opportunities for reusability and interoperability, the model had been developed primarily for learning environments based on linear and didactic learning designs.
One of the proponents and designers of SCORM, Dan Rehak, had commented earlier about this and indicated,
SCORM is essentially about a single learner, self paced and self directed. It has a limited pedagogical model unsuited for some environments." This is mainly a consequence of the needs of the main initiators of SCORM: the US Federal Government in general, and the Department of Defence in particular. Their needs are mainly in the area of training for specific systems and situations by people who are not generally in full time education. This need is addressed very well by the spec, but "SCORM has nothing in it about collaboration. This makes it inappropriate for use in HE and K-12. (Kraan & Wilson, 2002).
The Toolboxes have all tended to use contemporary learning designs based on knowledge construction (Oliver & Blanksby, 2003) and the comments by Dan Rehak were suggestive that these resources might be difficult to build with SCORM. As a trial activity to judge how SCORM might be applied in the design and development of Toolboxes, an activity was undertaken to produce a SCORM conformant Content Package using an existing Toolbox, The Grange Care Services. The purpose of this activity was to test the processes by which Toolboxes might be designed and developed using SCORM
Of the two available areas in the toolbox, we chose the Grange Home Care area to convert to a SCORM compliant Content Package. The Grange Home Care area consists of duty statements that cover each day of the week. Each day can have more than one duty statement, while each duty statement can have more than one task. This area also contains a resource library that contains: tests, links to manuals, policies and procedures in the form of word documents, and areas for discussion.
Figure 1: Grange Care Services front page
Before building the Content Package, we had to decide which html pages would be SCOs and which html pages would be assets. This meant choosing SCOs (i.e. learning objects) of a size and content that would make them optimally reusable and meaningful. According to the SCORM 1.2 standard, a SCO can be of any size and scope, as long as it is described by a resource element in a Content Package manifest file. Given the flexibility of SCORM, the onus of choosing the correct SCO size falls on the content developer.
The SCORM documentation does not provide any mandatory methods of deciding which learning resources are SCOs or assets. However, according to the SCORM, SCOs are intended to be subjectively small units, such that potential reuse across multiple learning objectives is feasible. When determining whether to make a resource a SCO or an asset, the content developer should consider the amount of material required to achieve the learning outcome, and the level of reuse to be obtained.
Any learning resource that is deemed a SCO must contain the minimum SCORM API calls to locate an LMS's API Adapter. A Content Aggregation provides content structure used to aggregate learning resources into a cohesive unit of instruction. The Content Aggregation provides the sequence in which learning resources are to be presented to the user. A Content Aggregation is often interchanged with the term Content Package. Technically, a Content Package is SCORM's mechanism for binding a Content Aggregation and metadata. A Resource Package is a Content Package without an organisation, in other words a Content Package that does not specify a sequence for the learning resources.
SCORM created SCOs must communicate with the LMS run time service using the LMSInitiliase and LMSFinish functions. This is mandatory SCORM behaviour. It is optional for SCOs to communicate with the LMS while being displayed using functions that get and set values. Any SCORM compliant LMS must handle these functions.
Figure 2 shows the navigation layout of Grange Home Care before conversion to the SCORM standard. We can see the navigation buttons on the left hand side. When moving to the SCORM standard, all hard coded navigation will have to be removed from our HTML pages. This ensures we do not include any links between SCOs.
Figure 2: Original Grange Home Care layout and navigation
A SCO may not assume that it will run in a top level window, or attempt to force itself to run in a top level window. This will have implications for many of the already produced toolboxes as they rely on having control of all surrounding frames for navigation. The idea behind this thinking is that a SCO can be launched without any prior knowledge of its surroundings.
Although the use of pop up windows is allowed within SCORM compliant SCOs, this behavior is discouraged by SCORM best practice (Ostyn 2001). SCOs are responsible for closing any pop up windows that are opened, before a SCO is unloaded. A SCO is not allowed to leave any trace of itself in the user's environment window after it has been unloaded. This implies that SCO developers using pop windows would have to write extra code to close all pop ups. This requirement, which would most likely be implemented in the form of client side scripts, could create compatibility problems.
According to SCORM, the general for creating manifests is that a package always contains a single top level manifest. This implies that a manifest file should be created for a stand alone SCO. However, when that SCO is part of a Content Package, a manifest file for the SCO is not necessary, since the SCO will be described within the top level manifest. There are still advantages to providing a manifest file for every SCO within a SCORM Content Package:
Figure 3: Grange Care Services toolbox layout
From a theoretical point of view, this is an ideal solution. By creating content packages at a low level, we have learning objects that are readily reusable, and because they are a content package they should be also be meaningful. Using the smaller content packages we create a larger content package that can be disaggregated by future users. Unfortunately, under the current definition of SCORM (1.2), the implementation for sub-manifest aggregation is awkward at best. While the problems are not explicitly documented in SCORM documentation, some include:
The efficient and obvious method for joining manifests would be if the top level manifest referred to a sub-manifest, in the same manner as a top level manifest refers to SCOs or assets. Unfortunately, under SCORM 1.2 and its underlying IMS Content Packaging Specification, one has to copy all sub-manifest information to the parent manifest. This requirement is counter productive as we have to produce a manifest file more than once. To get the same effect as aggregating sub-manifests, why not produce only one manifest that contains a number of nested SCOs? This has the same effect as combining several sub-manifests.
Figure 4: Multiple SCO layout
We had a choice to make, in that, should each day of the week be SCO? Given that a learning object should be reusable; would a SCO for each day of the week be reusable? For example, a collection of duty statements for Monday is only relevant to the set of circumstances for Monday. Given this, you would not expect an SCO for a particular day to be meaningful within a different set of circumstances and therefore reusable. Therefore we have not created SCOs for each day of the week.
The top level SCO is at the duty statements level. At this level, we know the circumstances for choosing duty statements and the context of those duty statements. For example, if certain tasks are chosen for Monday, at the top level SCO we can also see the tasks chosen for other days, which provides context.
To describe our content package we needed to create the top level IMSmanifest.XML file. There are three sections to this manifest: Metadata; Organisation; and Resource. Within the resources section we described SCOs and assets that comprise our content package. The navigation is defined in the organisation section.
Figure 5 shows the organisation section of our manifest within an XML editor. You can see that the SCO layout from Figure 4 matches the organisation section in the manifest. Figure 5 shows a subset of the resources sections within an XML editor.
Figure 5: Manifest resources section
Figure 6: Grange Home Care within a SCORM viewer
Technically, SCORM SCOs are joined together by defining items in the organisation section of the Content Package manifest file. The SCORM restricts sequencing embedded in content to exist only within SCOs - that is content from one SCO may not refer to content in another SCO. Sequencing between SCOs must he handled by an LMS and defined in the manifest file.
The LMS will control all SCO to SCO navigation. The order in which SCOs are presented to the learner is provided by the organisation section of the Content Package manifest. Typically an LMS will provide both a tree structure, and forward and next buttons for navigation. This means that a sequence of content will be presented and available, but the learner will be able to choose which learning objects to view and in what order.
While restrictive, there are several advantages to this approach:
The major disadvantage of content sequencing under SCORM 1.2 is what is referred to as the "glossary problem". The glossary problem describes the occurrence where a common resource is used throughout a Toolbox. Frequently, this common resource is a glossary.
In current Toolbox development, if a glossary is required, it is created only once, and all content within a Toolbox that refers to information from a glossary, will refer to a single copy of the glossary. However, under SCORM 1.2, you will need a copy of the glossary for each SCO you produce. This could get quite annoying for Toolboxes that lend themselves to reusability and foster large numbers of SCOs. The glossary problem creates two further problems:
The SCORM documentation defines the dependency element as one that "contains a reference to a single resource that can act as a container for multiple files that resources may be dependent on". Translated into technical terms, this means that you can:
We created an example Content Package where many SCOs refer to content within a single glossary asset. This Content Package has been tested and passed the SCORM ADLCP-PIF1 conformance test.
Figure 7 illustrates the layout of a Content Package where several different SCOs can access content from a single glossary asset.
Figure 7: Content package containing a glossary SCO
The first step was to create the glossary. Due to the technical implementation of SCORM we did not define the glossary as a SCO, but as an asset that contains a number of resources, namely html pages containing definitions. The glossary asset can be used by other SCOs. Unless we utilised the more elaborate elements of SCORM there was no disadvantage to treating the glossary as an Asset. The telling difference between a SCO and asset is that a LMS is not able to track an asset.
The products from the Series 7 National Flexible Toolbox project are all nearing completion and when this paper is presented at the Conference, there will be some examples of the SCORM compliant resources to show to delegates to further demonstrate the success of the project.
Advanced Distributed Learning (ADL) (2004). Sharable Content Object Reference Model (SCORM®) 2004 Overview. [verified 28 Oct 2004, menu] http://www.adlnet.org/index.cfm?fuseaction=DownFile&libid=648&bc=false
Brownfield, G. & Oliver, R. (2003). Factors influencing the discovery and reusability of digital resources for teaching and learning. Interact, Integrate, Impact: Proceedings 20th ASCILITE Conference (pp 74-83). Adelaide. http://www.ascilite.org.au/conferences/adelaide03/docs/pdf/74.pdf
Carnegie Mellon (2003). Best Practices Guide for Developers. [verified 28 Oct 2004] http://www.lsal.cmu.edu/lsal/expertise/projects/developersguide/index.html
IMS (2003). IMS Content Packaging Best Practice Guide, Version 1.1.3 Final Specification, June. http://www.imsglobal.org/content/packaging/index.cfm
Kraan, W, and Wilson, S. (2002). Dan Rehak: "SCORM is not for everyone". CETIS Discussion Article, CETIS, October. [verified 28 Oct 2004] http://www.cetis.ac.uk/content/20021002000737
Oliver, R. & Blanksby, V. (2003). Online learning designs in the training sector. Interact, Integrate, Impact: Proceedings 20th ASCILITE Conference (pp 364-374). Adelaide. http://www.ascilite.org.au/conferences/adelaide03/docs/pdf/364.pdf
Ostyn, C. (2001). Cooking up a Scorm. http://home.click2learn.com/standardswork/ [not found 28 Oct 2004; see http://academiaelearning.com/contenido/scorm/cooking/i_cookbook.htm]
Wiley, D. A. (2000). Connecting learning objects to instructional design theory: A definition, a metaphor, and a taxonomy. In D. A. Wiley (Ed.), The Instructional Use of Learning Objects: Online Version. [verified 28 Oct 2004] http://reusability.org/read/chapters/wiley.doc
Zhen Yin, Zhengfang Xu and Abdulmotaleb El Saddik (2003). Study of metadata for advanced multimedia learning objects. CCGEI 2003 Proceedings.
|Authors: Ralph Wirski can be contacted on firstname.lastname@example.org |
Grame Brownfield can be contacted on email@example.com
Ron Oliver an be contacted at firstname.lastname@example.org
Please cite as: Wirski, R., Brownfield, G. & Oliver, R. (2004). Exploring SCORM and the national flexible learning toolboxes. In R. Atkinson, C. McBeath, D. Jonas-Dwyer & R. Phillips (Eds), Beyond the comfort zone: Proceedings of the 21st ASCILITE Conference (pp.938-947). Perth, 5-8 December. http://www.ascilite.org.au/conferences/perth04/procs/wirski.html
© 2004 Ralph Wirski, Grame Brownfield & Ron Oliver
The authors assign to ASCILITE and educational non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The authors also grant a non-exclusive licence to ASCILITE to publish this document on the ASCILITE web site (including any mirror or archival sites that may be developed) and in printed form within the ASCILITE 2004 Conference Proceedings. Any other usage is prohibited without the express permission of the authors.