Implement front-end MUR filters

[noahmanger]

So that legal researchers can find the MURs to help them answer their questions, they should be able to filter MURs by various additional criteria.

---

This issue is for implementing the front-end fields to filter MURs. @nickykrause has a start on designs, but we can use this issue to hash through questions in preparation for implementation.

Dependency: Add fields to the API

Completion criteria:

• [x] Case number text filter <input type="text">
• [ ] Document type filter <input type="checkbox"> with options for each option available in the API
• [x] Respondent name text filter <input type="text">
• [ ] Election cycle select filter. <select> with <options> for every 2-years from 1976 - present.
• [ ] Final disposition checkbox filter <input type="checkbox"> with options for each option available in the API

[nickykrause]

There are still some things I was thinking through on these, but I'm going to share them now since we might as well get moving on getting reactions. I know this isn't the best delivery of my designs for critique, but I wanted to get this up there because I know @noahmanger has thoughts he wants to document somewhere, after I showed him these earlier today.

We had a separate issue going to design the interface for MUR document types only, but then we finished our user research this week and already have a pretty good sense of the additional filters that users will want, which Noah has included in the list above.

Since I was originally thinking about these in two separate streams, with the doc type filter prioritized first, my thinking is still a bit separated.

First, here is what I was thinking for the MUR doc type filters + results display

The filters themselves follow the checkbox pattern that we use elsewhere.

