Contact Us Support Forum Get Email Updates
 
 

Thanks! Someone will be in touch with you shortly.

Rather just email us? Email us here.
Rather speak with someone in person?
Call any time with Experience API questions:

866.497.2676

Archive for the "Deep Dive" Category

Why cmi5?

Posted by

Categories: cmi5, Deep Dive, LRS, Recipes, Standards, Statements, xAPI

Posted 11 May 2017

 

The part of the xAPI community that loves the freedom to live outside of an LMS, the vast majority of it, loves cmi5. They just don’t know it yet.

This is the story of how I came back to an LMS, after having never really used one. The story about a little specification that took forever, but in the end provides a wandering community with just enough fencing to get them back on a path. But the part they’ll really like — it can be any path.

That fence is constructed between the following posts:

  • Launch: have to have it for endpoint + credentials
  • Statement Guidelines: have to be able to recognize a statement and understand how it was intended to be understood
  • Session: we always want start and end anyways
  • Flexibility: allows you to take any trail you like

Launch

Don’t think of the LMS as an LMS, instead, think of it as a “cmi5 launching” system.

Everywhere I looked there was launch staring me back in the face. I couldn’t get away from it. (Believe me, I’m the revolutionary in a company who lives and breathes SCORM and LMSs, and I tried to get away from launch.) Repeatedly on calls with clients wanting to create products with xAPI, I would say, “Sure you can capture any data you want, that isn’t a problem, but the hard part is getting the endpoint, and even harder, the credentials.”

It turns out that in practice, so many of the clients I was working with had these systems that told their learners what types of learning and training they should be participating in. These clients were excited about xAPI, and they were already bringing their learners to the list of tasks available to them. cmi5 is providing a standard way to handle this across different systems and experiences.

Statement Guidelines

Presuming you have your endpoint and credential problem solved and the data is flowing into your LRS from your content, as well as from all your other xAPI-enabled sources, then the next problem hits — the xAPI flexibility problem. This is the problem that an xAPI recipe was initially intended to solve. A consumer of xAPI data needs to have a way to identify the semantic meaning of a statement as a whole so that it can “understand” that statement. cmi5 pays particularly close attention to this concept and provides a means to identify statements with specific cmi5 meaning that the launching system (or any reporting system) can use to frame the context. Beyond specific cmi5 statements, it provides a templating system for how other statements can include basic information, allowing all of the statements in an experience to be tied together efficiently. Although sometimes we prefer a path less taken, most often we want a well worn path with a pre-defined destination. Spelling out how to detect and use a cmi5 statement in a massive pile of data makes it much easier to develop and much faster to execute for the reporting system.

Session

I work with and on eLearning standards every day, particularly xAPI, and despite the best efforts of the community to date, it feels like gaining widespread adoption of profiles and recipes has been a slow, uphill push. The thing that I found, however, is that every non-trivial type of experience we want to explain with profiles and recipes all start with the actor “initialized something” and end with the actor “finished something,” and it didn’t matter what the “something” was. The session concept in cmi5 has these markers and can provide a shell for other profiles and recipes that are defined in the future to live inside of. There is no reason for anyone else to worry about how to create those types of statements and indicate these types of events. We can just wrap them in cmi5.

Flexibility

So far, a lot of adoption of xAPI has been from people that love to trailblaze, and they are critical to the process. But for every one of them, there are lots of people that like to start on a well traveled path, take small excursions into the thick, and then return to that comfortable path. cmi5 is perfect for both because it allows you to send nearly any statement you want (yeah, yeah, not voided; I said nearly). You can stick to the well defined statements associated with common LMS concepts such as completion, success (pass/fail) and score, or you can use cmi5’s concept of “allowed” statements which is virtually any other statement. You can have your cmi5 content send statements across several different profile types, or invent your own.

:::::::::::

The amazing thing about a path is that it is exciting for each new traveler, even though inherently none of it is new. The reason to love cmi5 is that all of these fundamental concepts necessary to start making robust end-to-end applications of xAPI have been codified in one succinct specification by original pioneers in the xAPI community. We’ve had four years of xAPI wandering, and now it is time for LMSs, rapid authoring tools and less traditional eLearning platforms to all find a path to success. cmi5 can be that path.

No Comments
 

We’ve launched a new services group.

 

 

Some Background

For years, we have relied on our products to be the solution to a number of complex problems facing companies that use learning standards. If you’re building an LMS or authoring tool and you need AICC or SCORM or, more recently, xAPI, we have a product that can do the heavy lifting. That’s been our bread and butter.

But we also have insights from years of thinking about experiential data and hearing how customers report on it. And we know that the problem isn’t always solved at the immediate boundary of our products.

