- Get Started
- Write Code
Posted by Andrew Downes
Posted 25 August 2015
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.
Posted by Tim Martin
Posted 20 August 2015
On August 13th, 2015, we launched a heavily revised version of tincanapi.com. Andrew Downes has been working away, as he does, creating new content. Rather than direct it all at the blog, though, he’s been rethinking and restructuring the core site and sharing his insights for first-timers, learning designers, learning product vendors, and organizations. There are countless other updates laid out below. Please spend some time with them.
Many readers of the site, though, will likely notice a significant change to our handling of the name… tincanapi.com. Years ago, Mike shared our perspective on the name, that we were going to call it Tin Can API. For some, this has been a contentious issue. With the new site, we’ve made the site behave as we have been personally for a long time. We call it whatever you call it.
On the site, you’ll notice a toggle in the upper left. If you prefer to call it Tin Can, do so. If you prefer xAPI, that’s great too. Whether you visit tincanapi.com or experienceapi.com, the site will present everything to you using your preferred name.
It comes down to this: arguing about an API’s name simply isn’t productive. We have far more important things to accomplish together.
So please, enjoy the new content. Go build a brilliant activity provider. Make some statements. Or ask us for help if you need it.
Here are the new sections of the site:
The existing Tin Can Explained page gives a really helpful introduction to Tin Can if you’ve never heard of it. We’ve brought this section up to date a little and added some pages around the different components of the new enterprise learning ecosystem that Tin Can enables. We’ve also added pages targeted specifically at organizations, learning product vendors and vendors of products outside L&D.
By now, if you haven’t heard of Tin Can and got a basic understanding, you’ve probably been living on mars. These days, the question we get asked most isn’t “what’s Tin Can?” but “how do I get started?” If that’s your question, then good news – we’ve created a new section just for you!
The get started section includes pages targeted at product vendors, content authors and organizations. It includes guides to help you see Tin Can in action, get a Learning Record Store (LRS) and run a pilot project in your organization. There’s a collection of pages to help you think about moving on from SCORM, too.
We already had a bunch of resources for developers, but not much really aimed at learning designers. We’ve added a page outlining the impact of Tin Can on learning design, including reflections on a handful of learning models and theories in the light of Tin Can. If you’re thinking more at the strategy level, we’ve got a page on incorporating Tin Can into your learning strategy, too.
The developers section was already crammed full of resources. We’ve tidied these up to make them easier to find and created an interactive statement explorer page to help you understand the structure of the statement.
The statement generator we created a few years ago was due for an update and ADL recently published a new more comprehensive statement generator. We don’t believe in reinventing the wheel, so we’ve taken the ADL tool, made it orange and included it on the site.
To help you put all these resources into practice, we’ve created a series of challenges for developers to try out writing code for Tin Can.
The previous webinar list contained embedded YouTube videos for all our webinars. We’ve got so many webinar recordings now that it was getting hard to find webinars on specific topics so we’ve created a new categorized webinar list. Each of the webinars is now on its own page, making it easier to share the recording with other people.
Posted by Andrew Downes
Posted 16 April 2015
We recently collaborated on a project to share statements between three LRSs by three different vendors. This three-part blog series outlines the project, explores some use cases for sharing statements and then dives into the technical details. You’ll find similar (but distinct) blogs by the other project collaborators on the Saltbox and Learning Locker websites.
The main goal of the Experience API (xAPI) is interoperability; the sharing of learning records between multiple systems created at different times, by different people and organizations. We’ve worked hard to produce a specification that defines that communication between learning systems in detail so that any two systems that follow the specification will be able to interact.
That’s great in theory, but what about the practice? Does it actually work with real systems available on the market today?
Recently, with our friends at Saltbox (Wax LRS) and HT2 (Learning Locker), we set out to put this to the test.
Our experiment involved the set-up illustrated in the diagram above. Statements were sent from activity providers to both Learning Locker and to Wax LRS and we set up Moodle LMS to display statements pulled from Watershed. We then configured statements to be shared one way from Learning Locker to Watershed and two ways between Watershed and Wax.
On the first attempt, the process was broadly successful but revealed a few issues that had to be resolved. On the second attempt, the process worked seamlessly; all statements going where they were supposed to without error.
The project proved the robustness of the the Experience API (xAPI), showing that where the spec is followed correctly, systems will work together. It also illustrated the importance of testing products with other systems to highlight areas where interoperability requires a little more work.
You can read about the project in more detail, including the results and lessons learned, in the whitepaper co-authored by the project collaborators. We’ve produced a screencast demonstrating the final system in action. You can also attend a webinar where we’ll discuss all of this in more detail!
We hope you’ll find the answer to any questions in the whitepaper, webinar and screencast, but if not, please do get in touch with any questions you have!
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.)
Posted by Brian Miller
Posted 17 March 2014
Growing adoption of the Experience API is a core part of what I’m tasked to do around here. Providing high quality, easy to use, open source libraries is one of the best ways I know to do that (aside from writing blog posts, of course!)