Showing posts with label SCORM. Show all posts
Showing posts with label SCORM. Show all posts

Saturday, March 15, 2008

Specifications and copyright

IMS Global Learning Consortium: Today the IMS Global Learning Consortium (IMS GLC) announced plans to initiate a pilot project in the distribution of interoperability specifications under a form of Creative Commons license.

There's a murky relationship between technical interoperability specifications and standard copyright. Here's an example.

Every SCORM-conformant content package needs to contain a set of W3C XML Schema documents. Since SCORM content packaging is derived from the IMS Content Packaging specification, one of these required documents is an IMS Content Packaging schema document, which contains an unambiguous IMS GLC copyright notice.

Based on this, it seems one could make a reasonable case that every SCORM-conformant content package is a derivative work, and hence an infringement of IMS' copyright.

Adopting a framework such as Creative Commons seems like a sensible way forward.

Thursday, March 6, 2008

SCORM and AICC compared

GerryWaz: Anyone know of a good, dispassionate comparison of the two standards? Strengths and weaknesses of each?

In matters of technology, newer is frequently equated with better. However, while SCORM is the newer specification and is more widely supported, there are valid reasons for using courses and management systems based on the AICC specifications.

Below are some points to consider when deciding between AICC and SCORM. (We consider only SCORM 1.2 and SCORM 2004, since earlier versions of SCORM are effectively obsolete.)

Packaging and deployment
Thanks to SCORM's well-defined packaging model, deploying SCORM courses is often as simple as uploading a zip file. Historically, deploying AICC courses involved more steps due to the lack of a similar packaging model for these courses. In late 2006, AICC published a packaging specification for AICC courses. However, this is still not part of the core AICC specification, so neither AICC-conformant courses nor AICC-conformant LMSs are required to support it. (EKP supports AICC course packages.)
Ease of development
SCORM-conformant courses communicate with an LMS by calling methods of a JavaScript object called the API adapter. AICC-conformant courses communicate with an LMS by sending HTTP messages to the LMS, and interpretting the LMS's responses. (This communication method is known as the HTTP AICC CMI Protocol, or HACP.) Where courses are developed without the aid of specialized course authoring tools, it's usually considerably easier to implement SCORM communication than AICC communication. (However, most specialized course authoring tools shield the developer from these differences.)
Technical requirements
A conformant SCORM API adapter must implement complex rules for validating tracking data and reporting errors and, in the case of SCORM 2004, for evaluating and enforcing sequencing rules and processing navigation requests. Because of this complexity, many robust implementations use Java technology to implement the API adapter, meaning that Java must be available on the user's machine. (Both EKP and ADL's reference implementations use Java to implement the API adapter.) On the other hand, since AICC courses use direct HTTP-based communication, LMSs typically don't require Java to track AICC courses. (However, the courseware itself might still require Java.)
Cross-site scripting
Cross-site scripting occurs when content loaded from one web site in a browser attempts to read or manipulate content loaded from another web site in the same browser. In general, cross-site scripting presents a security risk, and browsers rightly restrict it in most cases. However, these restrictions can also interfere with tracking of courses where the courses reside on a different web site from the LMS. The problem is usually more serious for SCORM courses than for AICC courses. As described above, SCORM courses communicate with the LMS using JavaScript calls, and these are almost always blocked when the course and LMS reside on different sites. On the other hand, due to the nature of AICC communication, AICC courses have greater choice about the specific technology used to perform the communication, and different technologies enforce different policies regarding cross-site communicating. For example, an unsigned Java applet may not communicate with a site other than the one from which it was loaded, but a signed Java applet may do so if the user explicitly grants permission. Even without the use of browser plug-ins such as Java or Flash, an AICC course can implement course-to-LMS communication (but not LMS-to-course communication) simply by using standard HTML forms.
Sequencing
The AICC, SCORM 1.2 and SCORM 2004 specifications all provide sequencing mechanisms—that is, mechanisms for specifying rules concerning the order in which independently trackable units of content can be delivered. (In SCORM terminology, these units of content are called shareable content objects, or SCOs. In AICC terminology, they are known as assignable units, or AUs.) However, only the SCORM 2004 specification requires the LMS to support these mechanisms. On the other hand, it's always possible to implement sequencing in a way that is internal to the SCO or AU. So this is only an issue if you aim to reuse SCOs/AUs at a level of granularity below the course level.
Internationalization
The polite term for the AICC specification's support for internationalization is “boneheaded .” In particular, the AICC specification specifically prohibits the use of Unicode character encodings (e.g. UTF-8, UTF-16), instead requiring the use of one of the ISO 8859 family of encodings. Whereas Unicode encodings support virtually all modern languages, the ISO 8859 encodings support only a very limited set of languages, with Asian languages being particularly poorly supported. (Chinese, Japanese and Korean are all unsupported for example.) There's no good reason for this restriction, and in practice many systems "extend" the AICC specifications to support other encodings. (For example, EKP supports a wide range of encodings beyond the ISO 8859 family, including both UTF-8 and UTF-16.) However, a further problem is that the AICC mechanisms provide no clear way to specify which encoding is being used, so trial and error is often necessary in order to ensure non-English text displays as intended.

