Make it clear that tasks can be completed anywhere in the window, not just on the due date

[yembrick]

Through design feedback sessions with CHWs in the PA pilot, we learned that they believe tasks could only be completed on their actual due date, not before, and not after. This was consistent across almost all CHWs we interacted with. CHWs expressed that if they were at a household and noticed that there was a task due for another member of the household the next day, that they would come back the next day to complete that task, rather than completing it in the same visit.

This has the potential to be a huge time/resource drain for CHWs and likely contributes to observed low task completion.

The "due date" language seemed to be particularly confusing.

[abbyad]

Assigned to @ranjuts to lead the design on this issue and recommend app changes with low-fidelity mockups for any visual changes. We can discuss further in this issue if changes to the configuration are also proposed.

[MaxDiz]

Hi @ranjuts design concepts are being reviewed with partners this week and are mostly complete. I will share feedback for discussion

[kennsippell]

@ranjuts @MaxDiz Any update on the designs for this issue? Since 3.8 is beginning, it would be nice to close on whether configuration changes are necessary for this.

[MaxDiz]

@kennsippell I'm bumping this issue to 3.9.0. Requires additional user feedback for design completion

[ecsalomon]

LG IN conducted a training for the PA CHVs to clarify that tasks can be completed at any time in the task window. It seemed to have a substantial effect on when tasks are completed.

[MaxDiz]

Design used for initial user feedback:

Functional detail:

• clarifying note in the information bar describes how the CHW should interpret the due dates. It is permanent (ie no dismiss option)
• only tasks that can be completed are displayed
• “urgent” tag is placed next to any task that is within a customizable date range. It is always displayed in bold + red to draw attention.
• “x day(s) left” tag is placed next to each task that is not “urgent”. The maximum number of days and the calculation are customizable. It is always displayed in normal + grey.

[MaxDiz]

follow-up notes from @ranjuts

1. I don’t think we should display tasks on this list unless they can be accessed and completed, we already have issues of them seeing too many tasks so this option is likely to add to that.

2. I like the explanatory note on top of this page as it is. The way that’s it’s written right now is clear- my suggestion is to stick to “anytime” vs “today”. I think it’s okay to NOT have an option to dismiss the note, it’s good value for the space. But I don’t have any strong reservations about having that option either.

3. I like the idea of grouping tasks based on due vs overdue -- however we need to consider how we fit the other filtering and sorting options that we might need for other user stories (e.g. based on location, type of tasks, high priority vs others etc)

4. The “1 day left” verbiage is clear and translates well in the languages we’ve worked w in asia -- spacing might be an issue though we should mock some up. “Urgent” is preferred to “High priority” however this is a term I envision being translated differently (there are subtle differences in how the two terms translate in the languages we work in so it’s sth really the designer on the project would need to think about in the particular context anyways).

5. This might be straying a bit from the conversation but the way we think about the “due date” and even the necessity to have a due date for each task is sth to reconsider. If we just had a window which has the start date where they can start completing tasks and an end date when they should be done by (so really the due date is the entire window instead of a particular date in the window - which is the case for many tasks) it might be much simpler for the CHW to grasp. So when I as a CHW see “1 day left” I really only have a day left to access and complete the tasks. If we shift to such thinking, then # 1 on the list above would be a good idea and we would group in terms of upcoming (that are coming up but can’t be completed yet) and those due and completed anytime (and we could add the explanatory note right under each group title instead of top of page)

[MaxDiz]

Feedback from @mmureithi design field visit: https://docs.google.com/document/d/14AHiWtqP7lnPmOVMEyFr2mS_3N8P1Teheg5vSeg-6-U/edit

[MaxDiz]

Feedback from @isaacholeman: https://medic.slack.com/archives/C09292U2U/p1570835299008200?thread_ts=1569853219.012800&cid=C09292U2U

[MaxDiz]

design concept pulled from asana that captures some of the task time window categorization that we've discussed and may better accommodate the use of labels

[MaxDiz]

@yembrick this issue is scheduled for development in 3.9 (Jan 2020). How is the final design progressing? Do you need team help?

[n-orlowski]

