Minor updates to report detail page header

[sglangevin]

This improvement makes a few tweaks to the header on the report detail page, making it easier to read.

UI changes:

• remove the detailed date from the report detail page
• move the relative date to the left hand side, below "Sent by"
• make sure the relative date shows the detailed date on hover/click

NOTE: No changes are being made to the reports list, only the report detail page, so the reports list should stay exactly as it is.

[garethbowen]

I strongly prefer using relative dates by default and only using absolute dates when there's a specific use case that benefits. This is for several reasons...

• They answer the most common questions users have (eg: "how long ago was this pregnancy registered?", "when did I last visit this user?", etc). There are some use cases that absolute dates answer better but they're less common in my experience (eg: "did this report come in before this other event?")
• They are very easy to scan and understand correctly without making a mistake when trying to answer the above use cases.
• They reduce in specificity as they recede into the past - who cares if a report from three years ago came in at 10.15am?
• They are timezone agnostic. While we always show absolute dates in the user's timezone, two users in different timezones will see a different absolute date, but they will see the same relative date (eg: "30 minutes ago")
• They are shorter so they take up less space and are less likely to wrap to the next line.

In our implementation of relative dates we watch for click, touch, and hover events and show the absolute time in a tooltip so if it's important to know the exact time then this is still possible without taking up any additional screen space.

@amandacilek @sglangevin I'm interested in your opinions. What use cases are better served by having absolute dates?

[sglangevin]

I'm fine with using a relative date if we can see the absolute date in the tooltip, but curious to hear your thoughts @amandacilek.

[amandacilek-zz]

I don't know much about the history of partner changes and requests that got the page to its current design with both relative and specific dates. I'll leave that to @diannakane and @sglangevin to remind us. My takeaway from a previous conversation with Sharon though was that: someone requested the specific date get added and they use it. I thought it was silly to have both the relative AND the specific date right on top of each other (seems like we should just choose one or the other) and since it sounded like the specific date was preferred, we decided the relative date was redundant on this page.

All the points you make are valid and I generally agree with you. My thinking with this was: users still see the relative date on the main Reports list. On that page, the relative date helps them quickly scan through the list and understand general timing. Once they've reached the point where they are clicking on an individual report to see the detail page, it makes sense that that page gives them more well, details, so I don't mind the more specific date once you get to the detail page.

From a purely aesthetic point of view I have no preference, and would lean towards the relative date because, as you mention, it's shorter. From a UX perspective, I'd need to be reminded of who requested the specific date and why first before speaking further about use cases.

[sglangevin]

It's true, people do use the detailed date. But I think it's ok that they have to hover over the relative date to see the detailed date on the web app. I realized that this might not work well on mobile - how can you access the detailed date on mobile? With no hover action, I'm concerned that the detailed date won't be discoverable by users.

[garethbowen]

@sglangevin Touch/click works to show the tooltip on mobile.

[amandacilek-zz]

But how would they know to touch/click the relative date? Is it styled like something clickable (blue and/or underlined)? I agree with Sharon that it doesn't seem very discoverable. Although if users are already familiar with doing it that way it's less of an issue. Could be something we mention in the in-app tour? @sglangevin @diannakane do you have any idea of what percentage of our users are looking at/using, the detailed date? Any idea if it's "almost all managers" or "managers from this one specific project" ...or we don't know?

[diannakane]

I think it's mostly our project managers using the detailed date for testing. It helps them differentiate between test reports and real reports. Is that your understanding, @sglangevin ?

[sglangevin]

I think it's used as a way to scan through and see if the gateway is working. Now that we are showing the exact time for reports coming in today, I think that satisfies that need. If the full date is needed, you can easily hover over the relative date in the list of reports, so having that match the report detail page works for me. Someone will complain if it's not usable! I'm more concerned with the user experience on mobile, but I think that can be handled through training and I'm not sure how much the precise date and time matter for most managers.

[garethbowen]

It would be nice to style it - perhaps not a blue underline, but maybe with a tooltip icon or dotted underline? I'm always too afraid to click links because they'll take me to a new page...

@diannakane We strongly recommend users use the provided testing instances for testing/training reports, so I hope nobody is using the date for differentiation between the two.

[diannakane]

Got it, @garethbowen. My information may have been based on the way training used to work.

[amandacilek-zz]

Ok so... if we leave the relative date exactly as-is in the upper right, and remove the long detailed date altogether, I think this ticket is no longer necessary.

Could create another little ticket if we want to make some sort of update to the styling of the relative date...you're probably right, Gareth, blue might not be the way to go. I was thinking maybe a little info icon or something? I can try out a few ideas and see what we think.

[sglangevin]

Could you also see if keeping the date in the same place but changing the detailed date to a relative date would work? I think that might be better for small screens. Looking at your mockup at the top of this issue, I'm not sure how we'd fit a relative date on the right.

[amandacilek-zz]

Here are a few options for where the relative date could live:

1. Upper right where it currently is
2. Bottom of left side, underneath sender name
3. Right after the sender info, on the same line

[sglangevin]

I like it on its own line, but am fine with it on the same line as the sender. I like leaving the right side for the status dot.

[amandacilek-zz]

The problem I was trying to solve with this ticket was the very long detailed date on the right side causing all sorts of weird wrapping. Getting rid of the detailed date solves that issue for me, so I don't have much of a preference between these three.

1 is more consistent with the short view we see on the LHS, 2 is friendliest when viewing on very small devices, 3 keeps the overall height of the header down... If you think about us having longer sender names than the example of "Janet Mwangi" then it might make sense to give the date it's own line (option 2).

[amandacilek-zz]

Ok is this what we all want? UI changes:

• remove the long, detailed date from the report detail page
• move the relative date to the left side, below "Sent by"
• touch/click on the relative date reveals screen tip with detailed date information (same functionality as seen on LHS)

I'm not sure if this is already implemented, but didn't we also discuss:

• sender name is styled blue and hyperlinked to their profile page

[sglangevin]

I'm fine with those first 3. The other one might have been discussed but it's not in the spec. Would be useful though. @garethbowen how much effort would it be to hyperlink the patient name to their profile? I'm inclined to do that now if it's really easy, but if not, then let's hold off as we need to make sure that this release gets out the door on time. I'd like to update the top comment in this issue - can you send me the updated mockup so that I can paste it up there?

[garethbowen]

It's fairly easy to add. There's a minor risk in doing it because that code is used in a lot of places to render the sender's name so we'd have to check all the other places.

[sglangevin]

Ok - if it's a risk then I'd leave it out for now, as I want to avoid regressions as much as possible and if we are changing code that's used in a lot of places, that expands our need for testing quite a bit.

[dianabarsan]

Please review, @SCdF . Thanks!

[SCdF]

@dianabarsan reviewed, back to you!

[sglangevin]

LGTM. Moving to ready.

[sglangevin]

I realized I shouldn't be testing this on alpha (master) and should wait for a 2.16.0 beta. Re-opening!

[sglangevin]

LGTM on 2.16.0-beta.2. Moving to ready.