Discussion: Search and Icons

[sturobson]

It was briefly discussed in our recent VF/UX Chat (23/02/21) about the possible need for an icon for the search input in certain instances.

Here's the stub for a discussion on the topic.

As we are moving to using the streamline icon set for 2.x.x+ I've dropped in the relative icons that 'might fit'.

Note: We are tending to use the 'bold' versions of icons, so I've only added those options here:

There are options for search icons in boxes and circles - but this would go against the style used in existing icons.

But I can share those if needed/requested.

[sturobson]

A quick note is that with the new Visual Framework + we are trying not rely on icons where labels will work, and work for a wider audience.

[khawkins98]

Just adding a note that echoes @sturobson's: adding icons will certainly provide some benefit in certain cases, however it also adds questions around governance, UX, visual and technical questions will distract from other work.

My current take is that we should consider exploring the role that icons could/should play in the VF, but that for implementation we focus on the existing roadmapped milestones

[gabsie]

Hi, both @khawkins98 and @sturobson

I suggested to use this in Search fields which act as filters, as opposed to Search boxes which are acting as Search, where they are usually accompanied by the Search button.
I and others have seen that pattern elsewhere, and provides good feedback.

@sturobson - maybe we can see those in the field itself and decide then if people are OK with this functionality

Gabs

[sturobson]

Hey @gabsie - so the icon is to show that it's an 'interactive' type ahead style search filter.

I've noticed that the govuk design system do this:

Myself, @cindyebi and @nikiforosk were discussing form fields again today and we happened upon the idea that 'search is a special case' for 'placeholder text' (the text that's inside the input until the user starts typing. Would that be an option?

We've also got an intranet project where there is possible confusion to - 'am I searching the intranet, or am I searching all of EMBL?'

During the VF catch up with Cindy and Niki I noticed that govuk makes use of the placeholder text for search to define 'where' you are searching.

I think for search things, whether it's interactive or not - we should make use of the placeholder text as 'search is special'.

The next question to ask is, what would be the function of the interactive search filter when JavaScript breaks. Going back to govuk - they hide the search and show the sitemap:

In terms of the 'design' - I think this one matches better the stroke we have with existing icons we are using in 2.x

[gabsie]

Thanks for this, @sturobson @nikiforosk @cindyebi

Yes, if I get this right, we are doing this in our case.. We will be saying Search in Projects
Looks good.

Will it go somewhere as a component, so that I refer the dev to it? :)
Gabs

[sturobson]

Will it go somewhere as a component, so that I refer the dev to it? :)

Yes, @cindyebi is working on this in Figma at the moment too.

Hopefully we will get it into the code early next week I think,

[cindyebi]

I made the mockups for the default and filled variants for Search @sturobson :

[gabsie]

hey @cindyebi and @sturobson Stu - just wondered. You know how sometimes (not in my current scenario, but yes to another scenario I have in mind), these also show suggestions below this search box? Is that something we want to show as well?

[sturobson]

Hey @gabsie - yes, I think it's something we need to define in the figma kit / code so that it's consistent across projects using it.

[cindyebi]

Hi all, there are two types of Search variants so far (see mockup below):

1. Default Search: a field form + a blue search button
2. Filtered Search: a field form without the blue search button; search suggestions will appear when a user is typing on the search field.

[nikiforosk]

I think that it will be helpful to explain in a bit more detail the context(s) in which each search box could be used.

1. Version 1 (with the button) assumes that there is enough space for the button. You can submit a keyword by pressing the button or by hitting enter. There could be suggestions (either as autocomplete or autosuggest [1]).

An example of that is the search box on the training site, especially when it is viewed on a desktop device:

2. Version 2 (without the button) is probably meant to be used when there isn't enough space for the button or if you want to differentiate this search from another (more generic?) search box. The keyword is submitted by pressing enter (given that when the magnifier icon appears on the left of the box, it is typically used as a signifier instead of a button). There could be suggestions in this case too (either as autocomplete or autosuggest [1]).

