Show Advanced KnowledgeHide Advanced Knowledge

Introducing Task Service and Queuing Derived Tasks

This entry was changed considerably after the workshop held 2017-01-12. 

1 Initial Problem

Users have to do stuff but their jobs are scattered in different courses in different objects. Users have no overview over what they have to do next. 

2 Conceptual Summary

A Task is an implicit concept. They do not have to be created manually, but will be automatically presented to users. 

Tasks are jobs users need to complete at an appointed time or in time. 

• Users need to complete some job for an upcoming deadline or end date.  IF there is an End Date or a Deadline a task is created.
• Users need to complete some job after a deadline or end date has passed. 
• Users need to complete some job after a previous action has been made by another user.

Tasks can occur from not-dated events that require following up. (NOT adressed in this article but here) 

• i.e. New user registered on the waiting list of a course and course administrator is to respond. 

Tasks are presented as

• a short entry in a block on the Personal Desktop
• a full entry in a section on the Personal Desktop

Feeding the list
For starters the list is fed by :

• Deadline of an assignment is set > complete the assignment 
• Deadline of an assigment reached > start gradig
• Deadline of an assigment reached > give Peer-Feedback 

Block on Personal Desktop 

1. Detail Level: n Task(s)
2. Detail Level: Linked title of Task-emitting object
3. Detail Level: Linked title and what to do as by-line 

Full entries in section on Personal Desktop
Full entries should indicate how many grades, feedbacks are to be given along with a link to the repective object.

Behavior of Block and Section 
Once the Task is completed the entry should disappear from the Task List. Cron-jobs could be implemented to make a self-updating list. 

If the Task service is opened it  will ask the objects on-the-fly for tasks. There will be no additional persitence layer. 

NOT suggested in this arcticle but conceivable extensions of this concept: 

• i.e. End date of test reached > start manual correction and communicate results
• i.e. Blog or Forum post need approval > approve
• i.e. End date of Learning Module is approaching > complete Learning Module 
• i.e. End date of Course is approaching > complete course

3 User Interface Modifications

3.1 List of Affected Views

• Drop-Down of Personal Desktop gets new entry  "Task List" 
• New section on Personal Desktop "Task List" 
• Personal Desktop gets a new Block "Task List" 

3.2 User Interface Details

3.3 New User Interface Concepts

None.

4 Technical / Conceptual Information

Killing, Alexander [alex], 22 Jan 2017: Collecting tasks for multiple components may take some time (e.g. get all exercises with edit permission, check if gradings have been done for all assignments). I would vote for a message on the screen that states when the task list has been updated the last time and an "Update Task List" button. The list updates itself once a day per default and moves all information to an internal cache, so that subsequent queries are quick.

4.1 Interface Sketch

Components that define derived tasks need to notice the use of the interface via module.xml/service.xml. E.g. by included a < tasks/> tag.

Additionally they need to provide a class that implements an interface "DerivedTaskProvider":

/**
 * Return all open derived tasks for the user
 * @param int $user_id user id
 * @returns DerivedTask[]
 */
function getTasks($user_id)


The objects returned by this function must implement another interface "DerivedTask":

/**
 * Get title of task
 * @returns string
 */
function getTitle()

/**
 * Get ref id of corresponding repository object
 * @returns int
 */
function getRefId()

/**
 * Get deadline of task
 * @returns ilDatetime|null
 */
function getDeadline()

/**
 * Get starting date/time of task
 * @returns ilDatetime|null
 */
function getStartingTime()

This is a PULL interface where the serivce pulls the information from the consuming components. As written above the service would provide some internal caching. A PUSH (consumer hands in tasks) interface is currently not suggested, since it is not feasible for the requirements we are currently dealing with, e.g. most of the exercise tasks will be triggered by time events (which would require a cron job to create PUSH these tasks).

4.2 Reminder vs. Task

JF 22 Jan 2018 asked: "Please explain if a reminder service is needed for a task aggregation service or not."

Killing, Alexander [alex], 21 Feb 2018: No, a reminder service is not needed. Some quotes from Reminder Service discussion:

• Fabian: "...dass ein Task durchaus einen Reminder haben kann, aber nicht zwingend."
• Colin: "...IMO the reminder service and the task management should technically only be loosely coupled"

So, IF a reminder service exists in the future it COULD be used by the task service as well. But I would not be a prerequisite for this proposal, since it only presents data on the personal desktop. It does not suggest to send any mails.

4.3 This proposal vs Task Manager Proposal

Killing, Alexander [alex], 21 Feb: The Introduction of TaskManager proposal is a much wider set of features and functionalities than this proposal. Nothing of the Introduction of TaskManager proposal is needed here: no repository object, no manual creation of tasks, even the system tasks on the Introduction of TaskManager proposal is characterized as:
A Systemtask features the following:

