Feature Wiki

Information about planned and released features

Tabs

Native HTML5 SCORM Offline Player

( also known as 'SCORM Offline Player 2' or 'SOP 2' )

1 Initial Problem

When planning the implementation of the first ILIAS SCORM Offline Player in 2011, browser's native support of storing huge content and data was unsuitable especially on mobile Android devices. Therefore we decided an implementation based on a Firefox extension that supports nearly all operation systems (Windows, Linux, OSX and Android) except iOS.

Unfortunately, Mozilla decided to restrict the support of required features like file system access for their next generation of WebExtensions (Needham, 2015). This will freeze our SCORM Offline Player to older Firefox versions.

2 Conceptual Summary

The improved browser support of native HTML5 offline-caching and web storage features in the last two years leads us to re-assess this technology for the implementation of a new ILIAS SCORM Offline Player. A feasibility study (see below) has been made to illustrate the various issues of a native HTML5 approach.

Feasability Study of a Native HTML5 ILIAS SCORM Offline Player

Summary of the feasability study

  • We need a replacement of our firefox based SCORM-Offline-Player (sop) because Mozilla restricted the support of required features like filesystem access in newer firefox browsers
  • Meanwhile the HTML5 features will be suitable for storage management of offline tracking and runtime data the main issue for this study was to figure out the potential of HTML5 AppCachefor storing the SCORM content.
  • We implemented a mockup for testing several os and browser versions and SCORM content sizes up to 200 MB
  • Based on the depicted facts we are reasoning that a SCORM-RTE based on a native HTML appcache and web storage is realistic and feasible
  • With a first approach we want to replace the underlying firefox technology with a HTML5 based player and storage components.

Workflow for users to export data & content and to import data (in german)

3 User Interface Modifications

3.1 List of Affected Views

  • Learning Module SCORM » Settings

3.2 User Interface Details

There are no user interface elements or screens which should be changed. In the first step the workflow of accessing the Learning Module SCORM and the workflows of exporting or importing the tracking data are the same as developed for SOP1.
In the future there might be an additional workflow to access the Learning Module SCORM without explicit export or import of tracking data. But this workflow is not well defined until now.

3.3 New User Interface Concepts

Like SOP1 the HTML5 ILIAS SCORM Offline Player has a component to display Learning Modules in the Offline Mode: The SCORM Offline Manager (SOM). The SOM is completely Client-based. Users can see

  • which Learning Modules are available for Offline-Use
  • the learning progress of each Learning Module
  • some tracking data for each Learning Module
In SOP1 the SOM was displayed at browser-start automatically in a separate tab.  The SOM in HTML5 ILIAS SCORM Offline Player takes specific ILIAS-clients into account which could be accessed via a specific URL, e.g. “https://host/ilias_webroot/Modules/ScormAicc/sop2/manager/som.html”. The URL could be bookmarked or set as an (additional) browser-start-page.
In the future it might be necessary to adjust the layout/skin of the SOM in the Administration interface of ILIAS. It would be useful to change e.g. the logo. We believe that new user interface concepts should be aligned with the development of ILIAS Apps.

4 Technical Information

The SOP is established in ILIAS since version 4.4 and the HTML5 ILIAS SCORM Offline Player has changes only on the client-side to avoid the Firefox extension. There are no new or modified dependencies on other ILIAS components and modifications in general services / architecture are not necessary. We can’t see any potential security issues.

