Along with the content interface APIs it includes a light offline or non-LMS mimc of the LMS Runtime. This enables you to see tracing of the LMS communication if it was present. This may save you time debugging issues.
What does this solve?
Many examples online are somewhat limited. This project made a effort to better support Objectives, and Interaction capabilities with friendly easy to use APIs. Much of the timestamps, durations, and SCORM formatted responses needed a single point of management vs. having it scattered throughout a project. The specifications range in the hundreds of not thousands of pages of reading, parsing and interpreting which also leads to months of lost development.
SCOBot Content support:
https://github.com/cybercussion/SCOBot/wiki - Please refer to this for much more detailed information.
Feel free to email or post any issues you run into.
You may be looking for the LMS Runtime API_1484_11, and this Project does not offer or include that. The light mimic that is included IS NOT a runtime. Its just the bare essentials to let this run on itself in a offline capability. The low-latency Runtime is available on https://cybercussion.com (Free for students) but licenced commercially.
- Save you time trying to support the SCORM Standard. Yes, its Initialize, Get Value, Set Value, Commit, and Terminate on the surface, but it goes way beyond that.
- Educate - Examples, concepts, options
- Modernize - No one likes 500 global variable constants coupled with endless other issues associated with un-managed code.
- Transparency - Know why something isn't working, and have logging to back it up.
- Test - Drove the whole project with unit tests against the specification. Scenarios, make having a complete test impossible. Which is why there is always room for more testing.
About the Project:
I've kept this project split up into 4 logical portions, leaving room for anyone to add or subtract from the complete package. The main focal point would be 'QUnit-Tests/js/scorm/', as the surrounding files are simply supporting files like JQuery, QUnit, and further README files. I've also added all the files that go into a Content Aggregation Model. This is a package used to export your content to a learning management server. The portions of this project is split into the following sections:
Now no longer requires jQuery in v4.x.x.? So where's the code?
I know not everyone is using jQuery, and we needed to be sensitive to that. Turns out this project was only using about 9KB (actual) of jQuery. (Migration covered on Wiki)
- QUnit-Tests/js/scorm/SCOBotBase.js (Required in a deployment)- This is now expanded to backwards support SCORM 1.2 with some warnings and limitations. Will connect to API or API_1484_11 supported by a LMS that hosts SCORM content. This is the core LMS API lookup, and switchboard used to talk to the Runtime API on the LMS.
- QUnit-Tests/js/scorm/SCOBot.js (Optional in a deployment)- This is the automatic sequenced out SCORM calls commonly used. Supports and boils down some of the more complicated parts of the standard by supporting time stamps (UTC/GMT), duration/latency, formatting interaction info, objectives and rolled up scoring if you choose. You must inform SCOBot how many interactions you have in order for it to caclulate score. Otherwise, you need to write your own score management internal to your SCO. Also supports timed (max time allowed) instances.
Standalone, Local or Offline failover
QUnit-Tests/js/scorm/SCOBot_API_1484_11.js (Optional in a deployment)- This is the LMS mimic capability for local testing (non-LMS). May save you some round trips testing out SCORM Calls, or may even allow you to support taking your content offline or running in a non-LMS fashion.
Also have now added a minified, or packed version of all 4 of these files in a 39KB easy to use single file for those not doing there own builds. See the scorm.bot.pack.js which is only the 4 above files merged, minified and packed.
If your testing a LMS, feel free to edit the imsmanifest.xml to fit your needs. Change the tests to match your launch parameters or launch data. These tests are not meant to remain static. Make it fit your needs.
qunit_SCOBotBase.html - This will run a series of 90+ tests against SCORM which include some local debug, gets and sets as well as classic Initialize, GetValue, SetValue, Commit and Terminate. Even some illegal calls. This whole package is great to run on a LMS to view if the LMS is compliant with SCORM. The test for this is found at 'js/test/scobotbase.js'.
qunit_SCOBot_dev_full.html - This will run through a series of 230+ tests rolled up common functionality that pelts the SCOBotBase with all the calls, stressing out the Interactions, Objectives, Suspend Data functionality. This will continue to grow, as I expand the tests to include proper and improper data formats.
So why do some tests fail?
Some are cosmetic (date differences between browsers), launch data or values that were written for something used vs. where it is now deployed or packaged. Comment out any tests you aren't using, modify the data its comparing to get your test(s) passing.
What else do you need?
HTML, Flash, Unity... you name it. Presenting your training may require you to construct your own player. This can mean loading, templatizing, blending views and data. Building out interactions, layouts etc ... You could be doing this by hand or using a CMS.
Packaging and or Zipping - You may find once you have SCOBot, plus your presentation you need to now bundle it. The files in this project were meant to assist you here getting a full scope of what needs to be done to make that successful. See the Wiki for more info on zipping/packaging options.
I also recommend trying out a bookmarklet I made to check the status of a content object running on your LMS. SCOverseer - see the Bookmarklet button on that page (drag it to your bookmarks bar). Directions on page.
Thanks for taking the time to take a look, and thanks to everyone that's assisted with feedback.