Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What software engineers should know about search (2017)

scribe.rip

Post reply on HN
Print view View original

111–120 of 132 posts

Re: What software engineers should know about search (2017)

#111

Post by jillesvangurp »

kristopolous wrote: post #2

Biggest advice I can give is you probably don't need search if you're indexable by search bots. No really. Look over people's shoulders sometime. They'll just go to Google and type in their search followed by terms such as Wikipedia, imdb, Stackoverflow, YouTube, Bandcamp, Amazon, eBay, Yelp... all sites that spent a lot of time on their search and have done quite a decent job. Oh well. So unless you really need it f…

It depends. If your main UI involves search, you might want to make sure that it is actually usable, competitive and not embarrassing.

If your main business is selling stuff that users find via your search features, then doubly so of course since you are literally losing cash every time your search ends up not doing its job. Easy to measure too and most eCommerce companies that survive long enough do that obsessively because it shows in their recurring revenue if they don't.

Also, if your competitors have awesome search and you don't, your users might realize and jump ship. If you have content that is great but nobody is finding it, you might want to fix it by allowing them to find it via better search functionality.

If search is actually not critical to your UX or product, then by all means, cut corners. Google will happily redirect users to your competitors as well. Make sure to give them plenty of money for keywords. If you don't, somebody will. Either way, your analytics will tell you how people come to your site and what they do once they get there.

Either way, it's not that hard to build a decent search experience if you know what you are doing. The key point of this article is that many engineers kind of don't know what they are getting into and mess it up.

Re: What software engineers should know about search (2017)

#112

Post by throwaway923840 »

I don't understand why people still waste so much money on making some perfect search engine when they can just filter on tags. Every retail product sales website in the world works by filtering on tags, not deciphering search terms in the "right" way.

Want black shoes? I could search for "black shoes", and receive shoes with the brand/product name "Black". Or I could select 'category: shoes' and 'color: black' in the drop-down box. Hey, look, now I have a list of black shoes.

Re: What software engineers should know about search (2017)

#113

Post by inshadows »

throwaway923840 wrote: post #112

I don't understand why people still waste so much money on making some perfect search engine when they can just filter on tags. Every retail product sales website in the world works by filtering on tags, not deciphering search terms in the "right" way. Want black shoes? I could search for "black shoes", and receive shoes with the brand/product name "Black". Or I could select 'category: shoes' and 'color: black' in th…

Lucky you. I search eshops with

  black shoes site:https://shittyeshop.com
on Google because of abysmal search on 99% of sites.

Re: What software engineers should know about search (2017)

#114

Post by inertiatic »

throwaway923840 wrote: post #112

I don't understand why people still waste so much money on making some perfect search engine when they can just filter on tags. Every retail product sales website in the world works by filtering on tags, not deciphering search terms in the "right" way. Want black shoes? I could search for "black shoes", and receive shoes with the brand/product name "Black". Or I could select 'category: shoes' and 'color: black' in th…

Because:

a) speaking "black shoes" into your phone is a better experience than scrolling down an arbitrarily long list of categories.

b) Is shoes a category? Is it clothing? Is it boots? Oh I need an ontology now? Will users find it intuitive to have to drill down on it???

c) Wait, the item comes in with an automatic description from a thousand different vendors. How do I decide what part of it maps to my "color" field? What if the color isn't in a separate field? How do I make sure that this item isn't dead in my inventory? How do I make sure that this popular item is retrievable for me too and not just my competitors that have a better search??? In this case just searching for "black" anywhere in the fields of the product, weighted for significance, gets me valid results without communicating to the user that they filtered on a color.

Re: What software engineers should know about search (2017)

#115

Post by Graffur »

dgb23 wrote: post #32
kristopolous wrote: post #2

