Haroen | Mobile search UX tips

I wrote a blog post on the Algolia blog: Small but impactful search UX tips for mobile web

As part of our annual tradition of giving a gift to the community, these past few weeks I was part of the team working to implement search inside of Yarn. During that time, I noticed some small quick-wins that could make our search boxes better, and today I’d like to share a few of them.

User experience is important at Algolia – both the developers who use our API and the end-users who use the products they build – and so we look a lot at how the tools we provide to developers can make it easy to create great UX.

One of our most recent projects, react-instantsearch, comes with many optimizations and we’ll highlight a few of them in this post.

Submit UX

We use <input type="search" /> because it allows us to take advantage of semantics for screen readers that tell the user it’s a search input, and it will also show a ? (magnifying glass icon) as the return button on Android. In Chrome and Safari this has more advantages, namely that it shows a search button on one side, and a clear button on the opposite side.

To get that functionality for everyone, react-instantsearch wraps the search box in a form, and includes two extra buttons: one with type reset to clear the input, and another with type submit that will be used if “search as you type” has been deactivated -we hide the latter with some css to avoid duplicating functionality.

See the Pen Default React InstantSearch layout by Algoliamanager (@Algolia) on CodePen.

We only want to submit the form when a user types something, so we will put the “required” attribute on the input. That prevents a user from submitting an empty search. However the default result isn’t too beautiful:

an input that has been submitted, but was required. It shows an error message 'Fill out this field'
A required input


We can avoid this message showing up, but still avoid the submitting of the form, by adding the “novalidate” attribute to the form.

See the Pen input type text vs input type search by Algoliamanager (@Algolia) on CodePen.

Button UX

Next, we can go further in improving the search box itself. On mobile, the submit button becomes more prominent, since it’s visible as the return key (on both iOS and Android). We would love to have something that has to do with search to be displayed there instead of return. On Android we already solved this, just by using input type=search, but iOS still shows “return”, because iOS requires the form to have an action. Search is available on the page we’re on, so we can leave the action attribute empty, and then it means the current page. This will cause the submit button to read “search” instead, and it will be translated to the language of the keyboard you’re using.

You can play around with the differences on all browsers in this codepen:

See the Pen input type text vs input type search + forms by Algoliamanager (@Algolia) on CodePen.

Don’t forget to Blur

Don’t fret, we aren’t done with the search button yet. If you have a button that says search, you expect the search results to appear. Because we show the results in realtime, while you’re typing, we don’t need to calculate the results at this point, so pressing search now does nothing at all for users. We fix this by
blurring (which is the opposite of focusing) the search input. The keyboard will then be dismissed when you hit search, and you can see all of the results.

No need for Autocorrect

Because Algolia is typo-tolerant, mobile-specific features like autocorrect become a bit obsolete. We don’t want to spend time undoing the suggestions by our browser to suggest other words, especially if you’re in a case like Yarn, where a lot of the packages have unique spelling that we don’t want to be corrected.

To disable autocorrect, you’ll need three attributes — autocorrect=off, spellcheck=false, and autocapitalize=off — the latter avoids starting a search with a capital letter all the time. With those improvements, a search on a mobile device will look like this:

image of an iPad that is focused on a search form. The return key says return and pressing it doesn't dismiss the keyboard
The situation before these improvements
Image of an iPad with a search form, it's return key says 'search'
The situation after these improvements

A last thing that has been added is the “role” added to the form. Since December of 2015 , with html-aria#18, it’s valid html5 to add an additional role to a form, and in this case a search role makes a lot of sense. In screen readers that support it, the search input will be read as a search form with inputs, and that’s exactly what we want.

With all those things  implemented in react-instantsearch in
instantsearch.js#1999 and instantsearch.js#2046, we get a search form that looks like this:

See the Pen React InstantSearch SearchBox by Algoliamanager (@Algolia) on CodePen.

You can get a search box like this one by using react-instantsearch to make your search experience, or apply this knowledge yourself.

When making the search for Yarn a few other things came to my attention —I’d like to thank James Kyle a lot, because he kept finding new things to give me feedback on. One of these is stylistic, and that is to always make sure your search input stands out from the background. You can do that by making sure it has a white (or light) background, a placeholder that’s not too light and not too dark. You should add an identifiable  icon (for example ?) to get extra clarity, and it’s also good practice to give a special border to active inputs. My colleague Kevin Granger made a really cool webapp that allows you to create all kinds of search boxes that follow these criteria at http://shipow.github.io/searchbox.


a browser with a focused URL bar, once 'yarn' is typed, and then a tab, followed by a keyword, then enter, the keywords get searched in
OpenSearch in action on the Yarn site

Another thing I learned about while making search for Yarn is the OpenSearch spec. It was developed by a9 (which is a subsidiary of Amazon) a long time ago, and deals with a lot of browser and search functionality. You can make your whole search available in the dropdown that comes up when you use “search in site”. Making your search available in the rss format that opensearch expects isn’t what Algolia is made for right now, but we can make browsers handle the “search in site” feature. To do that we have to add a <link rel=search to the <head> of every page. In that we add a href="/opensearch.xml" and type="application/opensearchdescription+xml", a title="name of your site" is also added to show up in the UI of browsers correctly. The /opensearch.xml file should contain something like this:

<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/" xmlns:moz="http://www.mozilla.org/2006/browser/search/">
  <Description>Package Search</Description>
  <Url type="text/html" method="get" template="https://www.yarnpkg.com/en/packages?q={searchTerms}" />
  <Image height="32" width="32" type="image/x-icon">https://yarnpkg.com/favicon.ico</Image>

You can read more about the implementation of OpenSearch in Chrome, Firefox, Safari, Internet Explorer, Yandex and in general.

The Devil is in the Details

I enjoyed discovering these quick fixes that get a search experience from good to great, and hope they help you create beautiful search for your users. If you have any questions about the tips above, or have UX tips of your own, we’d love to discuss this more with you on the Algolia forum.