Learning Progress on Visited Pages Sensitive to Changes

This request is a reaction to https://mantis.ilias.de/view.php?id=24035.

1 Initial Problem

A user who has already visited all pages of an ILIAS learning module and, according to the LP configuration, has the status "Completed" will keep this status even if more pages are added.
Vice versa, a user who has visited all but one page will not achieve the "Completed" status after deleting this page.

In many cases, this behaviour of the module LP results in distorted status information.
That's a pity especially because one of the very advantages of ILIAS learning modules (compared to SCORM a.s.o.) is that they can be edited while learners use them.

To even complicate the situation more, the status only remains until the user opens the learning module again.
So, the accuracy of the reporting quite depends on the happenstance who reopened the module and who didn't.

2 Conceptual Summary

I have suggestions on three levels:

2.1 Trigger recalculation of the LP status by LP setting activity instead of user activity

When someone wants to have a report on the LP status in an ILIAS learning module, it appears acceptable to me asking this person to refresh the data manually by re-saving the LP settings.Until this refresh is done, the status of users keeps the same, even if they open the module again.This way, at least the different users' data are comparable.It would be helpful to add such a hint to the description of the LP mode.

2.2 Trigger recalculation of the mode-specific LP status automatically by new pages

I understand akill's objections in https://mantis.ilias.de/view.php?id=24035#c58496, however, in contrast to him I'm only referring to the LP mode "Visited pages" and, thus, would like to suggest that recalculation of the LP status is only triggered by adding or removing pages - so as well his performance as the usability argument appears to me mainly obsolete.Anyhow, a hint could be placed in the "legend" appearing in the footer of chapters' edit mode.

2.3 Trigger recalculation of the LP status automatically by author decision

Finally, the "big" solution would be some kind of button in the edit mode of a page that triggers recalculating the LP status of users.The advantages were that this concept could also be applied to the "Questions" LP mode, now or in the future, and that the working-how of LP status calculation would be quite explicit towards authors while still avoiding performance problems.

3 User Interface Modifications

3.1 List of Affected Views

• lm/learning_progress/trac_settings (in case of variant 2.1)
• In case of variant 2.2, there is no specific screen ID up to now for viewing the interior of a chapter.
• copg/edit_lm/ (in case of variant 2.3)

3.2 User Interface Details

• In case of variant 2.1, the mode's description could be enhanced in the following way:
  The status ‘Completed’ is automatically assigned to a user once this user visited all pages of the learning module.
  Adding or deleting pages will not trigger recalculation of the status but only saving these setting again.
• In case of variant 2.2, the legend could be enhanced by the following line:
  Adding or deleting pages will trigger recalculation of the status.
• In case of variant 2.3, the trigger for recalculation could be an option in the "Actions" menu immediately above the page content (next to the "Edit Mode" menu).

3.3 New User Interface Concepts

(none)

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 Contact

• Author of the Request: Suittenpointner, Florian [suittenpointner]
• 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.}

6 Funding

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

• …

7 Discussion

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