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…
Yeah, the key part is IF, you are indexable. In the project I'm working on everything is behind a paywall.
What software engineers should know about search (2017)
71–80 of 132 posts
Re: What software engineers should know about search (2017)
#72Google does have an UX bug in its search/map product.
Let's say I google for "kuka deutschland". In my case, the first result is a link to KUKA, with sublinks to different sections of their website.
Next there's a map with A-, B-, C-markers, and below them fields with A: KUKA Deutschland GmbH [other info, website, route] B: KUKA Systems GmbH [...] and so on.
If I now click on A: KUKA Deutschland GmbH or on the map, then the map opens completely, with a left sidebar containing more related places, a popup with the currently selected item open which contains plenty-full information about the marker on the map.
The issue is that this is not a Google Maps map, it is not hosted under maps.google.com, but any normal person would expect to be able to interact with this map as if it were a normal map: have a button for satellite imagery, 3d-view and all of this, the ability have the normal Google Maps sidebar at my disposal. But this does no exists.
The worst thing about this view is that there is no link to Google Maps which would open that same view in Google Maps.
Re: What software engineers should know about search (2017)
#73Biggest 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's such a bad practice to let the users leave for whatever reason.
Sites are putting every effort not to leave their site and this is anti pattern.
Also I'd think the site doesn't even enough budget to put a search function and the business or the manager has some problem.
Re: What software engineers should know about search (2017)
#74Take clothing search, "blue t-shirt", what is the search space? Most engineers would naively shove the name/description into Elastic Search and then be surprised when it doesn't work. Why? Because most product descriptions are not as explicit as "This is a blue t-shirt" (see also YouTube video descriptions).
What we actually found was that by searching categories (where blue t-shirts is roughly a category), and then just filtering clothing items to that category, search worked far better. Understanding what terms people used (categories/colours) and what was actually in the data and what data models we should be searching (not products!), we built a far more effective search experience.
Re: What software engineers should know about search (2017)
#75Re: What software engineers should know about search (2017)
#76The biggest thing I've learned about search is to be very precise about WHAT is being searched. In my experience most people are very loose with this, but by being really precise you can skip past a lot of bad search experiences. Take clothing search, "blue t-shirt", what is the search space? Most engineers would naively shove the name/description into Elastic Search and then be surprised when it doesn't work. Why? B…
Re: What software engineers should know about search (2017)
#77Earlier 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.
I think this very much depends on what kind of service your site provides, but in many cases I think we can argue that the Google fallback is good UX. It means the user doesn't need to figure out and navigate a new/different search system for each service. If the GP's right and people really do just drop out and use Google every time (even though the target site has a search function), then I think it's hard to argue…
You lose trust in the search function very quickly, if you gain it at all. Whether yours is effective and helpful does not only depend on the search implementation but also on whether your site actually has the information (that it should or is assumed to have) to be effective and helpful. A lot of factors come into this, representation, content, design both for search results and for the actual target pages.
Now if you have the trust, are helpful and effective, then the UX is drastically improved.
For one, search engine results have been degrading. There is _so_much_spam_ out there. Countless SEO sites that just crawl the web and generate crap output to show you ads, some seem to be handwritten as well. It is increasingly probable to get top results that are just presenting "stolen" content in some form or another. You get low effort blog-like posts that are just restating things they read in a discussion that is actually not the primary source, but a generated site, which is referring to the actual information somewhere else.
Secondly if you have in-built, decent search people will use it and they will be happy for it, because you'll be presenting them much better suggestions in a better way and you'll do it faster.
Think of some of the _best_ sites like MDN. Sure, you might enter the site via DDG or Google (in the former case you'll be searching directly like so: "!mdn [search_term]"). But when you're on the site you'll be happily navigating it via links and search, because it's just a very good site.
Other examples of this are: wikipedia, tailwind, clojuredocs, reactjs, hn.algolia...
They all have rich content, good search, useful links. It's a very effective combination.
Re: What software engineers should know about search (2017)
#78When building an inexpensive app, the client will often ask for search. The UI designer will oblige and add a search bar to the app. Neither will give much thought to what the search will actually do except to say "make it work like Google".
Re: What software engineers should know about search (2017)
#79Google ruined search, by which I mean they made it so good that everyone expects search to be as good as Google. When building an inexpensive app, the client will often ask for search. The UI designer will oblige and add a search bar to the app. Neither will give much thought to what the search will actually do except to say "make it work like Google".
Re: What software engineers should know about search (2017)
#80Earlier quoted context omitted.
Typesense has been great for us so far. Easy to set up, works great with the simple queries that we need. Lots of great additional functionality on top of search, for example security, with scoped API keys and the likes that we're looking forward to making use of.
Thank you for your kind words. We are just getting started :)