Closed noahmanger closed 8 years ago
yup, on it!
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.
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.
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:
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.
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.
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.
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.,
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.,
and
but
Where is your preference leaning?
Your additional provocation has sparked a tiny idea that I may try to flesh out :)
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.
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.
Ooooh that's slick. I like it. Small thing: what do you think about putting the month picker above the dates?
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.
Oooh i really dig that. Not sure why, but it feels better.
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?
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 ?
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 ?
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.
Alternatively,
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
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
Date field with date picker & 2-year cycle selector
Next steps:
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:
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.
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?
Love it. Super compelling. Let's move it to implementation.
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!
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:
@onezerojeremy is this something you'd be able to take on this sprint?