Add support for boolean filters

[carolineschnapp]

PR Summary:

Add support for boolean filtering on collection and search results pages.

Why are these changes introduced?

New feature.

Checklist

• Added PR summary for release notes
• Followed theme code principles
• Linted with Theme Check
• Tested on mobile
• Tested on multiple browsers
• Tested for accessibility

[NathanPJF]

The label is being displayed to avoid just having the word "No" or "Yes" in the list of active facets. A convo @carolineschnapp and I had before: Should displaying the label be scoped to only when the filter.type is boolean?

Argument for always showing a label: The meaning of other active filter values can be unclear without their label, especially when their values are numbers.
e.g. What are these active filters here? https://screenshot.click/07-58-1qa3e-2pmid.png; now with a label on all of them: https://screenshot.click/07-57-6j9fi-4c3hc.png

So I'm a favour of this change being applied to all active filters for this reason. I know it will make all labels take up my space, but I think it's worth it.

[carolineschnapp]

Thank you, @NathanPJF !

[tyleralsbury]

I think we might need to add a setting for this. It's a lot of repetition for anyone who isn't using Boolean filters, and even for those who are to have that amount of repetition for everything. It's definitely a good idea, but maybe we should include it as a setting to allow folks to choose their preferred UX.

@duygukalaycioglu is working on exploring stuff around Filters right now, maybe she can weigh in.

[martinamarien]

Yes. I agree Tyler. I'm not sure we should always show the label.
Particularly on mobile, the added label could cause the filters to take up a lot of real-estate between the products and filter. From what I've experienced when using filtering, adding a label doesn't seem to be a common practice, but I'd be interested to see if D or another Product designer has any research to support this.

Some options

• Setting for labels
• Labels only for Booleans (may seem like magic/inconsistent)

[tyleralsbury]

Just a heads-up, @duygukalaycioglu will be looking into this.

[carolineschnapp]

Looks like using “or” is the preferred syntax here: https://github.com/Shopify/liquid/blob/master/lib/liquid/locales/en.yml#L8

[NathanPJF]

Interesting. How'd you come across that? Memory recall? I didn't see the "theme linter" catch it.

[gregjotau]

This would be useful for a lot of our filters if I understand the functionality correctly :)

[gregjotau]

https://famme.no/collections/treningstights a lot of our filters are either "on/off"

[carolineschnapp]

@gregjotau yes, those new filters will rely on the presence of metafields of type “boolean”

[gregjotau]

@gregjotau yes, those new filters will rely on the presence of metafields of type “boolean”

OK, hmmm, I guess it is more efficient than having text with 1 option. Then we have to change the metafield type for those / make new metafields to replace.

[martinamarien]

If we add the option for a label, should it also be applied to the "price" filter?

[carolineschnapp]

We figure seeing Price: is not needed:

The same could be said for the Availability filter.

The Price, Availability, Product Type, and Brand filters are default filters you can only have one of each. Their value is self-explanatory.

For custom filters, it might not be as obvious.

Imagine product options or metafield filters for dimensions, for products that have multiple dimensions e.g. Inseam, waist size. The value alone, without the label, is confusing:

A blanket theme setting — always show, never show — is not ideal. Maybe we can be smart about this.

• Show label for all production options and metafield-based settings.
• No label for:
  • Product Type
  • Brand
  • Availability
  • Price

[martinamarien]

Code-wise, this looks good to me. @duygukalaycioglu and @carolineschnapp, let me know if you need another review after the labels have been discussed.

[duygukalaycioglu]

Hi! I’ve conducted some benchmarking, and found a few examples in regards to the best practices for labeling pills.

1. In this example, the filter group name is not repeated in pills but the filter name itself is establishing this differentiation. I think this is the ideal option I would propose, but since the filter names are being entered by the merchant, I assume we can’t come up with a logic to achieve this.

2. These 2 examples below are replicating the same solution presented above, keeping the filter group names in the pill. One disadvantage with this is repetitiveness, but the advantage is that it is always clear, removing the risk of misinformation and possibly the best option for accessibility.

I recommend we go with the 2nd option and if possible, introduce show more and less capability to horizontal filters, so that if the number of filters end up being too many, we are giving the buyer the option to show more/less.

in future iterations - we can also introduce a setting to enable/disable labels in pills.

[bacounts]

"Kida-of-related" to this specific PR: While testing and researching, I came across the following notation about comma-separated lists for a "filter based on a specific variant metafield".... https://shopify.dev/themes/navigation-search/filtering/storefront-filtering#variant-specific-filters.

However, this "comma-separated list" does not render as described on the theme. If I understand the documentation right, I should be able to:

1. Create a product metafield, for example, "Product material."
2. Inside the product page in the admin, I add Gold, Yellow gold, Enamel."
3. Each comma-separated value should now be a separate clickable filter on the collection page, but they are not.

What am I missing, or is this feature not fully supported yet? I even went as far as to add the "m" structure when creating the metafield, but it threw an error and did not allow more than one "." period (error - m.my_fields.fabric).

Comunity thread of people discussing this issue: https://community.shopify.com/c/technical-q-a/insert-a-table-in-product-description-area-with-metafields-amp/td-p/1413183 — issue also raised in #381 (comment)

PS: A separated list metafield could come in handy in other places like the product page. By giving access to the storefront API, I could eventually create a block that lists each of these values as a clickable URL, creating a pho "tag list" that allows the buyer to click and return to a filtered collection for that value. << This is a rough example to prove scalability.

I have included some reference images below using my system.

[carolineschnapp]

@bacounts the comma-separation is in the URL when filtering a collection or search results page, not in the value of a metafield you set in your admin. It's one way to construct the filtering URL, so it is shorter. If you use commas in the value of a single_line_text_field metafield in your admin, it will be interpreted as one value that happens to contain commas.

[bacounts]

@bacounts the comma-separation is in the URL when filtering a collection or search results page, not in the value of a metafield you set in your admin. It's one way to construct the filtering URL, so it is shorter. Using commas in the value of a single_line_text_field metafield in your admin will be interpreted as one value that happens to contain commas.

Thanks, @carolineschnapp, for the clarification. So, if I understand you correctly, there is no way to use metafields to create new collapsable filter menus that hold multiple filter selections?

If that statement is true, it does seem counterintuitive not to have a better option that provides similar functionality to "tag groups," which were standard practice before storefront filtering. These tag groups allowed for more intuitive user filtering, especially when a merchant did not want to create a new variable option or all three options were already occupied within a product.

Possible solution:
The "single line of text" metafield allows a select menu option, which could be extended to a multi-select menu. Creating a new collapsible menu for every item like a "material" would be a nightmare and take up the 20 slots custom filtering slots available, especially on a store with a large catalog.

@tyleralsbury is looking into a core filtering issue I raised in #788; maybe this issue could be triaged alongside?! Otherwise, feel free to create a new issue from my original post if you think this should be addressed. I hope my thoughts help!

[carolineschnapp]

@bacounts this isn't the right place to discuss this. Please create an issue.

[NathanPJF]

From the comment here, #1456 (comment), it sounds like we are good to go.

I recommend we go with the 2nd option

The functionality of "hide/show more" would be a separate piece of work.

[tyleralsbury]

From the comment here, #1456 (comment), it sounds like we are good to go.

I recommend we go with the 2nd option

The functionality of "hide/show more" would be a separate piece of work.

Agreed. I've created a new issue from D's comment - #1494

I've re-requested Martina's review and will try to take a look at this myself today.

[martinamarien]

Looks good to me. Thanks Caro.