DIY – Your First xAPI Project

By Sean Putman (VP of Learning and Development, Altair Engineering)


Are you ready to give xAPI a try, but not sure where to start or what it means to take a project on yourself? Having been there, I can tell you it is possible to do this.

 I am not a programmer, although I have done some HTML coding over the last few years.  I had no knowledge of xAPI prior to looking over the specification and wanting to try something. My first try was probably a lot larger than it should have been.  It resulted in a lot of data that needed to be processed.  Hopefully you can learn from the lessons that I learned as I went through my first project.  When considering your first xAPI project it is easy to get overwhelmed. However, if you work with the guidelines set forth below you will increase your chances of success.

Keep it Simple for DIY

Follow the KISS (Keep It Simple, Stupid) principle as you are getting started, especially if this is a DIY project. Start small. Trying to start with a project that’s too large can produce mountains of data. Wading through all of that data becomes cumbersome and tedious, especially with a lack of high end analytics tools. If you have access to data scientists or some high end software it can scale up a bit. However, it is still a good idea to keep this first project relatively small.  What does a good first project look like?  That question can be answered by how brave you are.  Here are a few ideas for starting something small:

Course Activity – Have you always wondered what content inside a course people are accessing?  xAPI provides a perfect opportunity to do that.  See what people are accessing and what patterns emerge from that data.  It is an approach very similar to how people useGoogle Analytics.  Remember to keep it small and with a small test group to start with.

Process Capture – Do you have access to a programmer?  A useful piece of software with an API that could provide information?  You can design a set of statements to help gather data about the process.  Potentially, you’ll find answers about where people struggle, where can you provide an intervention, and if expanded into a course activity project, determine if the intervention actually helped.

Tracking answers from assessments – While there could be other ways to do this, you could use xAPI output to analyze the answers users have given to assessment questions.  Most rapid development tools will provide this in their output anyway, so the analytics is where this project can really show its value.  

What Are You Trying to Answer?

Identify one question you are trying to answer from the project. Having this question at the beginning of the project will help you figure out what data you will need to gather. In this early phase of defining a research question, treat the project like a scientific experiment. Create a hypothesis that tests an answer to your question and what the outcomes might be if the hypothesis is true. The hypothesis and those outcomes will form a guideline for gathering and analyzing the initial data that you collect. It is important to remember that you might prove yourself wrong. This is a good thing! Be willing to be wrong and iterate, defining more questions and forming more hypotheses to test — pivot your questions or project as necessary. The best answers can come from being wrong the first time.

Control Group

Like a good scientific experiment you will want to define a control group. That might mean running the process (ie, course material, software, etc.) yourself or with a known entity to get a baseline of the data that will be collected. By running through the project as an early prototype, you can initially gauge whether your questions can be answered by the chosen process. This is another great opportunity to make changes before expanding to a larger audience.

Building the Initial Prototype

Here is where it gets fun and tricky: building the first prototype of the project. Yes. You should prototype your project. Dumping something directly into a production environment will more than likely fail. The prototype allows for working the kinks out with collecting the statements. It also will be a much smaller test group than a deployed solution. When building the prototype use some of the ready-made solutions for generating statements to save yourself time and headaches. You could do this by tweaking a rapid authoring tool.

Examples of authoring tools that offer xAPI support:

  • Storyline – Out of the box support, requires minor tweaking to slide setup for tracking entities within a slide.  Tracks slide visits and quiz outcomes out of the box.
  • Captivate – Out of the box support, requires minor tweaking to slide setup for tracking entities within a slide.  Tracks slide visits and most quiz interactions out of the box.
  • Lectora – Out of the box support, offers the ability to create statements on any object via an action.  Tracks slide visits, objects that have had xAPI Statements added to their actions, and most quiz interactions.

Or using an open source library found on the web from the ADL or a vendor.

Examples of open source tools that are available:

  • Code Libraries from Rustici Software – These libraries are available for many popular code bases to help you create statements.
  • Saltbox Launcher from Saltbox – Provides a method to launch content that can report to an LRS.
  • ADL Developer Tools and Examples – A page on the ADL website that lists a number of resources and examples that you can download.

Remember, the final developed solution for production does not have to use the same tools to generate statements. To get a baseline set of statements and to answer your hypothesis a ready made activity generator will take one less thing out of the equation. If nothing else, you will have a better idea as to the tool you want to build for your production solution.

Prototype Deployment

Now as you start to deploy the prototype, especially if it is not “course” data, you can use the control group baseline to look for patterns in the statements. These patterns will start to emerge quickly. It is especially true if statements are coming from an activity provider  that is not a traditional eLearning course. Initially, it can be hard to know what statements will be created by an activity provider as you start to collect statements. The patterns will be critical to the processing of the data as it is collected from the prototype participants. Once you have started to collect the statements and look to answer the questions posed, don’t be afraid to change your approach based on the results. As data is collected you could find  what you thought might happen might not be exactly what took place.

As you go through your first project I think you will come to see that making statements is the easy part.  We can make statements in many different ways using many different tools.  The difficult part comes when we need to find value in the statements.  Spend the time to figure out what you information you are trying to get from the statements.  Be prepared that this could change when  working through the project.  Be prepared to pivot your project if necessary.  The time spent figuring out what it is that you need will pay off in the end.

SEAN PUTMAN (VP Learning and Development, Altair Engineering)

Sean Putman, the Vice President of Learning Development for Altair Engineering and the Owner of Intellectus Learning, has been an instructor, instructional designer, and developer for over 15 years. He has spent his career designing and developing training programs, both instructor-led and online, for many different industries.  Sean has also spent the last few years focusing on the use and deployment of the Experience API and its effect on learning interventions.  Sean has spoken at many industry conferences on xAPI and related topics.

Speak Your Mind

This site uses Akismet to reduce spam. Learn how your comment data is processed.