It’s those considerations that brought our services group to life.

What We Do

We help vendors and organizations consider how to use learning standards to accomplish their goals. These goals include delivering the learning material to their people and selling their products to discerning buyers.

We work on problems related to the learning standards AICC, SCORM, and xAPI.

In the case of xAPI, the newest of the standards, the off-the-shelf solutions are less mature. Listening carefully and collaboratively helps us build better products, but it also helps us get you the right solution now.

Of course, we haven’t stopped thinking about AICC and SCORM.

Where You Come In

We want you to ask us a question. You can learn more about how we’re responding to the questions we’ve already heard here. These are things we anticipate. Maybe something on this list prompts a question you were getting ready to ask. So, ask away– we’re listening and ready to help.

No Comments
 

Statements come from all kinds of places: content created in authoring tools, mobile apps, learning platforms and business systems. It’s not always immediately obvious which application the statement came from, which might be useful to know. This blog explains how you can tag the statements your tool or product generates and why that information is useful.

We’ve worked hard to make the Tin Can (xAPI) spec as clear as possible and have required Learning Record Stores (LRSs) to validate incoming data to ensure the same data structure is always used. There’s no way for statements to be sent to a conformant LRS unless they follow the prescribed data structure, and you’ll find that the major LRSs are strict with the data they accept.
MORE…

1 Comment
 

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 looks specifically at duration and how to report on it.

As a provider of an LMS, LRS or other system launching content and reporting on duration information, you can use the table presented last week as a guide for reporting. In an ideal world, you can simply look at the Result Duration property of the completed/passed/failed, suspended and terminated statements to grab your attempt and session durations. Win!

Handling limited data

Unfortunately, the world is not an ideal place. In practice, many Activity Providers have not implemented duration at all, or are only reporting duration at activity completion, leaving the report viewer wondering about the time spent by learners on partially completed attempts. Many early adopters, who designed their statements before the best practice I described last week emerged, are understandably waiting for the release of CMI5 before updating their statement structure.

As an LMS provider that leaves you with two options:

  1. Encourage your activity providers to improve the data they’re sending (point them to this blog series).

  2. Work with the data they provide or you can gather yourself.

Working with the data you have most likely means using Timestamp to calculate duration. For session duration, you can simply take the first and last statements issued in a session and subtract! The harder part is working out the break points between sessions, especially if the learner re-launches the experience soon after leaving it. The following guidelines will help:

  • As the LMS launching the experience, you should know when the session started. In fact it’s good practice for the LMS itself to issue a statement using the verb http://adlnet.gov/expapi/verbs/launched to indicate that it launched the experience. This means that even if the Activity Provider never issues a single statement, you know when experience was launched. This is essential for reporting if the experience can be launched from multiple systems and the Activity Provider is not sending the data you need.

  • When the learner has launched the experience again, you can assume that the previous session ended at about the time of the previous statement before that new launch.

  • When the learner hasn’t launched the experience again, you can assume that either the session is still in progress, or the last statement issued represents the end of the session.

  • To work out if the session is still in progress, you’ll need to define a session timeout period. If the activity provider is doing client side JavaScript tracking, then the LRS should define a timeout for the launch security credentials and you can use that same value. If not, define something sensible for the types of experience you’re launching. Any statements issued after the timeout period you define can be considered a new session.

Attempt duration can be harder or even impossible depending on what data the Activity Provider sends. If you can follow them, you can use the rules below in priority order depending on what data the Activity Provider sends:

  • If the Activity Provider sends a ‘suspended’, ‘completed’, ‘passed’ or ‘failed’ statement with a Result Duration, then take this as the attempt duration. If more than one of these statements are sent, the latest one in a given attempt will represent the latest duration.

  • If the Activity Provider sends an ‘attempted’ statement with a Result Duration of zero then this marks the start of the attempt for the purposes of calculating attempt duration.

  • If the Activity Provider sends a ‘suspended’, ‘completed’, ‘passed’ or ‘failed’ statement without a Result Duration, then then the latest of these within an attempt marks the end of that attempt. Add up the session durations of all sessions within that attempt.

  • Assume that the last statement (excluding ‘launch’ and ‘initialized’) before an ‘attempted’ statement with a Result Duration of zero was the last statement in that previous attempt.

  • If Result Duration is not used by an Activity Provider but they use the ‘attempted’ statement correctly, you can calculate the end of a previous attempt as the latest ‘suspended’, ‘completed’, ‘passed’ or ‘failed’ statement before an ‘attempted’ statement.

  • If Result Duration is not used by an Activity Provider and they use the ‘attempted’ statement incorrectly, then it may not be possible to accurately track the start and end of an attempt. The only sensible solution here is either not report attempt duration for these activities or allow your administrators to configure how duration is reported on a per activity basis.

