- Get Started
- Write Code
Posted by Andrew Downes
Posted 14 April 2015
The prototypes have been with us since the beginning. Recently I’ve given them an update from a tracking design perspective.
In the beginning, before xAPI version 0.9 and before you or I had even heard of xAPI, there were the prototypes. These example activities helped the world see the kinds of thing that might be possible with xAPI, and provided a reference point for early adopters and developers to see how statements could be sent and retrieved. I used the Golf example as a reference when building a xAPI wrapper for Captivate 5.0 swf files a couple of years ago.
Over the years, the prototypes have been updated to be conformant with the latest released version of xAPI, now 1.0.x. They are now less important in illustrating what’s possible with xAPI because there’s actual real life products doing exciting things in the real world. They’ve continued to be a good starting point for developers to see the mechanics of how xAPI works.
The prototypes were never designed to be examples of good practice or to illustrate the best statement structure. They weren’t supposed to tell you exactly what data you should track or which verbs and activity types you should use. In fact, the prototypes were created at a time before we had good practice in xAPI. Whilst we’ve updated them to be technically conformant with each version of the specification, we’ve not touched the actual data that was sent and events we were tracking.
As I’ve been working with various xAPI adopters, it’s become apparent that many are looking at the prototypes as a design template for what statements to send and the properties to include. Many adopters have looked beyond the prototypes to the various blogs and guides available online, but the prototypes are a significant influence on how people are designing their xAPI statements.
I’m also dishing out plenty of advice on how to implement xAPI well, but a lot of the times the prototypes weren’t following that advice. I figured it was time to apply that advice to the prototypes and the data they’re sending.
The statements generated by the new prototypes will not be compatible with the old ones, so if you’re using the prototypes for testing, you’ll need to keep this in mind. In fact, one of the reasons we’ve held off updating the prototypes is that we didn’t want to break anyone’s use of them. You’ll need to consider this issue of backwards compatibility as you come to update your own products.
The easiest solution is to get the design right the first time, but that’s not always possible as requirements and best practices develop over time. We work around this issue in the new prototypes by tagging every statement with a Recipe Id as a “category” Context Activity. The next time we update the prototypes, we’ll also update the Recipe and update the Id to point to the new version. Any tools reporting on the prototypes could use that property to see which version of the statement structure is being used and handle the data accordingly, though the reports included with the prototypes don’t yet do this.
There’s still more that could be done to improve the design of the prototypes and take full advantage of xAPI. These are prototypes, not products, so I recommend you look to other sources (like this blog or my eLearning Guild course) for advice on how to best design your tracking. That said, the prototypes are now providing a better base line for you to build and improve on in your design and development.
Some examples of how the prototypes could be developed further are:
We may get onto these in the future, but for now, please consider how you might apply them in your real-world products!
If you’re sending xAPI statements and would like somebody to review and feedback on your tracking, we’re happy to help; please get in touch.