Implementation Of The Experience API Within The SOFAD Author Environment

Implementation Of The Experience API Within The SOFAD Author Environment
Summary: This experimentation was conducted in the course of the regular activities of GTN-Québec, with the technical support of the SOFAD IT team. The purpose of the experimentation is to make recommendations available to the education community on the implementation of this new standard in the online learning field. The following lines briefly present the approach taken for implementation of the xAPI specification within our author environment. We first explain why we decided to design our own plugin (SOFAD/author). We describe the limitations we encountered with SCORM. We show how the implementation of xAPI in our authoring environment allowed us to solve the limitations encountered with SCORM. We identify some possible issues and constraints with this new standard. Finally, we propose some recommendations.

Implementation of the xAPI specification (Experience API) within the SOFAD author environment.

The SOFAD Author Environment - A WordPress plugin

Of all the plugins we consulted (Namaste LMS, Sensei, WP Courseware, etc.), practically none was really compliant with a standard in particular; the plugins that advertised an "author" aspect only provided it to a tiny extent; also, all the plugins consulted only allowed WordPress to be used as a learning management system (LMS) (e.g. SCORM Cloud, LearnDash) and not as an authoring tool per se. This is when we decided to design our own SOFAD/author plugin. For more information on SOFAD/author and what an authoring tool really is, click here (in french).

SOFAD developed a plugin around the WordPress environment to allow it to design and produce its online courses.

This plugin (SOFAD/author) includes an interactivity engine, allowing it to produce multiple learning interactivities and deploy them in SCORM 1.2 format to multiple learning management systems compliant with this standard (e.g. Moodle, Desire2Learn, Blackboard, etc.)

The reasons that motivated this experimentation

Some of our learning interactivities (e.g. Vote and manual correction test) cannot be achieved with the SCORM specification. Indeed, it is not possible with SCORM to collect certain data on learners' learning experiences, in view of the limited communication mode between the content and the LMS. Also, with SCORM, all learning must be initialized from a learning management system (LMS). The content must reside in the same domain as the LMS. In addition, the SCORM content must function in a browser (impossible on mobile apps). Furthermore, it is impossible to track the learners' activities offline and it is very easy for a seasoned learner to hack SCORM content. Finally, the media used nowadays to learn (social platforms, tablets, digital books, smartphones, etc.) have changed greatly. This was not the case for SCORM, because the specification is over ten years old!

The solution envisioned

xAPI_architecture

 

One of the solutions we envisioned at SOFAD to get around the limitations of SCORM was to implement the xAPI standard in our author environment. The implementation of xAPI necessitated the use of a new system, the LRS. The LRS is an integral part of the xAPI architecture, i.e. the place where data from different learning experiences is validated, stored and made available. A detailed presentation on the LRS to this effect is available here (in french). Also, we chose the Learning Locker open source solution for the requirements of our experimentation, given that it seemed more advanced in terms of development than the ADL LRS. (To our knowledge, these are the only two open source solutions currently on the market. The others are proprietary or hosted solutions.) Moreover, the design of an LRS went beyond the mandate of our experimentation, and our LRS had to be public, i.e. not implemented in an LMS, since the other member institutions of GTN-Québec might also send their data to this LRS. It should be noted that an LRS can reside outside or within an LMS.

The implementation approach

Our experimentation focused on two interactivities that cannot be achieved with the SCORM specification.

The first interactivity is a manual correction test, in which a learner answers a series of questions that are asked and then submits his answers for evaluation to a corrector (teacher and/or classmate). After submitting his test, the corrector can compare the answers to the correct versions provided, annotate them and grade them according to the established scale. The corrector can also add an overall comment, if he considers the evaluation insufficient. Furthermore, the corrector can ask the learner to retake the test.

The second interactivity is a discussion topic, accompanied by a question on which the learner must vote. In this interactive Poll, a compilation of all the learners' votes is displayed on the screen at the same time as the feedback to the learner.

