xAPI tracking events support in framework/components

[ryangadams]

This issue is really to anchor a discussion about the right way to implement this feature.

We have an adapt-xapi component that we're working on. It records State to an LRS and works with the Page Level Progress component to allow revisiting a course and having previous progress recorded.

We're implementing Statement tracking for some extensions (we've picked two to get started with, Assessment and Open Text Input) and we expect to record statements on completion back to the LRS to include sensible additional data (like Context, Result, submitted text, pass or fail status) - those last two will likely be verbs.

Early investigation suggests that the xapi plugin would need to know detailed information about the component in order to generate an appropriate statement (for example, in an MCQ is the title or the body text the question? Which should be recorded to the LRS as part of the Statement object? It doesn't feel right for the xapi plugin to dig into the open text input component to extract the entered text to add to an attachment on the statement.)

Our thinking is that the component or extension should be responsible for defining the core statement to be sent to the LRS and the xAPI extension should listen for it and respond appropriately.

We're suggesting that components should fire a “track me” event, passing in a statement object that the xapi plugin will listen for and manage. xAPI will then prepare the statement for the LRS, making sure the Actor data is correct and the IRIs for the statements are prefixed with the Activity Id before sending it to the LRS or storing it for later transmission.

This does require that all components support xAPI and prepare their own statements, which blesses xAPI with special status - we wouldn't imagine doing a similar thing for other tracking systems. That might be an acceptable trade-off considering xAPIs special status in e-learning.

So to recap:

• we're proposing a new event that plugins should trigger
• the event should include a tracking statement that is (almost) valid xAPI
• adapt-xapi (and other tracking plugins) will listen for that event, decorate the statement with actor and activity level information then send to the LRS.

[moloko]

actually we are already doing something slightly similar for SCORM support, have a look at this

So clearly I wouldn't have any issue doing the same thing to enable xAPI support. I think the key is to have the component/extension do as little as it's possible to get away with.

For example, that function in matching just outputs the data in the simplest format possible - the spoor SCORM wrapper code will then 'translate' it into the relevant SCORM 1.2 or 2004 format.

[ryangadams]

I've been doing a bit of thinking about the simplest code possible. Given the possible variance in xapi statements, I'm wondering whether the simplest format is actually “an actor-less xapi statement”. Obviously that has implications for other tracking types, but perhaps xAPI is special… Not sure really.

[davidpesce]

From a code standpoint, I really like this idea. From an implementation standpoint, I'm against it. This would significantly limit adoption of xAPI in the extensions. Users are then limited to extensions that support xAPI.

[ryangadams]

That's true, and we're looking into whether we can record a generic statement of completion for components that don't support xAPI, with components that do firing the enhanced event (As far as I can tell, there is no component complete event currently). I'm keen to see alternatives though.

[davidpesce]

I could get behind it if it's a requirement across all extensions. Then it's not a matter of users who want xapi needing to go back to the developer and ask for modifications.

[moloko]

We have always accepted the fact that non-core plugins may not offer the same level of support as core plugins - most won't have accessibility/RTL support for example, many may well not have IE8 support and a non-core question component isn't going to support SCORM cmi.interaction tracking unless you add that in, it'll have no way of stating what kind of interaction it is unless you specify that as a minimum.

If we are able to do something generic & basic that would be great though.

[brian-learningpool]

@ryangadams, we can listen to completion events on components -- they all inherit from AdaptModel.

Why not have the xAPI extension support component JSON that has been decorated with a new _xapi property? This could even support string interpolation of any given model attributes in the statement string, which the xAPI extension could then convert into something more meaningful.

This way the statements are left for the user to define and the components don't really have to worry about doing anything special for xAPI at all.

[ryangadams]

Thanks @brian-learningpool

do components emit the completion event by default? If they do that's great and we can use that event to introduce generic statement tracking, the content of which is to be determined. I guess that since they fire completion events then that's the right event for the xapi extension to listen for.

I was anticipating a new property like _xapi on the component objects. A component._xapi.statement property with variable interpolation might work in many circumstances, but I think the complexity of statements in some circumstances may need additional processing. I'm not certain of that though, I'll find out.

Why would the user define the statements? Wouldn't the component define its completion statement and the user decide whether to track it or not?

[oliverfoster]

while it occurs to me. you might have a problem getting change events from a sub objects in a backbone model.

you can do:

model.on("change:_isComplete", function(model, val) {});

but you can't do:

model.on("change:_xapi._subproperty", function(model, val) {});

it won't fire if you change the _xapi._subproperty, backbone models only work on the first level.

[moloko]

@ryangadams yes all components emit a completion event

I guess if you had a component that had more fine-grained events than just 'completed' then the course author should to be able to choose which ones they wanted to track - for example on the media component you could have 'read the transcript' as well as 'watched the video' (or even 'switched on captions').

I'm not so sure the course author would need to be able to define statements though - @brian-learningpool could you give us an example of when you think this would be useful

[dennis-learningpool]

Sorry for jumping into an old thread, but just wanted to respond to @moloko's question above (and also respond to @oliverfoster's "use cases!" request in this morning's framework call).

One reason to allow course authors to define statements is simply to empower them, so they can ensure consistent reporting from a variety of sources, which may not agree with whatever statement format we have decided to use. This post neatly describes the kind of problem I'm thinking of.

Other reasons to support custom statements are well articulated in this post. For example, content creators can use custom statements to inform "adaptive pathway" learning experiences, where actions within a piece of e-learning or elsewhere can affect future learning. There's a ton of things (well ... nine) in that post make the case for customising statements more effectively than I can.

I can also imagine ways to gamify content using this feature - imagine an extension that pulls data from the LRS to allow real-time interactions between users engaging with the same content at the same time, such as attaching user generated hints an assessment. I think such things would be easier if we support a customisable mechanism for generating statements.

Hopefully the links above answer your question, @moloko. Happy to discuss.

[oliverfoster]

I completely agree @dennis-learningpool

I'd like an Adapt API and an XAPI api exposed inside the extension, with the possibility of loading in preconfigured, custom or layered profiles.

[oliverfoster]

is this resolved with this commit, this issue and some documentation (not yet written)?