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 "Experiments" Category

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
 

A Tale of Three LRSs

Posted by

Categories: APIs, Best Practices, Experiments, LRS, Use Cases, xAPI

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.

three-LRS

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!

7 Comments
 

Which xAPI tools would you like?

Posted by

Categories: Announcements, Experiments, Ideas, xAPI

Posted 11 March 2014

 

We’re building free tools for the xAPI community, and we want to know which ones you’d like us to build.

Back story:

We’re trying a special project. We’re hiring interns to build some of the xAPI tools that we don’t have the time to build on our own, but we want to be smart about it. We want to build the tools that you want, and the tools that you’ll use.

Please take a second (well, more like a minute or two) and click on some checkboxes in our one-page survey.

We’ll look at your votes, and we’ll build the most-wanted tools!

Click here to take the survey.

2 Comments
 

Making Checklists Easier

Posted by

Categories: Experiments, Ideas, Use Cases, xAPI

Posted 11 September 2013

 

Airlines use complex software and systems for their operations. Enormous retailers have incredibly efficient supply chain management and retail operation systems. Despite these impressive systems, it’s still common for big companies to send managers out to evaluate employee performance with clipboards full of paper checklists.

When it comes to evaluating employee performance, they use these paper checklists for multiple people, which end up having to be manually entered into a computer system. Meanwhile the evaluating person almost always has a device on them that could easily capture what is on their clipboard.

We’re a little stunned by this.
MORE…

No Comments