Search Filter Design

[techgique]

Search filter design currently uses   (highlighted in screenshot) to separate active filter strings and close links. This should probably be handled with <li>'s using float: left; and margin-left: 0.5em; or similar.

The little "x" image for removing individual filters should be replaced by a bigger, more user-friendly <button> or link styled like one, possibly styled with Bootstrap. This small image is problematic for mousing motor control issues with such a small area available to click, despite otherwise being keyboard/screen reader accessible with an appropriate alt attribute on the image.

[jechols]

+1 on dropping &nbsp. We should avoid that anywhere we don't actually want the semantic meaning (non-breaking space doesn't just mean "force a space right here")

The "x" should be a button, not just styled to look like one:

• It's altering the page data - despite being a raw link, it's basically resubmitting the form. Semantically a link should be used to change a person's location (on-page or to a new page), and a button when altering page data - either via JS or a form.
  • If we make it look like a button, it should also behave like one for keyboard-only users (activation via spacebar). This means adding JS and an extra bit of maintenance overhead. At that point, it's really just easier to have a button.

It's not a WCAG failure to stick to a link, I don't believe, but going with a button makes it easier.

[jduss4]

While we're in here doing this, I would like to propose something. I am adding language on a branch right now and it needs somewhere to live. How do people feel about grouping things like this?

Row 1 : pagination, jump to page, gallery vs list --------- Row 2 : county, city, year Row 3 : frequency, language, front pages only --------- Row 4: rows, sort, refine search button

I like the idea of having some kind of visual indication of where the filters are vs the pagination / sorting type mechanisms. Maybe a background color change or spacing, etc. This is NOT styled correctly at all, but this is kinda what I have in mind:

Each row would have its own block so that it was easier to override in themes

[jechols]

I think something like that makes sense. The pagination bits are definitely "too close" to the filters, given that they are completely unrelated. Maybe a panel around the search refinements could help, in addition to a separation of filter vs. sort?

I could argue to get rid of "Jump to page". If there are so many pages you want to jump to one, filtering is probably what you actually need. I'm pretty sure much larger sites than ours dropped page-jumping years ago (e.g., e-commerce sites).

And "Refine Search" should probably stand out more - it just kind of fades into the background with the controls, despite being the primary actionable element.

[jduss4]

Agreed about removing jump to page. Gallery and List I almost put in the rows / sort portion of my proposal because it seems like it's related to display type stuff (but gallery / list are links instead of part of the form so idk).

I think that Refine Search should probably be the bright red option on the page instead of Gallery!

[jechols]

Hmmm, gallery/list would be better off in the form. I think the way they are right now is kind of a mistake - as you say, they're altering the search presentation, much as sorting or number-per-page. We could make them radio buttons (with the icons if we really like those) or a dropdown or something, but having them in the form, in the same area as rows/sort, that makes a lot of sense to me.

I wonder if this might be a perfect case for fieldsets. One for filters, one for display options.

I don't know about red for the primary refine button, though. Maybe just the default bootstrap blue. Red implies danger. I mean, this is ONI, so a search could be dangerous, but we don't want our users to know that :P

[jduss4]

Works for me!

[techgique]

I'd break the parts up into named blocks like pagination, filtering, and display rather than generic names like row1, row2, etc. And if the whole thing is a block as well, it'll allow people to customize the order of the named blocks within as well

[techgique]

One more detail: Notice how in my screenshot, the "GO" button text is not visible. This is due to only the font color being set. Also need to set the background color to not break dark themes like I'm using.

[karindalziel]

(Jess asked me to mock up some ideas) I have two proposals here - sorry for the roughness, I wanted to get it out quickly. Neither of these are exactly what the end result would look like (cue cursing at bootstrap) but should be closeish.

Option 1:

• Keeps things mostly the same, but groups everything affected by form button in a box labeled "refine search"
• Go button would be colored more dramatically

Option 2:

• Puts all the actual search refine options together, and moves the options that are refining the view outside the box.
• Note that in this option, we'd need to make the rows and relevance act on selection, rather than depending on the submit button. This is how the CDRH handles their search sort options, and how blacklight handles theirs as well

[karindalziel]

Apart from this I will look into options for making the list/gallery toggle more apparent. Perhaps something as simple as a bootstrap button group. Something like this but with only two options?

[jduss4]

Looks like we already did some work on this a few years ago, anything here we want to use?

https://github.com/open-oni/open-oni/issues/213

[techgique]

Initial work on redesign: https://github.com/open-oni/open-oni/pull/376

The PR doesn't address other ideas discussed here:

• <button> elements rather than links
  • More discussion necessary involving search engine crawling, (keyboard) a11y, etc
• Possibly moving Gallery/List controls and sorting into the form
• Further changes to layout of filter controls, such as moving to left of search results with presentational controls (gallery/list view, sorting, results per page, etc) remaining above results
• Faceting a field with multiple values per field rather than only one value via the form <select>s
• Karin's designs include a "Clear Search" button which I forgot to add. One already present on the Advanced Search page, so want to make that consistent between the two pages

[techgique]

Hope to discuss more and create separate issues once we decide how to move forward with these considerations

[raybrarian]

Closing - will consider with a11y/ui audit.