Initial sketches

Apologies for not posting sketches along the way. Here is some in-progress work from the past few weeks:

General terminology

Search box states

Configurability of the results list
We've learned that for some projects (e.g. Wikidata) it does not make sense to include thumbnails in the results list. For other projects (e.g. Commons) it might not make sense to include descriptions in the results list. Rough assumption: the more configurable the search component is the more places we will be able to use it in (e.g. mobile, portal, VE, etc.).

	title	description
thumbnail (left)
thumbnail (right)

Loading state for search box / results list on slow connections

Thumbnail alignment challenge

Through discussions with the design team and others we've come to the conclusion that for the main search experience, in cases where we're including thumbnails in the results list, the best practice should be to left-align the thumbnails:

However we also concluded that it'd be best to have the search term left-aligned with the titles (+ descriptions), which potentially leaves an awkward gap on the left-side of the search box:

From there some questions arise:

1. What, if anything, should we put in that weird gap space to make it less weird?
   
2. Should the gap be present before the results list is rendered (like the images above)? Or should we extend the search box to the left by X pixels upon focus? Here is a GIF of what it might look like to expand the search box upon focus:
   
3. How context-specific is this solution? how will it work/not work in other places where we want to re-use the search component?

Custom icons & non-main namespace searches

[more in-progress design thoughts] the current search experience allows you to limit your search to specific namespaces by using Namespace:[search term], e.g. if I wanted to search for a specific user I could search User:Stephen. Currently in the mobile web search experience and the VE insert link search we show the generic thumbnail next to these results:

mobile web	VE insert link

We might want to consider a more nuanced approach to these non-main namespace searches. Two options that come to mind:

1. use a context-specific image - even if we didn't have have a custom image for every namespace we could at least cover the most popular ones and then use the generic thumbnail for the rest
   

2. don't display an image - this could be a little tricky if we pursue the offset in the input because then all of a sudden the result text is no longer aligned with the search text
   

@alexhollender, these results look nicer but I don't think we have page namespace in the search responses.

Re: Namespace search. The search API only searches the main namespace unless the beginning of the query matches the namespace name exactly.

no namespace, only main	Fuzzy namespace match, nope	Exact match, yup

Technically, we could fetch the list of namespaces via the meta=siteinfo API, (sandbox link here) and match the namespace to the query based on that. However, this is certainly a non-trivial amount of work, an extra API request, and it's potentially Wikipedia specific. I don't know how we would set up different thumbnails for Wikiversity for example, which has a different set of namespaces like "School" and "Module". Maybe we could stick to common namespaces like "User" and "Template", but I'd certainly put this feature in the "nice-to-have" bucket.

@alexhollender one state that I didn't see in the designs above is when a user hovers/focuses on an actual search suggestion. It's not vital for mouse interactions but it helps with keyboard navigation.

Also re:Loading indicator, I think we have to take into account when we exactly we want that to appear, and how likely it is that someone will see it.
I don't know if we've settled on the loading strategy for the widget, but if we load the code for the widget lazily, e.g. we wait until someone focuses or hovers on the search input before we initiate the search-suggestion code, then it's likely that the initial search suggestions will be delayed (for the benefit of loading less code upfront). In this scenario it might be good to notify the users that some results are on the way, but if we show some sort of loading indicator on subsequent API requests, while users are typing, in between keypresses, I think that might be distracting.

Another often overlooked aspect of loading indicators is error-state handling. Infinite loading spinners are a sign that something went wrong, but that error is rarely conveyed to end users. I think if we have a loading state with text like "loading results...", we'll also have to include some sort of "no results found" or "error loading results" text as well.

@Jdrewniak, loading strategy hasn't changed as compared to the existing experience, except there's a lot more code to load. Code loads on focus. See T249306.

loading indicators is error-state handling.

I think you would be a good fit to work on T254695 when time allows. Regarding error handling, true, but we also have to keep the code smallish or users will have to wait until the code to load the code they actually want is available.

Misc. design updates

