5 ms·

> and if someone is searching on your site excessively maybe there's a problem with your UX (unless you're a search engine or repository of information). I don

> and if someone is searching on your site excessively maybe there's a problem with your UX (unless you're a search engine or repository of information). I don't understand this comment. Why would you search something that *isn't*, in some senses, a repository of information? I would say almost every website needs to have search in some sense, and it's *because* sites function as a repository of information that they need this search. Think about e.g. Stripe's documentation, or Github's repository / code search. HN is also another great example—I search for stories or comments all the time to try and remember something I read about recently or heard about last week, but couldn't quite remember. I'm hard-pressed to think of a web site I use regularly that *shouldn't* have full-text search, if I'm being honest.

hardwaresofton 4y ago
I don't consider use cases like documentation a "repository" of information, but maybe this is just me not phrasing it badly. In the literal sense sure it is, but when I think of a "repository of information" I think of wikipedia, amazon search items, etc. The scale of a documentation site is a very different problem -- you can brute force it in ways that you can't at larger scales. I agree that HN would be a case of the large repository, but even then what most people want out of HN search is pretty simple/basic keyword search. I think a decent non-frustrating HN search feature could be very basic and get by without most of the advanced features/rabbit holes available in search. Basically I think most apps fall into the lighter search use case -- command palettes, search inside of apps with a small scale of information, etc. My comment wasn't that apps shouldn't have full text search -- it was that most that have full text search don't need complex full text search with all the bells and whistles that lucene and other serious search engines provide. These up-and-comers might be enough for a bunch of apps for which search is not the main feature.
- nightpool 4y ago
  I think the sibling comment on this thread kind of disproves this to some extent. Sure, some simple in-memory search library might be good enough for a command palette or for "apps", but the fact that even tiny docs and "marketing" sites that try to implement site search are almost always outdone by google "site:example.com query" really goes to show how much value a full stemming / synonym clustering / syntax normalizing search engine can bring.
TylerE 4y ago
Most site searches are basically unusable. Either it isn't very good, is painfully slow, or both. Just gooling site:foo.com/baz <query> almost always produces better results.

hardwaresofton 4y ago

I don't consider use cases like documentation a "repository" of information, but maybe this is just me not phrasing it badly. In the literal sense sure it is, but when I think of a "repository of information" I think of wikipedia, amazon search items, etc. The scale of a documentation site is a very different problem -- you can brute force it in ways that you can't at larger scales. I agree that HN would be a case of the large repository, but even then what most people want out of HN search is pretty simple/basic keyword search. I think a decent non-frustrating HN search feature could be very basic and get by without most of the advanced features/rabbit holes available in search. Basically I think most apps fall into the lighter search use case -- command palettes, search inside of apps with a small scale of information, etc. My comment wasn't that apps shouldn't have full text search -- it was that most that have full text search don't need complex full text search with all the bells and whistles that lucene and other serious search engines provide. These up-and-comers might be enough for a bunch of apps for which search is not the main feature.

nightpool 4y ago
I think the sibling comment on this thread kind of disproves this to some extent. Sure, some simple in-memory search library might be good enough for a command palette or for "apps", but the fact that even tiny docs and "marketing" sites that try to implement site search are almost always outdone by google "site:example.com query" really goes to show how much value a full stemming / synonym clustering / syntax normalizing search engine can bring.

TylerE 4y ago

Most site searches are basically unusable. Either it isn't very good, is painfully slow, or both. Just gooling site:foo.com/baz <query> almost always produces better results.