• Can be assigned to a certain group of users, e.g. "All new users", "All Users", "Users with role x" etc. (Not needed here)
• Can be system-blocking: must be executed before ILIAS can be used (like "Accept the EULA") (Not needed here)
• A prompt for optional tasks can be configurable. E.g. users should be prompted after each login to complete these tasks.  (Not needed here)
• Each user has a "Systemlist", containing all assigned systemtasks (Yes, we need a list, but with even another kind of task)

Since manual created and system tasks are already terms being used in the Introduction of TaskManager proposal, I would like to call our tasks here implicit or derived tasks. These are tasks that already implicitly exist by the implementations of features today (ILIAS 5.3). E.g. if an exercise assignment or a peer feedback already defines a task for a user. There is just no service that provides an overview of these existing tasks. These tasks automatically vanish, if the corresponding actions in the consumer component have been done, e.g. if the user hands in an assignment the corresponding task will automatically disappear.

Hansjörgs comment below of Feb 1st 2018 includes a lot more requirements for a much more elaborated system than proposed here. If such a system exists, it could hopefully "simply" include the type of tasks we are dealing with here. But we cannot take care of these huge requirements (defining projects, ...) in this proposal. I do not see any reason why the implementation of this feature would prevent the development of the system described by Hansjörg in the future (which I would consider being a separate development).

5 Contact

• Author of the Request: Tödt, Alexandra [atoedt]
• Maintainer: Killing, Alexander [alex]
• 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

JourFixe, ILIAS [jourfixe], 22 JAN 2018 : We like the suggested feature and see it as an important tool in ILIAS. But still need some more input and feedback to make a final decision:

• We would like to have a suggestion for an interface concept that we can use as input for a common discussion.
• We invite everybody to list use cases on this page for future scenarios where task could be created / are necessary.
• Ideas for the presentation of a task list that can deal with different task types (with / without deadline, automatically / manually created tasks).
• Please explain if a reminder service is needed for a task aggregation service or not.

Lauener, Hansjörg [lauener], 1. Feb. 2018.: Tasks and a Task management system for ILIAS (abbr: ITMS)

We have at least two fw-entries focusing on tasks.

• https://www.ilias.de/docu/goto_docu_wiki_wpage_4125_1357.html
• https://www.ilias.de/docu/goto_docu_wiki_wpage_4910_1357.html

Thanks to SRAG and Alexandra for these proposals. We think tasks could be indeed a great functionality. We used both fw-entries for creating this statement.

1. In general, we should focus on Userstories: Ask our clients what kind of user stories they have, match them with our own ideas, discuss them in several groups, and do a condensation of the results. This should be done before we create the first mockups.
2. Then: Similar to the calendar, there are already dozens of well-designed TM-systems available. Teachers and learners use them, as a part of their Personal Learning Environment. A TM-system in ILIAS (ITMS) have to fulfill in several areas: Functionalities, Usability, Performance. If we don`t care about this, then nobody would use a ITMS!

For this two areas, we give some ideas, what the community should do.

1. Create new (and discuss the already existing) user stories. Some of our first user stories are:

• a) A ITMS allows teachers and learners to manage their own (learning-) tasks. The great advantage with ILIAS is: An TM-system in ILIAS would be available "at no charge" for the users, compared with "Freemium"-Systems. Individual users could use the ITMS also as a starting point. They should be able to create projects, task lists, and tasks in these lists. They should be able to create quick tasks connected with objects (Core and Plugin-Objects).
• b) An ITMS allows teachers and learner to create projects (e.g. in groups), and create collaboratively task lists and tasks. A project, task list or task is then visible (and/or) editable for all users. This allows an efficient project-management (e.g. writing a paper, prepare a lesson, manage a bigger project). Combined with the ILIAS-milestones, this ITMS-use case would foster the "Arbeitskooperation" in ILIAS: Sharing tasks, define task lists or tasks as milestones, share tasks, give users the possibility to organize their work with a Kanban-board (or other views) and show them with specialized views the degree of fulfilment of the project.
• c) The ITMS could be the instrument for creating (collaboratively) in new ILIAS course/group. With tasks and subtasks, they can "design" in their course. The title of the task could be the title of the object. Some additional information could design what kind of object this would be. A final button "Create Course" would add all folders, forums, exercises, and much more.
• d) Teachers/authors could use the ITMS to create Learning material (eg. ILIAS LM and ILIAS tests) collaboratively. Tasks are used to distribute and manage the work, incl. discussions about the quality of the produced content.
• e) A ITMS could be implemented together with the "Arrange and Replay Learning Resources"-functionality. With the ITMS-technology, with a special subtype of a task list, where teachers could create Learning paths. (see https://www.ilias.de/docu/goto_docu_wiki_wpage_4882_1357.html)
• f) And last but not least, teachers could create Learning-task lists with the ITMS, in their courses, or in groups. A Learning-task list then present a list of tasks for learners (e.g. Read-a-paper, create a forum entry, do a test, hand in exercise nr. 3, ...). Learners can check individually when the job is done, or ILIAS present to learners (and teachers) an overview.

2. Learn from existing task management systems
We should focus on several areas, depending on the final discussion in use cases.

Usability, User-Interaction

• Try out different elaborated TM-systems (asana, redbooth , ...)
• What user-interaction we think are fruitful in the ITMS?
• Discuss the design we want, the different places where individual, collaborative, learning, and aggregated tasks will be presented
• Discuss different views/reports we do like

technology

• The ITMS should be more or less as usable and as fast as the Redbooth-tm (try redbooth.com)
• What technology we have or what technology we`ll introduce for that?
• Do we build all views/reports (eg. Gant, Kanban, ...) in the core, or do we add plugin-slots
• Do we reuse existing (calendar)-views, or do we

