Implement schedule_a filter interaction changes for all receipts, indiv. contrib.

[JonellaCulmer]

User story: As a data user, I need to be able to increase my time period selection filter larger than a single 2 year time period for receipts and disbursements data so that I can view and filter data for that expanded time span.

What we're after: In order to successfully remove the two-year restriction from the all receipts, individual contributions and disbursements data tables, we need to consider what changes to the front-end interaction need to look like as well.

As an MVP, we're going to make the two-year period search consecutive, and not allow for users to choose random two-year periods. This changes the front-end interaction from its current implementation, although we do hope to retain both the two-year period selection as whole as well as allow for users to select between two year periods.

Example: User selects2015-2016 and 2017-2018. This search should return results. The user should also be able to refine this search to also specify specific dates with these full two-year periods such as 03/01/2016-10/01/2018 and should get results.

Completion criteria:

• Consider the necessary front-end interaction changes for the following datatables
  • All receipts https://www.fec.gov/data/receipts/
  • Individual contributions https://www.fec.gov/data/receipts/individual-contributions/
  • Disbursements https://www.fec.gov/data/disbursements/
• Discuss in design sync and make updates, if necessary
• Update front-end implementation issue, 2812 with mockup and completion criteria based on mockup Making this issue the front end ticket as well, since a lot of the thread about design and implementation is in this ticket.
• Finish up error message handling
• Notify @JonellaCulmer when we know the work will be finished so she can reach out to potential power users for usability testing

[JonellaCulmer]

Below is a first draft for the modified front-end time period filter. The view in its entirety is on the right and shows what it would look like for the two-year period selections, specific data filter and then the day-day view including month and year selectors.

I do have some preliminary questions though. I want to make double sure that we must use a two-year period on the front-end. Could we not present single years on the front-end but the API/database would look within the relevant two-year period?

Also, the tooltip language would need to change. Currently it says the following:

cc: @AmyKort @PaulClark2 @patphongs

[JonellaCulmer]

Updated mockups with new version that uses single years in the dropdowns, instead of two-year periods. The new single year dropdowns design also includes an "all" years checkbox, but I'm not sure it's necessary and may just add more complexity to the front-end.

[JonellaCulmer]

We've had some preliminary discussion about what we're hoping to do to on the front-end. But we still need to discuss some of the logic. Moving this ticket to blocked and out of 8.5 so we can make room for that discussion.

[JonellaCulmer]

Following a discussion on 4/23, we're going to proceed with the following business logic:

• Default: 2019-2020 (on load)
• User can choose any single two_year_transaction_period filter and/or receipt dates within that two-year period
  -- No other search criteria is required
• User can choose multiple two_year_transaction_period and/or an expanded receipt date that extends beyond one two-year period
  -- Requires user selects at least 1 additional search criteria
• Allow search for any two-year periods, not just consecutive periods.

[JonellaCulmer]

After additional discussions on 4/25, the following mock-ups were made for the receipts datatable. If we proceed in this direction, these same (or very similar changes) will also need to be made to the individual contributions datatable. Other, less involved, changes still need to be mocked up for the disbursement datatables.

Screen 1: Receipts - single period:
It will largely stay the same, maintaining all the current functionality and limitations, with the exception of separating out the time period selection from the date picker. The date picker will defer to the time period but can be used separately and an expanded amount of time can be searched.

Screen 2: Receipts - multi-period view 1:
All other filters are locked except for those we will allow users to filter by as a first step (in the name of performance). Even the time period filters will be locked but the default search will carry over from what the user was looking at in the single-period view. If we are not able to carry-over the time period filtering from the previous view we should default to 2019-2020.

Screen 3: Receipts - multi-period view 2:
This is a view of what it will look like when a single filter is applied from among the required filters. The additional filters are now available for use. This view also includes a modified version of the calendar that will allow for searching by month and year. (The calendar search can be a later ticket.)

Screen 4: Receipts - multi-period view 3:
This view shows what it looks like if a user removes the required filtering. It will lock the screen and force the user to make another choice from the top filters.

cc: @AmyKort @PaulClark2 @patphongs

[JonellaCulmer]

@patphongs Here's what I have so far for the Receipts filter panel. this incorporates our discussions up to this point to try to keep the filters in a single panel instead of split out.

Receipts filter panel

Individual contributions filter panel

Disbursements filter panel

[patphongs]

Thanks @JonellaCulmer, here's the workflow diagram for message states that we worked on together.

[JonellaCulmer]

@AmyKort @dorothyyeager

In the previous two comments, there are mock-ups and a workflow for different success and error messages. Below is a complete list. If you wouldn't mind taking a look and providing feedback sometime during 8.7 while @patphongs is working on the front-end implementation, that would be great.

Messages

• Success: “Filter added XXX fewer results” (checkmark) - green
• In progress: “Just a moment while we process your request. You are searching a large dataset.” (Exclamation mark) - orange
• Failure: “We had trouble processing your request. Please try again. If you still have trouble, let us know.” (X mark) - red
  • Only display failure message for 502 timeout
• Removed required filter: “You’re searching a large dataset. Narrow your search with additional filters.” Lock non-required filters
  • Only display message if multiple two-year periods are selected and no other secondary required criteria are applied.
• When adding additional time periods: “To expand your search to multiple time periods, filter by recipient name or ID, contributor details, or image number.”

We also plan to add static text below the time period filters that reads:
"Certain fields, including recipient name or ID, contributor name or ID, city, ZIP code, occupation or employer, or image number, are required for searching multiple time periods."

I like the direction of that message, and it's short, but I think it needs to be more clear that not ALL of those filters/fields are required. Just "at least one".

There are also some name changes to some of the filter groupings, like "More contributor details" not sure what else to call that. So really, anywhere there's words, I'd like a review, if possible.

[dorothyyeager]

The messages in bullet points seem fine to me. You might want @bmathesonFEC to take a look too as he's more used to searching data than I am.

For your static text, does this work? "When searching multiple time periods, choose at least one field (or more if desired): recipient name or ID, contributor name or ID, city, ZIP code, occupation or employer, or image numbers." Does ID in this case mean an ID number or contributor details?

For "contributor details" - do you mean name, address, occupation, employer? You could use "identification" - because that's a glossary word for those items that they could look up.

[AmyKort]

These look really good to me. I agree with @dorothyyeager about the static text suggestion. Maybe we don't even need (or more if desired) if we have at least one field in the message.

[AmyKort]

"When searching multiple time periods, choose one or more fields: recipient name or ID, contributor name or ID, city, ZIP code, occupation or employer, or image numbers."

[JonellaCulmer]

That looks great to me! Thanks @dorothyyeager and @AmyKort.

@dorothyyeager Contributor details in the top section made sense to me, but the section below that with just State and Restrict contributions was the other section I had trouble with. Now it's called "More contributor details". (At least that's what I labeled it in the first mock-up). #AttentionToDetailIsImportant Not sure what else to call it.

[AmyKort]

Do we want to move this to 9.1 for now?

[JonellaCulmer]

Updated mockup to include the approved language discussed above. This static message will be the same for both the receipts and individual contributors data tables. The only exception being that users can only search for contributor name NOT ID on the individual contributors data table.

[patphongs]

@JonellaCulmer When you get the chance, can you show me the design for a disabled accordion? Do we have an existing style for this?

[JonellaCulmer]

@patphongs Here are two mockups of what the receipts, and also the indiv. contrib. filter panels will look like when specific filters are disabled. Let me know if you have questions. Happy to take a closer look at this with you.