Learning Progress Support by ECS

1 Initial Problem

ECS course links do not support learning progress yet. Therefore, a user using an ECS course does not get any LP status for the ECS course link on this home installation. LP status is only provided for users using such a course on the installation where the course stays. Same for all other ECS object links where the related component offers LP support.

Effect is that ECS objects can neither be used as LP triggering objects within a complexer learning scenario, nor as precondition to access another object on the user's home installation.

2 Conceptual Summary

3 General Conceptual Changes

ECS Objects should receive a new tab "Learning Progress" and the possiblity to choose between a set of LP completion modes. Ideally, more information should be able to set, like a mark / grade for each user, as it is possible in the LP settings of ILIAS Courses, for example.

LP completion modes:

• Learning Progress is Deactivated
• Users Monitor and Set Status Themselves
• Status is Determined by the ECS target platform

ILIAS must be able to identify ECS users to reliably sent out LP status messasges to the "home" platforms of these users. Currently, this can only be accomplished by checking for the global role that is set up for incoming ECS users in the ECS administration in ILIAS.

Setting the LP status of a user in ILIAS needs to do an additional check: is the affected user an ECS user- if yes - sent LP status event to ECS. Since the LP status of a user might change automatically, a new Cron Jobs might be the simplest solution for doing this check on a regular base "Check for LP status changes of ECS users in ILIAs objects and create reelvant ECS events"

Additionally, it would be wise to design this implementation in such a way that in the future more data that just the LP status can be transferred. There are projects that opt at using the ECS to transfer grades / marks between systems. If ILIAS was capable of sending the mark that the user received for that course and process an incoming mark for that user for an ECS object, we would have a perfect base for such scenarios.

4 ECS Course objects should be able to receive and send LP status information of ECS users and deliver them to their home installation.

Moodle Courses:

• On the course level, Moodle knows a boolean status to reflect course completion (completed / not completed). Since Moodle neccessarily creates a "normal" course object for each imported ECS course, this is a viable base for receiveing LP statuses
• Importing an Moodle Course:
  • ILIAS user follows an ECS Course Link to a target platform > LP Status for the ECS Course Link object in ILIAS set to "Not started" by ILIAS
  • ILIAS user enrols in course on the target Moodle installation > LP Status sent via ECS Event: "In Progress"
  • Course Member completes course in Moodle (either by manual completion through a teacher or through a set of completed activities) > LP Status sent via ECS Event: "Completed"
• Exporting an ILIAS Course to Moodle:
  • Incoming Moodle User arrives on ILIAS throught the CampusConnect Link in Moodle > No Action
  • Incoming Moodle User joins ILIAS Course >LP Status "In Progress" sent as ECS Event (Moodle is crrently not able to process this information and will discard this)
  • Incoming Moodle User passes the ILIAS course (through LP tracking of sub-items or by manual assignment of status through tutor) > LP status "Completed" is sent as an ECS Event for the receiving platform
• currently, according to Moodle developers, it would be a bigger project to map completion status for sub-course activities in moodle since the currect Moodle ECS plugin set does not support other ECS object type than "ECS Courses"

• ECS object types should be able to display LP status information for users (when the related component supports LP, too).

5 User Interface Modifications

5.1 List of Affected Views

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

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

5.3 New User Interface Concepts

{If the proposal introduces any completely new user interface elements, please provide a link to separate feature wiki entries for each of them according to the kitchen sink template.}

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

7 Contact

• Author of the Request:
• Kunkel, Matthias [mkunkel], Glaubitz, Marko [mglaubitz]
• 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.

• [Universität Freiburg]

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