There are many people in the learning community who have varying relationships with technology. Some love. Some hate. Some love to hate. The only thing that I can really do is lay out options for starting. It mostly depends on how comfortable you are making technology bend to your will.
No matter how you want to go about this you will need two things: something that makes xAPI statements (an ‘Activity Provider’) and something that receives statements (a Learning Records Store — LRS). With these two things you can track interactions and collect the data for analysis.
The activity provider is whatever your user is interacting with. In real time or at regular intervals, the activity providers share the data about the person’s interactions with the LRS. Activity Providers can take many forms. Mobile applications, web applications, software of various forms, sensors, and beyond.
LRSs can also have a few incarnations: hosted, integrated or installed. They can be hosted, meaning an online service that keeps your data on someone else’s servers (you can call it the Cloud if you want, but it’s less light and fluffy than you would imagine). You can sign up and start using hosted LRSs right away. Integrated LRSs are generally tied into another piece of software, like an LMS. They are a component of the software and have to be worked with through that software. LRSs can also be installed. This means that the LRS is built by you or us and placed on one of your servers. This way you have total control of your data and uptime as well as the reporting and visualizations you have add on top of your LRS that make sense of your data, in your context.
Plug and play please — “Stop naming programming languages!”
There are a number of vendors who have software and applications available in the market right now that will make xAPI statements. You can go pick up one of these right now, point it to a hosted LRS and see statements move. What you should know is that many activity providers are using xAPI to move their data, but few let you choose where this data goes right out of the box. When you’re considering using a tool because it uses xAPI, ask how you can get the data into your LRS. It may be that you have an interface in the tool to set it up, it may be that there are a lot of modifications to be made.
For a courseware example, here’s a post on how to use Storyline with the LRS in SCORM Cloud. Any authoring tool that publishes packages for xAPI should work in the same way with SCORM Cloud. If you’re wondering how you can do this, take SCORM Driver for a spin.
There is a wordpress plugin called Grassblade that allows you to track many different types of interactions in WordPress and choose the LRS that your statements are sent to.
You can also check out Tappestry in the app store. Also, go to http://watershed.ws and register with the same email address you plan to use when you sign up for Tappestry. You will see the xAPI statements from Tappestry flowing into your personal (hosted) LRS in Watershed.
Frontend, for sure — “I’ve got a good handle on HTML, CSS, JS, and the like”
This is where it gets a bit more fun, you’re not totally reliant on vendors to build tools that give you access to your data. We have a number of open source libraries that you can use to start making statements from custom content. Using these, you pick which interactions make statements and get them flowing into the LRS of your choosing.
Kicking ass and taking names — “I’ve got a good amount of development under my belt, and maybe a few skeletons in my closet”
Aside from Flula* jokes, this is a fun place for you to be. You could build your own client library if ours don’t cover what you need. You could go on an Arduino dive and create an elaborate collection of sensors that make statements, like our friends at Hybrid. Imagine tracking how a pilot is using the switches and buttons in a cockpit.
You might consider attempting to build your own LRS, but that’s a lot of work. The spec lays out rules for how an LRS should behave but it doesn’t say how to build it. This is on purpose. If we defined a programming language, database structure, etc, the technology would likely be outdated before the spec was ready to move to the next version.
If an LRS isn’t the challenge for you, consider trying your hand at building a reporting layer. You can use the 4 sub-API’s in the spec to pull your data out of the LRS to fuel reports and visualizations.