I think we discussed a few contexts for that, including filtering a table. For example, in Open Targets they are using a similar search box as an instant filter of diseases that can be associated with a gene:

In that case, the table is filtered as you type (i.e. you don't need to press enter to submit the query) so they are not showing suggestions.

There is another search box on the masthead of this page for the main search of the site (where you can search for genes and find associated diseases and vice versa) which looks and behaves differently.

Another example is searching within the online tutorial, especially if we replace the link to "Search within this course" on the navigation panel on the left with a search box. In that case we'll need to use version 2 because there isn't enough space for a button in the navigation panel:

A third example would be viewing a site on mobile. The current search box both on the training home page and the search results within the online tutorial looks a bit disproportional:

A version with a magnifier glass may be more appropriate, although if we then have similar search boxes for different types of searches on the same page (as it happens with the Open Targets page) we may need to use some guiding text to explain what is searched in each case as @sturobson suggested or rely on where the box is placed: e.g. placing the filtering search box within the Table tab in Open Targets seems to signify that it searches the table underneath it whereas the search box on the masthead usually implies a search across the whole site.

[1] As I mentioned above, both boxes could offer suggestions or support instant search if this is appropriate in the context in which they are used. There are different kinds of suggestions, as explained in this article by Tony Russell-Rose (which also includes examples of instant search):

"Both auto-complete and auto-suggest offer varying degrees of support for query creation and reformulation, and the terms are used somewhat interchangeably by many people. But if we were to draw a precise distinction, it could be this:

• The purpose of auto-complete is to resolve a partial query, i.e., to search within a controlled vocabulary for items matching a given character string.

• The purpose of auto-suggest is to search a virtually unbounded list for related keywords and phrases, which may or may not match the precise query string."

I hope that this is helpful.

[sturobson]

the third example is fixed with https://latest.visual-framework.dev/components/vf-search/#vf-search--inline (to be deployed to npm)

[gabsie]

hey @cindyebi - these look great.
I am only wondering a little bit about the contrast of the white on blue background, but maybe you've checked this.
looking forward to using these - I need them for one of my designs :)
gabs

[nikiforosk]

In case this is of any help, in the training site we use a light gray background to highlight the suggestion that has been selected:

Google seems to use a similar background (although the exact colour and the type they use are slightly different):

[sturobson]

The colour contrast for white text on the interactive blue passes at 5.08

[cindyebi]

@gabsie Good catch Gabby, I did check the contrast yesterday and it passed all the other standards except for "Small texts AAA".

@nikiforosk Since our interactive color is blue, I would suggest using a light blue option (included in our new color palette) for the selection:

We could either:

1. Enlarge the text which is currently 16px so that it is accessible, keeping the interactive blue (Blue 600) color as a selection color.
2. Keep the text size as it is (16px) and change the selector color to light blue as it is our interactive color.

An example of how the gov.uk does it:

@nikiforosk The search field within the homepage of the training site will need an update since the label of the search field is no longer mandatory to be right on the top of the field as it is now. I had a separate trello card on the TOL two sprints ago on separating the Search label and the field. The rationale is the label isn't the same as the form field labels as Search is 'special'.

How the search label behaves on embl.org currently:

I think we could add the 'How to Use' instructions on the VF site since it's more accessible to have these instructions on the site homepage than on Figma.

It might be redundant to have the blue search button next to a Filtered Search because when a user has found what they are looking for from the suggestion, they might not need to click on the button anymore.

As for the mobile version, I think @sturobson already worked on the version of where the button and the field form are stacked. It is common practice that all buttons will stack and expand to fill in the screen on mobile, some examples:
Ebay desktop version:

Ebay mobile version:

FT desktop version:

FT mobile version:

This is because, on mobile, the bigger the 'target area' the better https://www.nngroup.com/articles/touch-target-size/

[cindyebi]

Stacked Search button from @sturobson @nikiforosk :

[sturobson]

This happens automatically -- if the search input has less than 60% (an arbitrary value I picked) of the width of it's container (in this case the sidebar column) it stacks automagically.

[sturobson]