Conclusion from Maryanne: Most of the CHVs interviewed were in favour of addition of the explanatory bar to serve as a reminder that tasks may be completed at any time. Training and regular refresher trainings on the labels used in the task page, is essential for accurate interpretation of the labels-this should be included in all training guides moving forward. Preferred labels combination by majority of CHVs interviewed include:

Xx Days ago
Today
XX days left

From Isaac: IMHO a more elegant solution would be to have an in-app notification system that uses angular animations. I first started seeing this kind of design pattern for in-app notifications in the Twitter app (will post screen shot) and it’s been pretty widely picked up by other apps now. There’s also an open source library for supporting this kind of notification, and it has a giff demo that may help to convey what this would look like. https://www.npmjs.com/package/angular-notifier

[yembrick]

Clarifying the above conclusion is from @mmureithi not @maremegaye -- here is the document link with the feedback from the sessions she ran with LG IN CHWs end of 2019 https://docs.google.com/document/d/14AHiWtqP7lnPmOVMEyFr2mS_3N8P1Teheg5vSeg-6-U/edit?usp=sharing

[n-orlowski]

Ah, my mistake! Thanks

[isaacholeman]

Just realized that I don’t know how we implement the “Report submitted” notification at the bottom of this screenshot, but this is more along the lines of the kind of temporary notification that I had thought might be helpful here. Even if this is specific to Enketo and not something we can easily implement in the Tasks screen, it might still be worth thinking through whether/how the UX of notifications like this could be coherent throughout the app.

[garethbowen]

@isaacholeman That's a Snackbar and is implemented in the app, not Enketo specific, so it's really easy to add anywhere and everywhere. The code is literally a one liner: $translate('report.created').then(Snackbar);

[n-orlowski]

Love this solution! Especially that it's consistent with what we already have implemented / users are familiar with. Tried it in the WIP mockup here (using the elevated layout used in Material): https://invis.io/M2VZL1OWQYZ#/405083494_V1

cc @maremegaye

[isaacholeman]

That's great! To confirm on implementation, is this one line of code in cht-core that we would release in 3.9 and it's inevitably there for everyone who upgrades to 3.9? Or is this something we would add or could turn of or change the content of the text in config code/translation?

I ask in anticipation of the documentation and roll out process; we might need to do some education to confirm that no one is building forms where the tasks do indeed show up before they should be completed. This came to mind when I was doing a demo for someone yesterday, we completed a malaria rapid diagnostic test workflow and community based treatment for malaria, and the task for follow up showed up immediately in the task tab as soon as you've submitted the report. But you're not actually supposed to do the follow up that moment, I believe that it's supposed to be a follow up the day after next. I think this was the older demo and the task showing up immediately was configured that way for demo purposes, perhaps someone could confirm that this isn't the case in the ANC Reference App?

[garethbowen]

Note that the Snackbar implementation we have is a temporary notification - it shows for 5 seconds (IIRC) and then disappears. I think the solution here would be to extend that implementation to make it dismissible, and once dismissed it never shows again.

is this one line of code in cht-core that we would release in 3.9 and it's inevitably there for everyone who upgrades to 3.9? Or is this something we would add or could turn of or change the content of the text in config code/translation?

It could be released in 3.9.0 and we could choose when to show it but it wouldn't be configurable. It would be translatable so a project can change the wording to suit.

[yembrick]

Interesting! A few thoughts:

[yembrick]

• @isaacholeman I have actually seen the scenario youve talked about a number of times. The followup shows up right away in the task list, but isnt actually meant to be completed then. I think we are implementing it that way for multiple projects, if I had to guess, but we could take a look across implementations and recommend changes to better align to actual recommendations.

[yembrick]

sorry im sending these separately by mistake.

• @garethbowen can we consider having it be dismissible but then re-appear monthly?
• @n-orlowski i love how that looks on the mockup! Still think we need to tweak the wording for the task due dates, but thats separate.

[maremegaye]

