- 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.
In the middle of last year, I made explicit a transition we at Rustici Software made, moving from the name Tin Can API to Experience API, or more frequently, xAPI. Coincidentally, we started redirecting web traffic from tincanapi.com to experienceapi.com.
And this spring, we’re in the midst of substantially reconstructing our various websites (scorm.com, experienceapi.com and rusticisoftware.com). A part of this will be making rusticisoftware.com the home of all things commercial, leaving the scorm.com and experienceapi.com websites as primarily community resources.
As a part of this transition, we have moved experienceapi.com to xapi.com, because who doesn’t prefer a four letter domain name? For reasons that are somewhat beyond me, that transition works better if we change the domain prior to changing the websites themselves. So, welcome to step one of the transition, where experienceapi.com will now be xapi.com. We’ll handle the redirects, etc, so you shouldn’t have to do anything differently at all. We’ll have further content changes for you over the next several months.
Posted by Tim Martin
Posted 14 February 2018
Political intrigue. High stakes drama. Inside baseball. This post is about something that is important but not exciting.
Facts: Next week, the IEEE LTSC xAPI TAG will be taking a vote about if and which aspects of xAPI 1.0.3 to propose to the broader IEEE for consideration as a standard.
I’m firmly amongst the xAPI pragmatists, seeking shorter term gains and use cases where xAPI is legitimately better than other solutions. This active group, the TAG, is crucial in that it will be able to explore and innovate allowing the utility of xAPI to grow beyond what is currently well supported. Simply, xAPI and its supporting technologies are already useful but not yet sufficient for everything people hope it can be. The work matters, and it needs a home. This seems to be that home.
The details come with full credit to Shelley Blake-Plock and Avron Barr for their clarity and content.
Posted by Tim Martin
Posted 29 January 2018
Just a quick note as I head from ATD TechKnowledge in San Jose to Learning Technologies in London…
TechKnowledge was a good event this year. I enjoyed presenting with Margaret Roth of Yet Analytics and Megan Torrance of Torrance Learning at the xAPI Showcase, where we shared examples of what people are doing with xAPI. We used xapiapps to survey the audience about our presentations and three different LRSs (Watershed, Yet and SCORM Cloud) to compile the survey data. That provided a good representation of how to connect different xAPI platforms and the differences between LRSs.
It was fascinating to see the variety of questions in the xAPI space these days. We had good questions about the basic players like, “What’s a learning record store and what’s a learning record provider?” And we had good questions about the underlying technologies employed by LRS vendors like, “Are they using NoSQL solutions or traditional databases? And what’s preferable?” On a continuum, these questions are at opposite ends. But they came within moments of each other. Trying to modulate the answers for an audience so diverse really keeps you on your toes.
My thoughts on these questions…
In regards to the difference between a learning record store (LRS) and learning record provider, who knew the word “store” would be so confusing? It makes sense to me now, particularly in the context of the “App Store” that we instinctively think of the learning record store as a place to buy things rather than a place to keep them.
As for the question about using NoSQL solutions or traditional databases, both kinds of data stores have their place. And some providers are actually using both. But there is no simple, clear, right answer as to which is better. And xAPI (the specification) shouldn’t have an answer to it. Technologists can though.
Overall, I really liked the slightly calmer vibe at TechKnowledge. There is a little more space for nuanced conversation with people and that was helpful to me.
Posted by Kirsty Hughan
Posted 13 December 2017
Last week wrapped up I/ITSEC 2017, the largest training and simulation event in the world. This year, we exhibited and talked with people about how we help solve problems around eLearning standards like xAPI and SCORM (along with the updated DoDI 1322.26). What was notable about this year, for me, was the introduction to a new term: “system of systems.” For those unfamiliar, system of systems refers to a collection of systems that are brought together to create a new, more complicated system that’s greater than the sum of its parts. System of systems is an idea used throughout organizations or softwares, but at I/ITSEC, many people were talking about it in the context of xAPI.
It’s safe to say that every DoD agency uses multiple systems for training. They may have one or multiple LMSs, AR tools, VR tools, authoring tools, content management tools, physical simulations, in-person training..the list can go on. Because of the complexity of their ecosystem, they must think strategically about how each system works within the whole. Thus, the idea of a system of systems.
What arose in conversations at I/ITSEC was how well-suited xAPI is for supporting the creation and reporting on a system of systems. xAPI is at its core a communication protocol that helps multiple, separate pieces communicate in the same way. Using xAPI, the DoD could connect experiences from in-person training to those in an LMS.
We saw some great tools that leverage modern technology for training, particularly when it comes to AR and VR. Traditionally, each of these tools would be self-contained. But with xAPI and a systems of systems approach, each of these tools can become part of a larger plan that connects disparate systems and experiences.
We look forward to learning more about how DoD agencies (or those outside the DoD too!) use xAPI to support the creation of their system of systems. If you ever have any questions about how you can do this or how we’ve helped other clients create their ecosystem, let us know. We like talking about the standards.