Friday, January 18, 2008

Tips on integrating Articulate-created content with an LMS

On Articulate's Word of Mouth Blog, Gabe Anderson has posted a useful checklist of things to look for when integrating Presenter- or QuizMaker-created content with an LMS.

Sunday, April 15, 2007

Batch importer for SCORM courses

EKP has long featured a batch importer for AICC-conformant courseware. Starting with EKP 4.7, the importer also supports SCORM-conformant courseware.

To use the batch importer, you'll need to create a new zip file that contains the individual SCORM content packages. (IMS content packages will work too.) Since these content packages are themselves zip files, you'll have a zip file that contains multiple individual zip files as entries. Then, go to Manage > Catalog Manager > Import Content Package, select the zip file you created, and click the Next > button.

EKP will display a summary of the courses that will be imported, and will walk you through the various import options. Just follow the on-screen instructions. (The process is pretty much identical to the AICC batch import process.) And, if you make a mistake, there's also a batch delete function that you can use to undo your changes.

Wednesday, February 28, 2007

Why does my SCORM course display an "Unable to find an API adapter" message?

When a SCORM course is packaged in a zip file (sometimes called a PIF, which stands for Package Interchange Format), the package needs to contain a manifest file named imsmanifest.xml. This file is used by delivery systems such as EKP to understand the contents of the package.

A SCORM course contains one or more resources (roughly speaking, the "lessons" in the course). In SCORM 1.2, each resource is either a sharable content object (SCO) or an asset. A SCO is specially designed to communicate with a learning management system (LMS)—for example by informing the LMS about the learner's test scores or other progress information—which it does using JavaScript calls. On the other hand, an asset is not specially designed to communicate with an LMS—essentially, it is just regular web content.

The manifest file contains information about each resource, together with an indication of whether each resource is a SCO or an asset. A typical XML element for a resource might look as shown below.

<resource identifier="R1" type="webcontent" adlcp:scormtype="sco" href="sco01.html">

Note the adlcp:scormtype attribute. There are two possible values for this attribute, sco and asset, corresponding with the two resource types described above. If the type is specified as sco, EKP will provide a JavaScript object called the API adapter, which the SCO can use to communicate with EKP. If the type is specified as asset, EKP assumes that the resource is not designed to communicate with an LMS using JavaScript, and therefore does not provide the API adapter. (Instead, EKP provides a button labeled Mark As Completed, which the learner can use to indicate that they have completed the activity.)

In particular, note that if the adlcp:scormtype attribute is omitted, EKP assumes that the resource is an asset, and therefore does not provide the API adapter.

If you see an error message that reads Unable to find an API adapter or similar when launching a course that has been imported from a content package, it might be that either the resource has incorrectly been tagged as an asset, or the adlcp:scormtype attribute is missing entirely. In this case, the problem can be fixed by manually editing the imsmanifest.xml file to include the correct attribute values for each resource.

There's one final XML technicality to be aware of. In order ensure that the attribute name adlcp:scormtype can be understood without ambiguity by an XML processor, it's necessary to ensure that the XML file contains a namespace declaration that corresponds with the namespace prefix adlcp. This declaration takes the form of an XML attribute that is usually placed on the root element of the file. The attribute is as shown below.

xmlns:adlcp="http://www.adlnet.org/xsd/adlcp_rootv1p2"

The initial opening tag of a manifest file that contains this attribute might look as shown below.

<manifest identifier="M1" version="1.1"
    xmlns="http://www.imsproject.org/xsd/imscp_rootv1p1p2"
    xmlns:adlcp="http://www.adlnet.org/xsd/adlcp_rootv1p2">

Monday, February 19, 2007

Why doesn't the Exit button in my course work?

This is an area where the courseware standards (SCORM, AICC) don't really correspond with real-world usage.

According to SCORM, exiting a course is considered a navigation event and so should not be invoked by the course itself—only the run-time environment (typically LMS) is supposed to control navigation. This is related to the SCORM philosophy of "reusable objects"—if an content object (SCO) contains a button that closes the window then it's making strong assumptions about where it will run (i.e. in a separate window rather than as part of a larger course) and hence is less reusable. So if one were to follow SCORM to the letter then the course should not have an Exit button at all.

