03 Jul No knot unties itself: Creating an xAPI learning system
tessello’s primary architect and Brightwave’s Chief Technology Officer Jonathan Archibald recounts the early conception of the total learning system, and looks at why working with xAPI brings a new dimension of opportunities – and challenges – to the world of learning technology.
Project Tin Can, as it was then known, soon to be known as Experience API and finally xAPI, was conceived by Advanced Distributed Learning and Rustici Software to be the next generation of SCORM. Back in 2012 the standard was still very much a work in progress, but from the early buzz in the developer community it was clear something interesting was happening, and a few forward thinking (and/or foolhardy!) organisations started developing platforms and solutions for this new specification. We wanted to turn its promise into practical, concrete products to change the way learning is practiced.
This is when I got involved. Like many others, my Brightwave colleagues and I started investigating xAPI as a one-to-one replacement for SCORM, but it didn’t take long to realise we were dealing with something more. We realised we had something entirely new – something that could capture any form of learning whenever and wherever it happened.
This was a defining moment of my professional career. xAPI changed the way I think about what we do as learning professionals: for too long our creativity had been shackled by SCORM and what it could (and couldn’t) do. The xAPI was our future – it still is – and we could not wait to get started.
The xAPI specification was still pre-v1.0. There was a lot of hype but very little in terms of usable applications or code. There were prototypes and a handful of early commercial offerings, but nothing which would meet our needs or those of our clients. We had two options: wait for the market to catch up, or build our own.
We chose to build our own.
Building an xAPI learning system
But build our own what? To answer this most simple question we had to start afresh and really understand what we were dealing with, from a technical developer’s perspective. The most important discovery was that xAPI is not just an Application Programming Interface which allows software applications to talk to each other. Realising its full potential to revolutionise workplace learning would in fact require the creation of an entire ecology of interweaving tools and systems:
1. Activity provider(s)
Activity providers are software applications that create xAPI learning statements. We developed three: a bookmarklet for learners to save web pages as they viewed them; a mobile application to capture real-life learning experiences on the go (audio, video, photo, QR etc.), and a powerful wizard for creating varied learning experiences.
2. The API
In the xAPI ecology, the API itself is the gatekeeper and enforcer: it sits in front of the Learning Record Store and manages the data in and out of the LRS. Activity Providers connect to xAPI via the web and send it formatted learning statements. Other applications – such as an LMS – then connect to the API and extract user learning experiences.
3. Learning Record Store (LRS)
This is the technology which stores xAPI learning statements – like a database of xAPI statements, unique to the learner. However the demands on an LRS in terms of expected load, and complexity, size and variance of xAPI statements are quite different to a regular database.
4. Next generation LMS
The first three components handle capture and storage of learning statements – but those are still just cold data. What makes xAPI really interesting is what you do with them. An xAPI LMS pulls statements out of the LRS via the API, and combines them with the user’s learning records and history to create an individualised picture of their learning journey. This is where the technical capacities of xAPI intersect with current trends towards social and informal learning: xAPI turns individual experiences into learning resources, which can be validated and shared across an organisation.
We started development in isolation but we soon discovered real progress was impossible without the wider xAPI community. As the specification was as yet unfinished, there were unforeseen issues we had to solve as we approached them, and we took several wrong turns. The community guided us through the maze with support, code samples and indispensable advice. We went straight to the open source spec and the core xAPI team, and could raise issues, ask for clarifications and eventually take pride in our own contribution to its evolution.
xAPI as a standard can only take your ideas so far – interpretation is everything and it’s easy to go off in unproductive directions. The spec has matured and is easier to work with today, but the community remains an essential resource for anyone designing xAPI systems.
Eventually we developed an xAPI-conformant total learning system, incorporating three activity providers, an LRS and LMS into the API. But I feel as if we’re still at the start of the journey, having just scratched the surface of this industry-defining standard.
The next challenge is still to be met: using xAPI to rewire the practice of workplace learning itself.
Follow Jonathan on Twitter: @JonArchibald