We’ve been testing these below wordings to display the overdue tasks. Maryanna, Joyanne, Nicole and I were able to test these wordings from different users. X days left: The majority seemed to have a high preference for this option. They explained that the label gives clear directions as to when the task will be “due” and that they are able to plan their work accordingly. They explained that the task can still be completed at any time even with the tag showing. This wording also came out as the best one from the last visit that Joyanne and Nicole did in Siaya.

• We will display all overdue tasks in red and the other ones in green
• Displaying “X days left” shows to users when the task will disappear from the task list. For example, having 2 days left means the task will disappear in 2 days
• Having “in X days” means the user has X days before the task turn red and is considered as an overdue task This mockup has been also validated by the service design team and thinks it is simple for users to understand, especially by showing to them when the task will disappear from the task tab.

[yembrick]

Thanks for the update @maremegaye , Im glad so many people have had eyes on this language now!

• So to make sure I understand, "in X days" essentially means the task will be "overdue in X days"... And it was clear to CHWs that tasks with the label "in 4 days" can still be completed before the 4 day countdown is complete?
• Is there also a "today" or does the label now switch from "in 1 day" to "X days left"?
• Have you confirmed the language for the pop up ("tasks on this list can be completed anytime")?

[maremegaye]

Hey @yembrick

• Yes "in X days" tasks will be "overdue in X days" and will turn red. It was clear for users and designers too

• From "in 1 day" the tasks will be "0 days left". We had also a "today" option in the mockups but realized that it might be confusing for users as there are tasks scheduled only for 24 hours (malaria follow-ups for example) and tasks that are overdue and will disappear in 24 hours also

• The last user feedback conducted, users did not share feedback on the pop-up message wording. But it was suggested by designers to replace "tasks on this list might be..." by "tasks on this list can be..."

Please let me know if you have additional questions/comments. If we all agree with the proposed solution I will go ahead and write the detailed requirements for the dev team. Thanks!

[isaacholeman]

Hi @maremegaye,

Thanks for this update on date labels, this is such a hard problem with so little space available. I really like how this mock-up makes it more transparent to the user when a task is going to disappear. I still feel like there’s some room for improvement though for: 1) text labels, and 2) the green color for non-overdue tasks.

The mock up above makes sense to me once I read your explanation, but I’m not convinced that this UI would be self-explanatory or intuitive to new users. When I initially look at the mock-up above, I think, “why is 2 days left red yet in 2 days is green? Are they due on the same day or not?” At face value these two text labels mean the same thing, and it’s hidden from the UI that one is referring to due date and the other is referring to date of disappearance from the Task list. The result is that we’re relying almost exclusively on text color for the user to differentiate due soon from overdue. It’s generally better practice to use color to reinforce points that are also communicated via text or other ways in the UI. This is partly because some users are color blind, and partly because it can be difficult to perceive colors of small text labels for users with bad eye glasses or a cracked screen or a sunlight glare on their screen. It also just reduces cognitive load to get a cue in multiple ways, and in this case seeing text that appears to mean the same thing with color labels that are clearly different just makes me have to stop and think more.

If the best option we’ve tested has these flaws, perhaps we haven’t tested enough options. Have we mocked up and user tested Disappears in X days? Would probably force longer names to display incompletely, but this may be the lesser of two evils if we can’t come up with a less flawed and shorter alternative. What if we considered labeling these Tasks as Overdue in red and then implementing a snackbar label, so that a user who clicks on an overdue task sees a snackbar label about the number of days until that task will disappear?

My other piece of feedback is that I’d like to reflect more on the choice of the green color for date labels of non-overdue tasks. One of our design goals is to make the use of color more consistent and coherent throughout the application as a whole. In other instances we (and many other web apps) typically use green to indicate completion or success of some user action. In Messages we use green to indicate that an SMS was successfully delivered, in Reports we use green to indicate that a form has been validated, in Targets we use green to indicate that a target or goal has been met.

In Tasks we’re not trying to say that these dates are completed or successful in relation to any user action, so I would expect the text to default to black. Is there some reason beyond the fact that these tasks are not yet overdue? I’m thinking about this in particular because our recent experiments with new algorithms and alerts are leading to a growing use of color to indicate priority and to nudge user behaviors. These kinds of developments pose increased risk that we’ll just add more and more colors with less and less coherence, in a way that overwhelms the UI and makes the meaning of colors less clear to users. I also realize that this is an example of “sweating the small stuff”, so thank you for your diligence on this and for hearing me out 😄

