Create workflows for Schedule A + B

[noahmanger]

Goal: Diagram out the interactions that will be possible when browsing and filtering Schedule A and B data.

Criteria for Completion: A plan that Josh can use to implement the filters.

[noahmanger]

For starters, @jmcarp can you outline what the constraints we're facing regarding filtering, sorting, pagination, etc.?

[jmcarp]

Filtering and sorting aren't a problem and will work as normal, but the more columns we want to sort on, the less data we can show. Pagination will be a bit different--we can load the next page of results, but not an arbitrary page.

[noahmanger]

Ah thanks. Do you have a sense of how many columns is reasonable to expect to sort on?

[noahmanger]

Also, this raises an interesting UX question as far as which columns we show and if there's a way to view more details. With Candidate and Committee tables, you can click through to get all the info about that entity. How do you get the full info about a particular transaction?

Probably the most natural option is to make use of the responsive DataTables collapsible rows, so that secondary info is nested, even on large displays.

Alternatively, I could see a sort of modal pop up approach possibly working better.

[jmcarp]

If we want the overflow data to be just more rows and columns, the responsive extension is probably a good fit. If we want to add formatting, a modal or master/detail view might make more sense.

Re. number of sort columns, I'll have a better sense once I have a prototype of the Schedule B endpoint ready (later today) and once we get the filings data.

[noahmanger]

Great. I'll experiment with some designs. Can you tell me what all the
possible columns for A and B are?

On Tue, Jun 23, 2015 at 7:04 AM, Joshua Carp [email protected]
wrote:

If we want the overflow data to be just more rows and columns, the
responsive extension is probably a good fit. If we want to add formatting,
a modal or master/detail view might make more sense.

Re. number of sort columns, I'll have a better sense once I have a
prototype of the Schedule B endpoint ready (later today) and once we get
the filings data.

—
Reply to this email directly or view it on GitHub
#283 (comment)
.

Noah Manger
18F http://18f.gsa.gov | Work: 415-696-6146

[noahmanger]

After looking at all the fields, I think we're going to be best served with a modal approach. There's just so many fields to include! Here's how it could work:

The left-hand column contains an icon to open up a detail view. I'm not sure if that's the right icon. Other ideas would be an eye or the three dots that often signify "more".

The detail view would then open up with more info, and you could arrow through the contributions.

Looking for feedback on the interaction design ( @jenniferthibault and @onezerojeremy ) and also how these fields/columns look ( @LindsayYoung and @jmcarp ).

[noahmanger]

And one more idea. Not sure exactly how the transition from table to this works, but with this option, the details would be alongside the table, and you could tab/arrow/click through the transactions to view the details.

[jenniferthibault]

@noahmanger The three dots for more make sense to me, but if it's a pop up, then the arrow out of the box (the thing you have) also makes sense.

Visually, I like the second option where the info replaces the table content, but I've never seen that before. Seems like the first option might be a more expected interaction. On both options, would someone be able to get a permalink to any specific transaction? That seems like something people might want, but I haven't been close to the research here.

On the top, what is the action that would happen when you click "Hide filters"?

[LindsayYoung]

I would want the table with more information. If we were going to go the small table with expanding details, we would want at least- Amount, Name, Employer, Date.

I am not sure we want to keep the soft-money option because that has been illegal for quite some years now.

One of the things we could improve upon is an option to search recipient by committee name or candidate. We could pass in the ids of the Principal and Authorized committees after selecting the candidate name form the typeahead.

[noahmanger]

Yeah, I think I share the preference / reluctance. One thing the pop up has going for it too is I think it's reminiscent of ecommerce "Quick View" sorts of interactions when you're looking at a table of products.

Good call on permalink. We can definitely force it in the browser. We haven't been including any sort of link icon or anything on any of the pages, but that may be something we want to add eventually. I think of it periodically.

Also, good idea on the candidate option, Lindsay. What do y'all think of a "basic filters" and "advanced filters" toggle? Where what we have here is advanced, but the basic would be more like Election Cycle, Contributor Name, Candidate or Committee Name?

[noahmanger]

Also, the modal view will be easier to pull off on small screens, pretty sure.

[LindsayYoung]

I think the most interesting stuff is the stuff that is most recent, I would guess that filtering by date could be a more advanced option. I think employer is important enough to be included in basic, with name and candidate or committee. I think we can default to the recent cycle and then date could be an advanced filter.

[noahmanger]

👍 makes sense to me.

[noahmanger]

Still need to think through the best way to work the autocomplete for selecting the recipient but here's another take:

Basic Filters

Advanced Filters

[noahmanger]

Updated with two options for being able to control searching for contributions from committees vs from individuals:

Option 1

You have to choose one or the other, with filters for individuals going inactive if you select committees

Option 2

You can choose to search both from individuals and from committees, with filters applied to both, which I think is the behavior we want.

[noahmanger]

Better toggle between basic and advanced.

[jenniferthibault]

I'm really diggin' this! Nice work on the field clear x & filter reset too!

[noahmanger]

I just realized another set of filters we may want, which are around the filing the contributions were reported on. People will want to see all Schedule A's for a particular report. So if they click the "Schedule A" link in this table:

...then it should take them to the browse screen with records limited to those from that report. For consistency's sake, we should have that be a visible filter that could be altered. But if that filter's there, then it should also be visible if you just come straight to the browse contributions page.

Maybe the way to do it is:

• Enter a committee name
• Asynchronously populate a dropdown of all of that committee's reports
• Choose a report

Sorry, just kind of vomiting it all out here, but wanted to talk it through before sketching.

[jenniferthibault]

I'm having a hard time following your suggestion just by reading through, but glad to talk this through by voice tomorrow @noahmanger if it will be helpful!

[noahmanger]

I chatted with Lindsay on this. Sounds like we still need to figure out how we're doing it on backend, but whatever method we use there, the filters will reflect.

[noahmanger]

Ok, this issue called for actually diagramming out the possible flows through, so here's an actual diagram (I faded out the parts of the app that aren't relevant to these flows).

The key thing here is that there's three main entry points into the Schedule A and B browse tables:

1. From the home page -> Browse Contributions or Disbursements (brings up all, within some time frame)
2. From candidate or committee pages -> Browse view filtered down to all Sched. A or B for a particular committee
3. From a filings browse table or committee page -> Browse view filtered down to all entries from a particular report from a committee (e.g. April Quarterly)

Hopefully nothing new in here, but wanted to get it documented.

[jenniferthibault]

Tweaking some screens based on feedback above and ongoing chats w/ @noahmanger. Moving the "View" button into the preview screen, and formatting the preview screen to feel more panel-like. Also relevant to #296

[noahmanger]

Oops, these actually belong over in #296 . Will repost (with a couple small edits).

[noahmanger]

Ok I think the issue of figuring out flows has been resolved, with the lingering question of how the detailed view works, so I moved that to a new issue: #311

Closing this out.