Improve Tracking for Learning Analytics

1 Initial Problem

In ILIAS tracking data is gathered to feed the learning progress of students and the object statistics. ILIAS persistently stores counters of generic read access to objects or single pages of learning modules. It tries to estimate the reading time of learning module pages by the timespan between server requests with a given timeout. Learning progress data is calculated by the different modules and stored as a current state.

A learning analytics project at FAU used the tracking data to interpret the learning activity of students and the effect of an intervention during the semester. The analysis was done based on the raw data from the database tables for read events and learning progress and the result tables for questions in tests and learning modules. This project reported some problems with the interpretation of the data:

• Only the total number of accesses (access counter) to objects is collected (read_count), i.e. no information about when exactly / in which time period accesses took place, only timestamps of the first and last access.
• The rule for increasing the access counter (time interval?) was not exactly clear.
• The access counter to child objects (child_read_count) was not consistent with to the access sum of the individual child objects. This could indicate a bug in the system.
• The calculation of the access duration to objects / parent and child folders (spend_seconds / child_spend_seconds) was not exactly traceable.
• Access to embedded videos without own object-ID is not collected.

All in all the current tracking system of ILIAS should be improved to support a better understanding of learning behaviors. This would help lecturers to improve their courses.

2 Conceptual Summary

Today the de-facto standard to track learning experiences is xAPI. ILIAS 6 already provides objects and functionality to use the data stored in an xAPI learning record store (LRS), see xAPI.
This feature request intends to streamline and improve the tracking system of ILIAS in a way that it can feed an xAPI LRS.

• All update of tracking or learning progress data should be done through the event system or at least raise an event with at least the minimum data needed for an LRS entry (time, user, verb, object)
• Detailed activity should raise such an event, too, e.g. the answering of test questions (with indication if the answer is correct or not).
• Client-side activity should be tracked, too, e.g. starting a video.
• A fine-grained recognition of reading times could be achieved by tracking scroll events in the browser.

This makes it possible to implement a data provider for xAPI, either as a core service or initially as a plugin.

3 User Interface Modifications

There are no visible user interface modifications so far. Tracking client-side events may affect the implementation of UI components.

3.1 List of Affected Views

{Please list all views (screens) of ILIAS that should be modified, newly introduced or removed.}

3.2 User Interface Details

{For each of these views please list all user interface elements that should be modified, added or removed. Please provide the textual appearance of the UI elements and their interactive behaviour.}

3.3 New User Interface Concepts

{If the proposal introduces any completely new user interface elements, you might consult UI Kitchen Sink in order to find the necessary information to propose new UI-Concepts. Note that any maintainer might gladly assist you with this.}

4 Technical Information

{The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues.}

5 Privacy Information

Raising an internal event should not affect privacy per se. It is the responsibility of the listening component.

{ Please list all personal data that will need to be stored or processed to implement this feature. For each date give a short explanation why it is necessary to use that date. }

6 Security Implications

{ Does the feature include any special security relevant changes, e.g. the introducion of new endpoints or other new possible attack vectors. If yes, please explain these implications and include a commitment to deliver a written security concept as part of the feature development. This concept will need an additional approvement by the JourFixe. }

7 Contact

• Author of the Request: Neumann, Fred [fneumann]
• Maintainer: {Please add your name before applying for an initial workshop or a Jour Fixe meeting.}
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• …

9 Discussion

10 Implementation

{The maintainer has to give a description of the final implementation and add screenshots if possible.}

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.