What’s the difference between session duration and attempt duration? Timestamp or Stored? When should you record time taken and how can you report it? This series of blogs will look specifically at duration and how to report on it.
Let’s start our first blog by making sure you’ve got a good understanding of what duration is.
At a basic level, duration is how much time something took. In SCORM there are three variables that match this description:
-
cmi.core.total_time: the total amount of time the learner spent in the course from first launch through to completion. This is the time taken to complete one attempt, so I call this attempt duration.
-
cmi.core.session_time: the total amount of time the learner spent in the course on one occasion. This is the time spent in the course on a given session, so I call this session duration. It’s quite common for attempts to be split out over multiple sessions. It’s also possible to have multiple attempts in one session; this is less common with e-learning, but more common with some other types of experience such as games.
-
cmi.interactions.n.latency: the time taken to respond to an interaction. This is attempt duration for interactions; it’s assumed that interactions don’t span sessions so there’s no such thing as interaction session time.
In xAPI world the concepts are the same. Whether we’re tracking traditional e-learning or something new and shiney, we either want to track how much time somebody spent doing something (session duration) or how long it took somebody to achieve something (attempt duration).
In his Deep Dive into Result, Brian Miller outlined how you can use the optional Duration property to record exactly how long the experience took. This is the best mechanism for activity providers to clearly state how long something took (see below).
Brian’s Deep Dive into Extras outlined the statement’s timestamp and stored properties. Brian explained how they can be used to support offline tracking. The Stored property tells you when the statement was stored in the LRS whilst the Timestamp is when the event actually happened. All statements will have a timestamp because even if the Activity Provider doesn’t include it, the LRS will fill it in. This makes Timestamp a valuable fallback to calculate duration if it’s not explicitly provided by the Activity Provider.
So now you know what duration is, how to you do track and report on it in practice? Tracking duration is something that’s been done reasonably badly by many activity providers to date, so that next blog in the series will help them do that better. The third blog will be aimed at reporting tools interpreting the statements. We’ll briefly looking at how to report on statements that follow the format described in blog two (spoiler: it’s easy) before moving onto some tricks to get the data out of statements that might not be so well crafted.
Watch this space for the next blog in this series coming next week, and in the meantime if you’ve got questions please get in touch.