In reality almost nobody does it that way—having an Exit button is a very common requirement.

EKP typically launches courses inside a frameset—frames are used for navigation, and a "hidden" frame is used for the SCORM API adapter. That's why window.close() won't work—it tries to close the frame rather than the top level window. If you use window.top.close() instead it should work in EKP. (Note: the name of the window object in JavaScript might be misleading, as it can refer to either a frame or a top-level window.) But there's no single method that's guaranteed to be 100% portable across LMSs, even if they are SCORM- and/or AICC-conformant.

Sunday, February 18, 2007

How do I enable Java tracing on a client machine?

When investigating issues related to SCORM courseware tracking, NetDimensions support staff might sometimes ask you to enable Java tracing on the client machine. Enabling Java tracing causes information about API calls made by the course to be written to a trace file on the client. The steps below describe how to enable Java logging when using Sun Microsystems' Java Runtime Environment (RTE).

  1. Open the Java Control Panel. (On Windows, this can be done by going to Start > Control Panel, and double-clicking the Java icon.)
  2. In the Java Control Panel window, click on the Advanced tab.
  3. On the Advanced tab, expand the Debugging item by clicking on the plus sign icon.
  4. Ensure the checkbox labeled Enable tracing is checked.
  5. Click OK.

By default, the trace file is written to the <user>\Sun\Java\Deployment\log directory on Windows. Sun Microsystems' web site has more information on Java tracing and logging.

Note that the information written to the log file is generally the same as is available in the Java console. However, unlike the console, the information in the log file is still available after a browser restart or browser crash.

Tuesday, February 13, 2007

What is PENS, and when should I use it?

Starting from version 4.5, EKP supports the Package Exchange Notification Services (PENS). PENS enables one-click publishing of courses from a PENS-conformant authoring tool or LCMS to EKP. Note that PENS is not a format for learning content like SCORM or AICC CMI001. That is, by itself it does not define any formats or protocols for course catalog metadata, course structure, course/LMS communication, or sequencing. PENS simply defines a way for a publishing tool to notify a delivery system (LMS) that new content is available for collection. The relevant content is still transferred using an establish format such as SCORM or AICC packages (most commonly the former).

So PENS is not an alternative to, say, SCORM content packages. Rather, it simply eliminates the step of manually exporting a content package from the publishing system and then importing it into EKP. Note that if your workflow requires you to make use of the packages (e.g. you need to manually modify the packages, or wish to archive them outside of EKP) then it's probably not appropriate to use PENS.

Tuesday, February 6, 2007

Can I create a custom Table of Contents for a multi-SCO SCORM course?

A SCORM-conformant course contains one or more Sharable Content Objects (SCOs). A SCO is defined as the smallest unit of content that can be independently tracked by a SCORM-conformant run-time environment (i.e. an LMS). Although it's quite common for courses to be built using only a single SCO, this post concerns courses that are built using more than one SCO.

Where a course contains multiple SCOs, it needs to be set up in EKP in such a way that EKP is aware of the individual SCOs. Normally this happens automatically if the course is imported from a SCORM content package, as the imsmanifest.xml file in the package tells EKP what it needs to know about the individual SCOs. (If necessary, the same thing can also be accomplished manually using the Courseware Manager, by creating a separate lesson for each SCO and setting the Run-Time Environment for each lesson to "JavaScript API".) When the course is set up in this way, EKP provides navigation controls that learners can use to navigate between the SCOs. (If the course is built using only one SCO, these navigation controls are redundant and do not appear.) In this way, EKP can keep track of which SCO the learner is currently attempting, and can ensure that any progress information communicated by a SCO is associated with the appropriate SCO in EKP's records. EKP can also "roll-up" progress information from each lesson to provide overall progress information for the course.

However, this only works if EKP's own navigation controls are used to launch the SCOs; it won't work if you attempt to create a custom Table of Contents page and link to the individual SCOs from there. This is because EKP is unable to keep track of which SCO the learner is currently attempting—and, in fact, EKP is unaware that the course contains multiple SCOs. Any progress information communicated by an individual SCO will therefore be interpreted as course-level progress information; so, for example, when an individual SCO reports that it is completed this will be interpreted as completion of the course as a whole.

The solution is to avoid using a custom Tables of Contents for multi-SCO courses. Instead, import the course using the original content package, and ensure that the learner navigates between the SCOs using the navigation controls provided by EKP. (On the Navigation Setup page in the Catalog Editor, you can configure for each individual multi-SCO course whether EKP displays the top navigation frame only, the left navigation frame only, or both frames. You can also customize the look-and-feel of EKP's navigation controls by creating a courseware template and uploading it under Manage > Courseware Manager > Courseware Template Editor.)