The major changes for the new Offline Player affect the storage of data and content. Regarding the storage of data there are challenges especially for SCORM2004 synchronizing tracking data with ILIAS. Regarding the storage of content, the concepts of webcache and service workers differ and are evaluated differently depending on the browser. We favor service worker as a long-term concept, but it might be necessary to use specific Apps for iOS or Appcache-fallbacks / polyfills (https://github.com/eqsoft/jakecache) et cetera if there will be no general consensus about webcache vs. service worker.

Like with potential all offline components there are challenges to keep the learning progress up to date – or to communicate that the learning progress for a specific situation could not be determined. If there are more ILIAS components, which support offline handling too and have effects on the presentation of the learning progress, a general offline flag might be useful in the presentations of the learning progress. Since the SCORM Offline Player is used especially in situations, where the offline status of the users is known by the tutors et cetera, it is actually in our opinion not necessary to mark the offline mode in all presentations of the learning progress. At the learning module itself, the tutors et cetera can see, who uses the offline mode – and they can stop the offline mode for example if the device with the ‘offline’ tracking data is no longer available.

In the future we want to establish a special offline mode with offline storage of content but without an explicit export or import of tracking data. If it is actually not possible to synchronize the tracking data with ILIAS, the tracking data should be stored in the browser. If the SOM (or an ILIAS app) could establish a connection with the ILIAS client, the tracking data should be synchronized automatically. We expect two decisive advantages for scenarios with unstable internet connections:

  • higher usability because nearly no SCORM authoring tools export learning modules which give feedback to the users if the storage of tracking data was not successful
  • advantages for performance in general and especially for SCORM learning modules which often consist of a lot of small files. The amount of server requests could be reduced noticeably especially if the ILIAS web access checker is activated.
Also it should not be necessary to implement different players for special offline scenarios. We should integrate the explicit, implicit and pure online processing of SCORM Learning Modules within one general player component.
We hope the code could be used in further offline-scenarios

5 Contact

6 Funding

If you are interest in funding this feature, please add your name and institution to this list.

7 Discussion

Kunkel, Matthias [mkunkel], March 24, 2017: I changed the feature's title from 'SCORM Offline Player 2' to 'Native HTML5 SCORM Offline Player' because this label gives a clearer impression of the feature.

Killing, Alexander [alex], 25 Mar 2017: Thanks to Stefan and Uwe, this is great stuff. Two questions:

  • Do you have more info on the service worker approach? Beside its current limited browser support, do we have an idea about it's site limitations? The better control of multiple caches would definitely be an advantage, right?
  • I hope it is feasible and possible to generalise a lot of code in a way, that other components can support offline handling, too. E.g. in the current approach lots of the sop2.js code seems to be general cache handling code. What do you think?

Schneider, Stefan [sschneider], 18 May 2017

HTML5 Caching Storage for (SCORM) static content
A realy good overview about service worker support and size-limit-quota:
https://www.html5rocks.com/en/tutorials/offline/quota-research/

Summery:
Most browser are supporting a customizable quota limit for the global cache size, the limits should be comparable with the AppCache results of our feasability study. There is a special quota-api defined in the W3C ServiceWorker spec which will allow the processing of eviction events in future implementation. Unfortunately the quota-api and other api‘s around offline handling are work on progress. Persistent and temporary storage requests will be possible.
https://www.w3.org/TR/quota-api/#quota-management-api

AppCache vs serviceworkers
An easy work around may be the usage of sopmething like jakecache which implements an AppCache like wrapper for dynamic usage of serviceworkers and if not supported (like in any webkit based browsers) uses an AppCache fallback.
I forked the jakecache repo for posting pullrequests:
https://github.com/eqsoft/jakecache
other resources:

https://developers.google.com/web/updates/2016/06/persistent-storage
https://developer.chrome.com/apps/offline_storage

HTML5 Storage of runtime data (trackingdata, management of offline learning modules etc.)
There are well defined webstorage api‘s and we are confident that a pouch db wrapper will fit our needs:

https://pouchdb.com/


Synergies to a general offline concept for other ILIAS components
Its early days yet to look ahead the range of offline-caching features defined in the W3C spec that browser will support in the future. We should discuss this issue especially against the background of an intended ILIAS App.

JourFixe, ILIAS [jourfixe], May 22, 2017: We highly appreciate this promising and ambitious suggestion and schedule the SOP2 for ILIAS 5.3.

8 Implementation

Video about the implementation in english language
Video about the implementation in french language

Test Cases

Test cases completed at {date} by {user}

  • C18756 : SCORM Offline-Modus eines LM aktivieren
  • C18757 : SCORM Offline LM starten (direkt aus ILIAS nach Export)
  • C18758 : SCORM Offline LM starten (vom SCORM-Offline-Manager)
  • C18759 : Import der Lernstandsdaten in ILIAS
  • C18760 : Testen der Lernstandsdaten
  • C18761 : Administration des Nutzer Offline-Status

Approval

Approved on August 28, 2017 by Kunkel, Matthias [mkunkel]

Last edited: 8. Apr 2018, 21:53, Kohnle, Uwe [ukohnle]