We are exploring how best to package and deliver our SCORM content to customers running a variety of LMSs. One of the big considerations is management because our content only deals fall into three buckets:
A) Course content only (no tests or surveys)
B) Course content with tests
C) Course content with tests and surveys
Obviously the worst case scenario would be to maintain three copies of every course. Do you have any insight on how best to manage SCORM content with these goals in mind?
You have a few options for managing different versions of a course. Each option runs on a scale that has a trade off of elegance vs compatibility.
Before I get started, I'm assuming that your tests and surveys are in separate SCOs. Let me know if this assumption is incorrect.
The most compatible option would be the least elegant. As you mentioned, you could just maintain three different versions of the content. But that doesn't have to be as painful as you might think. What you really are maintaining is just three different versions of the manifest. All of the SCOs remain the same. You could have a central directory of your SCOs and then a script that picks them off and packages them accordingly.
Another option would be to just maintain three different copies of the manifest within the content directory. There can only be one file named "imsmanifest.xml", but you could have "imsmanifest-basic.xml", "imsmanifest-tests.xml" and "imsmanifest-testsurveys.xml". When you deliver the course, you just need to rename the appropriate one to "imsmanifest.xml".
The next option becomes a bit more elegant. It is correct SCORM, but you might run into some compatibility problems. If you look at a manifest file, you will notice that there is an <organizations> element that contains an <organization> element. An organization is what defines the structure of the course and which SCOs are included. SCORM allows you to define more than one organization element for precisely this use case...it lets you deliver different versions of the course within on package. On the organizations element, you can add an attribute that indicates which version is the default organization. You could deliver a package like that and just change the default organization for different versions of the course. Some LMS's even allow you to select which organization you want when importing a course (but not many). This is a nice simple option and if you run into compatibility problems, it is very easy to just delete the alternate organizations.
The final option would be to use SCORM 2004 sequencing rules to provide different paths through the content. This would require either that the learner make a choice of which path to go through or it would require that you chance a variable in the manifest for the different versions.
When it comes to SCORM Cloud, you are probably referring to our SCORM Dispatch functionality. Basically what that allows you to do is host a course in the Cloud and then create a tiny shell package that gets imported into your clients' LMS. That shell simply points back to the Cloud to deliver the content, and then through some cross domain hocus pocus reports the data back to the clients' LMS. There are a few big advantages to this solution:
1) You get to maintain control of your content and not send it out to clients. It stays on the Cloud server.
2) You can create different shell packages for each client and thus turn off access to clients who stop paying the bills.
3) You can take advantage of the Cloud functionality. This give you all the compatibility our SCORM Engine provides as well as all of the detailed reporting and tracking functionality. In other words, you can often give your clients more functionality than their existing LMS provides.
I hope this answers your question, let us know if you want to talk through them more.
Let us know if you have any questions!