New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expand Search block customization #22071
Comments
I've made a first pass at some iterations. Still working, but wanted to share what I had for today.
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. PrototypeMockuphttps://www.figma.com/file/TvjAY5aNMMM8boPHPNwGpT/Search-block?node-id=1%3A329 |
What elements (if any) do you think could be added to the toolbar? |
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. |
These are not rich-text inline options, they should not show up in the dropdown arrow but in the main toolbar, before "bold" etc. |
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. |
Love all you have done, but styling should be done by themes or plugins? |
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:
These particular examples do not include settings for:
@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.
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:
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. |
@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 |
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. |
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. |
Reopening this because it was only partly completed in #24666. |
In addition to these changes it would be good to add a few extra things that TwentyTwentyOne does to this block:
|
Border block support now provides control over border color, style and width. #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. |
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:
|
I've added border color support over in #31783
@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! |
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. ToolbarThis is the current toolbar The penultimate icon (the 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 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. SidebarsHere are the sections we could include in the sidebar:
StylesThis section would deal with the main appearance of the bar and display four options:
Display settingsThis section would allow adjusting the general width of the block and also toggling the following settings:
SpacingIn 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 (
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: BorderThere'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). TypographyThe typography section would deal with the font of the placeholder, the text button, and the label, depending on what's selected. ColorThis 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 |
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:
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, do you know what the reasons for that change were? Thanks for your comments, suggestions, and that GIF, @jasmussen!
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. |
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. |
@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. |
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!
|
I'm unassigning myself from this, others are welcome to pick up items from the list. |
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. |
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. |
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. |
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:
Some of these could be built as variations offered when inserting the block (in the placeholder scope).
The text was updated successfully, but these errors were encountered: