- Get Started
- Write Code
Posted by Kirsty Hughan
Posted 18 April 2018
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.
Posted by Tara Morey
Posted 11 April 2018
After attending a number of xAPI-focused sessions at Learning Solutions Conference plus attending xAPI Camp before LSCon kicked off, I was astounded to see such a clear theme emerge when it comes to the spec. For xAPI practitioners, the recommendation is to “crawl, walk, run.”
This was a theme echoed by RISC, HT2 Labs, TorranceLearning, Watershed, xapiapps, Riptide Software and our very own Chris Tompkins in his session, “xAPI in your RFP.” All of them recommended that to get started it is wise to start small. Begin by mapping out a few key data points you need to prove your success. The key is to align your L&D goals with your company’s overall business goals.
For example, the benefits of a sales training course could be proved by a resulting increase in revenue. To prove this true, you’ll need an ecosystem of tools such as a sales management application (like Salesforce), an LMS and a learning analytics platform or LRS. Connecting the dots between the tools using xAPI can allow you to correlate learning experiences to meaningful metrics in your organization. Once you’ve been able to start small and prove the value of using xAPI for your training, then you’ll be able to tackle adding additional integrations within your organization’s ecosystem such as an HRIS, customer support platform, etc.
TorranceLearning’s Megan Torrance had a great take away in regards to ecosystems, she said, “It’s unrealistic for you to expect one system to do it all.”
Similarly, Steve Forman at InfoMedia Designs remarked, “It’s no longer build vs. buy–it’s assemble. Your eLearning ecosystem will be designed specifically for your organization and use case model.”
Our own Chris Tompkins reminded us that even though it’s exciting to use xAPI because it’s new, you want to be sensitive to choosing the right tool for the job. He advised, “Don’t just assume you’ll need xAPI.” Each of the standards (SCORM, xAPI, cmi5 and AICC) has specific strengths, so it’s important to begin by identifying why you need xAPI and what you want to achieve using the standard.
Leaving Learning Solutions, I felt inspired and excited to see other attendees use an agile approach with xAPI to get started. Just remember: xAPI can be tough to kick off so be ready to test, fail and iterate.
Posted by Kirsty Hughan
Posted 11 October 2017
Last week, the Department of Defense (DoD) signed the updated DoDI 1322.26 Distributed Learning (DL). The latest DoDI advises all entities within the DoD to procure eLearning technology solutions that are compliant with the SCORM or Experience API (xAPI) specifications.
This Instruction replaces the 2006 version of DoDI 1322.26, “Development, Management, and Delivery of Distributed Learning,” which mandated (as opposed to advised) the use of SCORM in all eLearning technology used by the DoD. With the updated DoDI released, DoD entities can source the right DL solution based on their requirements, as opposed to being limited by the SCORM-focused scope of the older Instruction.
The 2006 DoDI required any DL technology to be SCORM conformant. After xAPI was released in 2013, it was hard for government organizations to purchase modern products as xAPI was not supported by the existing Instruction and there was no way to verify if an xAPI solution conformed to the specification. Now, government organizations have the flexibility to procure the right technical solution based on their requirements, and a means to verify that the products conform to either SCORM or xAPI.
We are excited because this is the culmination of a lot of work for many people at both ADL and Rustici Software. In 2015, we at Rustici were awarded a BAA from ADL to help them revise the 2006 DoDI 1322.26. You can read more about that story on the Rustici Software blog if you’d like.
Lucky for you, ADL recently launched a list of Conformant LRSs as part of their xAPI Adopter Registry. If you’re looking to procure an xAPI conformant LRS, this is a great place to start. If you’re looking for resources about xAPI conformance, check out the official xAPI reference and support resource for DoDI 1322.26.
Posted by Freddie O'Connell
Posted 24 January 2017
You’re going to hear us talk a lot about semantic interoperability this year. So we might as well present a working definition.
Semantic interoperability is when information—the meaning behind captured data—is portable and well understood by any subsequent system requesting and reviewing it.
Why will we be talking about it a lot? Because without semantic interoperability, the Experience API (xAPI) has a limited future.
For us, semantic interoperability in xAPI will be achieved when there is a generally accepted information model. We expect profiles to help with this a great deal. There’s a strong possibility that collaborative work between ADL and IMS could help a great deal.
Consider SCORM, the usage of which remains widespread in LMSs everywhere. The CMI data model leveraged by SCORM is closely linked to its information model. There is a finite set of data that can be recorded about the types of learning experiences common to online training, and summarizing information from that data is a relatively straightforward exercise. So straightforward, in fact, that practitioners have long cared primarily about a big four—score, completion, satisfaction (i.e., pass/fail), and duration. SCORM makes requesting and understanding the big four easy.
xAPI, on the other hand, is fundamentally a communication protocol applied as a specification for elearning. In xAPI, apart from a few familiar holdovers from SCORM (the big four, native support for interactions), there is no limit to what can be captured about a given learning experience. One could literally choose any verb available in any language. Or one could create a new activity definition to describe any type of experience.
Can you imagine how difficult it would be to report on data with so few constraints? We can. Because we’ve been trying.
Even when there is consensus that a concept has sufficient value to merit a profile, there can be difficulty. Take video, for instance. Not only is there a profile in our Registry, there’s also a Community of Practice still working on a version. If there are multiple working versions of what data to capture, then how is a reporting system attempting to derive meaning about “video” supposed to do so?
We think the answer right now is: leadership. The concept of Registry has utility to semantic interoperability in xAPI, and we have a feature roadmap for it. Still, we recognize the difficulty in a single industry participant to establish credibility and trust.
What would alternatives look like? We think ADL could assert an information model. As a subtle alternative, ADL could host a collaborative process with some authority. This might look like the establishment of a baseline with a community process similar to how the specification itself operates now—managed workflow in GitHub supported by regular calls.
Expect to hear more from us on this topic because we think it’s critical to the future success of xAPI.
Posted by Andrew Downes
Posted 25 August 2015
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.