Posted on 28th June, 2013 by LEO Learning Web Team
This post was written by John Helmer and first appeared on the LINE blog on 28th June 2013.
John Helmer reports from the Learning and Skills Group Conference June 18th 2013, Olympia 2 London.
The Tin Can API (also known as the Experience API) was a hot topic at this year’s Learning Technologies conference in January. In the meantime, version 1.0 has been launched, and there has been a lot of discussion about its possibilities. So I was interested to hear what Rusticci’s Megan Bowe had to say about the questions to which minds were inevitably turning, after the first flush of enthusiasm. How easy, or difficult, will it be to implement, and how widely is it being adopted?
To take the adoption question first. Tin Can seems to have been most popular with content developers so far. Granted, some of these companies also have LMS solutions, but the slide that Megan put up seemed to be a bit light as far as major LMS providers go – with the exception of Blackboard and Sakai.
Many of these companies have elderly software and might have difficulty incorporating Tin Can support, others may be waiting to see whether the standard takes off or not (previous updates to SCORM have been less than successful). And of course, many might just not have gotten round to it yet. Tin Can is still very new.
Megan showed some examples of implementations Rusticci has been involved in:
- Vanderbilt University Medical Centre
- Altair Hyperworks
- University of Michigan Health System
It was notable that most of these were programmes with a clearly identified business goal. Vanderbilt University Medical Centre, for instance, was an initiative that aimed at bringing down infection rates through more hand washing. Altair Hyperworks aimed at decreasing support costs and improving customer satisfaction. While the Metryx project was about improving teacher efficiency in a blended environment.
Tin Can promises a great deal in being able to track results against activity in such learning programmes.
I’m not going to report everything Megan said because a lot of it was material we have already covered on this blog, but aside form the adoption question three things stuck out for me as being new information.
It seems that the Learning Record Store (LRS) is being positioned as a central hub, that will bring together data from a number of sources such as LMS, LCMS, CRM, POS, HRIS, ERP (enough TLAs for you there?) and provide meaningful as opposed to generic reporting and visualisations by combining different data streams. This seems to me a movement on from January, when we heard simply that the LRS could sit either inside or outside an LMS.
We heard about something called a Personal Data Locker (PDL) where learners’ individual activities and results can be centralised using Tin Can. See http://watershed.ws for a demonstration of how this works. This sounded a lot like e-portfolios to some in the audience, but it also raised the issue of whether the data would belong to the individual or the organisation – i.e would your PDL be portable to your next job?
In fact much about Tin Can turns out to have data issues – should the organisation have to tell its employees when and how it is gathering all this information about their work activities, for instance?
Lastly was something that may well turn out not to be an issue at all, but which rang slight alarm bells for me. A lot of the power of Tin Can lies in its flexibility; the fact that the three-part statements it uses (noun, verb, object: e.g. John completed Marketing 101) can be used to describe and record almost any kind of activity L&D departments might need it for. However this very flexibility become a problem when you are gathering a firehose of data and need to report on it using consistent terminology – ie did John ‘complete’ Marketing 101 or ‘take’ the course or ‘do’ the course ..? You have to define your verbs properly in order to make the information reportable.
On the Tin Can site there is a registry you can access. This gives definitions for basic terms such as ‘assessment’, ‘course’, ‘interaction’, etc. which anyone can make use of in defining their verbs.
But here’s the thing.
As you move beyond these basics into learning and performance activities that might be particular to your business sector, to areas of professional practice, or activities that only ever happen within your own organisation, you are slightly on your own. This takes you into areas of ontology, taxonomy and thesauri that are familiar to librarians, but not the preserve of the average training manager.
It also poses a problem that the more specialised an organisation’s use of Tin Can becomes, the less portable becomes the data it produces – an issue for PDLs but also for other types of integration. One alternative is for organisations to coalesce around more generic forms of Tin Can, confining themselves to off-the-shelf registries, which slightly dumbs down the whole idea. Flexibility versus simplicity.
This question has an effect on uptake, since it can tend to increase the complexity of the proposition, and adds costs to implementation.
And on the latter point, a further thing we learned is that while getting Tin Can to generate statements from learning activity is relatively easy, the hard and more expensive part is getting that data into the LRS. Integration costs could be high.
Tin Can is still an exciting development, but with the initial rush of enthusiasm over, now is the time to knuckle down to the serious business of implementation – and the issues that raises of cost, employee privacy, technical architectures and workflow.