Reminder Service

1 Initial Problem

You want to remind learners (e.g. course members) who didn’t complete a set of learning objects at a specific date per mail.

2 Conceptual Summary

We suggest implementing this reminder feature as a general service.

• ILIAS objects can implement this new service with a few lines of code (ilCtrl forwarding etc.)
  • As for now, the ILIAS object needs to implement learning progress first, because this will be the only criterion in the initial implementation – different criteria could be added later.
  • the service will initially be implemented for container objects with learning progress, i.e. courses, groups and folders (see future outlook)
• The service will be implemented as a new tab “reminder” (it should be the same location for all objects – e.g. settings > reminder).
  • The tab shows a list of configured reminders [no sorting or filtering]
    • shorthand name (alternatively: summary of reminder settings)
    • activation status
    • action menu (edit / de-activate / delete)
  • Button “Add new Reminder”
• Reminder options
  • activation status
    • on / off
  • shorthand name
    • This name (unique per object) will appear in the listing (alternatively ILIAS must construct a meaningful summary for each reminder, based on its settings)
  • trigger event (see future outlook for other options)
    • fixed date without time (date-input gui)
  • criteria (see future outlook for other options)
    • learning progress is not “completed”
  • affected users
    • all users with access (READ permission, including parent objects)
    • course members (if current object is or is in a course – see open questions)
  • recipients (see future outlook)
    • ILIAS user to be reminded [MAILTO]
    • arbitrary other ILIAS users (comma separated) [will act as BCC recipients – i.e. the mail-text will be identical to the ILIAS user to be reminded, even if the mail is only sent to BCC-recipients]
  • mail text (see future outlook)
    • in different languages
    • place-holders (fullname, username and salutation of the ILIAS user to be reminded, name and link to current object)
  • The service keeps track if a reminder has been triggered before, to avoid duplication.
    • If the reminder has been triggered before, it will not trigger again - even, if new users join the course etc. (see future outlook “keep alive” option)
    • If a reminder is edited, the service will check if reminders have already been triggered. If so, the editing user can decide to reset this status and allow sending the reminder again.
  • A cronjob will check the initial fixed-date-trigger condition (future trigger events might not need this)
  • ILIAS objects don’t need to handle these settings explicitly, when ILIAS objects are copied. Instead the general service will listen to “copy-object” events and do the work.
  • If a container with a reminder is copied, the reminder shall be copied too.
  • If the reminder was triggered once it should not be triggered again for that course (even if new course members are added, etc.).

2.1 Example Usage

• Consider a blended learning course with a folder “online training” and a session object. The learning progress of the course is online-training + session. The online training should be completed 10 days before the session. In this case the reminder can be setup for the folder “online training” for all course members at a fixed date (manually 10 days before the session). By using the folder, the reminder can be send independently of the session.

2.2 Open Questions

• What should happen, if an object is moved from within a course to another location outside of any course and uses the setting “affected users: all course members”
  • The reminder should be inactive due to incorrect options. This should be shown in the reminder listing. It should be possible to cure this condition by editing the reminder (e.g. selecting “all users with access” instead).
• What should happen, if the system language is changed and there is no mail-text for the new system language configured? Is there any precedent?
• Do ILIAS objects need to implement export / import explicitly?
  • Does not seem necessary for the start (see future outlook instead)

2.3 Future Outlook

• Implement service for more objects
  • g. all ILIAS objects with learning progress. To achieve this further discussion is needed for objects, which already have reminder-like functionality. The Jour-Fixe might also decide to limit the implementation to container objects.
• Add more criteria, different than learning progress (the ILIAS object should be able to inject these into the general service). For example:
  • learning progress
    • is / is not
    • multi-selection: not started, in progress, completed, failed
    • selection of sub-objects(?)
  • survey: no participation
  • exercise: no feedback given
• Add more affected users. For example
  • Global Roles
  • Group Members (if current object is or is in a group)
  • … (each ILIAS object could be able to inject more options in the future)
