- Get Started
- Write Code
Posted by Kirsty Hughan
Posted 26 May 2017
Recently, ADL (the Advanced Distributed Learning Initiative) launched the xAPI Adopter Registry, which lists xAPI Adopters and Conformant LRSs. We’re thrilled to be one of the first companies included on the xAPI Adopter Registry and the only company so far to have two conformant LRSs–both SCORM Cloud and SCORM Engine passed the LRS Test Suite.
So why is this so exciting?
The registry is a valuable resource for the eLearning community because it promotes adoption of the Experience API and provides a core list of xAPI conformant products. The LRS Test Suite is extensive, covering 1,300 strict criteria that ensures true adoption of the xAPI specification and therefore guarantees interoperability across eLearning systems.
Personally, we have been involved in the learning standards community since 2002 and in that time have come to understand the true value eLearning specifications provide in ensuring interoperability. With xAPI, we are excited about the possibilities for new ways of learning and are here to both encourage adoption and help add other companies and vendors to this growing list.
Posted by Tim Martin
Posted 14 February 2017
Today we’re excited to announce support for a new specification in SCORM Cloud- cmi5, which is something that doesn’t happen all that often in its history. Along with making cmi5 support readily available in SCORM Cloud, we’ve also added support for cmi5 to some of our other products including SCORM Engine and SCORM Driver.
Obviously, supporting a variety of specifications is a huge part of what we do well at Rustici Software. More than anything, though, I think it’s important for us to be conscious of, and to explain well to all of you, when and why we add support for a particular specification.
So, what is cmi5?
cmi5 is technically a profile of xAPI which means it piggy backs on top of things already well defined in xAPI, but adds specificity in others. For cmi5, this means that certain xAPI statements are required, and launch is handled in a very specific way.
For me, it’s the launch piece that’s so important. From xAPI’s advent years ago, there have been issues with launching content. In the earliest days, we at Rustici Software defined a very simple launch specification that several content vendors picked up on. It was good enough for the time being, but it wasn’t really good enough in practice.
So, over the last couple of years, many people including Bill McDonald (as Chair of the working group) and Art Werkenthin and others at RISC have put a lot of energy into considering how their AICC work could be applied to launch in the xAPI world. The result is that we have a good solution for launching content via xAPI.
Why it matters
Years ago, as we at Rustici Software and others around us started evangelizing xAPI, we made some mistakes. We talked about all of the things that could be enabled by xAPI, the things for which it was necessary but not sufficient. Over the last year or two, we’ve really started to fill in the gaps to make it sufficient as well. And while launch isn’t the dreamiest of capabilities for which xAPI is a solution, it is absolutely fundamental.
If content launch is ultimately going to transition from SCORM to xAPI, cmi5’s support for launch will be a requirement. And further, so many other activities actually benefit from having a well defined, implemented, and adopted specification for launch. So for now, we’re excited to share that Cloud now offers vendors and others a great place to test cmi5 based launchable activities. We hope this helps spur the development of many xAPI/cmi5 adopters.
Posted by Andrew Downes
Posted 7 January 2015
Last January I made some predictions for the Tin Can world in 2014 and did surprisingly well. In this post I review my 2014 predictions and make some fresh ones for 2015.
At the start of 2014 I predicted a year with little change to the Tin Can specification, development of conformance testing tools, release of an open source LRS, Tin Can adoption in Moodle and stories of more innovative solutions. These predictions were all based on insider knowledge of being a part of the xAPI Working Group and I’m pleased to say they all came true!
Posted by Andrew Downes
Posted 19 December 2014
Since joining Rustici Software at the start of November, I’ve been working my way through the list of adopters on tincanapi.com: making contact, updating and adding entries and helping people to do Tin Can better. I’m now getting to the end of that list, so this blog is an invitation to anybody not on that list to get in touch.
Equally, if you are on the adopters list and haven’t seen an email from me (maybe I mailed the wrong person in your org or the message got lost), or if you’ve had an email from me and not yet replied, this post is for you too!
So why do I want to speak to you? Well…
Some of the entries on the adopters list are brand new, but many of them are a couple of years old now. What you’re doing with Tin Can will have developed over that time and in some cases website URLs, logos and product/company names have changed, too. We want to make sure the list is accurate.
Posted by Andrew Downes
Posted 18 December 2014
A word of caution to PHP developers and others about Tin Can timestamps.
My involvement in Tin Can or Experience API specification has led me to explore a number of finer technical details that I never imagined existed. The specification is pedantically precise in places, and it needs to be. For all of the learning industry’s software to work seamlessly and smoothly for the end user, the programs in the background need to be exact in their communication; nobody wants to lose the tracking data of thousands of learners on the launch of a new training course because somebody missed a colon.
The format of the timestamp string is one of these pedantic technical details that needs to be right. There’s a specific set of standards outlined by the ISO organization (ISO 8601) that describes the format of this timestamp, and the Tin Can specification simply references that existing standard. Using an existing standard makes things simpler, because:
Programming languages are created by some very clever people, so you can expect to rely on them to get the standard right. Can’t you?