Expand Search block customization

[mtias]

The search block is currently very rough to use as a design element on a theme or navigation design. It currently renders like this:

This block should have some options in its attributes to:

• Not render a visible label. (@apeatling) Search Block: Add button, label, and width options #24666
• Allow rendering a magnifying glass icon and use it as the submit button. (@apeatling) Search Block: Add button, label, and width options #24666
• Allow not having the submit button visible. (@apeatling) Search Block: Add button, label, and width options #24666
• Control over border radii. (@apeatling) Search Block: Add support for setting the border radius #25203
• Control over background color [Search Block]: Add color support to search button #32416
• Control over text color [Search Block]: Add color support to search button #32416
• Control over border color. Search Block: Add border color support #31783
• Control over margin: Search: Add margin support #63547
• Control over typography: Search block: Add typography supports #43499
• Allow expanding the field on focus Search Block: add button only with expandable input #50487
• Ability to render search interface as a full-screen overlay (and other treatments).
• Control over padding: Tracking: Dimensions Design Tools Consistency #43243

Some of these could be built as variations offered when inserting the block (in the placeholder scope).

[mapk]

I've made a first pass at some iterations. Still working, but wanted to share what I had for today.

1. I improved the block to match G2 iterations.
2. Settings:
   a. Show/hide button
   b. Use icon instead of text in button
   c. Place button inside field instead of outside field
   d. Show/hide label
   e. Adjust border radius of field. (I'm thinking the button would inherit the theme styles) Doing this keeps the settings simplified more.
   f. Adjust border color
3. Block styles:
   a. Default – What you see.
   b. Expanding – A version that expands on focus.

We can probably add a lot more settings to allow more control, but I'm attempting to start out simple. I'll work on revisions tomorrow.

Prototype

https://www.figma.com/proto/TvjAY5aNMMM8boPHPNwGpT/Search-block?node-id=1%3A329&viewport=-973%2C287%2C0.5&scaling=min-zoom

Mockup

https://www.figma.com/file/TvjAY5aNMMM8boPHPNwGpT/Search-block?node-id=1%3A329

[mtias]

What elements (if any) do you think could be added to the toolbar?

[karmatosed]

Interesting explorations @mapk. I tend to agree with @mtias that considering what could be added to toolbar might be interesting.

One thing worth noting is we currently have these:

Whilst having uniform interactions is good, I am not convinced if all of these are needed for this block. In my explorations I removed a lot, however, I don't believe that will be the end case so examining each is a good idea.

In exploring this more, I think with the padding work being done on other blocks we can move that out of any menu, so I dropped that.

There is prior art for text and background colors, we could just add border to:

Where we have options like showing button and also an icon, I do wonder if those are style variations? It feels like that could avoid having too many options here. I wonder if by using only style variations and styling in toolbar, could we get all of these options? How many need to still be in sidebar?

As far as border-radius is concerned, I think exploring what that could be in the toolbar could be interesting. For example, there is a pattern with text/background color to follow. Here is a really rough mock of that potential.

All of these aren't complete, but hopefully, they add some fuel to your mocks for the next iteration phase.

[mtias]

These are not rich-text inline options, they should not show up in the dropdown arrow but in the main toolbar, before "bold" etc.

[iamtakashi]

Some sketches to illustrate what the user might want to achieve:

As @mtias mentioned above, it's often to see a search in a full or partial overlay that appears by clicking an icon. I tried to illustrate an example with below.

[karmatosed]

An iteration with the note on text tools. I did move out the background / text color as it now has border combined. Again, the icons and ideas are all fuel over complete.

[tomtev]

Love all you have done, but styling should be done by themes or plugins?
IMO core blocks should only have options like "Show button", "Show label" etc, but styling should be done by themes.

[mapk]

My goal for this block is to achieve common search interfaces without an overwhelming amount of settings. As a Core block, I'd like to keep it somewhat limited and allow detailed styles to be applied by the theme.

@iamtakashi, your mockups above are beautiful and highlight the many variations of search forms. Thank you! However, I'd like to start out with a simpler set of options like this:

These variations alone include a large number of settings already. But ultimately, taking into consideration the issue's outline, we can edit:

• Border & background colors
• Border radius
• Icon or button, or no button
• Label, placeholder, and button text edits
• Show or hide label
• Icon display inside search field
• [not seen] Search overlay option

These particular examples do not include settings for:

• Padding
• Spacing
• Border width
• Text color

---

@karmatosed has done some great explorations to bring settings to the block toolbar – Thanks!

Initially, the complexity of tabs inside the toolbar popover felt too overwhelming, especially when we consider that Border color can include border colors for both the input field and the button. Background color can include background colors for the input field and the button too. And finally, if we choose to allow text color edits, this can include the text color for the label and the button. So quickly these settings multiply. This is why in my note above, I've excluded text color edits for the initial MVP.

What elements (if any) do you think could be added to the toolbar?

So now, with all these settings, which do we display in the top toolbar that are both important and easy to interact with?

My first goto for important and easy settings are:

• Text or icon button.
• Placement of button inside or outside of input field.

Here's where I landed today:

All of this is experimentation. I'm not quite solid on any of it yet. These can very well just be style variations. I'm still working in the same Figma file.

[mtias]

@tomtev that's generally the case, yes, but note that blocks also need a default in case a theme has not specified styles for a block (particularly for 3rd party blocks). That's why some of these are being defined as attributes of the block with the expectations themes will set the default attributes based on their design requirements. Right now that exists in a theme.scss split file that is opt in through add_theme_support. A larger overview of how all these pieces need to fit in is here: #20331

[gibrown]

The pattern of using a search icon that then unhides a search box is very common and should be supported by Core. The search box should maybe even default to this behavior when on mobile. 2020 for instance uses this pattern.

[apeatling]

In #24666 I've started work on the options for labels and button position. The UI is currently an odd hybrid of the above, but I hope having something to try moves the conversation forward and we can get the UI to a good and final place.

[gibrown]

I tried adding the search block into a page recently and one issue I had was the width and having no control over the width of the search box. This feels like an important thing for the end user to be able to control rather than leaving it to the theme.

Another thought is control over a button vs a search box depending on whether the visitor is on a mobile device or not. A common approach is that on desktop the site may have a full search box, but on mobile it is just a button.

[apeatling]

Reopening this because it was only partly completed in #24666.

[scruffian]

In addition to these changes it would be good to add a few extra things that TwentyTwentyOne does to this block:

• control over border-size
• control over the gap between the search field and button
• control over the height of the field and the button
• typography - font size, weight, family
• line height

[gibrown]

Love that this is moving forward. Thanks!

One case I noticed missing is an option for displaying text or an X when the search box has text in it. Latest version of Jetpack Search (moved from an X to "Clear"):

[javierarce]

Latest version of Jetpack Search (moved from an X to "Clear"):

@gibrown, do you know what the reasons for that change were?

---

Thanks for your comments, suggestions, and that GIF, @jasmussen!

In that vein, it does make sense to me to group all those inside a single dropdown, so they get the benefit of text labels. I'd be curious to see that menu open — we probably need some separators, as the button position is more of a radio group than multiple choice.

I'm not sure about this solution because of your concern about some options being radio groups and other being toggles (that also are only enabled if some of the previous options are selected). Wouldn't this add a lot of complexity? Here's a quick mockup (please, don't pay too much attention to the icons and labels) of the eight items:

But maybe instead of having the 8 items in one dropdown, we could split them in two: one would be responsible for the "style" of the search bar and the other one for the "refinements" or the toggles.

[jasmussen]

Yep, the dropdowns aren't the best in the world. But I do like that they offer icon plus label, as these particular icons are hard to discern otherwise. More importantly, I think keeping them in the toolbar is the right interface.

If you thought of the popover as a canvas just like you think of an inspector panel, what would it look like? As we progress on #27331, I think some of the patterns we find there might work also inside block toolbar popovers.

[gibrown]

do you know what the reasons for that change were?

@javierarce I think find the original reasons from the various design discussions. It came from customizing for P2+ and eventually moved to become the default for Jetpack Search. I suspect it was because there is also a big X in the mobile for closing the overlay and so having "Clear" differentiates clearing the search box from closing the overlay. An "X" feels to me like it better indicates exiting while "Clear" actually says what that button does. Having two Xs is confusing.

[donalirl]

An option missing from the current functionality of the Search block is a control for the color of the placeholder and input texts. I'm not sure what is more logical:

• for the current text color setting to control the placeholder and input text or
• a new color setting to control the input & placeholder color

Let me know if I should create a separate GH issue for this, or if it's fine to leave this here!

[annezazu]

Just wanted to note some feedback from the eleventh call for testing for the FSE Outreach program that shows interest in more advanced customization mentioned in this overview issue!