After patch-y discussions yesterday I think I'm leaning towards:

• the autocomplete/autosuggest pattern being available where needed.
• always having a search button (which removes the magnifying glass'd 'filter' variant.

Thinking on this more:

• I don't think we can expect all site visitors to know that they can hit enter to submit the search.
• That JS will also work or always work correctly enough so that the autosuggest works - so a fallback would be to have the button.
• Original use cases for only having an input (where space was minimal) have mostly been mitigated (not having a search option in the sidebar on training - but a link to the search itself).
• The search will default to having the button drop under the input when there is not enough space.

[sturobson]

The other thing, which you don't see unless you're on an actual device, is that the OS will give you the correct keyboard, if the form is labeled correctly -- which I'd suggest voids the issue of the overlay here.

Obviously you don't get a special 'search' button on desktop OSs.

iOS:

Android:

[nikiforosk]

In a mobile context, e.g. on the BBC sports site, the search box tends to appear on the top of the screen to leave some space for the suggestions:

Perhaps this can happen when the input field is in focus?

Also the enter key on the keyboard is often labeled as Search.

I think hiding the suggestions in order to be able to show the large search button under the input key will affect negatively the user experience, particularly in the training site. The suggestions are key to guiding learners on what content is available and help them search more efficiently, especially on a small screen.

[nikiforosk]

This is how the search box on the training looks like on my iphone:

As you mentioned, the search button under the input field is not usable but I can select a suggestion (which will submit it as a query) or hit return (which will select the first suggestion in this example). Notably, the button next to space on the keyboard isn't labelled search in this case (unlike the BBC site above).

[sturobson]

I think hiding the suggestions in order to be able to show the large search button under the input key will affect negatively the user experience, particularly in the training site.

As mobile/tablet OSs have thought about this -- I think you can have the autocorrect -- but you would need to limit the results too I think - which is a suggestion I read on a UX site about this -- but cannot find.

[sturobson]

Perhaps this can happen when the input field is in focus?

to be tested -- but I think the browser on mobile/tablet OSs would do this - if not … I don't think it's a good practice to move the site visitors position because if they tap out of the form - their position would be different?

[sturobson]

some points (in quote marks) from a book of form design patterns:

As we are hiding the label for search (because it's special) the button becomes "a quasi-label for sighted users".

If we remove the button we "can't use it as a quasi label, the label would need to be reinstated, taking up room again" and "the button is a fundamental part of a form -- without it, it's not clear how users are meant to perform the search. While we may be aware that forms can be submitted implicitly […] not all users are"

"Interestingly, many of the sites that omit the submit button normally find room to include a magnifying glass icon to signify its otherwise hidden affordance." (emphasis mine).

[nikiforosk]

I'm not really sure how the search field works when voice offer is on but I can ask my blind friends. I would somehow expect it to identify itself as "search"... Wouldn't the magnifying icon be read out as "search button" on voice over?

The version of the search box with the icon on the left as a signifier is really meant to support instant search like the filtering of the table in Open Targets where you don't really need to submit the search query. I don't know how accessible this is either. I agree with you that it's probably better to have a button there too, except that in my opinion the input field there should be smaller and the button should look as like magnifying glass so that it fits on the same row (when there isn't much space for a larger button).

[sturobson]

VO on MacOS latest, when tabbing through, will:

• read out the label (there is a hidden label)
• read out the placeholder
• read out the button

[sturobson]

for reference here's a (five year old) post on what some assistive technologies announce depending on how the search form is marked up

https://www.a11ymatters.com/pattern/accessible-search/

[cindyebi]

@nikiforosk @sturobson and I discussed the Search field variants on the vf catch-up meeting the other day and we decided to add the magnifying icon button as a replacement for the large "Search" button as a responsive mobile variant. Basically, the Search label would 'fade' out and be replaced with an icon once the screen is resized. Mockups below:

1. Responsive Large: for screens >600px width

2. Responsive Small: for screens <600px width

@sturobson has a demo video of how it works exactly.

[khawkins98]

PR for this at #1455