I'm in the process of implementing an xAPI extension into adapt. In talking with Dennis I realized that it'd be great to get input from the community on how you all think an xAPI extension should work.
Let's use this forum to aggregate all the thoughts and see if we can come to a conclusion.
Thoughts, comments, critiques, all welcome!
I'd had an idea that you'd be able to set a 'verb' for pretty much any object within Adapt, based on events generated by that object
Ideally we'd be trying to tie these into Adapt events somehow so work may be required to expose these
For example, you might have:
"set 'launched' on 'started' event of contentObject 'co-05'"
Am I right in thinking that xAPI and SCORM can be used together? If so, I guess Adapt should support this.
I have to say, my grasp of xAPI is not great, it may help for you to give the core team a bit of a run down as to what sort of thing is typically done?
xAPI and SCORM can be used together. One of the examples that ADL put together sets up a SCORM to xAPI wrapper. Another extends this to allow SCORM content and LMS to take advantage of xAPI stuff. For example, a query of how many folks answered a question a certain way, to shape presentation of the content.
Most of the solutions I've seen with both standards have been more like an adapter rather than dual functionality.
As you described above:
I'm not sure of an instance where you'd want both SCORM and xAPI functioning at the same time. (ie sending SCORM tracking to an LMS AND xAPI statements to an LRS). That being said, I'm open to ideas on how it would be useful.
The use case I've seen articulated is for folks that are stuck with a legacy LMS but want to extend and take advantage of xAPI features. So if an organization has found an LMS that fits their business processes and have spent time linking competency structures, for example, they might want to (or need to) stick with the LMS for awhile. The mix allows for extensions that the LMS simply doesn't support while retaining the system they selected (or might be stuck with.)
SCORM to xAPI wrapper:
https://github.com/adlnet/SCORM-to-xAPI-Wrapper
This presentation from ADL describes a continuum.
http://www.adlnet.gov/wp-content/uploads/2014/12/PlugFest-Scorm-to-xAPI-PDF.pdf
SCORM > SCORM + xAPI (LMS Centric) > SCORM + xAPI (LRS Centric) > xAPI & TLA
This is similar to how I pictured things after talking with Dennis.
My original thought was that the accessed, launched, completed, etc. would be hidden from the users and then we'd automatically used the verb "viewed" for each section of the course.
Ideally, we'd still set those by default, but then allow an override (for more advanced users). Something with a dropdown of verbs and text input for the object.
Happy to do an xAPI intro session. I'll also dig up some links and post them somewhere The gist is that statements are formed with the following formula <actor> <verb> <object>. John viewed 'Intro to xAPI'.
I do have a blog post with a mini-course introduction to xAPI (done in Storyline... sorry) but I don't know if it's appropriate to put such link in this forum... if anyone wants it, let me know.
I'm not sure if it will help but ADL has written some things about how to report/encode SCORM data in xAPI.
xAPI SCORM Profile http://adlnet.github.io/xAPI-SCORM-Profile/
This profile gives guidance on how to report and encode SCORM data as xAPI Statements. It's useful if you want to move SCORM tracking to a more accessible API like xAPI.
SCORM to xAPI Wrapper https://github.com/adlnet/SCORM-to-xAPI-Wrapper
The wrapper is based on the xAPI SCORM Profile. It can be used as a replacement for the old SCORM APIWrapper.js and basically encodes the SCORM data to xAPI Statements and sends them to an LRS. You could look at that to see how we're doing things.
The overarching idea is coming from our view of the SCORM + xAPI Roadmap - the possible ways to migrate from a SCORM environment to an xAPI environment more gradually. http://adlnet.github.io/SCORM-to-TLA-Roadmap/
I think the one that is closest to some of the ideas here is our "Phase 1", where there's still an LMS managing content and users, but there's a side channel that's reporting those same SCORM events (and possibly more) to xAPI.
Anyway, hope some of this is useful.
tom
I have an interest in xAPI as well. I mentioned to Brian Quinn that I might be able to somehow contribute about this. I've given some thought to this, but I haven't been able to sit down and think 'seriously' about it... so, I'm not at a point where I can even think about code (still trying to familiarize myself with Adapt and the code etc. ... I'm not a Node guy, so there's some learning curve there...)... But, David, if you have started working on it, I'm looking forward to seeing what you're doing or how you want to go about it. I do have some thoughts ... but they're pretty high level at this point.⋅
I'm not sure about thinking of xAPI as something similar to SCORM... they're different things. In some regards, there are important conceptual differences, which -I think- will make the implementation of xAPI in Adapt challenging (and interesting, of course!). I'm looking forward to this!⋅
Here's a great resource for learning xAPI: http://learnxapi.com/resource-library-2/
Updated instructions on how to install the adapt-tincan plugin here: https://github.com/LearningPool/adapt-tincan
Feel free to install it and provide feedback.
Also, if you're looking for a free LRS, LearningLocker (http://www.learninglocker.com) is awesome! If you are looking for something with limited setup (and free), check out SCORM CLOUD (http://scorm.com/scorm-solved/scorm-cloud-features/).
Feel free to ask any questions!
I wrote a new extension, related to this...
I had an itch for a tracking extension that could give me some flexibility to track what's going on as a learner uses a course, but not necessarily using xAPI. However, at a wider level, I was interested in xAPI too, and this forum conversation about xAPI was starting to take place.
At the same time, I wanted to learn about Adapt development, so I spent time studying adapt-tincan and adapt-contrib-Spoor, until I understood to some extent how these things work.⋅
So, long story short, one thing led to another, and I've ended up implementing what I think is a fairly flexible and "extensible" tracking extension, that does xAPI, but allows other tracking scenarios as well. It's here, in case anyone wants to take a look:
https://github.com/Acutilis/adapt-trackingHub
I wrote a fairly detailed Readme to try to explain my reasoning behind what's been done and how it's been done...
As I said, this kind of happened at the same time that the xAPI conversation emerged, and then the adapt-tincan extension was released. But I needed some time to organize my thoughts around xAPI and tracking in general -I had no idea if I'd be able to develop anything. Needless to say that studying what others have done in adapt-tincan and Spoor has been instrumental for what I ended up doing.
However, this is my first attempt to develop something in the Adapt "ecosystem" and stack,... so I may have done things that are weird, or just plain wrong... I don't know!
As for SCORM... I particularly don't see a need for xAPI and SCORM to go together... to me they're different things. And SCORM is very widely used and way too important be "messed with", but that's just my opinion.
Any feeback or comments are welcome.
Regards.