Input offset
My current thinking is to go with the a magnifying glass icon (🔍) on the left, and an explicit Search button on the right. See mockup below (or you can also check it out in the updated demo: https://di-search-3.web.app/Volvo)

language	image
German
Burmese
Korean
Vietnamese
Russian

The various words for "Search" used above and in the demo are coming from the placeholder text found in the search box in Vector. So far the German word "Durchsuchen" is the longest I've encountered (though interestingly Google uses "Suche" and Ebay uses "Finden", so perhaps there are shorter alternatives - generally speaking, not just for German).

If the offset pattern as explored above is concerning to us, or ends up being technically complex, we can still consider:

• eliminating the offset on the left altogether
  
• following the Google pattern, which avoids the need for a persistent icon in that area (see GIF below)
  

Width of search results menu
I was wondering if the width of the results menu should match the input field width PLUS the width of the button, or just the input width. Thus far 6 people (5 of them designers) have expressed a preference for matching the input field (option A below)

cc @ovasileva

Search button refinements

Continuing to play around with the Search button. Based on some feedback from @Volker_E about there being too many mentions of "Search" (leading icon, placeholder text, button) I'm playing around with two ideas:

1. what if we only showed the search button on hover/focus?
2. what if we tried an ⮕ icon instead of the text “Search”?

Demo here: https://di-searchland.web.app/ (use the radio button in the gray box on the bottom corner to switch between text & icon)

text	icon

@MNeisler @Mayakp.wiki — we have been discussing various options for the search button for the new search component. Currently, in the existing search experience, there are 3 ways ways to submit a search:

1. clicking the search icon on the right
2. clicking on a result in the dropdown menu that appears once you start typing in the search box
3. pressing enter on your keyboard
   

Additionally, if you press the search icon (#1 above) without entering any text into the search box you are taken to the advanced search page (link).

I am wondering if we have any data on the usage of this button? I would be interested in knowing:

• what percentage of submitted searches are submitted via the button?
• how often is the button clicked with the search box empty?

noting that in VE insert link search widget there are custom icons for disambiguation and redirect results

@alexhollender : Can you please file a task, set a priority and tag Product-Analytics ? We can triage this request tomorrow in our Board Refinement meeting.

I am wondering if we have any data on the usage of this button? I would be interested in knowing:

• what percentage of submitted searches are submitted via the button?
• how often is the button clicked with the search box empty?

Loading state

cross-posting here for those who aren't following T254695 — today I worked on a search loading experience. There are two possible states, though maybe we only need the initial one. Link to prototype.

initial loading experience	subsequent loading experience (if needed / slow API?)

Search result title text formatting

There are three different approaches I've seen regarding how to format the search result title in relation to the search term:

	bold the matching portion (we do this currently)	bold the non-matching portion	don't bold anything
single word
multi-word

It seems that bolding patterns shown above are most effective with a multi-word search term & results, particularly when the first word has been completed in the search box. For example with the term "Vermont" entered either of these options look good (though I do think that bolding the non-matching part is more helpful here):

When the search term & results are only one word the pattern seems much less helpful:

Based on that observation we could look at the data to see whether single word or multi-word search terms & results are more common. If single is more common we could ditch the bolding altogether. If multi is more common we could go with the pattern where we bold the non-matching part. Or if we don't think that the bolding presents an issue for single word search terms & results we could just go with bolding the non-matching portion without even looking at data.

Some other notes from recent conversations:

Bolding the matching portion

• bolding the beginning highlights the content that has been confirmed by the user...since it is uniform in length it acts as a column that may add less visual noise (looking more like a block than a bunch of elements).
• bolding the first part helps the user understand why the search result appears in the list.
• why highlight the common piece in each suggestion?

Bolding the non-matching portion

• Bolding the non-matching part emphasizes the part of the text that the user may be looking at, but may add more visual noise since lots of different elements of different size get emphasized. It also feels a bit weird when the bold part is a meaningless. That is, “Bread slicer” looks better than “Apple”

Don't bold anything

• Google has recently changed their suggestion bolding scheme—they don't apply bolding to "entities" (people & places with thumbnails and mini descriptions), but they do apply it to suggested searches. Maybe its time as a design pattern is over?
  

Also there was a discussion about this in 2017: T153417#3170622

When thinking more thoroughly about the current search experience in legacy Vector, the outlined current spec similar to the first iteration here on top T255603#6293760, there are a few things to consider:

Consider not having “Search” button at all
All the items in the autocomplete are direct actions and let you jump to another view. The buttons is labelled “Search”, but the action is actually a “Go”.
The only time the bound action is really “Search” is when there's no direct match for the query. In larger wikis that have a lot of articles that might be the exception, on smaller wikis, it would be more common.
With the instrumentation in T259766 soon taking place we should gather more insights how often the button is used.
But in order to cut the knot in confusing UI elements, it's worth considering to remove the Search button entirely under the current two-way bound action – and with ensuring to not add usability or accessibility hurdles.

Highlight color of active typeahead results
Current layouts use Accent90 as background color, this has been shortly proposed in T166560, but never got prioritized. Current interface standard is to use Base80 for :hover and Accent90 for (pre)selected items. Compare ComboboxWidget or Special:RecentChanges

Typeahead results should carry cursor:pointer
All results should carry pointer cursor, as all the results are direct action elements (see reasoning about unnecessary button above)

An experiment on marrying current widget's input padding and icon position with each other, normal state equals normal paddings, focus state indents the icon and the query input value position:

noting that there's a loading state for the search on Wikidata, in case that's a useful reference:

was just noticing that it's common for the search term to remain in the search box once the search has been submitted. I think this makes sense for search experiences where search leads you to a list of results. I'm not sure if it still makes sense in our case where you land on a specific result (rather than a list). Thoughts @RHo @Volker_E @ovasileva? I feel like it might help to reinforce what has just happened, though I'm not sure there's an issue with how it currently works.

Here are some examples of sites that keep the search term in the box after it has been submitted:

To further clarify with images:

current behavior
wondering if we should do this

In T255603#6416710, @alexhollender wrote:

was just noticing that it's common for the search term to remain in the search box once the search has been submitted. I think this makes sense for search experiences where search leads you to a list of results. I'm not sure if it still makes sense in our case where you land on a specific result (rather than a list). Thoughts @RHo @Volker_E @ovasileva? I feel like it might help to reinforce what has just happened, though I'm not sure there's an issue with how it currently works.

Here are some examples of sites that keep the search term in the box after it has been submitted:

Agree this seems to make more sense for experiences which lead to a results list, so that you can easily go in and modify/refine your search term ("elephant +asian", "toaster oven +bagel setting"), so it makes sense being kept in the Advanced search.

Another distinction might be that these other examples are where the intention of the search box is more about exploring more broadly (what are the different toasters available that match a specific criteria) vs search box on the Wikipedia page being more about finding specific articles that exist for a given subject. So once a user is on an article, its wikilinks enable navigation to related/more in-depth articles more quickly than changing the search term (e.g., the Elephant article has links to the specific Asian and African species).

Maybe there is no harm i leaving the search term there, but in that case it would be more important to have a "clear" button so users have a quick way to clear the search result. Also, ideally this is much more useful if the search box could provide better recommendations/related results than we currently do. Consider the Elephant example:

Alphabetically-related "elephant __" articles	vs Google

was just noticing that it's common for the search term to remain in the search box once the search has been submitted. I think this makes sense for search experiences where search leads you to a list of results. I'm not sure if it still makes sense in our case where you land on a specific result (rather than a list).

Just pointing out that we do in fact have a search results page https://en.wikipedia.org/wiki/Special:Search

If you submit the search query and land on that page (when there isn't an exact title match or redirect) that query does appear in the big search box.

Now why that page has two search boxes and the global one isn't integrated with that page at all is another question :P

@alexhollender - just to make sure I'm following. This is the current behavior:

• Search that goes directly to the page - search results does NOT appear in the search box
• Search that goes to the advanced search page - results does appear in the search box

And the question is whether we should also have it appear in the search box when you do go to a single page?

In T255603#6422137, @Jdrewniak wrote:

Just pointing out that we do in fact have a search results page https://en.wikipedia.org/wiki/Special:Search
If you submit the search query and land on that page (when there isn't an exact title match or redirect) that query does appear in the big search box.

Ah sorry, yes that's what I meant when I mentioned "Advanced search"

Now why that page has two search boxes and the global one isn't integrated with that page at all is another question :P

That would make a lot of sense, but I suspect is out of scope for this project... Although, how hard would it be technically to load the Special:Search results page with a header that doesn't include the searchbox?

In T255603#6422156, @ovasileva wrote:

@alexhollender - just to make sure I'm following. This is the current behavior:

• Search that goes directly to the page - search results does NOT appear in the search box
• Search that goes to the advanced search page - results does appear in the search box

Yes that's correct.

And the question is whether we should also have it appear in the search box when you do go to a single page?

Yes, that's what I was wondering about. To further clarify with images:

current behavior
wondering if we should do this

@TJones I was wondering if you have any opinions regarding the question I raised here: T255603#6416710?

In T255603#6463954, @alexhollender wrote:

@TJones I was wondering if you have any opinions regarding the question I raised here: T255603#6416710?

As a user, I find it very useful to have my query retained on a page with a list of results, in case I want to edit it because I didn't get the results I wanted (often because of a typo). I get annoyed at sites that don't do that.

I don't have strong feelings about keeping the search terms in the search box when you get to an individual result page (like a specific Wikipedia page). I would want to test it by enabling it for a small percentage of users and seeing how often they do another search with a similar query, versus rewriting it entirely, or not searching again.

At the extreme end of holding onto queries, I find it deeply weird that YouTube, for example, keeps your query in the search box as you navigate from video to video. Six clicks later and the query has nothing to do with the video you are watching. I guess it's an interesting bread crumb.