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.
Until now.
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.
We have…
- Updated the index page to make use of Context Registration and issue a ‘launched’ statement. This now serves as a closer example of how we’d expect an LMS to behave when launching content. Registration is now a required property in the config file.
- Refreshed the verb, activity type and extension IRIs used throughout to include a wider range taken from the Registry (which didn’t exist when the prototypes were first born). Instead of reporting ‘Andrew experienced the Country Music Hall of Fame’ in the locator prototype, we now report ‘Andrew was at the Country Music Hall of Fame’. Much better.
- Documented all the verbs, activity ids, activity types and extensions used and recorded this in a Registry profile.
- Added ‘initialized’, ‘terminated’, ‘suspended’ and ‘resumed’ statements and made some other changes so that we do a better job of tracking session and attempt duration. Duration tracking is one of the most common xAPI related questions we get. We included a couple of additions to TinCanJS’s utility functions to support this. (More on duration tracking in a blog sometime soon!)
- Improved the way bookmarking data is saved in the Golf example to give an example of storing and amending a JSON object within the State. We included some new functionality in TinCanJS’s setState method to make this possible.
- Improved the tracking data sent when switching players in the Tetris example.
- Added a ‘Save & Exit’ button to the Golf example as an example of good practice to avoid losing data when learners close the window.
- Added two types of “category” Context Activity to record the Recipe being used and the original source of the content (more on this in a blog soon!)
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:
- Launching activities in the same window as the launcher and returning there at the end of the activity; modifying the UI accordingly.
- Passing language preference or other learner preferences from the launcher to the activity and displaying localized or personalized content.
- More thought into the user experience of returning to an attempt within the Golf example, including saving progress within the assessment.
- Allowing the user to review their quiz answers and the content after an attempt and tracking this using the https://brindlewaye.com/xAPITerms/verbs/reviewed/ verb.
- Server side tracked versions of the prototypes, including statement signing for the Golf assessment.
- Taking recipe version into account within the reports.
- More interesting and visual reports and dashboards targeting different stakeholder groups.
- Move varied use of media including xAPI tracked video and audio within the Golf example.
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.