As you can see, reporting on limited data from Activity Providers is hard! This complexity can be avoided by Activity Providers sending the data as outlined last week. If they don’t and you really need to report on their data, we can help.

1 Comment
 

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.

The SCORM veterans at Rustici Software tell me that duration reporting by SCOs was notoriously patchy. That’s why you’ll notice that SCORM Cloud will tell you it’s calculation of duration alongside the figure reported by your e-learning. It can do this because the SCO sits inside a player – either a frame or a pop-up window – that allows SCORM Cloud to keep an eye on the SCO. xAPI does away with the need for frames and pop-ups; that’s a really good thing for everybody but it does mean that activity providers need to be on the ball with reporting duration.

As an Activity Provider, if you want to provide good duration information you’ll need to issue statements for the events in the table below. There’s no universally agreed set of verb ids for this yet (CMI5 is still under development), but I’ve listed the verbs that I would use (and have used) when designing statements.

Event

Verb id

Comments

Entering the experience

http://adlnet.gov/expapi/verbs/initialized

The very first statement issued by the activity provider as soon as it can. I recommend including a Result Duration of zero (“PT0S”) with this statement.

Exiting the experience

http://adlnet.gov/expapi/verbs/terminated

Issued whenever the learner leaves the activity and includes the session duration as the value of Result Duration.

Starting an attempt

http://adlnet.gov/expapi/verbs/attempted

Issued at the start of a new attempt. You should always include a Result Duration of zero (“PT0S”) with this statement.

Suspending an attempt

http://adlnet.gov/expapi/verbs/suspended

Issued when the learner leaves mid-way through an attempt. Includes the current attempt duration as the value of Result Duration.

Resuming an attempt

http://adlnet.gov/expapi/verbs/resumed

Issued when the learner returns to an attempt that’s been suspended. You can optionally include the attempt duration tracked so far as the value of Result Duration with this statement.

Ending an attempt

http://adlnet.gov/expapi/verbs/passed

http://adlnet.gov/expapi/verbs/failed

http://adlnet.gov/expapi/verbs/completed

The attempt can be considered over when the learner passes, fails or completes the activity. These statements should include the final attempt duration as the value of Result Duration and a Result Completion of “true” to make clear that the attempt is complete.

The object of all these statements needs to be the main activity itself rather than something within that activity. You might also want to track duration for sub-activities such as modules, screens or interactions within an e-learning course too, but this is no substitute for tracking the duration of the activity as a whole.

Note that you should use the Context Registration property to link groups of statements together. The concept of registration is linked to the idea of a learner being enrolled on a course and can be a little complex. Sometimes a registration is equal to an attempt for all practical purposes, but that’s not always the case and single registration may contain multiple attempts.

In our golf prototype, for example, the user is given the option to return to a saved location or start again. If they choose to start again, that’s a new attempt but not a new registration. In our Tetris prototype each game of Tetris is a new attempt, but they all sit within a single registration. As a rule of thumb, if the LMS initiates a clear slate for the learner when launching the activity, that’s a new registration; if the learner has multiple attempts within the activity, it’s not.

What if the user closes the browser?

A common problem with SCORM was that if the user closed browser windows or got disconnected then tracking data could be lost. xAPI solves this by allowing tracking to be performed server side so that data can be sent even after the user disconnects. It is still possible to do xAPI with client side JavaScript though, and in this case the same problem remains.

For duration tracking, this means that the crucial final statements containing the duration information can be lost if the user closes the browser before they can be sent. There are a number of things activity providers can do to minimise this issue:

  • Make clear how learners can safely exit the course; provide some instructions and a clear save button at the top of the page. For example, the latest version of our golf prototype adds a ‘Save and Exit’ button to the navigation.

  • Consider the session over and issue statements when the learner gets to the end, not when they exit.

  • Launch the course in the same window rather than a new window and return the user to the LMS when they exit. This may require some collaboration with the LMS provider to achieve, but is a smoother experience for the user and discourages closing the window. The draft CMI5 specification includes a standard way for the LMS to provide a return URL to the activity provider.

I hope that clears up the questions you had around how to track duration and helps us all to do xAPI better. If you do have further questions, please get in touch.

1 Comment
 

Experience API Email Updates

* indicates required

Experience API Email Updates

Thanks for signing up for the Experience API newsletter!

Make sure to follow us on Twitter @ProjectTinCan,
and tweet this page to let others know about the Experience API.

Close