Build card-based layout (testing is a separate card)

[ondrae]

What: We want to know whether pre-defined searches would be helpful to our users both at GSA and outside of GSA.

Why: To understand whether this will simplify their workflow and is worth pursuing further.

Potential design options:

• we might want to have buttons on the top to do some of the most important searches 🤷‍♀
• we might want SSN, ICAM (usernames, PIV), High risk systems more visible 🤷‍♀
• maybe there could be combined term searches so that a user types "usernames, PIV" and it returns results that have those two separate terms available.

Or something else . . .

@nikzei and @igorkorenfeld to pair on research + testing

Acceptance (we know we're done when):

• [x] we have a live webpage based on the mock ups and all its features
• [x] @igorkorenfeld to verify that webpage meets the features he designed

First round of Acceptance

• [x] Move matching count to the right. Float?
• [x] Matching count not updating on first SORN and PIA checkbox click.
• [x] Quick filters styling and functionality. It should show as an active filter.
• [x] Styling of the pagination
• [x] Maintain same distance between filter and the card . Match right side of card to top hr.
• [x] Gutter spacing between PII columns
• [x] Quick filters show up on Active Filter pills
• [x] Work with Igor on max height of filter section background

[ondrae]

• Check our notes from a recent session with Marcela.
• Have a conversation with Marcela about other use cases for search.

[nikzei]

Still need to test mocks.

Next:

• recruiting
• figure out how we want to test - so we know whether Invision is fine or if we want to build this out before testing

So far, we want:

• we want to test for the usefulness of pre-defined search buttons (SSN, etc)
• card lay out (working prototype would be best here)

[igorkorenfeld]

Mockup of the card direction:

With Annotations:

Notes

(Giving a little more context to the annotations)

1. For the System, SORN-ID, and PII boxes I was picturing these would be "type-ahead" filters where a user could start typing a query and it would show them the available options. That way the filters are limited to the options that are actually in the system, but in way that is more manageable than a long dropdown. These boxes are important to helping narrow down a list of results and doing a targeted search for a specific field, rather than seeing where a keyword might show up.

2. For the list of PII in within a card, I think it would be helpful to the user if the list was in two-columns and alphabetized. My guess is that this would be easier to scan through and read than grouped in a paragraph or an unsorted list.

3. "Matching x of y" on the top right should show how many results are left after filtering to help the user decide if they need to apply more filters.

[igorkorenfeld]

Mockup of the table layout:

[ondrae]

@igorkorenfeld I'm struggling to find a way to be able to do multiple separate searches on the same data. Its very complicated to code and it doesn't seem like a common web pattern. I don't know if I've seen multiple search bars for a single data source before.

I suggest we do a single search bar across all the fields. As we talked about in our meeting, for now we've pulled out most of the other columns of data that were polluting the search results anyways.

If we find through user testing that we do need more advanced search options, I vote for doing a hidden advanced search menu. It could offer filtering of fields for the single search bar. That is a more common pattern on the web and will be a lot easier to build.

See the advanced search options at https://lucaong.github.io/minisearch/examples/

Also the USWDS recommends not offering advanced search as the default.

Don’t offer advanced search as the default. The majority of people will do a simple search with one or two search terms. If advanced search is offered, it increases the likelihood of mistakes.

Feel free to push back on any of this. You've got to represent what you've learned from user testing, while I'm going try and be lazy and ask for the easy way every time.

[ondrae]

WIP ready at https://cg-9341b8ea-025c-4fe2-aa6c-850edbebc499.app.cloud.gov/site/18f/privacy-dashboard/

For data it has system name, url, and pii. To get the type and sorn id in there, we'll need to do some spreadsheet munging. There is a lot to clean up in our data workflow still.

For features it has a single search and pagination. I still need to figure out typeahead, and pre-filters. I've got ideas for both.

[igorkorenfeld]

This is great!

The advanced search suggestion could definitely work. I agree that without the other fields it seems like the user would get more relevant results and we may not need the more granular filtering options upfront. I think we can find out in feedback sessions.

Got it on the type and ID. I think if we could at least get the type on there that would helpful. Right now it's hard to tell what the result is if there is both a PIA and a SORN. For instance, searching for "child" returns two boxes both with the title "Child Care Subsidy."

For the multiple boxes, I think we might be framing it slightly differently. I don't thing of them as separate search boxes but rather as filter boxes. The way I think of it, search is additive, so you are adding to the screen all items that match the keyword. While filter is subtractive, and you are removing anything that doesn't match the keyword.

Here are two examples that have multiple typeahead filters:

Job Search – Where each category of filter has a typeahead

Sofa search – Here certain lists like material and style have a typeahead style filter.

I am guessing the filtered out results are not happening client side in this examples though.

[ondrae]

@igorkorenfeld I figured out how to do multiple search boxes filtering on the list. It wasn't as hard as I thought it would be.

[igorkorenfeld]

awesome!

[peterrowland]

Just noticed this bug:

[igorkorenfeld]

I noticed another strange bug.

Whenever any of the filters have just character, the tag for the filter changes label is "System Name." This is true for System too, it switches from "System Name" to just "System" (the latter being the correct label)

[peterrowland]

2 questions for when we review this work:

• Should we show checkbox filters as active and inactive in the toolbar section? They do in the mock-up, but the boxes themselves are pretty easy to grasp.
• If we don't do that, should we rename the toolbar section to 'Active Searches' instead of 'Active Filters'?

[igorkorenfeld]

That's a good point, I think it makes sense to include them as active filters in the toolbar area for both clarity and consistency. I think it'll reinforce how thee filters work and how they should be read.

[ondrae]

@igorkorenfeld I got the "Quick Filters" to show up as pills in the "Active Filter" section.

I added a PII: label to them. Is that how you wanted it?

[igorkorenfeld]

Yes, that works great