Update and unify date filter patterns

[noahmanger]

While discussing the new date filter validation pattern with @jenniferthibault and @xtine we uncovered a design issue we need to resolve. We currently have two date filter patterns. The original, which is used on the filings and independent expenditures pages, is used in instances where the tables aren't partitioned, thus allowing users to enter any date range they want, as well as select from radio button options:

The second is the newer version, used on pages like receipts, where the underlying tables are partitioned by two-year transaction_period. In this pattern, a two-year period is always set, and then users can refine their dates within that:

Additionally, we also have an open usability issue around our date inputs, as some users have had difficulty using them.

I think it makes sense to address these all together, and hold off on front-end implementation until we have a new pattern.

I don't think we need to have a single pattern that is shared by both types of date filters; I don't think we should force those tables where you can enter an open-ended range to select a two-year period, for instance. But maybe there's a more elegant way to make the interaction feel consistent, while at the same time communicating the relationship between the transaction period filter and the specific dates.

Criteria for completion:

• [ ] Decide on approach for the two kinds of date filters
• [ ] Design new form of custom date input

@onezerojeremy is this something you'd be able to take on this sprint?

[onezerojeremy]

yup, on it!

[LindsayYoung]

Maybe this is not the right place to comment, but since the two-year transaction period is required and applied by default, we might want to un-nest it. That way, people can see that is applied and easily change it.

[onezerojeremy]

So after a bunch of looking around the good 'ol net, a visit to my critique group, etc, I've come to a couple conclusions.

• date pickers are tricky! mostly because there are about 1,000 different ways people use dates. plus mobile, plus accessibility.
• best practice: if you can help it, don't let them select invalid dates, but also don't go crazy trying to interpret and fix what a user is entering that doesn't make sense.
• best practice seems to be to allow selection via some sort of a picker, but don't take away the ability to just type it in
• the cycle selection and the date tailoring are two parts of the same kind of thing, even if one is just a default based on the shape of the underlying data. Therefore, I propose that the two interactions should be tightly linked.

based on this, i got to thinking about how it might make sense to provide a way for folks to select things, and how to tighten up the date entry. A couple options:

standard calendar picker

• pretty standard calendar picker interaction. Seems like best practice for accessibility is that the calendar widget does not get focus, even on click.
• people (rightly or wrongly) seem to expect a calendar picker, and including one helps us put guard rails on the interaction. We could, in the future, think about fanciness where we let them select a date outside the cycle, warn them that what they're doing will flip to the next cycle, and do so, but that sounds like a tricky thing to get right.
• one additional benefit of the calendar widget is that it reinforces the date you've picked (especially useful for the dd-mm-yyyy crowd.

month slider picker

• based on the idea that there might not be as much value in the actual date of a data row, because of the inherent lack of date precision of the reported data, and given that generally speaking we're dealing with 2 year partitioned data, i thought it might be fun to try a slider-selector. Inspired by this one:

in-situ checkbox tag filter action

Ok so with either of these, for the cycle-constrained data we should demonstrate the constraints. Here, the filter check boxes are doing the work of showing when you can mess with them, and when you need to play with the cycle selector.

Date filter typing tweaks:

So the WDS (and GDS) calls for 3 fields, and I've always felt like it's a little clunky but I think I get why. There's the accessibility angle, but using three fields also clarifies user intent. I switched from the dash to the slash and made them bigger because it seemed like a stronger division between field sections. I don't know how much of this we can actually do, but the basic ixd principle is to mimic the functionality of three fields without necessarily sectioning out 3 fields.

additional provocation

There might be a way to better make this one interaction where the cycle dropdown is sort of advanced and lets you tailor right in it.

Not married to any of this, of course. Hopefully at least good fodder for a synchronous session.

[jenniferthibault]

Good fodder indeed @onezerojeremy — you've presented lots of options, but I'm not sure what criteria should guide our decision, since these each meet the goals you set out at the beginning. I.e.,

• if you can help it, don't let them select invalid dates, but also don't go crazy trying to interpret and fix what a user is entering that doesn't make sense.
• allow selection via some sort of a picker, but don't take away the ability to just type it in
• the cycle selection and the date tailoring are two parts of the same kind of thing, so the two interactions should be tightly linked.

