Picture this: you've just imported a brand new shiny piece of cmi5 content into SCORM Cloud, and you want to see what it looks like inside Rustici's content player. But you don't want to create a registration and take the assessments that are part of the course, and you don't care about any registration data being saved. How can you do this?

For other learning standards, you could simply use the API to make a preview launch link, but as some of our customers have noted, the launch fails for cmi5 courses (including media files) and you end up with an error message like the following:

In SCORM Cloud's logs, we see the following:

Reason: Registration must be provided for cmi5 package launches

What does this error message mean? Is there a way around it? Does Rustici have a plan to solve this problem? In this article, I'll help clear up some of the confusion around cmi5 preview launches, and outline our path forward to provide this service for our customers.

So why can't I preview cmi5 courses?

To answer that, we have to go visit the cmi5 spec, specifically the section about the registration requirement. One of the main aspects of cmi5 is that the learner is enrolled in the course inside the LMS, and that information is passed to the AU to be used in the statements that the AU sends back to the LMS. The LMS then uses the AU's MoveOn criteria to determine if that learner can progress through the course structure.

In SCORM Cloud (and its sister product, Rustici Engine), preview launches allow someone like a system admin to look at courses outside of the context of a learner, thus allowing that person to check for things like spelling errors or issues with certain course settings. Since the cmi5 spec doesn't have the concept of not having a learner, we can't launch the course without a registration like we do with other learning standards.

One of the main goals with our products like SCORM Cloud and Rustici Engine is to try and mask the differences between learning standards. We want you to be able to import, launch, and track your content in the same fashion regardless of if it's SCORM, AICC, cmi5, or any other learning standard. Because of this, we don't want our customers to have to do any extra work just to preview cmi5 courses.

What about the "Browse" launch mode?

For those savvy folks who dive even deeper into the cmi5 spec, you might notice that there is a "Browse" launch mode. The definition in the spec is this:

Indicates to the AU that completion-related data MUST NOT be recorded in the LMS using 
xAPI statements. When Browse mode is used, the AU SHOULD provide a user experience that
allows the user to "look around" without judgement.

This definition sounds really close to what we're looking for, but there are a few key differences.

First off, while "Browse" is a concept defined by the cmi5 spec, "preview" isn't, which makes the two mutually exclusive. Theoretically, a user may want to "Browse" a preview launch, or they may want to preview a "Normal" launch. Since the concept of "previewing a course" is something that we have defined across multiple learning standards already in our products, we can't technically build a preview implementation for cmi5 based on this launch mode.

Secondly, the "Browse" launch mode still requires a registration, and thus requires that immutable statements be written to an LRS endpoint. These statements are crucial to a cmi5 course, since they are what contain the data that would be shared across sessions for a given AU, or shares the data between AUs in a multi-AU course. Since preview launches don't use registration data, we can't have that data persisted in the LRS endpoint where regular registration statements are sent. So that leads us to our last idea.

Can't you use a disposable registration?

The short answer here is: "yes, we could." But there are a few things to consider that make this implementation a little tricky.

First of all, there's the issue of the statements getting into the main LRS. Since we want preview to act as if you're just checking a course for errors without the context of launching with a registration, we can't have any statements saved into the main LRS. Therefore we would need to send the statements to a "dummy" LRS endpoint that lives separately from the regular one, and it would contain all of the statements from these preview launches. Then users could preview more complicated courses that require state to be transferred, like a multi-AU course, but that state and those statements would not show up in any reporting that was built off of the main LRS endpoint.

Secondly, these disposable registrations would eventually have to be cleaned up to avoid bloat in the database. If we create a dummy registration for each preview launch, we'd have to delete it once it has finished the preview. However, determining when that data is "finished" isn't as easy to do in cmi5, since, as previously mentioned, some registration data needs to persist between cmi5 sessions. So to avoid this bloat, we would need to implement a background process that cleans up these excess registrations every now and then, but we still haven't figured out what the right way to do that is.

So when will this be ready for me to use?

As you can see from this article, implementing preview launches for cmi5 content is no small feat. This has been on our roadmap for a while, but as the adoption of cmi5 continues to increase, and the amount of cmi5 content available grows, this feature request gets pushed higher on our priority list. Since this is such a big haul to complete, we want to make sure that we think it through and implement it the right way. That means no surprises, a complete solution, and focus on ease-of-use for our customers.

As always, if you have any questions or concerns about this feature, or anything else, please feel free to reach out at support@rusticisoftware.com.