At the moment we include a list of time-splitting methods with hardcoded values. As this list increases is it more confusing for people to know which time-splitting methods suit which models. To include a UI for time-splitting methods would reduce our dependency of PHP-coded time-splitting methods (they would use the UI to set them up) and would allow people to tailor the predictions to their exact needs (instead of using 'upcoming week' or 'upcoming fortnight' they could set it up for the upcoming X days).
This is not a trivial issue and it requires good UI/UX. Even with a nice UX this is a complex tool only for advanced users. All the UI/UX should be lead by the UX team, but just to illustrate how the feature would work: I see this as a new 'Custom' option in the time-splitting methods' select menu (internally it would be a custom_timesplitting class), when selected a new 'Customise' button would be made visible next to the selector. Clicking on this new button would open a modal window where the custom time-splitting method would be set up.
We basically would have 3 different root types of time-splitting methods, each of them with its own variables, set by the user:
- Split the course in equal parts and generate insights for each of them.
- Number of parts (e.g. 4, 10, 15...)
- Accumulative or not (should each new part include the previous?)
- Predictions for the past or for the future (are we calculating indicators for past data or are interested in upcoming stuff)
- These existing time-splitting methods could be converted to this type: "Quarters", "Quarters accumulative", "Tenths", "Tenths accumulative"
- Generate insights periodically
- Periodicity (e.g. Every day, every 3 days, every fortnight...)
- Data used to calculate the indicators (e.g. Previous day, previous 3 days, upcoming 3 days...)
- These existing time-splitting methods could be converted to this type: "Upcoming 3 days", "Upcoming week", "Upcoming fortnight"
- Specific time ranges
- This root type would allow users to define a set of time ranges when insights will be generated. E.g. One 3 days after the analysable start, another one 1 month after the analysable start and another one 1 week before the course end.
- Time ranges would be relative to analysables start and end, as well as hardcoded values introduced by the user.
Technically, we still want people to have the ability to write time-splitting methods in PHP so I see this as:
- A new 'custom_timesplitting' class that would delegate the internal processing to other classes, instantiating them also internally.
- A new db table 'analytics_timesp_custom' with fields: id, modelid, type, data. Where 'data' would be 'type' dependant.
- has been marked as being related by
MDL-69967 Create a upcoming 1 day time splitting method
- Development in progress