General Problems
It's important to note if you are using the full SCOBot package, it is locating the LMS Runtime. All to often the rest of your page is in the process of loading, and in some cases if you don't wait for the 'load' event from SCOBot, you may end up in an out-of-order situation. Do not begin to communicate with SCOBot until 'load is fired. Typically, its recommended you do not initiate your content presentations until that occurs, or create some management to make sure it occurs. This includes plugins, or other presentation technology like WebGL, Canvas etc ... The Asynchronous nature of loading assets and resources is fine, but in this case, your presentation is relying on a prepared connection to the LMS Runtime, just like it may rely on external data (JSON, XML, CSV or otherwise).
Not all features and functionality of SCORM are apparent. All to often this leads to proprietary decisions being made, and in turn making your content less portable. Research what it is that needs to be built, and if SCORM fits your use case. Just like you'd review any other technology, know that SCORM is entirely a string based communication model using JavaScript, and there are read/write, as well as character limits within the specification.
Typically when building several presentations you may want to chain them together to create a single SCO with many 'pages'. Another approach is to build single pages out and let the LMS manage it. This is an important distinction since the approach for presenting multiple pages within a SCO requires the use of AJAX, or a IFRAME/Frameset. Since the Content API connects to the LMS Runtime, loading and unloading individual pages will cause you to have to keep invoking and locating this runtime API, and would require to you maintain when to exit and terminate. Once the Runtime API is terminated, you cannot reconnect to it and start making requests again. A LMS Player is typically a navigation hierarchy (tree, or tabs/sub tabs). It can also be something custom like accordion or dropdown boxes. LMSs commonly launch SCOs in IFRAMEs or new windows, tabs or popup windows. This is necessary since they are interactive standalone web pages. A SCO Player typically includes next, previous and other options much like a video player would. The theme, layout and navigation is entirely custom and its support for mobile or other screen sizes rests entirely on the not only the SCO's support, but also the LMS which is commonly housing it. The portability of the SCO is of great importance, as all necessary files need to either be fully qualified or apart of the package.
Protocol-relative paths is where you opt to ship with a protocol free script or asset reference. If you package up the QUnit tests and they all point to http and serve the SCO on a https connection any CDN or media server request will fail. Switch the paths to "//" vs "http://" and now it will work for http and https. However, now locally this will fail because it's looking for file:// and these files aren't locally. Things to keep in mind.
Any HTML links possibly used by bootstrap buttons or other, may cause a '#' to get tacked on to your SCO. This can often cause a false positive and may cause your SCO to terminate due to the unload event firing. Workaround:
e.preventDefault(); // in button click function/eventThe LMS had a HTTPS / SSL and it was reported on IE 8. There are some documented issues with the cache header in this situation. Common fix, is to correct the servers headers. Documented link - no-cache issue via HTTPS/SSL
ActiveX Filtering can prevent it working. More on this here
It was spotted that certain legacy mozilla deployments were having issues with the JavaScript event 'on unload' firing on the body tag. SCOBot shifts this to 'window' instead, but for IE 8 'document' is used for reliability. This is now managed through SCOBotUtil.js, and is baked in if you use the full SCOBot package. This is a fairly popular issue with other libraries.
In order for some legacy LMS systems to attempt to research who/what is calling the SCORM API/API_1484_11, they make this reference. With the compiled SCOBot packed or minified code this will fail. Work around would be to download the source code, and remove the "use strict"; statement from the function objects. See
Strict Mode.
SCORM 1.2 uses a single 'lesson_status' which comprises of 'passed, failed, completed, incomplete'. Due to this, some LMS systems will not mark the SCO completed as a result if the last status was 'passed'.
Utilizing file types like JSON on a legacy system may pose an issue. Because of this it's normally recommended you use '.js' vs '.json' to keep your compatibility/portability up. You may even be using a RESTful API which speaks JSON and when you request the file it causes issues. These area all issues that occur server-side so they may be more challenging to get fixed.
This has happened a few times on platforms and it makes it harder for your find API algorithm to locate the intended SCORM version. Normally, a platform should only expose the API that in intends to conduct communication on normally based on how the content was packaged. However, some shortcuts often get made and you may need to actualy force your SCO to only look for a specific version of SCORM.
Also noted are several platforms which added SCORM 2004 support by name only. They created the API_1484_11, but whats underneath it all has the substance of SCORM 1.2. You may suddenly find yourself unable to exit a SCO in 'normal' mode, terminate. Only to return and it keeps loading your old attempt. You may even find other behaviors that differ from the specification.
This commonly occurs on some platforms that have implemented a non-cached Student Attempt via the Runtime API. The end result can commonly be an hour glass or beach ball spinning with no real reason why you can click on buttons or scroll. This video dives a bit more into it at a high level.
Non-Cached essentially means every get/set is making a round trip to the server which is highly latent and can hurt the students user experience. Your platform team may ask you to stop making so many calls to SCORM. This is simply a sign they are almost being hit with a Denial Of Service attack on their server due to how they implemented the SCORM Runtime.
Aside from how the SCO->LMS->Server communicates, there is the fact that every time the SCO calls 'commit' the LMS is suppose to save the current student attempt. You normally won't know how the LMS is doing this, but SCOBot has latency detection and you can request scorm.checkLatency() to get a average latency between commits. SCOverseer bookmarklet will also represent latency.
There was no exposed method of finding out how many times the content has been launched. So people took extraordinary measures to try to support this use case. But what is an attempt anyway? An attempt occurs from the time the SCO initializes in normal mode (vs. browse or review) until it Terminates with a exit type of "", "normal", "logout" or "timeout". If it exists with "suspend" it is still the same attempt, resumed at a later time.
For SCORM 2004 it went as far as trying to create a global objective, which to most is considered a dark art. It's a more difficult task trying into the Sequence & Navigation spec of SCORM 2004, and when you're attempting to move over a larger Table of Contents becomes a bit more problematic. There was also Shared State Persistence, which if supported by the LMS may be a place to track this. But it was an add-on to SCORM and is a somewhat rare feature.
Cookies, Local Storage are all single machine based approaches. If your student uses multiple computers, they won't be able to rely on it.
So within the content some have used the option of creating a retry button and not setting the exit type to "normal" until the student hits a "finish", "done" or certificate page. This allows you to internally track and also score adjust the student based on the number of times they hit retry. You'll lose the historical nature of the attempts the LMS was tracking, but you'll gain the use case you were seeking.
This also leads us to another common issue...
There are platforms out there that do not offer the student the option to retry. This is an unfortunate admin level activity that requires you to email, phone or beg your teacher to allow you another attempt. Content can often be part of the problem, but it can also be part of the solution. Many times while debugging content, it exits in 'suspend' mode. But, the content didn't offer any ability to re-take the activity, quiz or exam. There are reasons why allowing the student to keep retaking content is undesirable, but there are the occasional reasons it should be allowed. Those may require the occasional pleading with your teacher. If the content was authored in a way that its default exit type is "suspend" and you fail the attempt, you can no longer change your score or outcome. You are stuck on the score review page, and the LMS looks at it as "in progress" with a 33% failing grade. Some platforms went to the extent of putting a "done" button on the Table of Contents so you could signify you were finished. Ultimately, you may need to evaluate the content to find out how you can set the exit type to 'normal' or '' on the final page, or allow the student to re-take the activity.
Wider reports of a single empty objective being present when a Shareable Content Object first starts. After looking into the issue its unclear why certain platforms do this. It commonly goofs up the objective count and auto-score feature within the SCOBot API. Currently, the only way to work around this issue is to review this with the Platform to find out if they can fix it. Reviewing other options for detecting and ignoring the roque objective.
SCORM's portability goals does not necessarily mean you have to keep replicating all your shared files from SCO to SCO. The process of packaging your content means you have to come up with new publishing models to consider taking advantage of CDNs, or static content servers to host these files. It is highly probable when dealing with JavaScript frameworks/libraries that each SCO would have this code nested in it. This causes the student to have to keep downloading the same files over and over again. Another way to handle this would be to take advantage of the "common files" so they are all added to the imsmanifest.xml to allow all SCOs to access them. Obviously, you can't always rely on access to CDNs either due to network constraints or otherwise, but this is a good thing to consider when designing your publishing options.
Often content implementations use other SCORM libraries or frameworks, and each implementation is unique. Due to this, there are challenges troubleshooting what the content is communicating and when and how it choses to communicate it. There have been implementations that specifically check for SCORM Error codes and if they don't receive the right error code, the content breaks. This typically requires evaluation of the JavaScript and if you are unfamiliar with this, you'll often need assistance to debug and correct the issue. SCOBot has been used in conjunction with weak or limited designed SCORM implementations to mimic the original functionality, but expand the capabilities as well as support SCORM 1.2 and or SCORM 2004. All without re-coding. This assists in the conversion or converting SCORM 2004 to SCORM 1.2. Converting from SCORM 1.2 to SCORM 2004 will typically require a converter since SCOBot speaks SCORM 2004, with rollback to 1.2 support. When used in conjunction with the SCOBot Packager, this allows you to quickly make necessary edits/file replacements and bundle the content for the desired delivery version.