Time Tracking for Traditional Content?


Andrew writes:

"I had another question, this time about duration. I'm currently sending 3 statements per attempt plus an import one at the start of a session (so 4 it a session contains 1 attempt). The last two of these which are attempted/completed/passed/failed (let's call this my result statement) and then experienced (progress:false). 

Both these statements report duration. The result statement tells the observer (teacher, parent, employer supervisor etc.)  How long it took the learner to pass (or otherwise) the activity and the experienced statement tells them how long the learner has been in the activity, which may be a longer period of time. Both periods of time are important so should be reported.

So here's my question: what happens when I ask my LMS to report on the total time the learner has spent in all their learning activities for a given month? How will the lms know to include only the experienced duration? If the activities come from a range of vendors and authoring tools/methods, will they all use experienced statements to report session duration?

I know you're trying to get away from the idea of sessions with xAPI, so I hope you will forgive me for asking lots of session related questions. The reason is, in an education setting you are most often contracted to deliver a certain number of hours of learning, so tracking a learner's time spent is vital."

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


  • Avatar
    David Ells


    The current answer for time tracking is for the content to track it's own time and report it through a statement's "duration" field, in final statement about the activity that corresponds to course. So, when a user finally completes a course, the course content (a.k.a. the "activity provider") would issue a statement that says "user joe completed activity [course activity] with duration of [cumulative time in course, tracked by the content]".

    Hence, the content has to track times that it wants to report, and then report them using the "duration" field. For packaged web based content (the traditional SCORM model), the content will have to persist tracked time across launches in order to report cumulative time spent in the course. For this, it can use the TCAPI State API, saving the tracked time on exit, and fetching it again on launch, in order to add up time across all launches.

    The rule for LMSs to follow would be to look for the most recent duration reported in a statement about the activity which corresponds to the course. Then you get time spent for each learner in each course, as reported by the content.

    But we feel that, for traditional content, that isn't really a wonderful answer, particularly if you want to track the concept of launches anyway, and always know when a user has entered or exited your content (in the traditional sense). If we allowed a way for content to report that, we could also allow a standard way for LRSs to calculate a tracked time based on entry and exit times, and provide it's own cumulative tracked time, which takes the burden off of the content to always track it's own time (though it still can, if it wants).

    So, we're looking now at the best way to implement tracking that concept. We talked earlier about a convention using experienced along with the inProgress flag, but tracking launches and exits I think deserves special explicit attention in the TCAPI specification itself. So the best answer for your question is still forthcoming, but it ought to be one that is probably put right in the standard itself (and not just an ad-hoc convention).

    This is on our radar now, and we'll post an update once we've got something together to address this. In the meantime, you can continue forward with the duration concept, which may cover some of your use case. Thanks again for your questions, they are having impact. We appreciate it.

Powered by Zendesk