I think this article is setting up a pretty high bar for search. For small datasets, you can very well just add an automatically generated "description" column in your database, and then do a SQL LIKE query: it's a simple substring matching.
It's by no means smart, doesn't handle misspellings or anything, but it works reasonably fast and predictably. This is basically how almost every desktop app with a search bar works. This is how word processors and editors work when users search within the document.
When was the last time your average (non programmer) user expected search to behave like CTRL+F?
I'm not sure you're doing your users a service implementing search with SQL LIKE. I think it's probably better to divert them to Google, use a full text SQL index, use a managed search service like Algolia, or not do search. Otherwise, you're just promising them functionality that is almost always going to fail them.
Why is that?
Users have been pretty heavily conditioned to use search in specific ways that are different than finding a text in documents. They have a broad range of needs that a wildcard 'find in files' search doesn't really support. And most frustratingly users expect a single search bar to support them all. Some needs are known item - finding an item by name (like contacts on your phone). Other needs are informational - finding a fact or idea by expressing requirements. Sometimes its about getting a survey of information about a topic, or sometimes its about compare-and-contrasting different products.
The primitives available in SQL LIKE don't really lend themselves to solving any of these problems. There's no concept of relevance ranking, there's exact, direct, case-insensitive search, not to mention it's going to do a full table scan on every search...
(You'd have my ear more if we were talking about full text search features in SQL.)
"I think this article is setting up a pretty high bar for search."
All of the "Falsehoods Programmers Believe About ..." genre articles do.
The way to use them is not to view them as an immutable checklist that all programs must conform to or else they are forever and always nothing but total crap, but as a list of things professionals should at least have some clue about, and that you should generally make deliberate decisions about, rather than accidental ones. Are you a pizza place with ten locations in a single state? Then by all means, take US-only addresses, and hard-code the time zone on your web site, and probably just ignore search, and expect first & last names or whatever. Just do it as a deliberate tradeoff, with an understanding of what it may take to undo it later.
Are you working in an international company serving customers all around the world, with the need to provide some search functionality? Well, you probably need to be able to fulfill a lot more of the relevant lists.
I actually went to town on the features for the search on an internal project... And all anyone ever uses is pulling up tickets by number or by client or technician names.
"It has x, y, z features that the Google search has..."
"I didn't know Google did that."
There's even an explanatory popup with how to do anything fancier than a straight text search.... But they just really use numbers and names. Advanced feature usage is once in a blue moon.
At least they're happy with the search function, but lesson learned - for a lot of usages, people aren't expecting much more than a simple text match.
This is more or less what I recently told a client who wanted search on a utility I built him. He wanted rich search, like using quote marks and database operators, but his budget for the whole project was about $1500. I told him that I could build the entire project, plus simple searches on the description fields with wildcard matching. Or I could give him fully featured search by using third party software, but for triple the budget. Explaining it that way got the message across, and it turned out that simple search was enough.
Sorry but that’s going to result in a pretty horrible search experience. If you are putting a search bar on your page and that’s your search backend - you might as well skip search entirely because it’s only going to cause you and your customers pain.
The difference with find on page is that it’s obvious and transparent what is being searched and the expectations of the interface. Trust me when I say that a search bar to a layperson on your site is them thinking “oooh I can google”
I appreciate your experience, but you may have also noticed that there's a number of sibling comments from developers whose customers definitely did want a Ctrl-F type search, and not some near-AI match-what-I-really-meant thing. I've certainly worked in vertical markets where that's what the customer actually wanted.
I think it more goes back to the real most important lesson of programming - you must know your customer and their needs first. If a google-like experience is what your customers demand, then you better understand all of that stuff and build it. If they just want to search for names and ticket numbers, any more advanced intelligence is a waste of time that could have been used to build other features that the customer actually wants.
I'm not a professional UI/UX designer but here's a guess. It should not be the prominent thing on your page. Prominent search bars like the one on Google's home page convey to users the idea that this is the primary way to navigate and use this website, and therefore be loaded with higher expectations. So don't make the search bar look prominent.
Next, make it context-specific. Don't put a search bar at the top of the page suggesting that this bar can search for everything. If you use a simple implementation like a SQL LIKE to implement search, put the search bar right next to the thing that is displaying results from the table. Make it look like it's filtering the table.
Finally, label the search bar using words like "Keywords," which also suggest to users that they should be typing keywords instead of a more complicated natural language phrase.
Those are interesting ideas thanks for the thoughts. FWIW I’ve seen users try to use even non-prominent search boxes like those as if they can do more than SQL LIKE. Most users have no idea how any of this works and just want answers.
Mostly I think this whole thread demonstrates the point of the original article, but I appreciate your response.
Yeah, I rolled my eyes after opening the article, it's a load of tosh depending on what your need is.
I have written search engines for a couple of sites that combined serve about a million uniques a year.
It's not great, but it's not terrible, and took less than a week. People search for places and names, so it's quite easy to match them.
We looked at one of the open source engines, but it was a lot of effort for not a lot of gain, and essentially adds another significant moving part to go wrong.
agreed, simple and effective. but also- most databases have more advanced full-text search functions, for example in about an extra hour of work you can easily set up simple boolean searches using mysql's MATCH against a full-text index over multiple columns.
It's by no means smart, doesn't handle misspellings or anything, but it works reasonably fast and predictably. This is basically how almost every desktop app with a search bar works. This is how word processors and editors work when users search within the document.