• Add more trigger events, different than the fixed date. For example
  • individual learning schedule
    • period started
    • period ended
  • Add an option “keep alive” for new users:
    • OFF (default): The reminder will trigger only once after the trigger event, and will only be sent to users who are present at the time the reminder is triggered.
    • ON: The reminder will trigger once per user, even if they join after the initial trigger event.
  • Add more recipients, for example:
    • superior or responsible person (via org units)
  • Add centralized mail-templates, which can be reused locally
  • Implement Export / Import of reminder settings

3 User Interface Modifications

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, please provide a link to separate feature wiki entries for each of them according to the kitchen sink template.}

4 API

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

6 Contact

• Author of the Request: Kiegel, Colin [kiegel]
• 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.}

7 Funding

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

• Lotto Hessen

8 Discussion

Kiegel, Colin [kiegel] 2017-01-18: Since we suggest a new service it is unclear to me, a maintainer has to be found. If however the jour fixe decides that this feature should not be a general service but a course feature, it probably belongs to course maintainership.

Kunkel, Matthias [mkunkel] 2017-01-19 via email (rough translation): Please outline the relationship between the reminder service, the task manager and notification system on the other hand.

Killing, Alexander [alex] 20 Jan 2017: I do not think that the concept solves the initial problem very well. The problem is: "You want to remind learners (e.g. course members) who didn’t complete a set of learning objects at a specific date per mail."

Courses can be structured in very different ways and handle a lot of different content. The idea to be forced to manage manually all kind of reminders seems to be not very efficient to me. Think of a course with lots of exercises, each exercise has a set of assignments. Or a set of tests in learning objective driven courses which should be done up to a specific deadline (access period ends). Or the timings (Lernplanungs) mode of courses that allows to set indivual deadlines.

It will be quite impossible to manage reminders for all these things manually. I think a much better approach is the idea of having a generalised (system) task management, where tasks can be implemented automatically by all the components listed. The personal desktop could feature all open tasks and one(!) daily reminder mail could list all open tasks. And I think this system needs to closely collaborate with the calendar componente (or be a sub feature of the calendar).

Kiegel, Colin [kiegel] 2017-01-23: I can see that the abstraction of tasks makes sense (like here). But I think we would loose the ability to have customised reminders (e.g. on a per course level). Yes I can see it as a task, but customized reminders can also be useful. Would the 'task service' be able to define customized reminders? Can we have multiple reminders per task at different dates with different texts and recipients? E.g. "30 days before deadline: Please remember to ...", and "1 day after deadline: You missed the deadline, your supervisor will be informed ...". I am not sure if a new 'task service' of ILIAS would be flexible enough to support these use cases.

PS: In the long-term I would like to have reusable mail-templates for these kinds of reminders.

Kiegel, Colin [kiegel] 2017-01-23 (via email) in response to Matthias Kunkel (translated):

1. I see little overlap with the task manager concept, from what I have read so far about the task manager concept. But I do see some possibilities to connect things.
2. According to the concept, the task manager knows both: (a) manually managed tasks as well as (b) automatically defined tasks by the system. Of course, it makes sense to remind users of such tasks - but that's not part of the concept so far. The focus is on task management, as the name implies.
3. A reminder service would care as little as possible about defining "tasks", etc. according to my thinking. Instead it would rather build on existing functionality: Course memberships + LP groupings via folders could be an implicit "task" (in an attempt to use the vocabulary of the task manager).
4. A reminder service would likely benefit from such an abstraction of tasks. IMO ILIAS objects should then be able to define system tasks (in the sense of the TM concept). At the same time, it should be possible to define potentially different multi-stage reminders for this one task of that object. Reminder texts could be either defined on-site or selected from templates each time. IMO this goes far beyond a task manager and would therefore be well-off in a dedicated service - which could certainly be wired tightly with the TaskManager. This also leaves the door a little bit open to have reminders that are not coupled to a task.
5. The notification system would later take care of the aspect of how the reminders are delivered. I also see this as a separate service.

• Wednesday 10.02.2017, 10-12 h

Schmid, Fabian [fschmid] 2017-01-23 (via email) in response to Colin Kiegel: 

Die von Colin genannten Punkte sehe ich grundsätzlich gleich, gerne führe ich hier noch etwas aus. Im CC ist zudem Theodor Truffer, er ist seitens srag für den TaskManager zuständig.

