Mobile time slider UX: text, open with tab?

[corradio]

Is your feature request related to a problem? Please describe. On mobile, the bottom time slider drawer can only be opened by sliding. I find that interaction a bit cumbersome, and I'm not sure all users would "get" it.

Describe the solution you'd like Suggestion: why not also open it after the user taps the drawer?

Additional context Maybe it's completely different, but I find the copy "Display data from the past" a bit weird when the live data is currently shown on the map. I could open another issue if this resonates with others. It would be nice if the collapsed drawer could make it clear that live data is shown (currently, one needs to open the drawer to see that).

[VIKTORVAV99]

I think past is actually pretty appropriate as it is now as there is a 2 hour delay on the map, so even when the map is "live" it's not actually live.

However I think we could change the date to "LIVE" and add a small disclaimer saying the data is delayed by 2 hours and then we could change the title form "Display data from the past" to something like "Show historical data?" or "Browse historical data?".

[Kongkille]

Agreed on opening with tab, I don't know how difficult it is but let's see! I feel like the copy is taking a bit more space than opening with tab, so perhaps we can rename the issue.

I'll let @rasmusjeppsen elaborate on the UX. However, essentially one of the issues we had with early testing was that people did not really notice the slider and did not see it as something they could interact with. After adding the text we saw that people were more inclined to open it to see the full context. I am not extremely hooked on the exact copy, the idea was that it would work with saying "Display data from the past (24 hours, 30 days, 12 months, 5 years..)"

[rasmusjeppsen]

Agreed on opening with tab, I don't know how difficult it is but let's see!

I also agree with adding the ability to open with a tab to ensure that no one misunderstands the intended interaction. What is important with the interaction is that the user should be able to both open the component by dragging and tabbing. In other words, the integration of the tab interaction should not replace the dragging, but be an additional interaction to open the component.

I'll let @rasmusjeppsen elaborate on the UX. However, essentially one of the issues we had with early testing was that people did not really notice the slider and did not see it as something they could interact with. After adding the text we saw that people were more inclined to open it to see the full context. I am not extremely hooked on the exact copy, the idea was that it would work with saying "Display data from the past (24 hours, 30 days, 12 months, 5 years..)"

Yes, agreed. To give some context, we did some testing of showing the component without text and just the dragging signifier which clearly showed that we need to give some context to users. I'm also not hooked to the exact copy and am very open to suggestions for a change if can improve the UX. The idea was, as @Kongkille writes, that it would work by saying "Display data from the past (24 hours, 30 days, 12 months, 5 years..)". Furthermore, I think that having "display data" and "the past" in the text gives a decent description of the historical view component.

During the design process, we also explored adding another layer of interaction which might be a fix to provide more context to users before dragging/tabbing to fully show the historical view component:

Default (without dragging/tabbing): Make the toggles (24 hours, 30 days, 12 months, 5 years..) visible:

Dragging up/Tabbing interaction: The component opens fully (like it currently does):

Dragging down interaction: The component "hides" and only shows the text, like it does by default now:

During the design exploration, we also created this iteration of the "hiding" interaction (dragging down), where the text gets smaller to take up even less space. This could be convenient, as when a user decides to drag down one may assume that they intend to hide the component to get more space to view the map/graphs:

I know that the extra "hiding" interaction adds a layer of complexity, but I think it would create a nice UX. Nonetheless, I'm definitely in favour of adding the additional tab interaction as @corradio suggests, as I also fear that some users might not get the dragging interaction alone.

[corradio]

Thanks for clarifying. Let's leave the copy aside in this issue and focus on the extra interaction. Maybe we can also track in analytics to see if it helps the discovery of this feature?

[waltonzt]

@corradio @Kongkille Pull Request #4448 should help with adding this functionality if it is accepted.

[corradio]

I just checked and on iOS this issue is still happening.