My course overview improvements
This page will detail the technical specification for the improvements to the My course overview block.
| Improvements to my course overview block. | |
|---|---|
| Project state | Starting |
| Tracker issue | MDL-55611 |
| Discussion | https://tracker.moodle.org/browse/UX-8 |
| Assignee | HQ Projects Team |
Summary
The new design for the UI for the course overview block requires the ability for Moodle to efficiently query plugins for a list of "date based" tasks for the current user.
The existing "mod print_overview" callbacks do not have sufficient functionality (no separation of fields, inefficient, incomplete, no relation to completion API, inconsistently implemented across modules) so we will have to build a new API (and deprecate mod_xx_print_overview).
Requirements
A user viewing the "My course overview" block will need to be able to see:
Todos
A list of tasks from activities with the following attributes:
- A unique identifier for the todo, the context id, component, area and itemid.
- The name of the thing this relates to (default to the activity full name)
- The link to the thing that this relates to (defaults to the view.php of the module)
- The course this thing relates to (required)
- An icon (default to activity icon)
- A start date and time (optional)
- An end date and time (optional) - current prototype shows this - maybe it's not needed
- A count of items (e.g. 4 unread posts)
- Name of the task ("Submit assignment")
- Action when clicked (optional)
- Action only available from-to (optional date)
- Display/order date (either the start or end date)
The action stuff (name of the action, url, count of items, availability) could be generated at run time, per module, based on the event details since it can change based on permissions etc.
This list needs to be able to be ordered and paginated by course, date, and original course order of the items themselves.
The items in this list must obey the rules for module visibility. If the user cannot see the module they cannot see the task.
To clarify with UX team
- How many items to display in "Next 7 days"? Is there a limit, or we always show all of the items?
- In the prototype 6c (the one that we are supposed to develop from) the todo disappears from the list when it is actioned. Is this the correct behaviour? What happens to the corresponding event in the calendar? Does that also get removed?
- What do we show when a todo is only available for a certain duration? E.g. chat where it's open for only 3 days. Only having the end date seems weird in that case.
Progress
We need a way to determine a users course progress.
Course completion: For courses using completion this will be the % completed activities.
No course completion: For courses without course completion - we still need to show the progression percentage, and need to find a way to compute one.
Courses tab
The course end date must have an effect on the students access/permissions in the course. Currently, students can still access the course and complete activities.
To clarify with UX team
- Are the courses paginated? Is there a "More" button to load more courses?
- What happens with courses which do not have a start date, and end date? Will they show in "In progress" for as long as I am enrolled in them? Note that if I unenrol from the course, I will lose access to it.
- Are all the three tabs (in progress, upcoming, completed) always shown, even if they are empty?
Specification
Make functions to get the data. Print the data Remove obsolete code
Deprecate print_overview API Todos API
Progress API
The current progression needs to be stored somewhere to performance. Caching may lead to losing the data on upgrade whereas the data is not stale yet. Being notified of changes can easily be known if the course is using the completion API. If not, we'll have to think of something...
Todos API
- Identify todos each core activity will provide
- Identify actions which may affect the status of the current todos (editing module, submitting assignment, changing dates, ...) for each module
Todos could be stored in a gigantic table, possible with another table containing user overrides not to have to create an entry per todo per user per module. Or, query each module each time for the current user, and cache the result. Or, something else.
Invalidating the cache of list of todos has to be considered, we may want to edit/delete a task once the user has taken action on it.
The name is "Todo".
We've decided that we're going to use the existing calendar event stuff to track what the user needs to know about.
Stuff we need to do:
- Make sure we're creating calendar events in every module that requires an action from the user
- Make the calendar API more robust
- Check that the calendar API shows the appropriate events for the user, e.g. if one user has permission to see an assignment and another doesn't then does the event show up for both users?
- Make sure there are proper indexes on the events table
- Add a display/order by date field to the events table
- Build a display API on top of the event data for the "todos" to display them on the course overview block
