Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Tin Can

From MoodleDocs

Quiz

This section is a working document and outlines our proposed approach to implementing Tin Can tracking into Moodle quiz. It’s envisaged that the pattern followed in this approach may be applied to other modules in future.


High level approach

At a high level, the approach well follow is outlined below.

  1. Quiz tracking data will be sent server side using OAuth authentication. We recommend using a separate set of credentials to those used for the launch integration.
  2. We will develop a report type plugin for Moodle that hooks into the Moodle Events API to trigger the creation of statements.
  3. Where a required event does not exist in the Moodle API, Moodle HQ CEO Martin Dougiamas has agreed in principal to add these events to Moodle core.
  4. Once created, statements will be stored in the Moodle database and sent in batches at regular intervals as a chron job. Statements will not be removed from the database until they have been successfully sent.
  5. A record of failed attempts and error codes will be stored in a separate database table and a summary email will be sent to a configurable email address at configurable periods (e.g. daily) where there have been failed attempts in that period.

A very early open source prototype can be found here: https://github.com/garemoko/moodle-report_tincan

Events

The table below lists the events we’ll track. This is based on the statements listed in CMI5 and is similar to the events tracked by rapid e-learning tools such as gomo. The Moodle Events API event that will be used as a trigger and the data we’ll include in the statement. Events that do not currently exist in Moodle have been marked in bold.


Event Moodle event Data required
Starting an attempt mod_quiz\event\attempt_started Moodle site URL, Quiz id, Course id,
Completing an attempt mod_quiz\event\attempt_submitted Moodle site URL, Quiz id, Course id
Passing an attempt mod_quiz\event\attempt_submitted Moodle site URL, Quiz id, Course id, attempt grade, quiz pass mark.
Failing an attempt mod_quiz\event\attempt_submitted Moodle site URL, Quiz id, Course id, attempt grade, maximum and minimum grades, quiz pass mark.
Submitting a question mod_quiz\event\attempt_submitted Moodle site URL, Quiz id, Course id, Question id, Question name, Question content (description), options, selected option, score (min, max, raw)


Session and attempt suspend/resume related events will not be tracked within scope of this project. These include:

Event Moodle event Data required
Launching a session core\event\course_module_viewed Moodle site URL, Quiz id, name and description. Course id, name and description.
Starting a session mod_quiz\event\attempt_started mod_quiz\event\attempt_resumed* Moodle site URL, Quiz id, Course id.
Exiting a session mod_quiz\event\attempt_submitted

mod_quiz\event\attempt_suspended*

Moodle site URL, Quiz id, Course id, session duration.
Suspending an attempt mod_quiz\event\attempt_suspended* Moodle site URL, Quiz id, Course id, attempt duration
Resuming an attempt mod_quiz\event\attempt_resumed* Moodle site URL, Quiz id, Course id

For completeness, here’s a list of other events that we will not track within the scope of this project.

  • Abandoning an attempt
  • Waiving an attempt
  • An attempt becoming overdue
  • Interacting with a question

All question level tracking data will be sent when the attempt is submitted. Tracking question interactions as they happen will be too complex for the scope of this project, but could be added later if required.

Duration

Attempt or quiz duration will not be tracked for this first project, but may need to be added later.

Statement queuing and batches

In order to improve performance and as a mechanism to ensure that all data is sent, we’ll implement a system for queuing statements and sending them in batches. The process for this is outlined below:

Tin Can Moodle statement batches

The regularity of the cron event is a set up on the Moodle as a whole. The regularity of the admin alert will be a configuration setting in the report plugin and is likely to be less regular, e.g. once a day. All failed statements will remain in the ‘Batch failed’ table until they are either sent (possibly after being manually edited) or manually deleted. Assuming a compatible LRS and no bugs in the report plugin, there should never be any statements that get stuck in the ‘batch failed’ table; the vast majority of statements should be successfully sent by the batch process.