@stjn thanks for raising this. I agree with you that the expanding search bar is not ideal. We explored this question a bit when originally designing the new search feature (link), and I think it's worthwhile to revisit. I think we have two options:

Option 1. include the necessary padding in the search box (if the website has thumbnails in search suggestions), so that the search bar doesn't need to expand (as you mentioned)
Option 2. find a way to make the expanding animation less distracting and confusing

Option 1
If we left the thumbnails at their current size and spacing, we would have a search bar that looks like this:

The initial feedback from the design systems team was this is too much spacing around the search icon. One way we could reduce this is by reducing the size of the image thumbnails. Our thumbnails are currently 40x40px. For comparison the thumbnails on Google are 32x32px. If we reduced ours to 32x32px the spacing of the initial search bar, and the search menu, would look like this more or less:

If you toggle back and forth between the two above images you can clearly see the sizing and spacing differences. Looking at this again I feel like the spacing, and the thumbnails, seem to be fine, so maybe this solution could work.

Option 2
One approach we've been considering here is described in this task: T312594: TypeaheadSearch: search input should expand width when menu opens.
Another approach could be doing what LinkedIn does, and move the word "Search" over to the right, instead of expanding the width of the search bar. I think the downside here is that the search icon and the image thumbnails would not be vertically aligned.

As a note/reference, if you are on a Google search results page the width of the search bar expands when you focus it, though interestingly if you are on the main page it does not:

Thankfully we now have the partnership of the Design-System-Team for the design and implementation of this component. @Sarai-WMDE, what do you think about the possibilities explored above? Might we be able to get away with 32x32px image thumbnails, and slightly non-standard spacing around the icon to avoid the expanding search box?

@stjn Just to your point on

While I see the reasoning in this, I want to at least suggest that this distracting animation would be removed and a solution can be found where this search bar always displays with the padding necessary if the website has thumbnails in search suggestions and if it doesn’t. This way, the designers’ sensibilities can be met while not confusing or distracting anyone with unnecessary animation that probably can’t be turned off, too (see WCAG 2.1 criterion 2.3.3).

Web engineering team and myself have introduced functionality to MediaWiki with T254399: Add ability to take `prefers-reduced-motion` user setting into account in Vector, back in May 2022, and as one of our goals for Global Accessibility Awareness Day, users already have the ability to not show animations and transitions according with their operating system preferences and compliant browsers to fulfill above success criterion.

On another note, I think the big thumbnails are a clear user benefit that was in parts behind the decision for the expansion and the expansion is a reasonable pattern when we're providing users with certain needs the possibility to not show the animation. A clear user benefit and a massive improvement over the legacy Vector search.

In T314179#8143610, @Volker_E wrote:

Web engineering team and myself have introduced functionality to MediaWiki with T254399: Add ability to take `prefers-reduced-motion` user setting into account in Vector, back in May 2022, and as one of our goals for Global Accessibility Awareness Day, users already have the ability to not show animations and transitions according with their operating system preferences and compliant browsers to fulfill above success criterion.

Cool to hear that it can be turned off. At the same time, I still think it’s distracting more generally when the search is something you do often, as many editors do. Especially since there’s also another change happening there at the same time (Search button appearance).

Maybe one alternative to reducing thumbnail size is reducing left padding on the search result box by some amount and then seeing if the design would be as spacious as before.

Google’s example above is less egregious since nothing really visibly moves there (borders etc.), what I would compare the current design to is YouTube’s expanding icon which is more annoying since you usually notice how the animation happens every time.

(I would also note that ‘Search results containing…’ result is slightly misaligned at the moment due to the images having a border and an icon of the same size not having one, and no one noticed that in months, so I am slightly doubting the premise that everyone notices when it’s misaligned.)

(Logistics update: This ticket has been added to the current DST sprint because – following @alexhollender_WMF's recommendations based on feedback – we need to explore with the creation of a non-animated version of TahS in Codex. This involves applying adjustments to the spacing and sizing of this component, and of the elements that it's reusing (i.e. Thumbnail).)

Hey @stjn 👋🏻 We've been working on a design exploration to try to define a version of the main search component that doesn't expand on focus. While working on this, though, we've kept wondering if you had a chance to check the version that Alex shared in his comment above, where the search input expands at the same time that results are displayed: T312594: TypeaheadSearch: search input should expand width when menu opens. The Web team was evaluating this new approach to reduce the issues you're describing. Could you let us know if this would be an acceptable alternative?

I think the prototype in that task is a bit better, but would be even better if the search box expanded only when suggestions are actually visible (right now it expands when typing starts, and only then shows the search results, which makes it two animations if the loading is not quick enough).

In T314179#8187567, @stjn wrote:

but would be even better if the search box expanded only when suggestions are actually visible

yes, that's the exact intention of the proposal/prototype (though the prototype is not setup to handle loading delays, so if you are seeing the expansion happen before the results load that's just a bug)

Logistics note: this task should be resolved once T312594: TypeaheadSearch: search input should expand width when menu opens is released.

While this is mostly nitpicking, I’ve looked at this component again and want to ask: is there anything bad from the design perspective if the search bulb icon itself did not move to the left when results are there? Like this:

Hey there @stjn! Yes, from a design perspective, not moving the icon to the left to centrally align it with the thumbnails in the menu options would have a negative impact on visual balance. Aligning all icons at the center creates a more symmetrical design: this way, the visual weight is on a straight line, and all elements have an even amount of spacing around them (notice the excessive white space to the left of the search icon in your example). In general, centrally aligning the icons gives a more organized appearance to the component's UI.

Can we consider this task resolved by T312594?

In T314179#8983126, @CCiufo-WMF wrote:

Can we consider this task resolved by T312594?

@CCiufo-WMF. I'd say so, yes!