Techniques for saving data and importing data from learning objects

Instructional designers and content developers often request that learning objects be allowed to save and import data. This functionality is, however, currently not allowed by TLF's Technical specification for content development .

This short paper describes the requirements for importing and exporting data from learning objects and issues restricting its implementation. The intended audience is TLF content developers and the TLF Exchange Consultative Committee. The purpose is to stimulate discussion about other possibilities for saving and importing data from learning objects.

Uses for import and export functionality

Learning object designers and developers often request the ability to save and import data from a learning object. Common reasons for requesting this functionality include:

1. Saving student outputs such as reports, documents and pictures that are created by a student while using a learning object. The outputs can then be re-used in other activities (e.g. imported into a document).
2. Saving state, such as a student's location in a learning object. This allows the student to stop their current interaction and return to the same point in the learning object at a later stage.
3. Communicating between learning objects by saving some information from one learning object and importing it into another learning object.
4. Configuring a learning object with new data. For example, importing new statistical data into a learning object about statistics.

Technology issues

The application formats defined in TLF's Technical specification for content development use browser plugins to display content on the end-user's computer. For example, Flash content is displayed using the Flash Player browser plugin.

TLF specifies use of browsers and plugins because are easier to deploy to classroom desktops than standalone applications. They do, however, place technical limitations on successful implementation of the import and export requirements described above.

Browser plugin security

Browsers and plugins implement strict 'sandbox' security models to protect the integrity of end-user computers and the privacy of users.

A sandbox restricts the operation of a plugin to protect operating system data and user data. Sandboxes restrict, or even disallow, the ability to write to a local disk. This prevents the plugin from corrupting data on the user's computer. Sandboxes also define which parts of the local disk the plugin can read from. This protects the user's private data from being read by the plugin.

A sandbox also defines a limited space on the network with which the plugin can communicate. Sandboxes typically restrict a plugin to communicating with only the network host which served the content to the browser. This prevents the plugin content from uploading or downloading data from un-trusted sources.

Flash

Macromedia Flash Player has a sandbox security and privacy policy that restricts the ability to read and write data . Flash objects running in Flash Player cannot read or write arbitrary local files. Flash Player only allows limited local file storage using 'SharedObjects', which have the following restrictions:

• SharedObjects can only be written to a specific directory on the user's computer. The developer cannot control that directory.
• The data stored on the local file system is a binary format determined by Flash Player.
• By default, SharedObjects are limited to 100K in size.

This means that it is not possible to use Flash to achieve requirements (1) Save student outputs and (4) Configuring a learning object with new data because the SharedObject format cannot be written or imported by other programs.

Although it is technically possible to use Flash to achieve requirements (2) Saving state and (3) Communicating between learning objects, there are restrictions. Firstly, the data must be small (less than 100k). Secondly, since state can only be saved to the user's computer, it also requires the user to use the same computer next time they interact with the learning object. This is not always a realistic classroom scenario: Many schools have classroom or laboratory computers that are shared between students. In these schools it is difficult to guarantee that a student will be able to access the same computer at a later date.

Director

Macromedia Shockwave Player runs Director Objects in a safe mode that restricts the ability to read and write data . Safe mode does not allow the object to read or write files on the user's local disk. There are two exceptions:

• to get or set preferences, or
• to read files that are stored in a folder named dswmedia, which is a subfolder of the folder containing the Shockwave player.

This means that it is not possible to use Shockwave to achieve requirements (1) Save student outputs, (2) Saving state, or (3) Communicating between learning objects because they all rely on saving data.

It is, however, possible to achieve requirement (4) Configuring a learning object with new data with Shockwave by reading data from the dswmedia directory on the user's computer. This relies on the user placing a configuration file in the dswmedia directory and correctly naming it so the Shockwave object can read it.

Java applets

Normal (unsigned) Java applets have a sandbox security policy which prevents them from reading and writing files on the client file system . This means that (unsigned) Java applets cannot meet any of our requirements.

One way around this restriction is to 'sign' applets with an identity marked as trusted in your browser's certificate database. This requires the applet developer to digitally sign the applet and the user to accept the applet signature. For example, running a sample signed applet from Sun MicroSystems website displays the following to the user:

Signed applets can read and write to the user's file system, allowing them to meet all four of our requirements.

NB: there may be some issues regarding cross browser support for the Java Virtual Machine (JVM). In particular, future versions of Internet Explorer may no longer fully support the JVM security model.

Technologies outside TLF's technical specification

SCORM run-time environment

The Sharable Content Object Reference Model (SCORM) Run-Time Environment (RTE) describes a mechanism for allowing data exchange between a learning object (a sharable content object in SCORM terminology) and a Learning Management System (LMS).

The SCORM RTE includes data elements for tracking learner experience with learning objects. In particular, there are data elements which could be used to implement some of our requirements:

• cmi.comments_from_learner communicates text comments made by the learner. This could be used to implement requirement (1) Save student outputs for text-based student outputs.
• cmi.location indicates the learner's location within the object. This could be used to implement requirement (2) Saving state.
• cmi.launch_data allows initialisation of the learning object with configuration data. This could be used to implement requirement (4) Configuring a learning object with new data.

The SCORM RTE has not been designed to implement communication between learning objects. The run-time environment would need to be extended to implement requirement (3) Communicating between learning objects.

Use of the SCORM RTE to implement these requirements assumes that learning objects are launched from within a Learning Management System that implements the SCORM RTE. TLF's Technical Specification for Content Development currently does not require that learning objects are launched from an LMS, let alone an LMS with the SCORM RTE. Very few Learning Management Systems are currently deployed in Australian and New Zealand K-12 classrooms.

Standalone applications

TLF's Technical Specification for Content Development is focussed on learning objects that launch through web browsers and plugins. An alternative is to consider learning objects that are standalone applications. Standalone applications can easily read and write files.

Standalone applications are more difficult to install than browser applications because they may fall outside of jurisdictions' standard operating environments. Additionally, they would have to be built using cross-platform technologies such as Java or as Office documents containing input and output macros.

Summary

The reasons for saving and importing data into learning objects are compelling: allowing student outputs to be saved, allowing learning objects to remember a student's progress across sessions, allowing learning objects to communicate with each other, and allowing learning objects to be dynamically configured with new data by a user.

None of TLF's current learning object technologies can easily implement all of these requirements. For this reason, proposals to develop learning objects that can save and import data will be considered on a case-by-case basis. Any such proposal would need a detailed explanation of how the learning object can save and import data and still meet TLF's technical specification.