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:

• [x] Not render a visible label. (@apeatling) https://github.com/WordPress/gutenberg/pull/24666
• [x] Allow rendering a magnifying glass icon and use it as the submit button. (@apeatling) https://github.com/WordPress/gutenberg/pull/24666
• [x] Allow not having the submit button visible. (@apeatling) https://github.com/WordPress/gutenberg/pull/24666
• [x] Control over border radii. (@apeatling) https://github.com/WordPress/gutenberg/pull/25203
• [x] Control over background color https://github.com/WordPress/gutenberg/pull/32416
• [x] Control over text color https://github.com/WordPress/gutenberg/pull/32416
• [x] Control over border color. #31783
• [x] Control over margin: https://github.com/WordPress/gutenberg/pull/63547
• [x] Control over typography: https://github.com/WordPress/gutenberg/pull/43499
• [x] Allow expanding the field on focus https://github.com/WordPress/gutenberg/pull/50487
• [ ] Ability to render search interface as a full-screen overlay (and other treatments).
• [ ] Control over padding: https://github.com/WordPress/gutenberg/issues/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: https://github.com/WordPress/gutenberg/issues/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

[jasmussen]

Allow expanding the field on focus.

Split this one out, with some additions, to a separate ticket:

https://github.com/WordPress/gutenberg/issues/31128

Also created one for adding contextual defaults when inserting: https://github.com/WordPress/gutenberg/issues/31127

[aaronrobertshaw]

Border block support now provides control over border color, style and width. https://github.com/WordPress/gutenberg/pull/30124

Also, if we are leveraging color block support for managing the background and text colors, I imagine the user would also expect to be able to control the button colors. Without the button being an inner block this might require some ad-hoc color controls being added.

[stacimc]

Also, if we are leveraging color block support for managing the background and text colors, I imagine the user would also expect to be able to control the button colors.

I agree with @aaronrobertshaw here. Ideally I think it would be great to be able to configure the background color for the search input and the button separately, and the text color for the ‘Search’ label and button text separately as well. Using the block as-is and the existing block support, we’d have to choose whether to apply color selections to the whole block or, for example, to just the button.

Some options might be:

• Use the block support and apply color selections to the entire block
• Use the block support and apply color selections only to the Search button
• Break the existing block up into multiple blocks —search, search-input, search-button — which each use the colors block support
• Implement colors adhoc using withColors instead of the block support

[ramonjd]

Control over border color.

I've added border color support over in https://github.com/WordPress/gutenberg/pull/31783

I think it would be great to be able to configure the background color for the search input and the button separately

@stacimc I've not applied the border color separately, but to both the input and button elements. This was just to get things going.

Happy to collaborate and help reach a common approach. Thanks!

[javierarce]

Hi! I've been looking at the current state of this block and the main suggestions in this thread, and I'd like to bump this issue with some refreshed designs.

Here's the original Figma file shared by @shaunandrews a while ago. I've updated the designs to the latest version of the UI and introduced some changes. I've also created a page to collect examples of actual search bars whose general style we could attempt to generate with this block.

Toolbar

This is the current toolbar

The penultimate icon (the block-button) is used in some blocks to display the available styles for the block, while in this case toggles between a button with an icon or with text.

This is the toolbar I'd like to propose:

In order to be more consistent and simplify the toolbar, I think we could move the "Toggle search label" icon and "Change button position" icon from the toolbar to the sidebar (see below) and use the block-button to switch between styles.

I also think we could add a setting to change the alignment of the text inside the input field. That option would allow users to create these kinds of search bars (the first one, for example, is similar to the one that Slack uses).

And yes, these alignment options will allow users to create some weird search bars, but as we all know… with great power comes great responsibility.

Sidebars

Here are the sections we could include in the sidebar:

• Styles
• Display Settings
• Spacing Settings
• Border Settings
• Typography
• Color
• Advanced

Styles

This section would deal with the main appearance of the bar and display four options:

• Button outside (the default option)
• Button inside
• Input only
• Button only

Display settings

This section would allow adjusting the general width of the block and also toggling the following settings:

• The icon inside the search input
• The icon/text of the button
• The search label (not shown in the image below)

Spacing

In this section, users could update the padding of the item and also affect the spacing (the distance between the button and the input field).

Depending on the style (button outside or button inside) the padding will behave differently:

• If button outside is selected the padding will affect both the input field and the button.
• If button inside is selected the padding will affect the outermost element.

The spacing setting could also be modified using a handle in the block itself.

Controlling the space between elements is important to create these kinds of search bars:

Border

There's an open PR that deals with border color support here

Something super neat would be to allow users to modify the border of the input and the button independently for each of the four sides. That would give users great power to create different styles (like having a search bar with just a bottom border).

Typography

The typography section would deal with the font of the placeholder, the text button, and the label, depending on what's selected.

Color

This section would affect the text color and background of both the placeholder and the button (depending on the selection).

---

Again, you can check these designs in the Figma file

[jasmussen]

Lots of good ideas, Javi!

I wanted to rewind a bit and just show the block in GIF form, because a little nuance and detail are lost in the initial block toolbar mockups:

• The block's alignment tools are none, left, center, right, and in block themes that control is only surfaced when the block is placed inside a group.
• Inline formatting tools appear when selecting the editable label.
• Nitpick: the padding between items is wrong, and we've begun the process of grouping block level items together in a "Tools" section.

Outside of missing options, such as showing an icon-only search field that expands on focus, to me the biggest problem with the current in-canvas user experience is that the icons for toggling label, button position, icon instead of text label, aren't very legible. 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.

Speaking of in-canvas, I'm not sure there's huge value in duplicating the label/icon position tools from the block toolbar, and into the sidebar, especially when they look so different (icon only toggles in the toolbar, explicit toggles with labels in the inspector). Redundancy can make sense, but if the duplicated options differ in appearance, it can be confusing to figure out "which option is the right option to click".

More on a technical level, the style variation thumbnails seem like they should stick to being visual-only. Any change of defaults feel like they should be patterns. I mean this more as a critique of how style variations work at the moment — and I do think there's an opportunity to revisit how style variations and pattern transforms can coexist in a system that feels more coherent. But that's probably best explore separately.

A text align could be a nice addition. In some blocks we use "justification" instead. I think text align is the correct one to use here, but wanted to surface the option:

Thanks for the mockups!

[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: https://github.com/WordPress/gutenberg/issues/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.