In preparation for the xAPI activities at Learning Solutions Conference and Expo 2019, this article is an update to the July 2018 Learning Solutions "xAPI: Out of the Box" report on authoring tools that support the implementation of the xAPI standard.
The authors of thE 2018 report noted, "While some might still debate if xAPI is ' ready,' we feel that it clearly is here to stay, and can now make a tremendous impact on your organization through authoring tool xAPI support 'out of the box.'"
We, the current authors, still agree with that statement, as we note the ongoing evolution of those tools. And as was the case last year, we continue to note the following key points:
The standard’s key tenets include the ability to:
- Track virtually any type of learning activity
- Track any aspect of these activities
- Leverage data from these activities to drive new learning experiences
In essence, xAPI seeks to bring learning analytics and business intelligence (BI) to the learning industry, and to transform the uses and impact of learning. Authoring tools are a key piece of the way that learning technologists use xAPI. These tools enable organizations to create a variety of different training experiences. Historically, these experiences have primarily been self-paced eLearning, but today learning technologists are seeing growing use of these tools for just-in-time activities, performance support, classroom-based materials, and more.
The possibilities of xAPI are enormous, but its implementation and execution across different authoring solutions can vary greatly. Because xAPI is an open standard, tools that enable “JavaScript tweaking” can provide programmers an avenue by which they can realize its full possibilities. However, coding is not needed, nor do we feel that it should be required. Thus, we chose to focus on providing a broad understanding of what many common tools could provide everyone, in terms of xAPI support, right out of the box.
In our research we found that there were four key areas where tools varied in their approach to and support of xAPI. With this article we seek to provide you with a better understanding of each area, and how the various solutions operationalize them. Those four key areas are:
- xAPI built-in statements: Specifically, what statements does the tool send automatically without author intervention, other than creating content?
- Custom xAPI statements: Moving beyond the out-of-the-box statements, what options are there to send custom statements in the same way you might trigger a show-image action without programming?
- Support for JavaScript: While we focused on out-of-the-box functionality, one can’t eliminate the possibility of needing to do something unique. So given this, does the tool support enabling this approach?
- xAPI deployment: While the design for publishing xAPI packages is elegant and provides more flexibility, the implementation isn’t as simple as SCORM in most solutions. We focused on the limitations, how to publish, and if there was a need to make changes post publish.
What are the tools? In alphabetical order, we reviewed Captivate, dominKnow | ONE, iSpring, Lectora, Rise, SmartBuilder, and Storyline. SmartBuilder was not reviewed last year. This article includes new features in the other six tools. Our hope is that this side-by-side approach will help in selection and use of the tools.
Out-of-the-box statements
All of the tools had a number of out-of-the-box statements. One interesting aspect of xAPI, in terms of conformance, is that currently there are conformance tests for learning record stores (LRSs), but there are no conformance tests for authoring or content creation tools. As such, we didn’t focus on the conformance aspects of individual statements, but strictly on what types of statements were provided, and any specific aspects that directly affected reporting and understanding the xAPI results. In the future we would like to see more conformance tests be made available, so the quality of the statements created could be accurately assessed.
Not surprisingly, one set of statements that all tools supported to various extents was data already available in SCORM, but now translated into xAPI format. The following information details how each of the tools captures this basic information. Last year's article presented this information in a table; to better serve readers who access Learning Solutions on smart devices, we have reformatted the information as a bulleted list.
Note: Actor refers to the user consuming the content. Generally the launching platform sends this information. Verbs refer to the type of behavior. In all cases these items are tied to a specific element (course, object in the course, etc.). In some cases the descriptive information for this element is included in the statement, but not always.
xAPI automatic built-in statements
Started / Returned to Course
? Captivate: Actor - Launched/Attempted - [activity_id]
? dominKnow: Actor - Launched/Attempted - [activity_id]; Course Name
? iSpring: Actor - Launched/Attempted - [activity_id]; Course Name
? Lectora: Actor - Launched/Attempted - [activity_id]; Course Name
? Rise: Actor - Launched/Attempted - [activity_id];
? SmartBuilder: Actor - Launched/Attempted - [activity_id]; Course Name
? Storyline: Actor - Launched/Attempted - [activity_id]; Course Name
Completed Course with Test
? Captivate: Actor Passed / Failed Course Name with score XX%
? dominKnow: Actor Passed / Failed Course Name with score XX%
? iSpring: Actor Passed / Failed Course Name with score XX%
? Lectora: Actor Passed / Failed Course Name with score XX%
? Rise: Actor Passed / Failed (activity ID URL)
? SmartBuilder: Actor Passed/Failed Course Name with score XX%
? Storyline: Actor Passed / Failed with score XX%
Completed Course with no Test
? Captivate: Actor Completed Course Name
? dominKnow: Actor Completed or Passed / Incomplete or Failed Course Name
? iSpring: Actor Completed Course Name
? Lectora: Actor Completed Course Name
? Rise: Actor Completed (activity ID URL)
? SmartBuilder: Actor Completed Course Name
? Storyline: Actor Completed Course Name
Test Questions
? Captivate: Actor (in)correctly answered “question text” with response “answer”
? dominKnow: Actor (in)correctly answered “question text” with response “answer”
? iSpring: Actor (in)correctly answered “question text” with response “answer”
? Lectora: Actor (in)correctly answered “question text” with response “answer”
? Rise: Actor (in)correctly answered “question text” with response “answer”
? SmartBuilder: Actor (in)correctly answered “question text” with response “answer”
? Storyline: Actor Actor (in)correctly answered “question text” with response “answer”
Going beyond SCORM to track common course interactions
In this next section we examined common course interactions tracked automatically by the various solutions, above and beyond what SCORM can provide.
Page Access
? Captivate: Actor Experienced Page Name
? dominKnow: Actor Experienced Page Name
? iSpring: Actor Experienced Page Name
? Lectora: Actor Experienced Page Name
? Rise: Actor Experienced (activity ID URL)
? SmartBuilder: Actor Experienced Page Name
? Storyline: Actor Experienced Page Name
Practice Questions (non-scored)
? Captivate: none
? dominKnow: Actor (in)correctly answered “question text” with response “answer”
? iSpring: none
? Lectora: none
? Rise: none
? SmartBuilder: Actor (in)correctly answered “question text” with response “answer”
? Storyline: none
Audio and Video
? Captivate: none
? dominKnow: Actor started / paused / consumed element name
? iSpring: none
? Lectora: none
? Rise: none
? SmartBuilder: none
? Storyline: none
Click Interactions (user interaction)
? Captivate: none
? dominKnow: Actor clicked element name*
? iSpring: none
? Lectora: none
? Rise: none
? SmartBuilder: none
? Storyline: none
Custom Form Fields (input boxes)
? Captivate: none
? dominKnow: Actor form action element Name*
? iSpring: none
? Lectora: none
? Rise: none
? SmartBuilder: Actor [verb] element Name
? Storyline: none
Player Navigation
? Captivate: none
? dominKnow: Actor clicked button name*
? iSpring: none
? Lectora: none
? Rise: none
? SmartBuilder: Actor [verb] element Name
? Storyline: none
Unique Items
? Captivate: none
? dominKnow: Unique tracking of a variety of built in components*
? iSpring: none
? Lectora: none
? Rise: Actor Attempted Storyline block name, Actor Passed Sorting activity ID
? SmartBuilder: none
? Storyline: none
Course Structure Metadata: Completion/Score Tracking
? Captivate: Course only
? dominKnow: Course, Modules, and Learning Objectives
? iSpring: Course only
? Lectora: Course only
? Rise: Course only
? SmartBuilder: Course only
? Storyline: Course only
* See dominKnow for more details
Support for customized xAPI
As we looked at additional tracking information, we then focused on custom capabilities. How can an author customize beyond out-of-the-box to better meet the organization’s needs?
Create Customized xAPI statements (without JavaScript)
? Captivate: none
? dominKnow: Action ? multiple trigger options ? select statement verb, type, and include title, description, and variable data as desired.
? iSpring: none
? Lectora: Action ? multiple trigger options ? select statement verb, type, and include title, description and variable data as desired.
? Rise: none
? SmartBuilder: Action ? multiple trigger options ? select statement verb, type, and include title, description and variable data as desired.
? Storyline: none
Send Custom information via JavaScript
? Captivate: Use execute JavaScript
? dominKnow: Use execute JavaScript
? iSpring: none
? Lectora: Use run JavaScript
? Rise: Not tested*
? SmartBuilder: User can run JavaScript
? Storyline: Use execute JavaScript
*Rise: Not tested, but may be possible to use the execute JS trigger in a storyline block to send statements.
Retrieve and process data from LRS (Learning Record Store)
? Captivate: None
? dominKnow: None
? iSpring: none
? Lectora: None
? Rise: None
? SmartBuilder:Use State API or Activity Profile API action blocks
? Storyline: None
Configuration and publication of xAPI packages
Finally, we examined how each tool configures and publishes the xAPI packages. With xAPI, not all content packages need to be, or are, loaded directly into the end system such as an LMS. This means that the packages often need an LRS endpoint and credentials in order to operate correctly.
Set LRS Endpoint and Credentials
? Captivate: none
? dominKnow: Configure in UI and select when publishing
? iSpring: Configure in UI and select when publishing
? Lectora: none
? Rise: none
? SmartBuilder: Select integrated LRS when publishing, or manually after publish for 3rd party LRS
? Storyline: none
Set Multiple LRS Endpoints for one package
? Captivate: none
? dominKnow: Configure in UI and multi-select when publishing
? iSpring: none
? Lectora: none
? Rise: none
? SmartBuilder: Add manually after publish
? Storyline: none
Enable a SCORM package to simultaneously track xAPI
? Captivate: none
? dominKnow: Configure in UI and select when publishing
? iSpring: none
? Lectora: none
? Rise: none
? SmartBuilder: Configure in UI and select when publishing
? Storyline: none
xAPI Wrapper
? Captivate: none
? dominKnow: Included when published
? iSpring: Included when published
? Lectora: Yes, add it manually after publish
? Rise: Included when published
? SmartBuilder: Included when published
? Storyline: Included when published
Notes and tips on the individual tools
Captivate
Captivate provides the standard statement information included in SCORM and page access.
Captivate does not have an ability to create author-created xAPI actions using their standard action trigger mechanisms. Authors can use the Execute JavaScript action to create their own unique xAPI statements.
When publishing the xAPI package you may need to do some post-publish editing. Many LRS systems require that the LRS endpoint and authentication information be part of the xAPI package. If this is the case in your situation, it will require that you edit the file post-publish and/or add an xAPI wrapper.
General Tips:
? Thoughtfully name your course and slides. Don’t use spaces in the names though, as the space will be converted to “%20” in the LRS instead of a space.
? Completion criteria set for the course will drive what xAPI verb is used in the completion information.
? Interaction data for test questions does not include all data, namely selection pairs and possible answers.
? LRS endpoint and credentials are not set in the tool, you will need to edit the published package after you publish or pass the endpoint and credentials through URL parameters in order to make this work for most LRSs.
? Actor information must be supplied by the launching platform or a wrapper. In the absence of actor information, the course will fail to launch properly.
dominKnow | ONE
When you create a dominKnow course out of the box you will get the standard statements previously noted, along with many unique statements. dominKnow provides the following automatic xAPI statements along with publish settings to enable authors to turn on/off the tracking for most of these automatic statements:
? Learning Objective and Module completion information
? Practice questions (single page and inline) responses/results
? Content search actions
? Player navigation and controls such as next, back, transcript launched, etc.
? Interaction with the content outline, such as jump from one page to another
? Form inputs (radio buttons, check boxes, slider controls, and text entry boxes)
? Access content resources, glossary terms, and citations
? Drag drop-statements
? Click interactions (including single click, double click, mouse over, branched, etc.)
? Interactions with media elements
? Component interactions (interacting with built-in components that provide tabs, flip cards, timelines, etc.)
? Authors can enable statements inclusion (or not) information about the user’s browser type, version, etc.
For custom statements authors, can use the standard action system to create unique xAPI statements that can include author-chosen verbs and types, variable data, and author-defined title and description information. The verbs and types available are based on a list of ADL and Tin Can-approved verbs and types, and are not currently editable by the author. In addition to defining their statements, authors can include dynamic values for parameters such as “success”, “response”, and “score”. This allows for integration with objects in the course (e.g., an input text field can be used to set the “response” parameter, or a variable can be used to set the “score” parameter).
When configuring xAPI endpoints, admins can set up the endpoint and authentication information that authors can utilize to select one or more LRS endpoints when publishing. If authors create SCORM packages, they can also send xAPI statements to specified LRSs at the same time. If items are reused in the LCMS system, the IDs for elements are reused and reported to the LRS as the same IDs across different content packages. The xAPI packages include a wrapper and security endpoints, and, while editable post publish, do not require any post processing for loading directly into an LRS or launching directly from a web server.
General Tips:
? Thoughtfully name your course, modules, learning objects, pages, and elements. This information becomes part of the Activity ID.
? Completion criteria set in the publishing configuration will drive what xAPI verb is used in the completion information.
? You can control the types of statements that are sent automatically with the publishing profiles and create unique profiles for different situations.
? Make sure your admin configures the desired LRS endpoints and credentials before publishing if your LRS requires these items.
? Utilize their built-in reusable learning object design and metadata to track learning objectives.
iSpring
iSpring provides xAPI support out of the box. When you create an iSpring course you will get the standard statements previously noted.
iSpring doesn’t have the ability to trigger xAPI statements other than the predefined set, nor can users use an Execute JavaScript action to create unique xAPI statements through the interface.
General Tips:
? Thoughtfully name your course and pages in the Presentation Explorer. This information will become part of the Activity ID.
? Activity ID is not fully customizable through the UI. An Activity ID should use a domain the creator is authorized to use for this purpose. You cannot customize the first part of the Activity ID.
? Has a built-in wrapper. If the launching platform does not provide Actor information, the course will prompt the learner to enter their name and email.
? Any desired edits to code files must occur post-publish (no set package template files to edit before publishing)
Lectora
Lectora provides xAPI support out of the box. Lectora supports a similar number of automatic statements out of the box as other tools, but also provides a robust Send xAPI Statement action in which authors can send a unique xAPI statement for any standard trigger. Authors can pick from a list of verbs or simply specify their own. Authors can also execute their own custom actions with a Run JavaScript action.
If your launching platform supplies the LRS credentials, you are set. If your LRS requires an endpoint and credentials, Trivantis provides an xAPI wrapper that simplifies this for Lectora projects. This wrapper is applied post publish.
General Tips:
? Thoughtfully name your course, pages, and page elements. This information becomes part of the Activity ID.
? You can edit .js templates so you can leverage custom functions directly within the Lectora UI. The customized templates can greatly increase consistency, and extend xAPI functionality.
? Verify the Verb IRI before specifying your own verb in the custom xAPI statements.
? Questions must be wrapped in a graded test to send question data.
? Test and question data is sent on the Process Test action.
Rise
Rise is Articulate’s responsive content creation tool and provides xAPI support out of the box. When you create a Rise course you will get the standard statements previously noted. In addition to the standard statements, Rise will send statements on its Sorting activity and launching of embedded Storyline packages.
Rise doesn’t currently have an ability to trigger xAPI actions out of the box using their standard action trigger mechanisms, nor can users use an Execute JavaScript action to create their own unique xAPI statements. However, using the embedded Storyline option, it might be possible to add JavaScript triggers to send statements (note: we did not test this option).
When publishing the xAPI package, Rise provides a UI to add LRS endpoints and configuration. This was an enhancement from the original release, which required post publish adjustments.
General Tips:
? When adding Storyline modules to your course, they cannot be packaged as xAPI objects, and thus do not automatically send any xAPI statements. However, it is technically possible to add JavaScript triggers to send xAPI statements from these embedded Storyline modules. This was not tested.
? Rise uses the activity ID, which is the URL for each section rather than the activity name or the author’s titles for the lesson. To understand what the activity ID represents, an author needs to open a file called tincan.xml in the Rise package to decode the relationship between the ID and section names. See this article for more details.
Note: Some LRS/LMSs may address this better than others. Review this with your LRS/LMS provider if you are planning to use Rise as your primary authoring tool.
SmartBuilder
SmartBuilder provides three types of xAPI support: automatic standard statements, custom statements, and advanced statements.
Standard Statements: SmartBuilder generates automatic statements as discussed above for common data such as completion status, pass/fail, question scoring, and more.
Custom Statements: Authors can create custom xAPI statements using any trigger. For example, you can create a trigger to send a statement when a video is played, a drag-and-drop is completed, or when a button is clicked. Authors choose the appropriate verb and type from a list of approved ADL and Tin Can verbs and types. In addition to defining their statements, authors can include dynamic values for parameters such as “success”, “response”, and “score”. This allows for integration with objects in the course (e.g., an input text field can be used to set the “response” parameter, or a variable can be used to set the “score” parameter).
Advanced Statements: One unique capability SmartBuilder provides is the enablement of content to receive data from an LRS using xAPI’s State API and Activity Profile API. This can be used to retrieve bookmarks and to store/restore session data. The Activity Profile API also enables authors to share data across different learners to create such activities as poll results, leaderboards, and discussion threads. See this article for more details.
For deployment, you can use SmartBuilder’s integrated LRS or third party LRS systems. For LRS systems that require an endpoint and credentials, SmartBuilder provides a wrapper that can be applied post publish.
General Tips:
? Thoughtfully name your course and pages, which become part of the Activity ID. However, these default Activity IDs can be customized if desired.
? To generate automatic completion and bookmarking statements, use one of SmartBuilder’s master navigation templates.
? To generate automatic scored, answered and pass/fail statements, use SmartBuilder’s question/quizzing templates.
Storyline 3
Storyline provides xAPI support out of the box. When you create a Storyline course you will get the standard statements previously noted. Storyline doesn’t currently have an ability to trigger xAPI actions as a standard feature. However, users can use an Execute JavaScript option to create their own unique xAPI statements in Storyline. When publishing the xAPI package, if the LRS requires a key and password in the package, authors will need to unzip the published package, add the necessary wrapper and information, and rezip the package prior to launching it.
General Tips:
? Thoughtfully name your course, pages, and page elements. This information becomes part of the Activity ID.
? LRS credentials are not set in the tool, you will need to edit the published package after you publish in order to make this work for most LRSs.
? Storyline tracks by slide. If users are making any interaction, make sure they create a new slide with a proper name instead of a layer.
? Access Tin CAN API to support Articulate Content for verb details
What’s next?
If your favorite tool wasn’t covered, don’t fret. There is always room for a follow up. Also, when implementing your chosen tool, please do consult with the vendor for their latest documentation and support of xAPI.
We fully expect that solutions will continue to evolve as more and more organizations begin to realize the power xAPI can bring in terms of improving their overall performance, and tying it directly to learning interventions. Beyond collecting advanced learner analytics, probably the next most exciting aspect of xAPI we are just beginning to see is utilizing the data in a bi-directional fashion, where data collected from other users— as well as the actor in question—is fed back into the training content to help provide the learner with customized information relating to their own needs and the organization’s needs as a whole.
The training industry has just begun to dip its proverbial toes into the possibilities of xAPI. We hope this information will enable your organization to begin to take full advantage of the advances authoring tool xAPI support can bring immediately, out of the box.