- Get Started
- Write Code
Posted by Brian Miller
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:
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.
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.
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.
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.
Posted by Brian Miller
Posted 15 April 2015
We’ve had some great contributions from the community over the last three months, and thrown in a little of our own time to push a bunch of our open source libraries and tools forward. Here’s a summary:
Hot off the press is release 0.7.0 which adds support (contributed by Dave Smith) for JSON document updates via the POST method.
A couple of releases for this library that were driven by a need from the prototypes (see below). 0.32.0 improved the library’s conformance and add a couple of handy methods for dealing with ISO8601 durations. 0.33.0 was a small release that landed a fix for URL parsing.
A small bug release that fixed “registration” handling in State Document handling, and corrected Result “duration” handling by allowing it to be null (read: not present).
This one landed a little while ago, but was a significant improvement to the overall code structure and the Score class in particular. George Cooksey provided this one with a really good bump in unit test coverage as well. Look for more about this library coming soon; it’s getting a neat new feature!
This group of code doesn’t follow a specific release scheme, but it recently received a big bunch of love from Andrew Downes. We made some backwards incompatible changes, but it really was time to modernize the prototypes in line with more current best practices around IRIs and Recipes. They should also run more smoothly taking advantage of a bump of a few releases of TinCanJS under the hood. You can get the code now, but look for a comprehensive blog from Andrew this coming Monday.
Technically, this one isn’t open source, but it is a popular, free tool available from our website and one of my favorites for capturing the informal learning I’m doing while working on all our open source stuff. Recent improvements include a new display of past sent statements so you can see whether you are repeating yourself, and improved Activity ID creation which removes certain query string parameters added to URLs just for analytics tracking.
We’ve been working on some improvements to the LRS Conformance test suite to make it easier to see whether an LRS is considered conformant, to provide an easier way to compare the conformance of two LRSs, and to fix kind of a big issue with how we were testing statement conflicts. Those improvements should be landing soonish.
I love that my job affords me the opportunity to work on projects that I can openly contribute back to the community, but that’s made all the better by receiving such well done contributions to those projects from the users out there in the world.
The Tin Can reporting bookmarklet has been around a long time, at least in terms of a now over one year old specification’s life. It was originally just a prototype, a simple way to show a pre-configured Agent could send a Statement about a readily available Activity— a web page. And it worked.
But after using it for the better part of a year, I realized just how much I used it, and how much more I could be tracking. I also realized just how much better the core functionality and user experience could be. So, I rewrote it (as I’m prone to do, something about asking for forgiveness and such).
Originally my goal was just to make it use TinCanJS to support a wider range of browsers and to make sure we were able to keep it up to date as new versions of the specification landed. That turned out to be a fairly substantial rewrite. One that suggested a little more effort would go a long way in making it work the way I would want, rather than just work.
Posted by Brian Miller
Posted 17 June 2014
As thought leaders in a rapidly progressing community, we’ve tasked ourselves with trying to figure out what the next thing is that the community will want, or more importantly need, to effectively work with the Tin Can API. As the specification approached a 1.0 release, it became apparent that switching the identifiers for Verbs and other Statement parts to URIs was going to leave a gap. Out of that recognition came the Registry. The Registry provides a place for users of the Tin Can API to catalog the various terms they use to construct Statements.
A year later we realized another gap existed—the Tin Can API provides a ton of flexibility, but even the early adopters (innovators in their own right) were having issues implementing effective solutions with so much flexibility. They had too much proverbial rope with which to hang themselves.
Posted by Brian Miller
Posted 20 March 2014
Today we had a discussion centered around the creation of statements corresponding to the actions that a client likes to capture for a live event. One of the actions they consider important is “raising a hand”. This is also an action that is common in online meetings, webinars, etc. because it is easily symbolized in an application’s interface. Our discussion started with the desire to create a verb for “raised hand,” but is that really the verb we need? (Clearly not, or I wouldn’t be writing this blog post.)