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

Learning plans, goals and targets are important. Setting goals for learning allows us to evaluate whether or not we are learning the things that we set out to learn. It’s standard practice for e-learning courses and qualifications to have learning outcomes attached to them, and these are used to measure if our learning has been successful. They are also used by educators and trainers to evaluate whether or not their teaching and training have been effective, and are used to inform interventions, further learning requirements and amendments to learning materials and lesson plans.

Learning Goals with Tin Can

Brian Miller touched on the use of sub-statements in Tin Can to represent future plans. The spec puts it this way: “One interesting use of sub-statements is in creating statements of intention.” and gives the following example:

{
    "actor": {
        "objectType": "Agent",
        "mbox":"mailto:test@example.com"
    },
    "verb" : {
        "id":"http://example.com/planned",
        "display": {
            "en-US":"planned"
        }
    },
    "object": {
        "objectType": "SubStatement",
        "actor" : {
            "objectType": "Agent",
            "mbox":"mailto:test@example.com"
        },
        "verb" : {
            "id":"http://example.com/visited",
            "display": {
                "en-US":"will visit"
            }
        },
        "object": {
            "id":"http://example.com/website",
            "definition": {
                "name" : {
                    "en-US":"Some Awesome Website"
                }
            }
        }
    }
}

MORE…

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…

No 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
 

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
 

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