UX improvements date range picker

[AquiGorka]

Reference: aragonone/product#88

These changes:

• Date range should be deselected by default displaying the following hint text: ‘Start date’ and ‘End date’, until user makes a date selection.
• We should indicate today’s date and open the calendar on the current month
• We should include an Apply and Clear buttons, that removes the current date range selection

Screenshots:

How to test:

# execute Aragon client with local apps:
REACT_APP_ASSET_BRIDGE=local npm run start

# in other terminal into /aragon-apps/apps/finance/app
git checkout feature/ux-improvements-date-range-picker
npm i
npm start 

Open up browser to http://localhost:3000 and head to Finance app

[coveralls]

Coverage remained the same at 97.015% when pulling 56a5b23 on feature/ux-improvements-date-range-picker into 31e674c on master.

[dizzypaty]

Hey @AquiGorka, a couple of comments:

• The start and end date hint text inside the date range component shouldn't use mono typeface, it should be Overpass Regular (15px #99A0A2)

• When users open the date range filter (default state), can we display the previous & current month instead of the 2 months being the current one? See mockups here #809.

[AquiGorka]

@dizzypaty

The start and end date hint text inside the date range component shouldn't use mono typeface, it should be Overpass Regular (15px #99A0A2)

No prob. This is how it would look then:

And when dates are selected there is not enough room:

[bpierre]

I left some comments in the code, and here are some comments about visual / interaction things I noticed, not sure it all need to be fixed though 😄 /cc @dizzypaty

Visual:

• I can’t select a starting date after the ending date, but nothing indicates it.
• Are we not supposed to see the selection range with a specific background, like on the mockups?
• Isn’t the mobile version supposed to look different (fullscreen with a close button)?
• The left button should use mode="outline".
• The weight and color of the current year doesn’t seem correct.
• The spacing of the calendar icon is a bit different than from the Figma file.
• The separator is different too (color and weight).

Behavior:

• I think we should reset it when it gets closed without applying a range?
• The apply button doesn’t always become active. For example: open the picker, select 14 and 16, apply. Reopen the picker, select 13: the apply button stays inactive.

[dizzypaty]

No prob. This is how it would look then:

And when dates are selected there is not enough room:

@AquiGorka Can you elaborate on the reasons why it couldn't be done like on the designs? Do you see any other way than using a mono space font?

[AquiGorka]

@dizzypaty the main reason is the text is being rendered in an input element where space-tweaking is limited. We could render the text on top of the input via another tag and then tweak the spacing there.

Having said that, and reading through some of @bpierre 's comments, this PR addresses the 3 items on the product issue, I have been patching this component to get it were we want it. Spending time re-implementing it from half-scratch to get the new style specs is on the list /cc @luisivan .

[dizzypaty]

Hey @AquiGorka, I totally agree with you in that we shouldn’t be re-implementing it from scratch now – we haven't even redesign it yet with the new style and interaction behavior. My focus is solely to get it to a more usable state as it’s something that came a lot during the user testing sessions.

I think that a low hanging fruit could be to display the previous and current months (i.e.: April – May), and when users selects a date such as [05-01-2019 — 05-15-2019], allow them to do so in the current calendar displayed. Otherwise, date selection feels unintuitive. But perhaps this is a bigger technical change than I imagine.

Also, if the solution you suggested above to make the right alignment (“We could render the text on top of the input via another tag and then tweak the spacing there.”) is completely out of scope, let’s go back to monospace, as you first suggested. I think in this case, it’s more important to fix the interaction with the calendar than visual consistency in this case.

[AquiGorka]

@bpierre

Visual:

I can’t select a starting date after the ending date, but nothing indicates it.
Are we not supposed to see the selection range with a specific background, like on the mockups?
Isn’t the mobile version supposed to look different (fullscreen with a close button)?
The weight and color of the current year doesn’t seem correct.
The spacing of the calendar icon is a bit different than from the Figma file.
The separator is different too (color and weight).

Discussed with @dizzypaty and pushed back til component re-design.

The left button should use mode="outline".

👍

Behavior:

I think we should reset it when it gets closed without applying a range?

It keeps the previous selection, think of a user opening it by mistake, if clicking outside resets their previous choice it might not be intuitive (intuitive, odd word to use in the context of this component).

The apply button doesn’t always become active. For example: open the picker, select 14 and 16, apply. Reopen the picker, select 13: the apply button stays inactive.

👍

[sohkai]

I'd agree that the current component is very unintuitive, because you don't know that the left one is for the start date and the right one is for the end date. Once you know this, it becomes a lot more intuitive (especially on mobile).

It is quite a bit of work to get the calendar to behave well in a 2-panel set up, as we're using it here, since it was originally developed for a single date (not an interval). We'd likely have to start from scratch to be able to handle the 2-panel design well.

Perhaps something super small that could make it more usable now is to add headers for the corresponding input fields? E.g.

It does make the calendar a bit big, but in this case UX > UI 😄

---

Unfortunately the input field is also a bit clunky to style right now because of the calendar limitation, and I don't see a good way outside of manually setting the width to something safe (e.g. 200px).

[AquiGorka]

cc @dizzypaty ☝️ thoughts? I can implement it easily and right away.

[dizzypaty]

@sohkai @AquiGorka I think it's a good idea. It's a small change that can make things a bit clearer. We'll redesign and rebuild this date range component with the new design system so for now, it's a go ahead from my side : )

[sohkai]

LGTM, I think the only thing we could look into is setting a width property on the input boxes so we don't have to use the monospace font.

[AquiGorka]

@sohkai

I think the only thing we could look into is setting a width property on the input boxes so we don't have to use the monospace font.

That wouldn't solve the issue, with input boxes we cannot set rules for how texts use the available space; even with a set width the content would just use the font's content width. A solution we proposed but will not work on for the time being is using a div on top of the input to display the data.
We will figure all this out with the redesign of the component.