[maremegaye]

Hi @isaacholeman ,

Thank you for this detailed feedback. I hear your point on the text label and the color.

I was able to take a few steps back and brainstorm on your ideas, particularly the snackbar. In the below document I did few mockups to validate the ideas.

For the wording you proposed I prefer having "overdue" in red instead of "disappears in X days" as this sentence might be too long to display on the mobile screen. But I did a mockup on this for the team to comment and share their feedback.

https://docs.google.com/presentation/d/1WYDT2F8NEFM2hhXiqf1PrwUMZkVnUtwy7OC6dNgxWzs/edit#slide=id.g52cf5e6f77_0_5

@n-orlowski it will be great to have your feedback on the UI as well

cc @garethbowen @yembrick @michaelkohn

[yembrick]

Hi @maremegaye. Overall, these mockups feel like a big improvement to me. Im curious to see what Gareth says about implementing the type of snack bar you propose here.

Going with the "overdue" option looks clean and though It does add a click for HWs to initiate a task, that's only for overdue tasks, which doesn't feel unreasonable to me.

I definitely like the look of this black snackbar more than the previous light blue version.

Also a big +1 on getting rid of the green text labels for non-overdue tasks.

The only thing I'm still struggling with here is the text "In 2 days." It's not clear from the UI if this means the task is going to be overdue in 2 days, or disappear in 2 days. It also doesnt seem to clarify if im supposed to do it in 2 days, or before the 2 days are up. We had received good feedback on "X days left" which I think clarifies the second set of questions, but not the first. Some other options "Due in X days" "X days until due" "due before X days."

[n-orlowski]

Latest iteration! Grouping tasks by "expiring soon" and "can be done at any time" with their respective countdowns which alleviates the need for a repetitive snackbar. In future sorting states (e.g. based on location, type of tasks, high priority vs others etc), we can use the same visual chunking pattern (labels for location, type..) for more distinguishable results.

[n-orlowski]

As per convo with @abbyad we should continue to explore treatments that do not break current patterns (and reevaluate patterns when we revisit the nav)

cc @maremegaye

[yembrick]

This is great! Nice work everyone.

[isaacholeman]