Biggest advice I can give is you probably don't need search if you're indexable by search bots. No really. Look over people's shoulders sometime. They'll just go to Google and type in their search followed by terms such as Wikipedia, imdb, Stackoverflow, YouTube, Bandcamp, Amazon, eBay, Yelp... all sites that spent a lot of time on their search and have done quite a decent job. Oh well. So unless you really need it f…

I don’t want users to leave the site and use google. That’s bad UX and DX at the same time as it only increases friction and uncertainty. I want them to believe that if it is there, they’ll find it with search. But that depends on how good it is and how helpful the feedback is.

How is it bad developer experience (DX)?

Re: What software engineers should know about search (2017)

#116

Post by AtNightWeCode »

karterk wrote: post #12

A problem close to my heart. Good search is certainly still too difficult to pull off for small teams, and this was one of my motivations for building and open sourcing Typesense[1]. Most people think of search and immediately think of large data sets, but the problems that plague smaller datasets are equally interesting. It's less about performance and more about relevance. For e.g. searching across multiple fields…

For sure it depends on the quality of data and the target of the service. Basic knowledge in Elastic search will beat Google for confined data sets.

Major search engines have grown to the size where it is theoretical more beneficial to train a model and then query that model. In theory this will win but in the real world this will not work as we already can see with the failing Google search engine.

Re: What software engineers should know about search (2017)

#117

Post by conceptme »

pc86 wrote: post #93
BatteryMountain wrote: post #47

Earlier quoted context omitted.

This only counts for public sites with semi-static information.. I've been on plenty of internal/LOB projects where the filtering/searching/slicing of data and exporting to various formats are one of the core features of the application, where the data will also be different as time marches forward (non-static sites). Thousands of non-tech people rely on those kinds of features to do their job. Oh, and some of them a…

Well they said in the very first sentence it only applies if you're indexed by search bots. Internal apps (typically) aren't accessible at all, and quickly-changing data isn't indexed in time to be relevant.

It can still be public and indexable but you will still miss finer grade filters.

Re: What software engineers should know about search (2017)

#118

Post by gifnamething »

throwaway923840 wrote: post #112

I don't understand why people still waste so much money on making some perfect search engine when they can just filter on tags. Every retail product sales website in the world works by filtering on tags, not deciphering search terms in the "right" way. Want black shoes? I could search for "black shoes", and receive shoes with the brand/product name "Black". Or I could select 'category: shoes' and 'color: black' in th…

What do I do if I want burgundy shoes? Do I decide if I think it's red or purple or blue? Or do I go further and think what the person listing it thought it was? Do I hope the decision went the same way each time, and all shoes have their colour listed?

I don't do any of this. I filter by shoes and look with my eyes. Retail search is a poor example because existing retail tagging is poor.

Re: What software engineers should know about search (2017)

#119

Post by bboreham »

totetsu wrote: post #35
mjlee wrote: post #27

Earlier quoted context omitted.

I don't see it anymore, but people used to put a google search bar on their website that would use the sitesearch parameter to restrict results to their domain. It looks like there is a modern alernative - seems a little more complex to get going with which might be why it's not so common. https://developers.google.com/custom-search

There used to be a big yellow blackbox server called Google search appliance that you could put in your data center and get internally indexed white label google search.

Before Google figured out what its business model was.

Re: What software engineers should know about search (2017)

#120

Post by dgb23 »

Graffur wrote: post #115
dgb23 wrote: post #32

Earlier quoted context omitted.

I don’t want users to leave the site and use google. That’s bad UX and DX at the same time as it only increases friction and uncertainty. I want them to believe that if it is there, they’ll find it with search. But that depends on how good it is and how helpful the feedback is.

How is it bad developer experience (DX)?

We don't want to be even more reliant on optimizing for something we have little to no control over right? Maybe this is more of a mindset/approach thing. But I like making things where I can communicate the guarantees and assumptions with confidence.

Note I'm not saying we shouldn't care about search engines. They are extremely useful and important. I'm saying if you have the type of content that benefits from being navigated via search, then consider direct control over this.

Post reply on HN