zu 2:
Genau, der Zusammenhang zum Reminder ist, dass ein Task durchaus einen Reminder haben kann, aber nicht zwingend. Das verhält sich genau gleich, wie beim Zusammenhang Kalender-Appointment und Task. Ein Task kann im Kalender repräsentiert sein, muss aber nicht.

zu 4: 
Das sind mögliche Anwendungsszenarien von SystemTasks. Alle Tasks, egal ob diese in einem TaskManager-Magazinobjekt oder aber als SystemTask bei einem Nutzer abgelegt sind, kann der Status des Tasks über externe Faktoren bestimmt werden (Lernfortschritt, Status, ...). Wird ein solcher Task aus einem ILIAS-Objekt erstellt (was ich mich durchaus vorstellen kann) und dem Benutzer in die SystemListe gelegt wird, erhält der Tasks eine Verbindung zum ILIAS-Objekt. Sind Tasks nun auch noch in der Lage, Reminders zu haben, fände ich dies auch sehr interessant. Die beiden Systeme schienen für mich gut geeignet um zusammen zu arbeiten, haben aber keine zusammenhängende Funktion.

zu 5:
Dito, siehe ich genau so. Vielen Dank Colin für deine Einschätzung. Generell begrüsse ich hier die einzelnen "Services" so auszulegen, dass die Interfaces dazwischen klar sind und dass sich zukünftige Services daran "bedienen" können. Ein Service soll eine Funktion haben und nicht mehrere in sich bündeln. 

Killing, Alexander [alex] 24 Jan 2017: I do not think it is a good idea to push customization of high number of task notifications when there is neither a good task nor a notification implementation in place. Customization of the texts should be the last step not the first. I would prefer to

• first have an overview of (system) tasks for users (using a general approach for task defintion),
• then have a system that notifies (using default texts) which can be configured by the recipients (if, when, how)
• and after that take care of customization of the texts.

Kiegel, Colin [kiegel] 2017-01-24:

• @Alex:
  • I agree that we should try to defer some aspects to later iterations in order to decrease the overall complexity. With customizable texts, I basically see it the other way around: I would like to start with customized texts and defer centralized templates instead. This better fits the needs of our customer.
  • I thought about aggregations too. I would like to introduce a different notion for that - something like a report. At least this helps us understand what we are talking about. I suggest to define a report as some kind of aggregation, whereas a reminder itself would not aggregate. You are right about situations where both make sense. Our experience with the Compliance AddOn from Databay (and Qualitus) tells me so. Some installations prefer monthly reports for their users, but most actually prefer individual reminders per course. I would argue that it should be possible to disable the reminders on a course level (without disabling any tasks). Then a global report could be enabled. This is also how the Compliance AddOn does it.
• @All: To prepare the workshop I want to throw in a suggestion which is based on our discussion so far. It's certainly a bit handwavy, but may give us some 'scaffolding' for further discussions.

Killing, Alexander [alex], 25 Jan 2017: I moved to API proposal to the top section, since it is part of the proposal and not of the discussion. I also fixed the discussion by assigning the DiscussionPosting style.

Kiegel, Colin [kiegel] 2017-01-25: Ok. I was hoping to get some feedback before integrating it into the proposal, but I see your point. :-)

Killing, Alexander [alex], 25 Jan 2017: It is your current proposal, you can mark it as work in progress, if you want. The discussion is open and you may change the proposal at any time.

Kiegel, Colin [kiegel] 2017-02-10: Protocol of JF Workshop (Matthias Kunkel, Colin Kiegel, Alexander Killing, Michael Jansen, Fabian Schmid)

Matthias Kunkel: A reminder service would be a very important addition to ILIAS. But we need to get it right. For use cases like here we should first introduce a task (as in Introduction of TaskManager). This task should then have a reminder.

Colin Kiegel: I agree, that having tasks as an intermediate layer makes sense in most cases (including the use case of lotto hessen). However I can also imagine reminders without the notion of a task, e.g. calender entries 'grandmas birthday', sessions, etc. IMO the reminder service and the task management should technically only be loosely coupled, such that other components like the calender can decide to implement reminders without tasks. At least we could keep this door open a little.

The overall opinion is that a technical concept is needed, which addresses the connection between task management and reminder service.

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