Searching checklists can be problematic

[jameskoster]

The current design pattern for searching a checklist is problematic because it's possible for checked items to be hidden from view. This can lead to posts being unintentionally published into undesired categories, among other quirks. See example;

We're using this current search pattern in the WooCommerce blocks we're working on where the issue is arguably more prominent. This feels like something that should be addressed in core rather than in custom blocks.

Possible solutions
I haven't looked into solutions in any great depth just yet but the crux is that - ideally - checked items should always be visible, even when searching.

One option would be to employ a Chrome-inspired ⌘+F pattern which highlights results and allows you to cycle through them.

Another option would be to simply list the current checked items beneath the search results.

I'm posting this now to gather input before we dive further into the problem.

[jameskoster]

Here's a prototype of the solution we're running with for WooCommerce.

It's similar to the core FormTokenField component except that the list of suggestions is permanently visible and selected items are separate displayed outside the input.

Our reasoning for keeping selected items separate is twofold;

• We anticipate that folks could select many, long-named items (products) which could make the input unwieldy, especially in the sidebar settings panel where space is limited
• It provides an affordance to easily remove all selected items with a single click

For the category selector in core, I wonder if something between these solutions might work best. In that use case it seems less likely that lots of selections would be made which decreases 1. the value of the "Clear all" button and 2. The concern about the input becoming visually saturated with tokens.

An instance of FormTokenField with the suggestions permanently visible might be the simplest solution for that use case.

[karmatosed]

@jameskoster as phase two progresses, this is good to take another look at. I wonder did you in your work on this research any patterns from apps or sites that solve this differently?

[koke]

One thing that came to mind here is how GitHub itself does it, for instance, with labels. If you look at the sidebar here, it only shows the labels that are already checked:

Changing the labels happens in a popup, which contains the search:

Searching there has the same behavior and it hides already checked labels that don't match the search:

However, it's less problematic because the moment you are done picking labels, the popup is dismissed and you can see the final selection. This is kind of similar to the WooCommerce prototype, since the current selection there is displayed separately from the search/list.

[mapk]

I really like the GitHub solution. Here's how it may look in Gutenberg.

Categories

1. Selected categories automatically appear at the top of the list.
2. All other categories are displayed alphabetically below the selected ones.

Category deselect

1. When a category is deselected, it drops down to its alphabetical position in list. (see "design")

Category Search

1. All selected categories that match the keyword are displayed at the top. (searched for keyword: "block")
2. All unselected categories that match the keyword are displayed after alphabetically.

[thanasakleas]

Design team update: Looks like a solid solution, let’s go with it!

Micro-improvement suggestions:
a) Maybe reduce the distance between a checkbox and the word by a tiny bit.
b) Maybe explore more ways for the appearance of nested checkbox lists.