Replace SCORM with xAPI

[liveaspankaj]

Hi @jonopoltrack

I want to know if this can be used to covert SCORM to xAPI content, instead of additionally sending xAPI Statement.

There are many who want to host SCORM content on an xAPI platform like on WordPress using our GrassBlade xAPI Companion plugin. And, it can be done one if the SCORM requirements are removed.

Pankaj

[jonopoltrack]

Hi Pankaj -

This sure can be updated for your use case. Basically, in the wrapper file, there are calls to the SCORM API that could be removed. I can provide specific details on this (or add comments in the code) if you think it would be valuable.

For example in SCORM1.2/APIWrapper.js the following line (#143) could be commented out - var result = api.LMSInitialize("");

This removes the call to the SCORM API. There are several other situations like this that would need to be removed.

I did leave in those calls so that the SCO could run in an LMS as expected -- and the LMS would behave as expected. For example, if the LMS was sequencing between SCOs, and it needed a score to determine what was next, it would be important for the LMS to have that data -- so I left the SCORM tracking in for that purpose.

However, if you're taking SCOs out of the LMS and launching them on another platform, there is no reason you couldn't remove the SCORM calls and only do xAPI using this wrapper.

I hope this helps.

[liveaspankaj]

Won't the package just want something to run the SCORM features?

SCORM packages generally are looking for an LMS. And without that they will start giving errors.

Regards,

Pankaj Agrawal

On Fri, May 6, 2016 at 1:33 AM, jonopoltrack notifications@github.com wrote:

Hi Pankaj -

This sure can be updated for your use case. Basically, in the wrapper file, there are calls to the SCORM API that could be removed. I can provide specific details on this (or add comments in the code) if you think it would be valuable.

For example in SCORM1.2/APIWrapper.js the following line (#143) could be commented out - var result = api.LMSInitialize("");

This removes the call to the SCORM API. There are several other situations like this that would need to be removed.

I did leave in those calls so that the SCO could run in an LMS as expected -- and the LMS would behave as expected. For example, if the LMS was sequencing between SCOs, and it needed a score to determine what was next, it would be important for the LMS to have that data -- so I left the SCORM tracking in for that purpose.

However, if you're taking SCOs out of the LMS and launching them on another platform, there is no reason you couldn't remove the SCORM calls and only do xAPI using this wrapper.

I hope this helps.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/adlnet/SCORM-to-xAPI-Wrapper/issues/5#issuecomment-217262413

[jonopoltrack]

There is a long, complicated, answer to this question, but I'll try to sum it up quickly.

The LMS "understands" the structure of the content and how it is to be sequenced. So, for example, if there is a table of contents that is structured into lessons/chapters/modules, etc -- the LMS renders this based on the entire package. If you move the individual course pieces to a different site, you would manually have to structure the course (and sequence it, and provide navigation controls) since the LMS was no longer in the loop. The wrapper DOES NOT handle anything at the SCORM package level, only the run-time environment (which is scoped to the individual SCO-level). So to sum up, if you moved your SCOs to Wordpress and built a table of contents or a next button or whatever to sequence them, then you don't need the LMS for this part.

The run-time environment is where things get sketchy, but you can use the conversion wrapper to help. Generally, when a SCO runs outside of an LMS, it will result JavaScript errors since the API instance the LMS provides is not there. This is what a was referring to in my last response. If the original content uses the APIWrapper, you can replace it with the one in this Github repo and then comment out the LMS-specific lines, leaving only the xAPI stuff. It is a little bit more complicated than that because the content current gets the users ID from the LMS and uses that as the actor (and there are a few other things like this) - so those items would also need to be updated to get the Wordpress users (or to support cmi5 launch, etc).

If your content did not use the original SCORM APIWrapper.js file, it is still possible to use this solution, but its a bit more complex than just swapping in a new APIWrapper.js file.

I hope this helps.

[liveaspankaj]

I can only say that it is: "Interesting" ................... and complicated. :)

Regards,

Pankaj Agrawal

On Mon, May 9, 2016 at 8:07 PM, jonopoltrack notifications@github.com wrote:

There is a long, complicated, answer to this question, but I'll try to sum it up quickly.

The LMS "understands" the structure of the content and how it is to be sequenced. So, for example, if there is a table of contents that is structured into lessons/chapters/modules, etc -- the LMS renders this based on the entire package. If you move the individual course pieces to a different site, you would manually have to structure the course (and sequence it, and provide navigation controls) since the LMS was no longer in the loop. The wrapper DOES NOT handle anything at the SCORM package level, only the run-time environment (which is scoped to the individual SCO-level). So to sum up, if you moved your SCOs to Wordpress and built a table of contents or a next button or whatever to sequence them, then you don't need the LMS for this part.

The run-time environment is where things get sketchy, but you can use the conversion wrapper to help. Generally, when a SCO runs outside of an LMS, it will result JavaScript errors since the API instance the LMS provides is not there. This is what a was referring to in my last response. If the original content uses the APIWrapper, you can replace it with the one in this Github repo and then comment out the LMS-specific lines, leaving only the xAPI stuff. It is a little bit more complicated than that because the content current gets the users ID from the LMS and uses that as the actor (and there are a few other things like this) - so those items would also need to be updated to get the Wordpress users (or to support cmi5 launch, etc).

If your content did not use the original SCORM APIWrapper.js file, it is still possible to use this solution, but its a bit more complex than just swapping in a new APIWrapper.js file.

I hope this helps.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/adlnet/SCORM-to-xAPI-Wrapper/issues/5#issuecomment-217882833

[jonopoltrack]

Pankaj -

I'm happy to provide more details if you're planning to do this implementation. Due to the complexity - it will require a thorough (and probably lengthy) write-up. If you're interested in this let me know.

JP

[liveaspankaj]

Hi JP,

I guess we should have a call to discuss, if possible.

Regards, Pankaj Agrawal

On Tue, May 10, 2016 at 4:58 PM, jonopoltrack notifications@github.com wrote:

Pankaj -

I'm happy to provide more details if you're planning to do this implementation. Due to the complexity - it will require a thorough (and probably lengthy) write-up. If you're interested in this let me know.

JP

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/adlnet/SCORM-to-xAPI-Wrapper/issues/5#issuecomment-218130780

[christophercorr]

Hi @jonopoltrack

Could you let me know if you got any further with this discussion. We would be interested in getting the scorm to xapi wrapper working without an LMS.

Chris

[jono-poltrack]

Hi Chris -

Happy to discuss. Ping me on Twitter at @adljono and/or watch ADLNet.gov for new resources (and potentially webinars,etc) on this topic.