-
Notifications
You must be signed in to change notification settings - Fork 31
Implement front-end MUR filters #1735
Comments
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 #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. |
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... |
(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:
Here are some images of this idea in InVision |
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:
Questions/concerns:
|
Lurking in this issue and have a question: I wonder if the words experience is different based on the placement of the selector.
|
@emileighoutlaw All great suggestions! Thank you. I agree with you! |
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:
(Finally, as I understand the logic, these would be actually be radio buttons, not checkboxes. ?) |
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 |
@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 #1780 |
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. |
Tony and I are think that the Document Type checkboxes default to all checked. ? Is that the sensible default? |
Assuming i know what you are referring to, the doc type filter would ideally be like this: With the |
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. |
Dev coding note: To develop this page,
|
Can somebody point me to a final spec for the Todo item, "Document type Checkbox Filter"? I'm not sure exactly what to implement. |
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. |
@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 #1797 (comment) It might be helpful for Nicky & you to connect synchronously to show you examples of some of the interactions & explain logic behind them? |
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. |
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 |
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 |
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 As far as all the possible options available for the I've updated the original issue, but let me know if it's still not clear. Sorry for the confusion! |
Ok, thanks @noahmanger |
Issue moved to 18F/fec-cms #1563 via ZenHub |
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:
<input type="text">
<input type="checkbox">
with options for each option available in the API<input type="text">
<select>
with<options>
for every 2-years from 1976 - present.<input type="checkbox">
with options for each option available in the APIThe text was updated successfully, but these errors were encountered: