Revisit UI for Filters & Behavior

[valeriegohier]

**UI **

• The current visual of Filter is quite boxy especially went merchant has multiple filters enable
• Could we make it a bit more delicate and take a bit less real estate?
• The UI could be improved in the presence of multiple filters

Potential solution
-Revisit the current behaviour to potentially add a setting for presentation: list out all filters vs collapse

[tyleralsbury]

Technical input...

Collapsing automatically when the filters wrap would not be easy, so a better avenue would be something like either:

1. Collapsing if there are X filters or more - this is a bit more difficult because we'll need to load different CSS based on these conditions. Also, there's a bit of magic going on in this case, which might confuse the merchant.
2. Collapsing as a setting. This has two distinct advantages. The setting will inform what CSS to load, which is easier to reason for a dev and we can separate them nicely to avoid large file sizes. The other advantage is that we could always add this setting later if we decide not to tackle it immediately.

For the collapsed version, the easiest approach would be to effectively use the mobile filters for all viewports, with the swing-out panel from the right side.

[chrisBradley-dev]

Possibility you could make these a horizontally scrolling list with a max-width for the container? I think ideally, when you past a specific level of filter options (say 4 or 5), it would be best to go a vertical filter bar next to the collection-list visually...

[valeriegohier]

Another note on that is the drop-down menu for ''Sort by''. I know it follows the principles around web-native but wondering if the experience could be closer to the one we have for filtering.

[Oliviammarcello]

Based on the feedback received we have decided to add these improvements:

• We will now allow merchants to collapse their filter and sorting on larger devices. Setting screenshot. The drawer styling (width/shadow) will watch what was done on pickup availability. Screenshot
• In all drawers, the clear all button will change from a secondary button to a text link. Screenshot
• Remove all bubble indicators from the drawer and labels when a filter has been selected. Drawer screenshot.
• The boxes for all labels will be removed to reduce some of the extra space that was added and to better align with the art direction. Screenshot.
• On mobile remove the button style for filter and sort and replace with a text link.
• On all screens remove the "Clear all" pill and add a text link. Screenshot
• When javascript is disabled use a text link for the "Apply filter" and "sort" buttons. Screenshot
• Currently, the number of products which is shown above the product cards will read for example, "Showing 74 of 74 products" before any filtering is applied and then change to "Showing X of 74 products" once filters are added. Can we change the text to "Showing X products" when filters haven't yet been applied.
• Style the sort by dropdown instead of leveraging the browser's.

For all edge cases like filter wrapping and spacing details the figma file can be found here.

[KaichenWang]

@Oliviammarcello

Style the sort by dropdown instead of leveraging the browser's.

If our rationale for implementing a custom select is purely for aesthetic reasons, IMO it is in the buyer's best interest to keep the browser's native <select> for sort.

If we were to replace the browser's native <select> with a custom select component, we would need to reimplement (requiring JS) + test all of this a11y functionality manually, whereas the native browser <select> provides this for free:

• The checked option is perceivable for all users regardless of their visual abilities.
• The component can interact with a keyboard in a predictable way across all browsers (e.g. using arrow keys to navigate, Enter to select, Esc to cancel, etc.).
• Assistive technologies (e.g. screen readers) announce the element clearly to users, including its role, name and state.
• The listbox position is adjusted. (i.e. does not get cut off of the screen).
• The element respects the user’s operating system preferences (e.g high contrast, color scheme, motion, etc.).

Source

Even if all a11y functionality is recreated, we have to take into account that native <select> behaves differently across browsers and screen readers. By using a custom select, we are forcing people to use it in a certain way that may not be what they expect.

Usability tests comparing custom selects to native <select> had the following conclusion:

the most conclusive result was that the native <select> element had
the most understandable and usable experience across every platform,
at least for single selection. It blew everything else out of the
water, and not a single participant had a complaint about its
behaviour.

Source

Alternatively, we could use an approach which allows mouse users to interact with a custom select, while allowing keyboard and mobile users to interact with a native <select>. This however requires duplication of functionality in our codebase and extensive a11y testing. If and only if we have strong rationale for implementing a custom select, this would be approach I would explore, but there is no guarantee that a11y requirements would be met.

Source