We first attempted to describe the use cases, i.e. identify the different systems concerned and specify the role of each actor, knowing that the xAPI specification (Experience API) governs communication among multiple systems and involves multiple stakeholders more or less directly. Diagram 1 below illustrates the different use cases.

Uses Case

In a second stage, to clarify the typical chronological sequence of use of an interactivity, we produced a sequence diagram for each of the interactivities concerned. For example, for the "Poll" interactivity, the interaction between the objects occurred on the learner side, in JavaScript, in a course deployed in xAPI format within an LMS. Diagram 2 below illustrates the interactive Poll sequence diagram.

Sequence_diagram

When a learner votes on a question, the system's operations can be summarized in two main stages: saving the learner's answer and displaying to the learner all the answers obtained to date.

The interactive Poll addresses a request to save the learner's answer in the SOFAD/author system (xAPI implementation of the SOFAD/author interface).

SOFAD/author executes this request with xAPI Wrapper.js. This then sends a statement to the LRS. The interactive Poll then requests all the learners' answers (getallAnswers) from SOFAD/author.

SOFAD/author interacts again with xAPI Wrapper to respond to this request. xAPI Wrapper obtains the statements from the LRS by Ajax.

Once the interactive Poll obtains the answers, it displays the learner's answers on the screen. Remember that xAPI Wrapper is a JavaScript file used to facilitate communication with the LRS.

We then defined the classes that model the entities or the concepts present in the application's domain, bearing in mind that the statements are at the centre of the xAPI architecture. Diagram 3 below is a non-exhaustive representation of all the possible components of a statement. It instead illustrates the essential components (those we retained from the entire version 1.0.0 of the xAPI specification) for our interactivities requirements.

Model_domain

The minimum formulation of a statement is the following: "Actor / Verb / Object / ". An actor can be a person, a learner or a system. Then an object is some kind of activity. Note that an object can play two roles in a statement.

It can be the object of a statement, e.g. "John has completed the math test", where math test is the object of the statement.

It can also be the parent of the object of a statement, e.g. in the statement "John has completed the math test of his algebra course", where  “algebra course” is the parent of the math test object. Moreover, the concept of object is fairly broad, ranging from a question to a complete course.

The identification (id) of the verbs, and the ID and object types are all represented by IRIs. Contrary to URIs, they are not limited to a subset of ASCII characters. In the case of an online resource, the ID of an object is simply the address from which the resource in question can be accessed. The figure below is the representation in JSON of a learner's interactive "Poll" statement.

json representation - poll

The request made to the LRS to display all the learners' answers to the interactive Poll is composed of the following two elements: the verb and the activity.

In response to this request, the LRS answers by sending all the statements, including the ID of the verb and the ID of the corresponding activity.

Finally, we identified the main classes involved in the mechanism for saving and restoring data relevant to the learner's learning and to guidance by a trainer. The classes represented are implemented in JavaScript and executed on the client side. Diagram 4 below illustrates this concept.

Class_diagram

The SOFAD/author interface (in the middle) exists to limit, as much as possible, the dependencies between the two parts of the solution: our sub-plugins (interactivities, questions and tests) and our deployment targets (xAPI, SCORM, eduSOFAD, etc). Moreover, additions are to be anticipated (new types of questions, new interactivities and deployment targets) throughout the environment's life cycle.

