In a recent hangout with Megan Torrance, the use of existing authoring tools was identified as a free option when looking to getting started with xAPI on a budget. So we sought to get some expert advice on just how up to the tasks such tools may be.  Enter: Sean Putman.

Sean has been in and around the xAPI community since it first existed and has done a huge amount of research into authoring tools and their usage of xAPI and over the course of an hour, gave us his insights to the current state of play, highlighting some common problems and issues with using these tools and xAPI, and sharing his best practice advice too.

The full session recording is available at the bottom of this post, but if you’ve only got time for the highlights, read on…

Authoring Tools and the xAPI

In short, although xAPI is relatively new, most authoring tools already support the spec – albeit to varying degrees. Most will let you generate statements that show you things that SCORM would show you but in an xAPI format, but others have a bit more capability.

What this generally translates to is that other than “screens viewed”, you’re not really going to get much usable information out of the box.  Where they come in useful however, is in affording you a prototyping-esque insight into how xAPI works, and to get a feel for what xAPI statements look like.

xAPI Statement Capabilities

To date, Sean has done in-depth reviews of Articulate Storyline, Adobe Captivate, Lectora and Claro.  Each of these tools will allow you to send xAPI statements, but with different levels of customisation available to you.

In Storyline and Captivate, by default you’ll get pre-described verbs, but these may be quite basic (e.g. “completed” as a response to quiz questions), and you are stuck with what they have pre-set, so you can’t really customise it.

Sean’s pro tip: If you’re using these tools, then it’s important to properly name screens/slides to ensure that your xAPI data is meaningful, and not just, e.g. “Joe experienced Slide1”.

Lectora and Claro are further ahead, and allow you to generate an xAPI statement for anything on a page as well as selecting the verb used for that statement. Claro also allows you to create custom verbs and use Activity IDs on objects throughout courses.  Also, whereas click/reveal actions in a course need to be build on separate slides in Storyline, Clara and Lectora allow you to use more traditional instructional design methods, rather than designing for the xAPI.

Sean’s pro tip:  “Experienced” doesn’t really give you a great detail on what a person did, so having more control over what verbs are used is very useful.  Similarly, not being able to see what people do on a slide kind of misses the point of xAPI.

It is also important to note that – with the exception of Storyline, which can be hacked – all Authoring Tools at present can only send xAPI statements; they can’t “get” or react in response to other activity statements stored in your learning record store (LRS).

Launching Packages

With SCORM, as long as you’re using a SCORM-LMS system, you could just launch the package. In the xAPI world, this is different as the package could be stored anywhere and in any format.

Sean recommends the Grassblade plugin for WordPress as it will allow you to launch content in a similar way to SCORM (it’s simple and easy to use).  But there are also a few custom tools that will enable you to launch and set end points with the right coding  (such as being able to customise the URL that sets the end point and asks for Actor info); and most tools have an HTML file that launches the course that can also be customised. (Claro has its own CMS-type system that you can use to launch content from.)

If your LRS still ties into an LMS, you can still upload the content there, and the Learning Tools Interoperability (LTI) Standard – largely used in Education settings at present – also allows you to pass credentials between systems.

Security Issues

People worry about putting LRS credentials into client-side packages of content, but using Grassblade means you don’t have to launch from a client-side tool. Many LRSs will at least encrypt logins these days, so although they are more secure that they once were, there are still some security issues.

Some LRSs, such as Learning Locker, overcome this through the scoping of authentical tokens, meaning, for example, that data can only be sent one way, or for the current session.

Should xAPI be seen as a SCORM Replacement?

In Sean’s view, this is a case of “apples and oranges” as xAPI gives you much more information to use in conjunction with other enterprise systems, enabling you to understand whether your learning interventions are having a bottom-line impact on the business.

For example, xAPI can be used to help identify potential design modifications by understanding how learners are interacting with courses (such as for capturing performance & skills, through mouse clicks in software applications). And whereas SCORM will show you the progress of a learning through a course, it won’t tell you what else they were doing; xAPI also allows you to see what’s happening outside of the LMS whilst they are working through the course itself.

The Need for a New Design Approach

For L&D to become highly functional in the use of xAPI there needs to be a skill set change and more technical understanding.  Although you don’t have to be a coder/developer, an understanding helps as you will need to think differently about your design approach: thinking about data as early as possible, thinking about designs in a different way.

It’s important that you don’t design for data, but have the data in mind that you need to see at the end. You don’t have to be a data scientist, but have a basic understanding of what you’d like to do/measure.

From a learning path perspective, these are mapped in the LMS but aren’t necessarily in the course. If you want to track the journey from novice to expert, xAPI data can identify that a certain blog post has helped a bunch of people and so can be more formally pulled into the course (quite literally in the case of curated courses using tools such as Curatr).   

This machine learning, of being able to identify that “other people did this, so we think you might want to also”, is something Sean calls “mentoring by cohort”. Understanding how people got from point A-to-B is important, but should not be agonised over by designers, but what might be the perfect content/journey for one person may not be the same for someone else: it is better that people find their own path through curated content.

Get The Full Picture

Watch the full hangout recording below to get more of Sean’s expert knowledge and advice.

Sean’s research also features heavily in Level 2 of our Introduction to the xAPI MOOC (which this hangout was part of).  If you’re not already on the course, it’s not too late to join – just head over to the course hubpage for more information and get started today.

[