

Ask HN: What do you think about our last HN Search update? - jlemoine

Last Friday, we have released the new HN Search (http:&#x2F;&#x2F;hn.algolia.com). We received impressive feedback, thanks! We used it to make several improvements.<p>Here is the ChangeLog:<p>- Added filters on item types (All&#x2F;Story&#x2F;Comment&#x2F;Poll), filter on story by default<p>- Added filters by date (last 24 hours, past week, past month, forever), past week by default<p>- Replaced infinite scrolling by standard pagination<p>- Added an author filter via the author:USERNAME syntax in search bar. Can filter on one or multiple authors (OR between authors)<p>- UI was redesigned to improve readability<p>- Improved responsiveness for mobiles<p>- Removed highlight of stop words in text<p>- Relevancy: changed typo tolerance settings to be stricter (now tolerates one typo starting at 5 characters in a word and two typos starting at 9 characters in a word)<p>- Only last query word is interpreted as a prefix (all query words was prefix before)<p>There is one last item that we didn&#x27;t implement as proposed: sorting by date. It will be for the next iteration. In the meantime, you can use date filtering.<p>Please continue to send feedback!
======
gruseom
Impressive work in so short a time. I'm relieved that you guys are this
responsive to the community. You've already addressed one of my personal
concerns and hopefully the other (sort by date) soon. Here's some more
feedback.

I think the defaults should be "all" (not story) and "forever" (not past
week). I searched for something that I knew existed and when it didn't come
up, my first thought was that the search was broken. Better to show everything
at first and let the user decide how to narrow it down if they want to.

Second, I think you'd be better off if the design looked like HN itself,
especially the comment rendering. Not that what you've got is bad, but the
user is almost always going to go from HN to search and back to HN. This
context switch is already a speed bump. Visual changes, which take time and
mental energy to process, add to that jolt. Anything you can to do minimize
these cognitive hurdles will serve the #1 goal, which is to get the reader the
info they're looking for with minimum overhead. In this respect, the old HN
Search is more usable, precisely for being unoriginal.

Thus, if I were you, I would drop the thumbnail pictures of the stories (it's
cool that you can do it, but they don't really add anything and are
distracting); would not include the story info with each coment (rather, I
would do just like HN does and have a bit of text that says "| on: the-story-
title-linked-here"), would make the text rendering look much like HN, and
would follow HN's lead in having a text- and information-density-centric
design. I'm not saying that HN's design is the global optimum (though I think
it is better than most attempts to improve on it), but rather that HN search
is an extension of HN and therefore not the place to innovate on its design.
You're in a counterintuitive position for a startup with this project, since
calling too much attention to yourself in this context is bad. You want to be
unobtrusive and have the thing just work; the HN community is smart enough to
figure out who you are from that and like you better for it. (That said, you
shouldn't obliterate yourselves. For example, I like the visual cues that say
"Page 1 of 10, got 237 results in 3 ms" and "1,244,896 stories and 5,289,181
comments indexed". They are unobtrusive and impressive.)

Lastly, a bug in Chrome: if I search for something, scroll to the bottom,
click on "about", then hit the back button, the original results page freezes
(i.e. refuses to scroll).

~~~
ndessaigne
Great feedback. Your UI comments in particular are insightful. It's impossible
to get something that pleases everyone, but we'll try to get it closer to
current HN design in the next iteration.

------
neverland
1\. Negative keyword search is not available. Can we please add that back in.

2\. Having a date filter is better than none but I STRONGLY preferred the old
one where you can sort by descending order from most recent to oldest. The
current date filter still leaves things out of order even if it restricts time
frame trying to mimic Google's filter.

3\. Exact match search doesn't work either. It currently works similar to
phrase match, where as long as the keywords exist, that will show results
rather than in the exact order specified. Perhaps create two separate ways to
do this kind of search.

------
mjn
Main two bits:

1\. Is there a way to force off the typo correction? I tried "smartos" both
with and without quotes, and either way I get results for the word "smartest",
which aren't about SmartOS (an operating system derived from OpenSolaris).

2\. In terms of CSS/font/layout, honestly I like hnsearch.com's results
better. I think part of it is that I use hnsearch.com as an alternative HN
interface, not just a search engine, and it's usable for that purpose, in part
because it looks more like regular HN.

The issue for me more generally is that hnsearch.com is almost perfect as an
HN search engine, as far as I'm concerned. It does what I want, does it fast,
with good coverage and a usable interface. So my advice for alternatives would
tend towards just "yeah, make it more like that", which is maybe not the most
useful commentary.

~~~
redox_
1\. For now, there isn't any way to force off the typo correction. It has been
added to our feature requests list.

2\. What do you think about
[http://hn.algolia.com/legacy#!/story/forever/0/algolia](http://hn.algolia.com/legacy#!/story/forever/0/algolia)
or
[http://hn.algolia.com/legacy#!/all/sort_by_date/0/story:7126...](http://hn.algolia.com/legacy#!/all/sort_by_date/0/story:7126301)
?

~~~
mjn
The 'legacy' mode is pretty nice, thanks! Does what I want for the HN-browsing
(vs. searching) use-case, no real complaints.

Minor bug: the results highlighting seems to break links. For example try this
search:
[http://hn.algolia.com/legacy#!/comment/forever/0/algolia](http://hn.algolia.com/legacy#!/comment/forever/0/algolia).
The link in the first comment ends up being turned into
[http://twittersearch.<em>algolia</em>.io](http://twittersearch.<em>algolia</em>.io)

~~~
redox_
We've just improved the links highlighting and have deployed it to production.
Thank for the bug report!

~~~
mjn
Looks good!

Another bug report, though I'm not sure if this is on your side or an issue
with the data HN is feeding: it looks like you're indexing even killed/dead HN
stories, which leads to a lot of spam on some queries. Example:
[https://hn.algolia.com/?q=air+max#!/story/forever/0/air%20ma...](https://hn.algolia.com/?q=air+max#!/story/forever/0/air%20max)

~~~
redox_
I'm on it.

------
dclara
Good job! I've learned a lot from it .

If I understand correctly, it is for enterprise search, not for web search,
correct?

The response time is really impressive, especially with the new sorting by
date function. To me, using NoSQL database, it's hard to do sorting if it's
not impossible. That's why it's not available in the initial current release.

This implementation reminded me about the CTF algorithm, which needs to match
the input query against a file. The reason why I thought it's not for large
volumes of queries is because:

1\. Each keystroke is a AJAX call which could be lightening fast when the
query volume is low. But JavaScript could run slow on mobile phones. In this
case probably it's not too bad because the AJAX call is very simple, fetch the
results from the server

2\. After receiving the request, on server side, there are only three steps to
go before the results are returned:

\- Initialized a new index (actually it's not a new index, just a new search)

\- set criteria for the order of the attributes sets

\- Call search and return

Of course, there are more detailed steps under the search api. The majority of
the work is done on the search engine server side to keep crawling and
updating the indexes.

When the request volume becomes huge, the real time response may be slow down
due to the file size.

I appreciate this tool to help me find things quickly on HN.

------
hardxxxtarget
The user-experience is not good as compared to the previous HN Search. I
couldn't figure out that the filters were located underneath the search bar
initially. Also, the thumbnail doesn't look good for me as I'd prefer the
compact view where I could see more search results in my screen. Lastly, I'd
prefer using a contrasting highlighted background color for search text
instead of having them bold, as it should be more distracting so that it
strikes into the user's eyes when he searches.

------
Trufa
Very nice but it seems to break the back button, if I type and search
something it seems to query every letter and so when I go back, I have to do
it for each letter I type, I think queries could be grouped smarter.

Thanks!

Good work!

~~~
redox_
The issue with the back button seems to be a Chrome rendering bug. I've work-
arounded it by scrolling to top on the first query, but I'm still looking for
a more elegant way to fix it. (Will be deployed later today)

------
thrush
There are already a lot of comments and feedback on this previous thread:
[https://news.ycombinator.com/item?id=7118496](https://news.ycombinator.com/item?id=7118496)

~~~
jlemoine
We took them into account and updated it. So comes this thread, to ask
feedback about the second version.

------
DanBC
I use iOS on an iPhone.

1) the hints shown on the desktop version if search (about prefixes) are not
shown on the mobile version of the site.

2) I have no idea how to sort the results by time or points or relevance after
you've returned the list.

3) searching for [danbc] doesn't return enough results. Searching for [danbc
operating] doesn't return any results - but I have used the word operating in
a few posts.

It is very fast though!

------
mindprince
Couple of things:

1) www.hnsearch.com had three sort options: relevance | date | points. It
would be great if the new search also have all three options.

2) Please make your legacy style exactly like the old one. That style matched
HN style perfectly. Right now there is an extra line which links to the HN
thread (we are used to clicking the comments link for that) and the way
comments are displayed feels not right.

------
petercooper
Had an interesting match for a vanity search: "peter cooper" matched "et
cetera" .. combining both a first character typo _and_ prefixing :-)

Also, one bug. If text in a URL gets highlighted and it's linked, the link URL
itself picks up the EM tags.

------
read
I wonder how much [http://hn.algolia.com](http://hn.algolia.com) will be used
if it continues to not be linked to from
[http://news.ycombinator.com](http://news.ycombinator.com)

~~~
jlemoine
Search queries on news.ycombinator.com are redirected to hn.algolia.io which
is an alias for hn.algolia.com.

Btw we have just put in production a new version with sort by date :)

~~~
read
The instant autocomplete feedback of the UI, which is a big strength, isn't
visible to the user when they type a search term in news.ycombinator.com.

------
negrit
So far so good: It's fast, accurate and readable.

The response time is actually really impressive!

------
deanclatworthy
Looks great. Now if only HN would have a responsive design too so I can read
properly on my phone.

------
fulmicoton
Awesome! Could we get indexation of url chunks?

~~~
jlemoine
We already search in url (after title and content)

------
tiboll
Great work Algolia!