Then, I added a Search block, but its options were far too limiting to fit it into the design. There was no way to edit the colors or typography of the input field. It would also be nice to have a search text input that expanded or popped up when clicking the search icon.

[apeatling]

I'm unassigning myself from this, others are welcome to pick up items from the list.

[Nixon-Joseph]

Can we also include the ability to add some extra search params? I need to use this, but specified to POST's only. Currently there's no way to do this the way it's set up.

[iamtakashi]

Ability to render search interface as a full-screen overlay (and other treatments).

It'd be great if we could tackle this item soon. It's a struggle to add a search field in the header in a way that works well with small screens. And this will help a lot.

[colorful-tones]

I'm not entirely a fan of the current toolbar implementation. I recently built a dynamic block with a modal overlay. At first, I overlooked the whole toolbar options because I did not even think to look there for configuration/styling options.

I would love to see this block get some attention for WP 6.2 or earlier. I just obtained access to the handy WordPress Figma Library and I intend to riff on some ideas based on @javierarce great work.

[pkuliga]

There is also no control over the space between the input text and the border. This is how it looks on Lettre theme Archive page:

[PradViking]

Current Search Block behaviour when "Button Only" option is selected breaks the UI/UX. If a website uses "Button Only" option to display just the magnifying glass icon and the user clicks on the button, the search field appears to the left of this button and PUSHES anything left of the search block. This means on desktop if there is minimal distance between navigation menu and the search button, this breaks the UI. And on Mobile/Tablet, this is even more pronounced. When the search text field is displayed on the click of the Search Button, it drops down and creates a new row so to speak below Site logo/Title cos it pushes all blocks to the left and due to lack of space, that entire row/group drops down.

As an example, this is a simple Header with Site Logo on the left, Nav Menu in the middle and Search Block on the Right with Button Only option chosen. Header has 1 row, which in turn has 2 rows inside. Row 1 has the Site logo and Row 2 has Nav Menu and Search block. On Mobile/Tablet View, when user clicks on the Search button the text field is generated to the left of the button and this pushes the Nav menu to the left and due to Row properties both get pushed down below the Site Logo. This could be solved by opening the Search Text field in an overlay, either in a small Search box or a full overlay like the Nvaigation Menu behaviour on Mobile/Tablet. (some example of search text box opening can be found on themes like "Breadly" or "Orin" among many others.

Desktop
Before Clicking Search button

Upon clicking Search Button

Mobile/Tablet
Before Clicking Search button

Upon clicking Search Button

Prefered Search Text box behaviour upon Click when "Button Only" option used-

[annezazu]

Quick note that I edited the main issue to share the work that's been done. From the original list, the following remains as of WordPress 6.6.1: Ability to render search interface as a full-screen overlay (and other treatments) & add padding support.

I imagine this might need a similar approach as the navigation block using a template part to control the overlay: #43852 so connecting those two ideas here for now.

I'm tempted to close this out and only open issues around these final items but curious to hear from others.

[mtias]

Closing this and let's follow up on more granular issues for any further improvements.