Ask HN: What do you think about our last HN Search update?
15 comments
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.
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.
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.
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. Any context switch is already a speed bump, and 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's, 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 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).
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.
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. Any context switch is already a speed bump, and 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's, 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 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).
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.
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.
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.
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 or http://hn.algolia.com/legacy#!/all/sort_by_date/0/story:7126... ?
2. What do you think about http://hn.algolia.com/legacy#!/story/forever/0/algolia or http://hn.algolia.com/legacy#!/all/sort_by_date/0/story:7126... ?
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. The link in the first comment ends up being turned into http://twittersearch.<em>algolia</em>.io
Minor bug: the results highlighting seems to break links. For example try this search: 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
We've just improved the links highlighting and have deployed it to production.
Thank for the bug report!
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...
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...
I'm on it.
I guess the word "smartos" is not found, then the typo correction results are shown instead.
I like the hnsearch.com too, but that will be shutdown soon. The interesting thing to me is they are using ThiftyDB which is a full-text database providing fast performance instead of the file-based search. I think the files have the indexes, but they are not scale if not using some kind of database on the backend.
Somehow the fast response to the key strike is not that preferred. Google provides autocomplete for the keywords when we are typing. hnsearch.com just let user to finish want they want to search. They are ok to me.
I like the hnsearch.com too, but that will be shutdown soon. The interesting thing to me is they are using ThiftyDB which is a full-text database providing fast performance instead of the file-based search. I think the files have the indexes, but they are not scale if not using some kind of database on the backend.
Somehow the fast response to the key strike is not that preferred. Google provides autocomplete for the keywords when we are typing. hnsearch.com just let user to finish want they want to search. They are ok to me.
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.
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.
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.
There are already a lot of comments and feedback on this previous thread: https://news.ycombinator.com/item?id=7118496
We took them into account and updated it. So comes this thread, to ask feedback about the second version.
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!
Thanks!
Good work!
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)
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!
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!
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.
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.
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.
Also, one bug. If text in a URL gets highlighted and it's linked, the link URL itself picks up the EM tags.
I wonder how much http://hn.algolia.com will be used if it continues to not be linked to from http://news.ycombinator.com
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 :)
Btw we have just put in production a new version with sort by date :)
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.
Looks great. Now if only HN would have a responsive design too so I can read properly on my phone.
So far so good: It's fast, accurate and readable.
The response time is actually really impressive!
The response time is actually really impressive!
Awesome! Could we get indexation of url chunks?
We already search in url (after title and content)
Great work Algolia!
Here is the ChangeLog:
- Added filters on item types (All/Story/Comment/Poll), filter on story by default
- Added filters by date (last 24 hours, past week, past month, forever), past week by default
- Replaced infinite scrolling by standard pagination
- Added an author filter via the author:USERNAME syntax in search bar. Can filter on one or multiple authors (OR between authors)
- UI was redesigned to improve readability
- Improved responsiveness for mobiles
- Removed highlight of stop words in text
- 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)
- Only last query word is interpreted as a prefix (all query words was prefix before)
There is one last item that we didn't implement as proposed: sorting by date. It will be for the next iteration. In the meantime, you can use date filtering.
Please continue to send feedback!