The SOFAD/author interface offers all the persistence services necessary for our sub-plugins (in the diagram, the Poll and Assignment (Manual correction test) interactivities. For each deployment target, an implementation of the SOFAD/author interface exists.

The objective is to be able to make new deployments compatible without intervening in the sub-plugins and, conversely, to develop new sub-plugins that are functional immediately for all the deployment targets.

Click on the following link for a complete demonstration of Poll interactivity.

The first advantages recognized

Data portability

The learners and the systems can share data on the learner's performance outside the LMS and with other applications.

xAPI supports a variety of content types. Learning experiences can occur anywhere and the conditions for tracking these learning activities are no longer simply limited to the LMS. The standard provides a method for following learning activities, which can take place on multiple media (tablets, smartphones, etc.). In addition, offline learning (without a network connection) is now possible.

Learner-centred approach

xAPI is at the centre of all the reported learning activities and experiences, which was not the case with SCORM (a more course-centred approach). The specification supports team learning scenarios and advanced evaluation scenarios. A designer can decide on the level of detail to report in terms of learning experience.

Flexibility of reports, analysis and design

The introduction of the new xAPI standard allows organizations to gather, view and analyze structured and unstructured learning data not previously accessible.

Issues and challenges to meet

Security and confidentiality

xAPI assumes nothing regarding pre-authentication of a user and does not provide any method to this effect. The activity is completely responsible for authentication and thus for the learner's identity. This flexibility is reflected in the fact that xAPI provides for several ways to identify a learner (actor) when a statement is sent: email or OpenID URI.

Learners are no longer necessarily known in advance by the LRS. As is the case in an LMS with SCORM, the LRS accepts a statement that is formulated correctly, even if this concerns a learner it does not know. When an LMS consults an LRS, it must be able to link efficiently the identifiers of the learners (actors) found in the statements of the LRS with its own user accounts.

This contrasts with SCORM API, where the learner must be authenticated in advance.

Also, xAPIWrapper.js  nonetheless offers an authentication model very similar to SCORM.

It proposes two ways to inform content what LRS to use and who is the current actor. However, it is unlikely that all the xAPI-compatible LMS will adopt this procedure.

Semantic dimension of verbs and activity types

An important factor in statement formulation is the choice and use of verbs and activity types. The practice communities or certain professional orders that use their own specific terminology may have to deploy, share and maintain directories of verbs and activity types with their exact definition and their context to avoid any ambiguity in the interpretation of results and data. The industry will have to maintain a central directory with a common vocabulary to ensure the statements are well understood and compliant with the agreed definitions. Also, there is little likelihood that each organization will voluntarily report their verbs and activity types to this central directory. Without forgetting the linguistic dimension: translation (from one language to another) of the same learning experience with different statements. There is reason to be concerned about the concordance between contents, if each uses different IRIs to identify the same activities. However, a solution seems to be looming on the horizon with the "recipes" concept.

Evolution and compliance

Over time, all systems will generate an enormous quantity of data that cannot be reinitialized. The organizations will have to choose LRS capable of evolving over time to meet the demand for data storage and processing. It will also be necessary to ensure the compliance of the new and old versions of the xAPI specification.

Since xAPI allows data granularity, it is possible to track information in more detail. This introduces new challenges. It will be necessary to avoid collecting useless data.

Recommendations

This experimentation allowed us to demonstrate how this new standard for online learning software facilitates communication between learning content and the different systems, in order to save and track any type of learning experience of the learners, including learning experiences on mobile apps (iPad/Tablets), which previously was not possible with the SCORM standard.

xAPI is indeed an alternative to SCORM. However, for successful implementation, we strongly suggest integrating your LRS into your LMS, for increased security. Contrary to popular belief, the LRS will not replace the LMS. Instead the LRS should be seen as complementary to the LMS.

Adopt the directory of ADL verbs and activity types to avoid any ambiguity in the interpretation of the statements and thus of the data. If you must create new verbs and activity types, don't hesitate to submit them to ADL for approval. Also, provide for several LRS in your architecture so that you do not have to mix your data, since as you know, it is not currently possible to reinitialize the data generated. Finally, opt for an LRS that is installed (behind your firewall) or hosted, because "cloud" solutions are becoming expensive again in terms of cost per statement.

In conclusion, I hope this experimentation will allow removal of the doubt and uncertainty experienced by many educational institutions and organizations regarding the adoption and use of this new standard, which is still little known to the education community.

References

Read Also

eLearning Authoring Tool Features eLearning Software Standards Experience API SCORM Tin Can API
Write or read Comments
Close
Change your privacy settings to see the content.
In order write or read comments you need to have functional cookies enabled.
You can adjust your cookie preferences here.