SearchControl style variants

[jameskoster]

The SearchControl appearance–notably the light gray background–can make it appear disabled in some contexts.

This has come up a few times, most recently in #64935 (comment), pointed out by @keoshi.

So far as I can tell, the original design for this component was created solely for the Block inserter context. While it may work well there, it might be time to consider adding a style variant to create a more 'standard' appearance, more like regular inputs.

Muted variant

Light gray background, no border, right-aligned icon, for the block inserter:

Regular variant

Appearance essentially matches other inputs, with decorative icon on the left, for use in data views and other non-block-inserter environments.

Placing the decorative element (search icon) on the left, and reserving the suffix slot for the x button would align with other input types like passwords:

[mirka]

Related: #56388

Is there anything stopping us from unifying them to the "regular variant"? To take a documentation-first approach, if we can't clearly state when you should use one variant over the other, it's probably going to result in a meaningless divergence. To make it meaningful, I think we need to be a bit more descriptive than "use this variant in the block inserter and this other variant for everywhere else".

[jameskoster]

I would vote for a single variant personally, but last time this came up there were quite strong feelings about keeping the gray background version for Inserter instances.

Alternatively the gray background could become a local style override in the block inserter rather than a dedicated variant? I don't love it, but it's probably preferable to any meaningless divergence :)

[mirka]

@jasmussen Your thoughts on this? Is there any way we can put the usage guidance for the gray search field into words, that is not "Use this gray variant for the block inserter"? I'm looking for something like "Use this gray variant when...".

[jasmussen]

It would seem that a design system effort is perfect in establishing a heuristic for using one or the other, and that if no clean and simple heuristic can be found, then it's an argument for choosing just one. Before making a call on the latter, however, it seems worth doing an audit of all the cases, and considering the before/after states. If we are going to do a drop-in replacement of the gray variant with the bordered variant, it'd be good to vet the after-states and see that things still come together.

[jameskoster]

So far as I can tell, here are all current instances of SearchControl:

Screenshots

Inserter

Quick inserter

Explore patterns modal

Media inserter

Query pattern modal

Add template modal

Global Styles > Blocks

Font manager

Block manager

Taxonomy selector

Data views

Personally I'm not convinced that the UX would be harmed in any case by adopting a more conventional input style. Arguably it would be improved because—when viewed as a part of the broader component set—the current style could be mistaken for a disabled state.

With that said it bears repeating; I don't think it would be a huge problem to apply style overrides to specific instances if we feel they are critical to a particular UI.

[mattrwalker]

From what I've read, some of the initial concerns were around performance and visual design choices in context of the inserter. However, making the input background color grey gives the impression that the input is disabled, which in my opinion is a much larger usability issue. We've let this issue persist because the visual style wasn't dialed in.

I suspect we should first solve the usability issue, then further adjust styling as necessary. It's important that we set the visual and interaction expectation for Search. WordPress users shouldn't have to spend the cognitive load on interpreting all the different ways in which we style a Search input.

TL;DR Let's consolidate and iterate on styling as needed going forward.

[mirka]

So I think the next step would be to prepare a PR with the SearchControl styled like a normal InputControl, with the search icon in the prefix slot. Then the design team can test run the PR and confirm that the consolidated design works across all instances in the app. If there are instances where it doesn't work, we can consider an ad hoc override for the time being.