Difference between revisions of "My course overview improvements"

Jump to: navigation, search
(Progress)
Line 32: Line 32:
 
* Name of the task ("Submit assignment")
 
* Name of the task ("Submit assignment")
 
* Action when clicked (optional)
 
* Action when clicked (optional)
 +
* Action only available from-to (optional date)
  
 
This list needs to be able to be ordered and paginated by course, date, and original course order of the items themselves.
 
This list needs to be able to be ordered and paginated by course, date, and original course order of the items themselves.
Line 49: Line 50:
  
 
No course completion:
 
No course completion:
For courses without course completion - this will be the active section number / the total number of sections - or some calculation based on course start / end date.
+
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.
  
===Specification===
 
  
==== Todos ====
 
  
 
The name is "Todo".
 
The name is "Todo".

Revision as of 06:00, 7 December 2016

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)

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?

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