Note:

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

Tin Can: Difference between revisions

From MoodleDocs
m (formatting fixes)
Line 35: Line 35:
| Completing an attempt
| Completing an attempt
| mod_quiz\event\attempt_submitted
| mod_quiz\event\attempt_submitted
| Moodle site URL, Quiz id, Course id, attempt duration
| Moodle site URL, Quiz id, Course id
|  
|  
|  
|  
Line 41: Line 41:
| Passing an attempt
| Passing an attempt
| mod_quiz\event\attempt_submitted
| mod_quiz\event\attempt_submitted
| Moodle site URL, Quiz id, Course id, attempt duration, attempt grade, quiz pass mark.
| Moodle site URL, Quiz id, Course id, attempt grade, quiz pass mark.
|  
|  
|  
|  
Line 48: Line 48:
| mod_quiz\event\attempt_submitted
| mod_quiz\event\attempt_submitted
| Moodle site URL, Quiz id, Course
| Moodle site URL, Quiz id, Course
   id, attempt duration, attempt grade, maximum and minimum grades, quiz pass
   id, attempt grade, maximum and minimum grades, quiz pass
   mark.
   mark.
|  
|  
Line 60: Line 60:
|}
|}


The attempt duration is the total time spent during the attempt, rather than the difference between start and end time; i.e. attempt duration does not include time between sessions. Moodle quiz does not currently record session or attempt duration in the way required.


Session and attempt suspend/resume related events will not be tracked within scope of this project. These include:
Session and attempt suspend/resume related events will not be tracked within scope of this project. These include:
Line 73: Line 72:
| Launching a session
| Launching a session
| core\event\course_module_viewed
| core\event\course_module_viewed
| Moodle site URL, Quiz id, name and
| Moodle site URL, Quiz id, name and description. Course id, name and description.
  description. Course id, name and description.
|  
|  
|  
|  
Line 80: Line 78:
| Starting a session
| Starting a session
| mod_quiz\event\attempt_started mod_quiz\event\attempt_resumed*
| mod_quiz\event\attempt_started mod_quiz\event\attempt_resumed*
| Moodle site URL, Quiz id, Course
| Moodle site URL, Quiz id, Course id.
  id.
|  
|  
|  
|  
Line 88: Line 85:
| mod_quiz\event\attempt_submitted  
| mod_quiz\event\attempt_submitted  
   mod_quiz\event\attempt_suspended*
   mod_quiz\event\attempt_suspended*
| Moodle site URL, Quiz id, Course
| Moodle site URL, Quiz id, Course id, session duration.
  id, session duration.
|  
|  
|  
|  
Line 95: Line 91:
| Suspending an attempt
| Suspending an attempt
| mod_quiz\event\attempt_suspended*
| mod_quiz\event\attempt_suspended*
| Moodle site URL, Quiz id, Course
| Moodle site URL, Quiz id, Course id, attempt duration
  id, attempt duration
|  
|  
|  
|  
Line 114: Line 109:
* Interacting with a question
* 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.  
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===
===Statement queuing and batches===

Revision as of 13:10, 9 April 2014

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 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.