Unless you live under L&D rocks, you’ve heard about the Experience API (xAPI), formally TinCan. You might have probably heard rumors like these:

1. It’s like SCORM but better (whatever that means)
2. It’s for tracking learners but not only completions! All kinds of experiences. For example, you can track things like “Sally experienced ‘Solo Hang Gliding’” (whatever that means)
3. Oh, it’s simple, you just have to pick an agent who’s not an actor but kind of, and a verb with a resolvable URI, otherwise the LRS would reject the xAPI statement you sent as JSON. But don’t worry there are recipes out there you can choose from. (whatever that means)
4. You can create custom statements. (whatever that means)
5. You can also read statements (queries)! At least, some of it. You’d better start with using Postman (whatever that means).
6. cmi5 (whatever that means)

Now you see why reading about xAPI does not sound like a soothing bed-time story. Whatever that means.

If you’re using Articulate Storyline, you know there’s an option to leave SCORM behind and export your course as xAPI. But where are all these xAPI statements in Storyline? How do I tell the LRS that Sally experienced solo hang gliding?

Realistic Example

For example, you may want to know who’s actually opening that Resources section that caused you extra days of work. Does anyone use it? How often? Was it worth the effort? What documents are more popular than others? Did they watch the video or read the doc? Or watched the video first? And then downloaded the doc? Etc.

Therefore, take all the help you need! This is where xapi.ly comes in as a statement builder for your Storyline projects.

Quick review of xapi.ly

This is what xapi.ly promises for you:

Use xapi.ly to help you send more and richer xAPI data from elearning courses that are:

• hosted in an LMS and sending SCORM,
• hosted on any site or learning experience platform with an LRS, or
• hosted in or pointing to an LRS and using xAPI only

I think what that means, you either need an LRS or an LMS that supports xAPI. (Which makes sense because someone would need to store these statements.) For my review of xapi.ly, I just used ScormCloud. You can set up a free trial account and you’re good to go. ScormCloud supports xAPI, it even has an LRS viewer.

What do you need?

To get the most out of using xapi.ly, you’ll need your own Articulate Storyline 3 or 360 license, a learning record store (LRS) (or at least a test account), and a place to host your course.

Inside xapi.ly

As with everything else, I suggest starting with the end goal: publishing. The publishing section has step-by-step instructions how to add xapi.ly to your published Storyline course in order to work.

You will need to add a line to the published story_html5.html. Requires slight editing and zipping skills.

Since Storyline overwrites this file every time you publish, you have to repeat this every time you publish.

TIP: If you feel adventurous, and you want to save BIG TIME while you’re testing your course by not doing this edit every single time you publish, there’s a workaround. You’ll find on Project 99 where we’re posting 99 practical examples of using JavaScript with Storyline .

Now that you know how to publish, it’s time to build your xAPI statements.

This is important: xapi.ly basically allows you to build a statement using a form that guides you through the process. AND THEN, it creates the actual statement (JSON), and JavaScript code for you that you can copy-paste into Storyline. xapi.ly DOES NOT send anything, anywhere from online. It’s a utility tool that helps you create/build statements you can use to send statements via Execute JS triggers in Storyline.

The form-based approach helps less experienced users who don’t want to write statements from scratch.

Where Storyline users might find the most pleasure in this tool is the ability to add Storyline variable names for input. For example, when you build these statements, you will not know what the user’s actual response would be to a question (either multiple choice or free form text). However, you know the variable that will hold the user’s response. That means you can create the statement about responding, and then let Storyline to tell you what the actual response is right before sending the statement to the LRS.

For example, in my bizarre dating example, we know there’s a meeting (date) but we do not know who’s dating until it happens. The response (the lucky person who we date based on the simulation) will be in the Storyline variable, messagexAPI. The statement code includes GetPlayer().GetVar() to grab the value of this Storyline variable and insert it into the statement right before it’s send to the LRS. But you don’t want to worry about it yourself.

I’ve built a statement. What now?

Once you’ve built your statement in xapi.ly, you can open your Storyline course. You’ll need to add an Execute JS trigger in your course when you want to send the statement. For example, if you’re sending data on who’s downloading a resource, or clicking a button, you would add the xapi.ly output in that Exexute JS trigger that fires on clicking the button.

Clarification for newbies: What you copy paste from xapi.ly’s output box is NOT technically an xAPI statement but JavaScript that will send the statement. When the statement arrives in an LRS (like ScormCloud), it will be a text in JSON format (you probably want to learn more about this data-interchange format).

The statements look something like this in the LRS (removed my account information):

In this case, I’m the actor (Zsolt Olah), watching the online dating site simulation. I experienced (which could be saw, observered, whatever makes sense just to be consistent) a broken heart. In the response a Storyline variable tells me whose broken heart I experienced.

Under context, you see we’re grouping activities by course id. That means I can run queries (reports and visualization) within a course. But also, across courses, depending on what I’m looking for.

Testing your hypothesis

The online dating simulation I made for testing is based on an actual research paper. So, in theory, this paper would tell you how to build your profile for maximum effect. Let’s say this is a real course. Your SME believes that it is essential to read policy XYZ in order to be able to complete the course, therefore learners would want to read that first.

You say, that is a hypothesis. We can test it. Offer people to start the course in two ways: read the policy or jump in (with providing the policy button any time during the course). You send an xAPI statement for this event.

Then, in the LRS you can create queries that show who started with the policy, and how did they do in the course. Who started with jumping into the course, and where in the course did they reach out to the policy, etc. How many never read the policy but passed the course? Once you define what data you’re capturing, you can answer lots of questions.

Or course, your SME and stakeholders will not read xAPI statements, so you’ll have to create an visualization in a bar chart, pie chart, or whatever.

Tip: when thinking about xAPI, don’t limit your thinking to a SCORM replacement for a course. The power of xAPI is that you can get data from various data sources, and use them together to spot trends and create insights. Your spreadsheets, Google forms, survey tools, enterprise operation data, Salesforce, etc. are all data sources about the same people. Wouldn’t you want to connect the dots?

All this starts with xAPI statements. For more info on xapi.ly, check out
www.torrancelearning.com/xapi.

Feature request

What I’d love to see in xapi.ly is reading/querying statements. It would be great to let xapi.ly figure out how to create a query statement to retrieve an existing user’s last choice, or the most popular selection in a particular question. It is more complicated than it sounds because most of the time the result is an array of data but maybe we could limit that to a single item such as a number or text.

With (simple) queries you could:

• Share information between courses (you pick up a key in one course, and use it to open a door in another)
• Save user preferences (personalized way to learn without asking the questions every time)
• What do others think? (ask a survey question and show where they user’s opinion is compared to the company average)
• Check if a user has done X (X can be any experience such a completion, action in another course but also things outside the learning: attending a conference as long as you track it via xAPI, etc.)
• Follow up questions (let’s say we don’t have a “confirmation of learning” in the course but we tell the user we’ll follow up, and based on how they did in the course, we trigger follow up questions targeting weaker or critical areas in one week, two weeks or 1 month, etc.)