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 Experience API questions:

866.497.2676

Archive for the "Use Cases" Category

Deciding when to use xAPI

Posted by

Categories: Best Practices, News, Use Cases, xAPI

Posted 18 April 2018

 

hammering home xAPI

For the better part of seven years, Tim Martin, our CEO at Rustici Software, has carried his xAPI hammer around telling the story of what the standard enables. The problem with his hammering is that it has led some to consider xAPI the solution to any problem. Fear not: he has recently written two articles in Learning Solutions Magazine that provide clear strategies to help you decide when it’s best to use (or not use) xAPI.

In short, “3 Guiding Principles for xAPI Evangelists” identifies xAPI as a suitable technology when two systems talk to each other about things people do. That makes it a fit if you have multiple systems that already support xAPI, if you want to track in-person experiences or if you have multiple LRSs.

The follow up article, “Tips for Deciding Whether to Implement an xAPI Solution,” gives scenarios of when to use xAPI and when not to use xAPI. Sometimes SCORM is a better choice. Like the MP3, which works in every music app, SCORM’s strength is its age and the fact that nearly every software on the market supports it.

But we won’t steal all the secrets from Tim’s articles. Head over to Learning Solutions Magazine to get all the best tips and tricks so you know just when to use xAPI. Still uncertain? Just reach out! We’re always happy to help.

No Comments
 

Last Friday, we were excited to be involved in xAPI Party. The celebration marked the end of the xAPI Cohort run by Torrance Learning (their next Cohort starts February 1) and our Director of Products TJ Seabrooks gave a demo. Since many of the folks at the xAPI Cohort were familiar with the free LRS in SCORM Cloud, we wanted to share a story of how we helped one of our clients with a super particular xAPI problem, so TJ shared how to add attachments to an xAPI course in Lectora.

This specific example comes from a client who is large and in a highly regulated industry. Before working with us, their certificates were tied to the end of each course. If a learner were to lose the certificate, they’d have to go back, relaunch the course and redownload the certificate. They needed the ability to maintain and later present certificates for learners so that any administrator in the organization could go into the LRS, view the learners’ scores and download certificates for each learner.

Our solution was to build out a simple reporting system that let them view xAPI attachments as part of a grade book reporting system. xAPI is particularly well-suited to this solution because it is reusable: any content you author can be launched from any LMS that supports xAPI and any LRS can store and fetch the attachments. This is unlike SCORM, with which you would need to build a custom solution that only works for a single system.

Since our customer was already familiar with Lectora, we provided instructions for setting an action in a Lectora course that lets us send our own custom event when we’re finished with the course. If you don’t use Lectora, you could adapt these steps to another authoring tool that supports xAPI pretty easily (and if you’re struggling – just reach out to us).

If you want to see everything “in action,” you can check out a video of TJ’s demonstration, head over to Torrance Learning’s Adobe Connect recording. In the video demo, TJ walks you through how to add the custom JavaScript code (TinCanJS and html2canvas) to Lectora, test the course in SCORM Cloud and then retrieve the certification in our custom reporting dashboard, which shares info like score, pass/fail, launch date and assessment result.

Technical steps for sending and receiving attachments in Lectora

To include TinCanJS in the project, you need to create an HTML Extension object (Figure 1) and set the “Type” property to “Top of file scripting” (Figure 2).

Figure 1

Figure 2

Click edit (seen in Figure 2 above) and add the TinCanJS file like you would on a webpage (through a <script> tag with a relative URL). Or paste the code in between <script> tags (Figure 3).

Figure 3

Something to note: any code in an HTML Extension has to be valid HTML, so if any JS added isn’t inside a <script> tag, it will break.

Next, to create the screenshot of the page, use html2canvas. You’ll need to add the html2canvas source code the same way you did for TinCanJS. If you want to capture and send the current document, i.e. the page where you loaded the JS, pass “document.body” to the html2canvas() function. This function returns a promise, so use a .then() to process the screenshot. The parameter passed to the .then() is an HTML canvas object, so to get the content and the content-type, we have to use the canvas.toDataURL() function. The format for a DataURL is as follows:

data:[<contenttype>][;base64],<content>

Figure 4

You will need to parse this string to get the content-type and the content itself (code for parsing shown in Figure 4). The content will be the raw binary data, which is what should be placed in the content section of the attachment.

In the code shown in Figure 4, cfg is the object that contains all of the other parameters of the statement. Cfg.attachments is an array that holds all of the attachments associated with that statement. Note that the code shown in Figure 4 happens after you have set up both the LRS and the other parameters of the statement in your Javascript.

Once you send the statement, you can run queryStatements() on the LRS, which will return a StatementsResult object. When you run queryStatements(), be sure to set the “attachments” flag to “true” (shown in Figure 5). This flag lets the LRS know to return both the statements and any attachments that it has.

Figure 5

Once the StatementsResult object is returned, you can iterate through its list of statements until you find the statement that has the attachment. To download the file, you’ll need to run the following code:

var link = document.createElement(“a”);
link.download = “Test.png”;
link.href = “data:”+<attachment>.contentType+”;base64,”+<attachment>.content;
link.click();

Where <attachment> is the TinCan.Attachment object whose content you want to download. This code reconstructs the dataURL, and then uses that to download the file. One thing to note is that the file extension of “link.download” should match the filetype of the attachment (if the file is a .jpeg, it should be .jpeg, if it’s a .pdf, it should be .pdf, etc.).

Customize for your needs

This is a basic guide for creating, sending and receiving attachments inside Lectora. It can be completely customized to your needs. For example, the object passed to html2canvas() can be any HTML element, not just the entire document. Therefore, if you only wanted to print a certain <div> on the page, you can pass that element instead.

Also, the TinCanJS library is designed to make sending and receiving attachments easier for the user, so the queryStatements() function handles verifying that the right attachment content is put with the rest of its data and attached to the correct statement.

If you have any questions implementing these steps or are curious about how we can help you with xAPI in general, reach out to us. In the meantime, we’d recommend checking out the free LRS in SCORM Cloud and the xAPI Open Source libraries.

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

How to share statements

Posted by

Categories: Experiments, Ideas, LRS, News, Use Cases, xAPI

Posted 30 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.

In the previous blog in this series I outlined five realistic scenarios in which an organization might have multiple LRS to share data between. This last blog dives into some of the technical approaches to share statements between two LRSs. If you’re looking more for how to set up Statement Forwarding in SCORM Cloud or Watershed, take a look at the News to Me: Statement Forwarding blog too!

how-to-share

One way sharing

One approach is to have one LRS share its statements with another. This means that all statements in one LRS are transferred to another, but any statements already in the second LRS are not transferred back to the first. This can either be achieved by one LRS sending statements to another, or by one LRS querying another for statements.

Two way sharing

An extension of one way sharing is to additionally share statements in the other direction such that all statements in each LRS are shared with the other. This can be achieved by:

  • Both LRSs sending their statements to the other.
  • Both LRSs regularly querying the other LRS to fetch statements.
  • One LRS sending it’s statements to the other LRS and also querying that LRS for statements.

Man-in-the-middle application

It’s also possible to share statements using a 3rd party, man-in-the-middle application that sits outside the LRSs. This kind of application is configured to fetch statements from particular LRSs and send them on to other LRSs. The application doesn’t necessarily store the statements itself, it just fetches them and sends them on to their required destination.

Download and upload

Finally, statements can be between LRSs by downloading the statements as a JSON document from one LRS and uploading it to another. This method is particularly valuable for transferring statements where the LRSs are not able to directly connect to one another due to connectivity issues or security restrictions.

These methods of sharing are outlined in more detail in the whitepaper co-authored by the project collaborators. We’ve produced a screencast demonstrating the project proof of concept 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!

 

3 Comments
 

Why share statements?

Posted by

Categories: Experiments, Ideas, LRS, Use Cases, xAPI

Posted 23 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.

In the previous blog in this series, I outlined an experiment we conducted to share statements between three different LRSs as a proof of concept. This blog outlines five realistic scenarios in which an organization might have multiple LRS to share data between.

why-share

LRSs owned by different stakeholders

One use case for sharing statements that’s already happening in the wild is product vendors maintaining their own LRS and also sending the data to the customer’s LRS. This might include authoring tool vendors, content vendors, LMS vendors, indeed any vendor with a product that generates statements.

Getting data out of or into an LMS

An LRS can either sit inside an LMS or be a separate product outside of it. Some organisations may have both an LRS inside their LMS and an external LRS that connects to a variety of different data sources. In these cases there is a need to share statements between the LMS embedded LRS and the external standalone LRS.

Migrating to a new system

When choosing a shiney new learning platform, it can be tempting to think it will last forever. All things come to an end though, and having a plan to get your data out when the time comes is vitally important. If you store all your learning records as statements in an LRS, statements can be shared with the new LRS when the time comes, making that part of the data migration incredibly straightforward. You then only have to worry about data not stored in the LRS! This is an important use case of statement sharing.

Pushing statements to a non-LRS system

There are a number of systems other than LRSs that use statements in some way to do some thing. Here’s some examples:

  • A business information tool might use information contained in statements alongside other data to deliver business intelligence and provide other functions.
  • A Training Delivery System might deliver performance support materials to learners at the point of need based on their activity as tracked in statements.
  • A credentialing, certification or badging tool might award credentials, certificates or badges based on achievements reported in statements.

Multiple LRSs within an organization

There are a number of reasons why an organization might have multiple LRSs. For example:

  • Following a merger of two companies, where both companies had their own LRS.
  • In a large organization with autonomous departments that have their own systems.
  • An organization spread across multiple sites and/or countries.
  • An organization including sites or operations with limited or intermittent connectivity such as a disaster zone or a ship.

These scenarios are outlined in more detail in the whitepaper co-authored by the project collaborators. We’ve produced a screencast demonstrating the project proof of concept 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!

2 Comments