Item — HN Reader

This is actually a great example that shows where Algolia doesn't shine.

Algolia is great a known-item searches. Searches that are like looking up a contact in your phone list. This is a common use case with search, but one of only many.

Your use case is closer to grasping at straws because you don't know the language to use. You can't quite remember the name for something. This is also very common, and not handled well with purely string matching. Another example is in this blog article[1] where I talk about searching for "manual lawn mower" not realizing the right terminology is a "reel mower." Mapping vernacular is a hard problem, and I feel like Solr/ES while harder are better equipped for the problem.

(I also often find instant search distracting)

[1]http://opensourceconnections.com/blog/2014/06/10/what-is-sea...

4 comments

> Algolia is great at known-item searches

I have not used Algolia much but that's not a particularly compelling selling point, most search engines tend to get it right if you know exactly what to query. The problem is this is, like, 1% of the difficulty of making a good search engine.

Totally agree, but in my example above I'm actually not even requiring vernacular mapping or any sort of conceptual disambiguation. Basic TF-IDF should rank that result pretty well and it certainly should not return 0 results.

Great article by the way!

@Lxr

In addition to being good at known item searches, my pitch for Algolia would be

(1) it's Easier to perform relevance tuning. You'd be surprised how annoying the Solr/ES defaults are. And the API is more advanced. (2) it has much better typo tolerance (again this gets at "known item" where you fat finger something)

Algolia contains a lot of customization parameters that can be used. For example the Product Hunt example could have been solve easily by using removeWordsIfNoResults=allOptional (query is trying as a AND and if there is no results, it is tried again as a OR)