This looks great @n-orlowski, glad we took the time to keep iterating here. Do we have a sense of how this new UI will combine with grouping by family (#5886 )? I'd be inclined to say that any family grouping with at least one overdue task will sort into the Expiring soon section. Curious what others think.

[n-orlowski]

@isaacholeman by this logic, this is what it could potentially look like. I'm not convinced this is clear enough (and I think this depends on how many Expiring soon tasks are visible and whether that pushes the rest of the content too far down)..

@abbyad also brought up that this solution breaks current sidebar conventions and that we may want to explore/consider using drop downs or other nav elements less disruptive to the current structure

[n-orlowski]

Proposed MVP for mobile:

Rethought this a little bit to better fit the existing structure.. If we have tasks that can be completed at any time, what is the value of providing the exact dates? What if we only highlight the urgent task dates in red with a countdown until they disappear? Simplifying the UI could be much easier to understand for end users.

This mock uses the dropdown styling to provide Sort options, with "First priority" by date (language picked up from user research docs above) or "Households" using the logic from https://github.com/medic/cht-core/issues/5886

Thoughts? cc @yembrick @isaacholeman @abbyad @maremegaye @mmureithi

[mmureithi]

Awesome work on this @n-orlowski. I also don't see the value of providing exact dates for tasks that can be completed at anytime and would recommend that urgent tasks start showing at least 3 or 4 days before the due date to carter for those whose countdown starts on a Friday as most CHVs/Facilities-level 2s and 3s- do not work during the weekends unless its an emergency.

Am also wondering how best we could encourage health workers (UI related) to complete time sensitive tasks that would not ordinarily "expire" , for example a family survey which would provide updated information that would result to a change in the risk status of a household/individual. Could we employ the use of colour variations...light, medium, dark etc ?

[yembrick]

@n-orlowski and I just got off the phone, and talked through the clinical significance of the due date vs the expiry date, and how we might tweak the above design based on those. The idea is still to simplify things by having only 1 countdown, rather than a countdown to the due date and another count down until the expiry date. The single countdown would count towards the due date, which is the point most clinically significant for encouraging followups to happen by in most cases.

Tasks that are due in >4 days would have no date listed Tasks due in 4-1 days would say "X days left" Tasks due today would say "Due today" Tasks overdue would still say "Due today"

I know we tested the concept of having both due and overdue tasks bucketed together, but I cant find any feedback about that specifically. At the time we had called that whole set of tasks "urgent" -- which CHWs definitely didn't like, but that seems to be more about the wording than the concept of having the tasks grouped in this way. I can't think of any reason that this wouldn't be acceptable from a clinical perspective, or for our programs trying to encourage specific time based followups that are incentivized, but definitely want others opinions on that also cc @isaacholeman .

Also, with only one countdown, the switch from "in X days" to "X days left" and the idea of not including dates for farther out tasks, how do people feel about dropping the snack bar reminder that "tasks cab be completed at any time?" Is that still needed?

[n-orlowski]

^my thoughts would be to launch with no snackbar, see if task completion improves over x number of months and if not to introduce it

[garethbowen]

I don't think the snackbar is the ideal implementation of the product education use case and we should custom develop something which can be used for this as well as other areas of the app for which there is some confusion.

[isaacholeman]

I really like how this has developed. The decision to simplify, the iteration @yembrick summarized above, and the decision to not implement a snack bar all make good sense to me. It feels like we’ve landed in a way that is a substantial improvement on the status quo and that addresses the most important things we need to address. I’d vote to implement this in 3.9 and track and iterate if we need to.

As I recall, we previously discussed using the label “Due today” for tasks that were originally due today and for all tasks that are overdue, but I don’t think we ever did present this option to users in our paper prototyping. I believe this option was rejected because it didn’t provide as much info about when tasks are going to expire, but at that time we didn’t yet realize how visually complex it would be to present more info on expiry and also combine that with grouping tasks by family. Not informing CHWs of exactly when a task will expire seems like the main trade-off here, and I think it’s worth it.

The decision to simplify is broadly something that CHWs tend to thank us for. Counting down to due date rather than expiry is important because it is the due date that is based on clinical protocols and the expiry is a matter of convenience/a logistical concession (so that never-completed tasks don’t clutter the UI) determined local implementers. The language “Due today” is good in that it doesn’t conflate timeline with clinical importance, and this design leaves more space to use icons etc. to indicate clinical importance when we need to (as we did with UHC mode).

Thanks again everyone for the hard work on this issue! I’m excited to ship this improvement.

[n-orlowski]

Final mock above, the only change is that tasks with a countdown that are not due today will display in grey to further emphasize the tasks due today.

Chatted with Marc and we think it would be helpful for the tasks dates and labels to be configurable as we are unclear is 4 is the right number of days to be counting down from, or if "due today" is the correct language for overdue tasks. Instead of A/B testing, having this be flexible may be more beneficial for our partners.

Proposed configurable elements:

• Number of days to count down from due, default 4
• Text label for countdown, default "x days left"
• Overdue label, default "Due today"

Thanks for all the input and feedback!

[garethbowen]

Ready for AT in 5776-task-list-date-format

[ngaruko]

LGTM. Before

After

3 days later --

4 days later - overdue

However, the default count seems to start at 3 days instead of 4 days as suggested in the discussion above. Is this configuration-dependent @garethbowen ?

[garethbowen]

It is configurable in settings. Check out the documentation PR here: https://github.com/medic/medic-docs/pull/206

[ngaruko]

Good to merge then @garethbowen . Thanks

[garethbowen]

It's quite possible there's a timezone element at play for tasks that are due near the cut off. I haven't been able to reproduce this so I'll merge it as is.

The workaround (if it does happen) is to configure the limit to 5 days not 4. If it happens again raise an issue with definitive reproduction steps so we can fix it fully.

[garethbowen]

Merged.