global administration-settings. The ILIAS-admin

• can (de)activate the ITMS globally?
• can allow individual TM. Decision (Usecase a)?
• can allow collaboration TM (Usecase b)?, etc.
• Default-statuses for different task-areas?

Design functionalities in detail

• detail specification
• ...

JourFixe, ILIAS [jourfixe], 26 FEB 2018 : We highly appreciate this feature request and schedule it for 5.4. We would like to clarify that tasks do not need necessarily a deadline. Open-end tasks are possible as well, e.g. the task to have a look at the waiting list (which is not subject of this request). Additionally, we would like to clarify that this feature request is independent from the request of a general task manager in ILIAS (see Introduction of TaskManager). A future task manager could integrate the current task service and probably would take over the control of the presentation of tasks in the Personal Desktop menu. We think that the task concept is extensible by the concepts being outlined in the Task Manager proposal and we think maintainership of future task manager is not bound to the maintainership of the current proposal.

Kunkel, Matthias [mkunkel], 28 FEB 2018: I changed the title of the feature request to "Introducing Task Service an Queuing Derived Tasks" to give a clearer impression of what this request is about.

Kunkel, Matthias [mkunkel], 27 APR 2018: While specifying the request "New task: Requests for membership" I noticed that the block detail level 2 described above does not consider the existence of tasks from other object types and should be implemented in a different way. We have three detail levels available for a PD widget.

• Level 1 of a task list widget should only show the overall number of tasks for a user - like shown above.
• Level 3 is a list of every open task that should indicate WHAT to do WHERE (and until WHEN) - like shown above.
• Level 2 is currently a list of every open task without that only indicates WHERE something has to be done until WHEN - but not mentioning WHAT to do. IMHO it would make much more sense to use level 2 for another aggregated list and to list the numbers of WHATs. Example:
  • 2 submit feedback
  • 1 provide feed-back
  • 3 request membership

Additionally, I suggest to link the level 2 entries to the PD menu entry Task List to speed up navigation. Same could be done with level 1 entry while level 3 entries - as far as I understood the request - are already linking to the object itself where the task has to be done. To improve the usability of the task list itself I have also added a new request Sortable Task List.

AT 2018-06-25: The block level 2 should not indicate the title of the object but rather the nature of the task:

• Submit Assignment before date (linked to assignment)
• Provide Peer Feedback before date (linked to assignment) 

JourFixe, ILIAS [jourfixe], 12 NOV 2018 : We highly appreciate this suggestion and re-schedule the feature for 6.0. Please consider Matthias' suggestions when implementing the feature.

8 Implementation

• Submission and Peer Review Task: Only listed participants[1] of the exercise will receive these tasks.
• Grading Tasks: Only users that activated the "Submission Notification" will receive these tasks (since there is not concrete tutor concept in exercises yet). The option will be renamed to something more suitable.

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

Test Cases

Test cases completed at 2019-05-09 by Tödt, Alexandra [atoedt]

• 25221: Abgabetermin einer Übungseinheit erscheint in der Liste der To-Dos
• 25222: Übungseinheit OHNE Abgabetermin erscheint in der Liste der To-Dos
• 25223: Seitenblock To-Do auf Persönlicher Schreibtisch > Übersicht
• 25224: Peer-Feedback zu einer Übungseinheit erscheint in der Liste der To-Dos
• 25225: Bewertung einer Übungseinheit erscheint in der Liste der To-Dos

Approval

Approved at 2019-03-11 by Claudia Frie and Maximilian Tietz, Uni Hannover

---