Cht-core: Ability to group tasks by family, and sort those groups by nearest due date

[amandacilek-zz]

Relates to #5776 (make it clear that tasks can be completed anywhere in the window). Assumes that #5697 and #5710 have already been completed (updating hierarchy levels, adding belongs to breadcrumbs to tasks).

Is your feature request related to a problem? Please describe.
Some CHWs have a hard time navigating the tasks page when it is organized by due date. What we have heard is that they would find it more useful to have the tasks organized by area or household, so that they can prioritize other tasks nearby.

Describe the solution you'd like

1. Add the ability to group tasks together by family, and then sort those grouped families by nearest due date. This means that tasks for the same family will always appear next to each other, but the family groupings will not be sorted alphabetically but instead by due date.

Referring to this mockup:

• The first two tasks are in the Beatrice Bass Family group. Because there is a task due today, this group (the Beatrice Bass Family group) is first.
• There is only one task for the Zelda Zed family. It comes next because the task is due in 1 day.
• The last two tasks are for Amanda Allen’s family. Even though this family would alphabetically go first, the group comes last because there aren’t any tasks due for at least 2 days.
• Note: The horizontal lines separating family groups are just for mockup purposes, no intended UI update.

1. Add a sort icon to the top tasks bar which gives users the choice to either filter "By date" or "By family". Also, I recommend that we change the default sort so that we sort "By family" by default.

Describe alternatives you've considered
Considered a true alphabetical sort of tasks by family name, but this isn't as helpful, since it might put a task due in 2 weeks for Amanda Allen's family at the very top of the list.

[MaxDiz]

fyi, completing design review with partner for this issue

[MaxDiz]

based on conversation with @n-orlowski , removing from release and returning to the backlog for future consideration

[ecsalomon]

A relevant story from a deployment:

Background:
An issue was reported of perceived duplicate tasks for a person. On investigation, the tasks belonged to 2 different people from different families with similar names.

Problem:
There wasn't a way of easily establishing that these were different persons since it is only the name of the person that's indicated on the tasks list. This also implies that even if the user is aware of the 2 persons with similar names, data capture can be mixed up as he/she can't tell which person is being worked on.

[MaxDiz]

adding to 3.12 based on roadmap discussion. @n-orlowski please make sure design is complete and work with @michaelkohn to scope dev requirements

[n-orlowski]

Reviewing the designs above we've noticed that once the top item (grouped by family and sorted by due date) is cleared, the task list will rearrange itself to show the next due item and its relative family (instead of keeping the initial task grouping at the top).

My proposal is to simplify and have the tasks be sorted only by household name (same order as the People tab). In the scenario described where a CHW is in a specific area and wants to prioritize tasks nearby, sorting alphabetically makes it easier to find those households than households grouped by due date.

This is also a more conventional sort order which is something to keep in mind when considering potential future sorting and filtering states.

@yembrick, tagging for your input as I believe you were involved in this initial design!
cc @michaelkohn

[yembrick]

I see what you are saying here. 

Playing this out a bit... say the CHW has the page sorted by due date to see their most time pressing tasks. Then the CHW goes to the household with the nearest due date to complete the task. To see other tasks for that household they would have to manually change the sort order to family. Is this something we imagine the CHW would do every time they visit the household? Would they start a day with the due date view, to plan their household visit schedule and then change to household sort for the actual visits? 

I don't love having to switch back and forth to see this info, but agree that the previous design doesn't really work as tasks are completed and the page re-arranges. That seems like it would be confusing and likely frustrating. I think this new proposal is better, even it requires a manual step to change the sort. I definitely agree its more extensible as well, as we might introduce other sorting options in the future. 

[ecsalomon]

Feel free to tell me this is a terrible idea and/or is not feasible, but what if grouping tasks by family gave a family summary instead of the individual tasks with something like 3 tasks for two people and the _soonest_ due date. Then, to see the tasks for that family, you clicked into a page that has that family's tasks. When you complete a task, you go back to _the family's task page_ rather than the list of families. Would this allow the families to be sorted by task due date without the re-ordering issue?

[This might be an alternate view of contacts rather than tasks... it falls somewhere between those pages in terms of functionality.]

[n-orlowski]

Working with the team we have come up with our desired V1 and V2 solutions to address the scenarios of CHWs wanting to easily find and complete available tasks within the same household and to find tasks for households nearby.

We'd like to be able to (V1) sort and group tasks and (V2) to add an interstitial page once a task is submitted to prompt users to complete other tasks within that group. For this issue I'll focus on V1:

• Default sort by due date as this is how CHWs prioritize their work
• Dropdown sort selection to view task groups (in this example, by household and "general" for tasks that are not associated to a household)
• Groups are labelled and ordered numerically for days left and alphabetically for households
• Tasks within groups are ordered by due date (ex. within household A, show tasks that are due soonest)
• Once a task is submitted, return to the same sort order
• If the user leaves the task tab (ex. closes app, opens other tab) and returns to it, default to due date view

The third screen (priority) is an example of how this pattern might scale to include future sorting options.

Questions: cc @garethbowen

