These interactions all work on the same principle.
- Detect the SCORM runtime version.
- if it's 2004, only use the API to read and write data.
- if it's 1.2, use the internal shim to read and write data.
- The 'shim' fingerprints the user/content/course and write/reads data from an external server
- It stores a lookup table of interaction ids in the
cmi.commentsfield. - It stores the user response on an external server
- It stores a lookup table of interaction ids in the
- Tell Scorm 1.2 about a public URL where the data is stored (for reporting / backend analysis)
Generic interactions
Interaction zips are all generic, and use a configuration object passed in my Mighty to set up specific behaviours. This is the window.riseSCORMBridgeConfig object, described in detail in the Token page.
External data security
User Data is served in files hosted on a server accessible from the internet. The data is stored on Amazon S3 storage in private buckets. Filenames are all hashes generated from the user/content/course and can't be reverse-engineered to reveal personal details.
Code implementation
Each interaction is a standalone iframe with several files:
- index.html contains the markup for the interaction
- app.css contains the layout/colour information
- app.js contains the interaction-specific code
the app.js references files externally hosted on a CDN.
- riseSCORMBridge.js core library
- scormFallbackAPI core SCORM library. Supports scorm1.2, scorm2004 and no-scorm (using session storage)
- utils.js support library
The app also requires a global object to be set - window.riseSCORMBridgeConfig which is done by Mighty.