Eight reasons why you shouldn't add search suggestions to your web app
Let's talk about search suggestions: the little dropdown of suggestions that a server thinks you care about when you go to search a web app or website. TL;DR: You probably shouldn't implement them.
This post is going to be me explaining why you shouldn't even bother.
Reason 1: The browser already does autocomplete
Any modern browser will already do autocomplete on your field for you. If you
mark the field as
<input type="search">, the browser can do a pretty good job
of figuring out what you'll type next if you've already used the site before.
Reason 2: Your interface is going to be crap
Making it look good and work well across browsers and platforms isn't going to be a walk in the park. Making sure the suggestions don't go off the bottom of the page, making sure they're not half off-screen on mobile (bonus points for making them bleed to the edges of the page), making sure when you scroll on mobile the search box's blur doesn't close the suggestions, making sure relevant keyboard events trigger appropriate behavior (ESC, anyone?), what order you're triggering a focus event (you don't want to download a list of suggestions before the keyboard loads on mobile), etc.
Getting all of that right is hard, even if you're using a library.
You know what would be even better? Just use
<datalist>. You can give it
basic styles, it uses the OS's native keyboard support and events, and it's
stupidly easy to implement (not that you should).
Reason 3: Most libraries are crap
Oh, you're using a jQuery plugin you found on Dynamic Drive from 2006? Good luck with that.
Reason 4: Most of your users are searching with Google, anyway
Let's be honest: if your site isn't one of the top 10 sites users use every day, your users aren't searching via your built-in search engine. Chances are, the vast majority of your users are finding your content because they searched on Google to begin with.
Reason 5: Your implementation is slow and naïve
Oh what's that? You've got a RESTful API that you're pinging every time the user presses a key? Bless your heart.
You could make it better by pinging the server with a debounce/throttle, but then you might have those awkward pauses where you aren't updating anything, or you're showing results from past keypresses.
Let's look at things you could be doing but probably won't because they're a massive pain in the ass:
- Aborting connections that aren't useful anymore (i.e.: aborting one connection when the user presses another key)
- Using predictive algorithms to send suggestions for the next few possible searches (i.e.: the user types "pi" and you return the results for "pi", "pink", and maybe "pickle")
- Compacting search suggestions into a trie
- Leveraging sockets or
EventSourceto open a single connection when the user gives the search box focus so you don't create a few dozen XHRs
- Predicting search terms when they first click in the search box based on past searches
Reason 6: You shouldn't suggest results, you should suggest terms
If you're suggesting results instead of search terms, shame on you.
- Users expect to get search term suggestions because it's the norm. Go ahead, go make a search on Google or YouTube. Either of those suggest results or videos directly in the suggestions? Didn't think so.
- If your users knew exactly what they were searching for, they probably wouldn't be using your crappy search to begin with.
- If you're showing results and the search isn't based on name alone, you are potentially showing items without context. I.e.: if the user is typing search "power" and you show a result for Chernobyl, you're trying to be too clever.
- Users get a sense of gratification when you suggest what they're about to type. They get a sense of frustration when you get it wrong. Your algorithm is probably wrong.
Reason 7: Your algorithm sucks
- You don't have as many users as you think you do, meaning pulling from aggregate search term data is going to give poor results.
- You're pulling from aggregate search term data, but you're not doing any work
to prevent single users from biasing results. (Don't worry, I'll be the guy
that writes a script to automatically search for
XXX poopfor every three letter combination)
- You don't support unicode.
- You do support unicode but you don't support canonicalization.
- You don't have stop word support for non-English locales.
- Your algorithm is too slow for search suggestions.
- Your algorithm doesn't look for multiple spellings or support contractions.
- Your algorithm doesn't account for misspellings.
Reason 8: The code is damn big
I have yet to see a full-featured search suggestions implementation that's reasonably small. In general, once you combine markup, styles, JS, and whatever hooks you need to add to make the library do what you want it to do (or if you're writing it yourself, all the code to tie into existing application logic), you're looking at 15KB or more minified. If your whole app is a hundred KB total, that means over 10% of your code is spent on a single feature, which is supposed to be subtle. Not cool.