• If we are collecting GPS data are we able to sort by household task distance? ex. within 2km, 5km+? This might be a more efficient way to find nearby tasks than scrolling through names
• This specific issue refers to households but I'm wondering if we are able to make these groups configurable so that other non-household apps may utilize this feature in a way to better suit?
• Can this address https://github.com/medic/cht-core/issues/5997?

As always, let me know if I missed anything ✌️

[kennsippell]

Very curious about the interface being exposed to app developers. Sounds like we can define groups, assign tasks into one or more groups with an associated sortable key? The default proposed here is "no grouping" (sort by due date) - could app builders select the default (eg. two apps right now would want the "priority" grouping by default).

[garethbowen]

If we are collecting GPS data are we able to sort by household task distance? ex. within 2km, 5km+? This might be a more efficient way to find nearby tasks than scrolling through names

This is definitely an idea worth exploring but I think it's probably outside the scope of this issue. Currently the GPS is collected based on where the form was filled in which isn't always at the family home. I think to do this properly we would want to add a location widget to the family registration to explicitly set the location of the family home. It may also be technically challenging to work how out far apart two GPS coordinates are, so I wouldn't like to see that derail the other improvements in this issue.

This specific issue refers to households but I'm wondering if we are able to make these groups configurable so that other non-household apps may utilize this feature in a way to better suit?

Because contact types are configurable the system doesn't know which type is a "household". I imagined that the implementation would be something like "allow sorting by the lowest place contact type you can see". Depending on how the replication depth is configured this may be useful for supervisors to group based on clinics.

Can this address #5997?

I think that can be done separately by adding an additional filter option to this filter.

Very curious about the interface being exposed to app developers. Sounds like we can define groups, assign tasks into one or more groups with an associated sortable key?

Currently I don't see that specified in the design. As in my comments above my initial thought was to implement this based on the configured contact types. I'd prefer that we implement a few hardcoded filters (eg: date, contact, priority) and if necessary allow them to be toggled on and off, with a configurable default. This allows the Product team to regression test pre-release and optimise the performance of each filter.

The default proposed here is "no grouping" (sort by due date) - could app builders select the default

The concern with setting the default sorting by contact group is that tasks for the Yankovic family will always be at the bottom, so even overdue tasks will probably be missed. So I don't think that sorting by contact group should ever be the default.

...two apps right now would want the "priority" grouping by default

Priority sorting is covered by a separate issue so it would be good to flag these projects there to help with the design of that feature.

[yembrick]

Thanks for these updates everyone. I really like your suggestions @n-orlowski , this feels like a big improvement. Upon further reflection, Id like to propose v1 and v2 be tackled together - including the summary page for other group tasks in this issue. I am not seeing v1 as an MVP and v2 as an improvement. Either option alone feels incomplete to me. This has been on the roadmap for a long time, and we've had such strong feedback from users about this being a priority area of improvement in the UI. @MaxDiz @garethbowen can we talk about this from a scheduling perspective?

[MaxDiz]

Hi @yembrick this issue is currently scheduled in v3.12 (next release). Breaking into v1 / v2 is new from the release prioritization. We can discuss at the next roadmap planning meeting.

[kennsippell]

we've had such strong feedback from users about this being a priority area of improvement in the UI

@yembrick Do recall which users gave this feedback? Which apps?

[yembrick]

Gosh, some of this was a long time ago, it would take me a bit of time to find notes from those visits. We ran a session with LG-Uganda CHWs on redesign for tasks page back in maybe 2016/7. Also with the LG-K IN Predictive Algorithms group in 2019. This was discussed with Muso CHWs last year, but I wasn't there for that and can't recall exactly how this ranked against other improvements to tasks page.

[kennsippell]

I'm wondering how we are going to measure this feature's success quantitatively, and which partners we have discussed this experiment with to ensure they will prioritise a cht-core upgrade to pilot, train, and give feedback when 3.12 is ready. I think this issue sounds like a really great experiment with a solid founding to add potential value to apps and users, let's make sure we can find real users who agree and are signed-up to try it.

That said, https://github.com/medic/cht-core/issues/5997 has quite some overlap with this issue (largely same UI). Tasks by priority are in-use today by two (or three?) CHT apps (Niger, Goma, Educational modules reference app) that use hacks to create task priority via static due-dates, and overwrite parts of the UI to make them disappear. For these apps, tasks by priority is a requirement (tasks have no duedate) and it's possible this feature could be implemented in a way that would make those apps ineligible to upgrade to >3.12 until https://github.com/medic/cht-core/issues/5997 is fixed. Just wanting to call out that concern to improve the changes it will be mitigated successfully.

[yembrick]

Thats really interesting @kennsippell - I am not yet familiar with those task by priority implementations that have happened recently, thanks for sharing! I know @n-orlowski thought about the "priority" tag/sort in this design, but not sure how these are considered in a staggered development across these 2 issues.

I think this is an experiment we could test with any partner that upgrades to 3.12, that was previously on 3.8 to have had some task data collected. There's a small pool of partners that might be. Theres an interesting conversation here on how ready and willing the users need to be, and how that improves our timelines (due to willingness to upgrade mainly).

[MaxDiz]

Following on our Dec-2020 Roadmap Planning meeting, we decided to split this issue into 2 improvements based on the designs shown here. Both issues should be scheduled in v3.12 to kick-off the release.