Fixed search bars on mobile - any good examples using Algolia?

My Algolia search UI is fairly similar to most of the instantsearch examples - fixed search bar up top, filtering/facets in a left sidebar.

On desktop, this looks and works great as there is plenty of screen real estate to show everything. On mobile, it’s fairly trivial to hide the sidebar in a slide-out or collapsible with a ‘filters’ icon to expand as needed. Searchstone.io (found via Awesome Algolia) does this well.

Does anyone have an opinion (or can point to any examples) on using a fixed search bar on mobile? None of the instantsearch examples are responsive, but I suspect the fine folks at Algolia have opinions on mobile search :slight_smile:

On the ‘pros’ side, a fixed search bar would allow a user to adjust a search input on the fly without having to scroll back and find the search bar, click to open the keyboard, and adjust the search. It also really shows off the live search capabilities of Algolia too, which my users are shocked to see (as they’re used to home-grown search that requires a page refresh).

I haven’t come up with many ‘cons’ to a fixed search bar other than taking up 75 or so pixels and having to deal with iOS Safari quirks.

Interested in the community’s opinion! Any and all thoughts most welcome.

1 Like

Hi @chad, interesting question you’re asking! As often with UX, the answer can be subjective as it will depend on your audience/context:

  • Does it bring value to your users? (In this case, would removing the search bar allow you to display fully one more hit?)
  • Does it put a cost on your users? (Potentially not finding the search bar anymore and being lost)

Usually on mobile we do recommend to keep the search bar visible (e.g. in our InstantSearch Android Examples) for two reasons:

  • as you said, it lets your users search on the fly, which will make it easier to do several successive searches without having to scroll back every time
  • the searchbox containing a search term, having it visible gives some context to the user when seeing the hits (they won’t need to scroll back to remember what they was searching for)

But as I said, this all boils down to the value added for your use-case: if you add more value by displaying one more hit than by displaying an accessible search bar and contextual information, there is no reason to keep a fixed searchbar! :slight_smile:

4 Likes

Just chiming in here with some data I gathered while doing the Yarn website (link). Here we saw a 10x increase in usage when the searchbar was always visible vs when it was hidden behind a link. I’d personally always show the search bar, but filters could be hidden with a clear icon and text until necessary.

5 Likes

This is hugely helpful…thank you both! Framing it as one-more-visible-hit vs accessible-and-contextual is a great way to think about it. The 10x increase in usage cemented the decision. Fixed search bar it is.

Our site users are nonprofit professionals trying to find the right funders based on free-text descriptions of a funder’s past grants. Providing real-time contextual changes as they search is hugely important, as, for example, one person’s “gender equality” is another person’s “gender parity”. Thus, context > one-more-visible-hit.

@haroen Curious - any specific reasons why the team decided to let the search bar on the Yarn site float, and not be fixed?

1 Like

There’s no particular reason why we didn’t make it stick to the top, apart from technical ones. We didn’t consider that pattern, so I can’t say which is the better option.

If your search bar isn’t too big, making it sticky seems also a good pattern, it will encourage users that scrolled down a bit to refine their search even more.

What’s really important when doing that though, is making sure that your search bar doesn’t impair users from actually seeing the results.

2 Likes