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 Tin Can questions:

866.497.2676

Archive for the "TinCanAPI.com" Category

cmi5 is ready to go in SCORM Cloud

Posted by

Categories: Spec Effort, Tin Can, TinCanAPI.com

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.

3 Comments
 

We call it “I call it”

Posted by

Categories: Adopters, Announcements, APIs, Ideas, News, Standards, TinCanAPI.com

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 prefered 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:

Understand

 
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.

Get Started

 
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.

Design

 
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.

At a practical level, there’s a guide on statement design, an introduction to recipes for learning designers, and an assignment for you to try out what you learn from the new pages we’ve written.

Developers

 
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.

Webinars

 
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.

No Comments
 

On June 2nd, 2015, we were part of a joint webinar presented by Bersin and CUES. As usual, the attendees had more questions than we could answer during the live webinar, so we’ve posted the questions and Andrew Downes’ answers here.

General

  Questions:

  • What is the common identifier that allows the xAPI to connect the data provided by the ‘activity provider’ to a specific user in the LRS?

Name of Answerer: Andrew Downes

Answer: Tin Can allows for learners to be identified by email address, Open ID or an account on some system, such as an LMS. For privacy reasons, a hashed version of the email address can also be used. In practice, most implementations either use email or an LMS account id. Activity Providers always need to know who a learner is in order to send the LRS data about that learner, which can either be done by having the learner log into the activity provider, or some kind of launch/single-sign-on process.

It’s possible that different Activity Providers might use different identifiers for the same person, for example accounts on different systems or different email addresses. In this case it’s important for the LRS to have a record of all the identifiers that relate to a single person. Activity Providers can request this information from the LRS if they need it (and if the LRS gives them permission).

See Brian Miller’s Deep Dive blog for a deeper dive.
MORE…

No Comments
 

On Tuesday, March 31st, 2015, we hosted a webinar about nine practical use cases of the Tin Can API (xAPI). As usual, the attendees had more questions than we could answer during the live webinar, so we’ve posted the questions and Andrew Downes’ answers here.


 

Q: LRS is learning XXX system? quick definition please
Q: what does LRS stand for?
Q: how does an LRS differ from an LMS?

A: Learning Record Store. There’s a great explanation of what an LRS is and how it differs from an LMS here: ../learning-record-store

Q: I’m in the US…and I’m not familiar with the way Andrew is using “bespoke”.
Q: What does “bespoke API” mean?

A: From the Wikipedia definition of bespoke: “altered or tailored to the customs, tastes or usage of an individual”. Many products and systems have an API that’s specific to that individual system. If you want to integrate with that system, you need to tailor-make an integration with that system and you won’t be able to re-use that work with another system. The point of Tin Can is that you can do the integration work once and it will work with any Tin Can conformant system. MORE…

No Comments
 

How do you build an LRS?

Posted by

Categories: APIs, Best Practices, LRS, Tin Can, TinCanAPI.com

Posted 1 July 2013

 

We get this question a lot.

To do Tin Can properly, you need an LRS to send your statements to. Statements are generally the focal point of Tin Can, but LRSs play a vital role in creating rich collections of data and making the data interoperable.

To answer the question, we built this page explaining what goes into an LRS.

It’s a complicated undertaking to build an LRS, whether it’s an installed or a hosted-standalone-enterprise system, or a component of some other system like an LMS.

MORE…

No Comments
 

Tin Can API Email Updates

* indicates required

Tin Can API Email Updates

Thanks for signing up for the Tin Can API newsletter!

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

Close