The results display shows not only the document type, but also the file name. Since we cannot separate out the GCRs and F&LAs, as the users would prefer (see https://github.com/18F/openFEC-web-app/issues/1718), it will be essential for users to have not only the "doc type" visible to them (to know their filters are working), but also to see the filename

Users said that they occasionally use the page numbers to get a quick clue as to how in-depth the doc is: If it's only a page long, it's probably not that important, and probably doesn't contain the detailed legal analysis they're seeking. We could talk about whether or not this is really necessary, but I thought I'd show it.

Finally, I have included an accordion-like feature called More matches from this document because there may be 20+ matches for a keyword in a document, and I'm not sure how much of that we want to show, given the amount of vertical space it will occupy (and since it will distance users from additional results, which are that much further away by scroll).

Here is another approach to the "table" of documents, with the doc type in a row instead of a column:

---

Beyond this, we have the question of the additional filters -- things like Final Commission Disposition, Election Cycle, and so on.

My initial pass at what those filters would be like, using the existing patterns, is something like this (not necessarily laid out in a giant line like this; we may need to group them and use accordions):

I haven't done deep thinking yet about how this would work, but I showed the Statutory Citation blown out this like because we need to address the question of mapping the Title 2 citations with the Title 52 citations (one option is shown here). The regulatory citations field is assumed to appear behind that typeahead box. This typeahead idea might not make sense.

I also noted that we have several different patterns for time-based filters, including:

I wasn't sure which of these would make the most sense, but, since the users said they think in terms of "Election Cycle," I chose that one for the mockup. They seem to function differently, though, and I don't know what functionality makes the most sense in this case. Also, the "Election Cycle" filter seems to need a default year to be selected (e.g., the current year), but I'm not sure.

Finally, I haven't really thought about how some of these filters will affect the results display, but there's already a lot going on here, so I'll stop there.

It's probably best to chat synchronously.

[nickykrause]

Quick correction: The "document type" filter in the extended filters panel would need to match the designs I sent in the first 2 images. The "document types" cannot be separated into GCRs and F&LAs, as the last screenshot shows.

Also, these designs are inconsistent in showing "CASE NUMBER" either as combined with Keyword, or as separated into its own field. I am not sure how that needs to work. The same might be true for the citations...

[nickykrause]

(cc @noahmanger )

I don't have tons of time for a post at the moment, but I did some more thinking on how this filter panel might lay out, and how each of the sections could function, so I wanted to drop my thoughts while they are still fresh:

• Keyword (works like it does now)

• Case Number (separate field for searching by case number; would call up only that case)

• Citation (section of the panel for searching by citations)

  • Boolean control (lets user specify if multiple citation filters should be AND or OR)
  • Statutory (searches the text of the doc but typeahead helps ensure it is entered in a specific way)
  • Regulatory (searches the text of the doc but typeahead helps ensure it is entered in a specific way)

• Doc type (This section would be open by default after a keyword search, maybe, so users would know which doc types are being searched initially)

  • Checkboxes (certain doc types are checked by default, per issue #1718)

• Participants (only includes respondent at first, but would possibly have other items later)

  • Respondent (search by name)
  • Maybe complainant, in the future (search by name)
  • Maybe respondent's counsel, in the future (search by name)

• Case details

  • Final Commission Disposition (checkboxes)
  • Years (Thinking this instead of "election cycle" - what is the difference, exactly? Might be helpful to discuss how the various existing date filter patterns are meant to be used)

Here are some images of this idea in InVision

[nickykrause]

Okay, I made a correction to the InVision that I linked. In the "citations" section, when the AND option is selected ("Show cases citing all of them"), the filter alert should say that there are now "fewer" results (per AND logic), rather than more results.

@noahmanger, instead of asking you to react to the whole filter panel in InVision, I'm going to just pull out the citations section and ask for your thoughts. In some cases, it may just be a matter of suggesting to me who you think I could/should talk to to get answers to some of my questions...I'm still trying to figure out who knows what (Amy K? Amy P? Vraj? Tony? You?). Any thoughts are appreciated:

Things shown/implied here:

• The statutory and regulatory citations fields are searching the text of the documents. Rationale: Our conversations with internal FEC users, as well as with the Amys, have revealed that the meta data does not always include all the relevant citations, which frustrates users. Our hope is that searching the body of the documents would be a more reliable way of searching against all the citations that a case might contain, and which might be relevant. This raises several questions/concerns:

  • Are there situations in which the meta data contains citations that the text of the document does not contain? (i.e., by searching only the text, and not searching the meta data, would we be missing valuable information?)
  • Was the OCR-ing process "clean" enough for us to assume that searching the text for citations will be a more "comprehensive" way of searching? Or, because of mis-OCRed text or inconsistent citation formatting in the body of the docs, will the results of a text search potentially be just as "incomplete" as a meta data search?
  • In cases where the search results include non-citation text matches, will users be confused? (For example, statute search 30101 returns matches for a ZIP code in Georgia)

• We could use a typeahead on the citation boxes. Rationale: Because the citation search would search the body of documents (rather than the meta data), the hope is that the typeahead would ensure that only citations are entered in this field, and only in the appropriate format. Furthermore, this may be an opportunity for us to offer a "translation" between Title 2 and Title 52 citations. Questions/concerns here:

  • What is the optimal citation-entry format (if there is one at all)? Do the citations appear consistently in the text of the documents? If not, the utility of the typeahead is questionable.

• We can offer a boolean control for users to specify if multiple citation filters should follow "AND" or "OR" logic. Rationale: Based on our conversations with users, it sounds like they have an interest in entering multiple citations in combination in order to narrow their search results (this is "and" logic). It is not clear whether or not they also need to use "OR" logic, but it seems possible.

  • Our current filter patterns follow "OR" logic when multiple instances of a given filter are entered. For example, when working with the Year filters, a user might add 2015 as well as 2016. In that case, they will receive results for 2015 or 2016. Thus, adding multiple Year filters yields more results. However, for citation filtering across MURs, we need a way for users to progressively narrow their results, using multiple citations. They want to use AND logic, so we'll need some kind of control that lets them choose between AND or OR logic. This control needs to be simple and must avoid using complex language to communicate this complex concept.

Here is what I'm suggesting:

Questions/concerns:

• Is this too reliant on words, or too wordy? (Can ask Emileigh, of course)
• This would not allow users to compose complex queries, such as statutory citations 30101 or 30111 and 30210.... if we were to allow such queries, things could become complicated quickly. (i.e., what is the order of operations in that example -- where would the parentheses go, so-to-speak?)

[emileighoutlaw]

Lurking in this issue and have a question:

I wonder if the words experience is different based on the placement of the selector.

Citations

Statues [__]

Regulations [__]

If multiple citations are entered:

• [ ] Show cases that cite any of them
• [x] Show cases that cite all of them

1. Something about having the selector after the action makes the "multiple citations" content easier for me to read and understand (but that's just my gut)
2. Reordering the options to be "show any" and then "show all" is more aligned with how I usually see this type of content written (any/all vs. all/any)
3. Also, I tried removing some of the extra "citations" words in the regs/statutes search to winnow how much folks have to read

[nickykrause]

@emileighoutlaw All great suggestions! Thank you. I agree with you!

[dogweather]

If multiple citations are entered:

• [ ] Show cases that cite any of them
• [ ] Show cases that cite all of them

1. Could we remove this altogether by ordering the results, showing those with all cites first? Like Craigslist sometimes shows a second section: "Not many local matches; here are some from further away". Or, just adding it as a sort column.

This avoids front-loading the search UX with decisions which require effort from the user. And like CL, once we show the results, we could include a prompt to expand or narrow. Because, then we'll know exactly what kinds of results exist for their query.

If not:

2. How about moving the If statement into the code itself, and only show the checkboxes when multiple citations have been entered. (Otherwise, this kind of forces the user to act like a computer.)

3. I think we can simplify and disambiguate the options a bit. I also have a hunch that "include" is more colloquial in other legal search apps. (?) As in, "Include ... in the search results"

• [ ] Include cases that cite any
• [ ] Include only cases that cite all

(Finally, as I understand the logic, these would be actually be radio buttons, not checkboxes. ?)

[noahmanger]

I like the idea of only showing the "and/or" radio buttons if multiple options are entered. I'll let @nickykrause and @emileighoutlaw weigh in on the other questions, but my understanding is that it's important to users to be able to have fine-grained control over this kind of boolean logic when it comes to this filter.

---

But to turn this in a slightly different direction, I'm realizing that this conversation has veered from the current completion criteria above, which do not include the citation filter (since it's kind of its own beast and has its own dependencies). This issue is for implementing that filter, so let's move further conversation over there so this can be focused on implementing the basic version of the filters using the API fields from https://github.com/18F/openFEC/issues/2099

[noahmanger]

@dogweather responding to your point in standup, the logic and everything for the filters that this issue covers should be all sorted out. They're just using basic text inputs, checkboxes and selects, with no tricky logic. Basically identical to what @anthonygarvan with the AO filters in https://github.com/18F/openFEC-web-app/pull/1780

[dogweather]

Thanks @noahmanger @anthonygarvan and I are about to pair on it and I'll ask him: I'm not clear about, e.g., what the intended effect of checking the final disposition filter should be, and how it'll look.

[dogweather]

Tony and I are think that the Document Type checkboxes default to all checked. ? Is that the sensible default?

[nickykrause]

@dogweather:

Assuming i know what you are referring to, the doc type filter would ideally be like this:

With the General Counsels Reports... and Conciliation agreements checked by default

[noahmanger]

Design-wise though, we won't have the "more" options in a dropdown, as that's an enhancement coming. So all the options can just be presented as checkboxes.

[dogweather]

Dev coding note: To develop this page,

• Start at http://localhost:3000/legal/search/enforcement/?search=presidents&search_type=murs
• Launch web app with env FEC_WEB_API_URL='http://fec-dev-api.18f.gov' FEC_FEATURE_LEGAL_MURS=true python manage.py runserver

[dogweather]

Can somebody point me to a final spec for the Todo item, "Document type Checkbox Filter"? I'm not sure exactly what to implement.

[dogweather]

Also, "Respondent name text filter", and really, all the remaining todo's in the Issue description (top). The respondent name text filter seems to be more complex than a single text input field. (?)

If we don't have a spec (mockup or wireframe), I could just implement something that's reasonable to me, and we can iterate on it.

[jenniferthibault]

@dogweather The Document type checkbox filter refers to the screenshot in Nicky's comment above

(these are funny names, sorry)

Some filters have changed since the completion criteria were set, but the further comonents can be seen in @nickykrause's mockups in https://github.com/18F/openFEC-web-app/issues/1797#issuecomment-274556695

It might be helpful for Nicky & you to connect synchronously to show you examples of some of the interactions & explain logic behind them?

[nickykrause]

My thoughts: We started implementing some aspects of the legal resources (particularly the AO and MUR filters) before we had a chance to really think them through / refine the designs. So, there have been lots of unanswered questions, which are being asked either as a part of implementation or as a part of designing similar components elsewhere (e.g., filters for ADRs/AFs).

I am hoping that we can chat about the MUR filters a bit in the legal grooming meeting today, to see if the latest thinking makes sense to the group. We can also connect separately though, Robb, if needed/desired.

[dogweather]

Thanks, @jenniferthibault I added the screenshot to the Issue description, top. It looks like there's more to this than meets the eye. For example, What does the More popup input display? What should happen when an item is chosen?

[jenniferthibault]

Sorry @dogweather , I feel like we're two ships passing between meetings! From @noahmanger 's comment above it looks like that feature isn't quite ready. Though I really don't know what's holding it up, maybe someone who knows the data could say better. @anthonygarvan ?

I can speak to the intended interaction logic though, it should work the same way as the political party filter here: https://beta.fec.gov/data/candidates/?election_year=2012&election_year=2014&election_year=2016&has_raised_funds=true

[noahmanger]

Sorry for hazy scope of this issue. To try to clear the fog: this issue is only for implementing plain, HTML-only versions of these filters. The whole "more" dropdown is part of the javascript-enhanced filters, which is work that is happening in parallel to this. For starters, we should just implement each of these as their plain <input type="text">, <input type="checkbox"> and <select> versions.

As far as all the possible options available for the Document type and Final disposition filters , those should come from whatever is available in the API.

I've updated the original issue, but let me know if it's still not clear. Sorry for the confusion!

[dogweather]

Ok, thanks @noahmanger

[AmyKort]

Issue moved to 18F/fec-cms #1563 via ZenHub