Tin Can
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.
- 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.
- We will develop a report type plugin for Moodle that hooks into the Moodle Events API to trigger the creation of statements.
- 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.
- 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.
- 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:
The regularity of the chron 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.