It also looks like some options presented are meant to be (or could be) combined with one another, but some are mutually exclusive. I.e.,

• The standard calendar picker could be combined with the in-situ checkbox selecting and the date filter typing tweaks, but should it? with one or both?

and

• the month slider picker could be combined with the in-situ checkbox selecting and the date filter typing tweaks, but should it? with one or both?

but

• you wouldn't have the calendar picker and the slider

Where is your preference leaning?

Your additional provocation has sparked a tiny idea that I may try to flesh out :)

[noahmanger]

Bunch of good thoughts here! My two cents: I really like where you're going with the slider idea. I think you're right: the date filters most likely to be used are probably not specific, but broad. (Though if you want to filter down to the day, you can). From what I've read, date pickers are best if users are a) looking to find a specific day and b) the day of the week is useful as a point of reference. I don't think those are true in our specific situation.

The other thing I like about a slider approach is that it saves people from having to type, which I think makes for a notably better interaction on mobile in particular, but also desktop as well.

That said, it's a notably more complex component that would be harder to engineer.

[jenniferthibault]

Here's a loose take at one that combines the slider with a month only calendar picker. What @noahmanger picked up on is where I was leaning, it's less important to let people set specific dates, than for them to set the months. First day/last day of the month can be generated automatically.

This design would not generate checkboxes, but it would generate tags and confirmation messages, just like we have now.

[noahmanger]

Ooooh that's slick. I like it. Small thing: what do you think about putting the month picker above the dates?

[jenniferthibault]

Heh, I definitely had that at one point and then changed it because it seems sliiiiightly like you'd miss it if you were looking for it to confirm what dates specifically you're looking at.

I don't know for sure though, that's something that a usability test might be able to tell us.

[noahmanger]

Oooh i really dig that. Not sure why, but it feels better.

[noahmanger]

The thing that just occurred to me this morning is that we still need to address the question of whether this is how both kinds of date filters will work. Do we want all date filters to only be able to select dates within a two-year period? Or do we want to continue to allow those date filters that don't need that parameter to choose any dates? If so, how does that work with this new interaction?

[jenniferthibault]

I also had that thought when looking at the preliminary mockups for the AO landing page: https://gsa.invisionapp.com/share/AR7U3Y662#/screens/167711252

Where we don't need the two-year time period as the first limiter. Which type of pattern do you think works best there @onezerojeremy ?

[jenniferthibault]

I'm about to upload a whoooole lot of stuff, but it all hinges on this first date field mockup. My for including validation and keeping the range on one line depends on treating ranges as a single unit for applying as a filter and validating. This starts to hint at toward tag behavior, but for now let's look at the field interactions:

If this looks agreeable, it becomes our primary date selector and the base unit for our two-year period slide cycle, in which you can edit the time period within that cycle:

Hang on to your seats, interactions showing a lotttttt of options below.

What do you think @onezerojeremy @noahmanger ?

[onezerojeremy]

This stuff is looking so good!

Some details: date_fields.3: I don't think we should necessarily reset the ending date on clicking on the beginning date, but curious to hear your thoughts on why.

default_state.1: I like the visual effect on the dates in the future, but I can't remember where we landed on the bad data that says it's from the future. Is it you can only get to them by the date fields, not the month picker? If so, because these two interact, what does the month picker look like when you type in a date that is disabled?

Overall: I'm not sure, it could be that I just need to play with it, but the interaction with the month picker is feeling a mite complicated and I'm curious if perhaps there may be a simpler rubric (by simpler, I'm thinking: could we do something that isn't dependent on what you've picked?). For example, what if the interaction is just reset everytime a user comes to it.

• clicking a month selects it
• clicking and dragging selects all months until mouse-up

Alternatively,

• on loss of focus or after a small time-out, we consider all interactions with the month picker as intended to pick the starting month.
• the next click after that picks the ending month. If they click that month again, or don't pick again after a time out, the ending and beginning are the same month.

One final thought: we could use the "beginning" and "ending" date fields to hint the user which month they are picking. Changing the visual style, and possibly visually connecting the current element on hover might give folks a clue as to which they are picking.

oh one last tiny thing: talk to me about what the angles on the display of the edge months are up to. I raise it because I think this visual might make it feel less contiguous.

These designs might also be good fodder for a synchronous session

[jenniferthibault]

Aiming for slightly fewer mocks, and hoping that most of the missing pieces can be inferred from our conversation today & from corresponding states on other sheets here.

Based on our convo today, here's a list of some changes:

Base date field pattern

• We won't use in-field color validation yet. Start without it and test to see if users understand what fields are being changed sufficiently through usability testing.
• We won't auto-populate any field that a user does not edit themselves, even if it's to nudge them to good data. This could feel intrusive, confusing, and potentially frustrating
• Right-align the cursor in each text unit
• Two types of validation errors: ( @emileighoutlaw , would appreciate your microcopy eye here!)
  • Error caused by date format (is it logical? Did you enter an end that is after the beginning date? Did you use dd/mm/yyyy instead of mm/dd/yyyy?)
  • Error caused by server/api

Date field with date picker & 2-year cycle selector

• Not new, but specify the principle that users can control the time by editing either the date grid or the text field. If the text fields are edited, the date grid adjusts accordingly, and when the date grid is edited, the text fields adjust accordingly.
• Use visual indication so that users know when adjusting one field also changes another: this must be recognized in usability testing
• On the date picker, we'll use the mini open/close icon
• Use rounded endpoints instead of pointed ones
• @onezerojeremy is working on the specifics of the click interactions for engaging and setting the start/end points on the date grid (it proved above my interaction weight class and end of day brain)

Next steps:

• @onezerojeremy filsl in the click interactions
• @emileighoutlaw 🔍 copy
• @noahmanger / @xtine take a pass as integrating the visual styles here with Jeremy's click interactions. Take best guesses at any missing visual pieces, and move forward to testing.
• Usability test! Some key questions in the change list above^
• I'll pick up any outstanding visual questions when I'm back from vacation

[onezerojeremy]

After sleeping on it, I think that perhaps the simplest way to make the month picker functionality understandable is to rely on the convention of a date picker, wherein our month selection is done as a child to the relevant date text entry field.

Justification:

• we can't know whether the users intent is to select an ending month or a beginning month first. To account for this, we either have to add an interaction where they tell us which they want to do first, and none of the options are seemingly totally clear. For instance, we could:
  • use a slider drag pattern, which is probably the closest convention, but there are not many multiline sliders and the conversation yesterday left me with the impression that dragging has accessibility ramifications. Possible click flow for this: [user clicks and drags either slider to the position they want it]
  • use a modified slider pattern where the first click "unlocks" the month slider from its current position, hovering and moving the mouse shows where you could drop it, and the second click locks it in a new position. It's always 2 clicks, and it's a new pattern, i.e., likely not one people will be familiar with in this context (my main concern is getting people to understand in looking at a grid that you need to click once to unlock) Possible click flow for this: [click once to unlock the beginning-month or ending-month selector, click again on the month desired]
  • make a design decision to always require selection of either a beginning or ending first. So as a user, you'd either always have to select the beginning month first, or always have to select an ending month first, before you could select the other This is what I was advocating for yesterday, but after sleeping on it, it feels a little problematic too: we don't know which the user wants to do, and we'll make the experience a little worse for those who want to do the opposite. Possible click Flow for filtering by ending month: [grid shows beginning-month selector active, user must know to click the already selected first month, which then will select it and activate the ending-month selector, the user can then click on what they originally wanted]

Happy to chat more about this! If this seems like the right way to go, I think Jen's designs and ixd above covers off on the rest of the elements but maybe let's start here and i can verify the edge case interactions if this feels right.

[jenniferthibault]

This! we can't know whether the users intent is to select an ending month or a beginning month first. !!!

This makes sense to me, and will save space on the default load space without the grid being exposed all the time. I can picture it sliding the content below it down gently as it opens, much the same as the validation text does. Let's give it a go?

[noahmanger]

Love it. Super compelling. Let's move it to implementation.

[jenniferthibault]

Hold it there, Quick Draw McGraw. @emileighoutlaw this needs your content 👀 , (look for your photo in the comment above) which can also happen in implementation, but I don't wanna rush your part of the process!