At what point does search quality degrade to the point where is becomes a bug?

A bug is when actual behavior does not match stated or intended behavior. If the search bears little connection to what was searched for, then it is a bug, as far as the user is concerned.

Or maybe you mean to say we should reserve the word bug for deviations that are unintentional?

▲

remus a day ago | parent | next [-]

For me the idea that poor quality search results are a bug muddies the idea of what a bug is. It's like saying the colour of the paint in my living room is buggy because I don't like it. It might be an ugly colour that I don't like, but it is what it is. A bug would be if the colour doesn't match what was shown on the tin.

> If the search bears little connection to what was searched for, then it is a bug, as far as the user is concerned.

A bad product perhaps, but not a bug.

▲

10 hours ago | parent | next [-]

[deleted]

▲

pixl97 11 hours ago | parent | prev | next [-]

That's because as computer people we're very invested in the idea of bugs, while your users are not.

In products your users are stuck with it doesn't matter much, they'll have to suffer with what they think are bugs.

In products that users can switch easily, you can get dropped for a product that you would consider crappier if the user believes it's less 'buggy'.

▲

prmph 17 hours ago | parent | prev [-]

So if I search for A, and I get results for B instead (where B has only the slightest connection to A), it is not a bug?

What about if B has no connection to A whatsoever? Still not a bug? If it is not, then we may have discovered a software domain (the first for me I should say) where bugs are not possible. Should a be a nice market to launch products for, then.

	▲	remus 10 hours ago \| parent [-]
		> So if I search for A, and I get results for B instead (where B has only the slightest connection to A), it is not a bug? It depends. There could be a bug in the system like query = query.replace(A,B), or it could be that there are no good results for A. Returning nonsense results is a bad design, but not necessarily a bug. I guess my underlying point is that bugs are about software not conforming to some specified behaviour, and trying to specify behaviour like "i should type in a search and get great results" is too loose of a spec to be meaningful so we should avoid saying things which don't meet that criteria are bugs. To use a concrete example, perhaps the set of search results returned for a query look useless to you but are actually useful for someone else. Compare that with something like a calculator app where part of the spec is "Must handle integer addition with for inputs i,j where -10,000 <= i <= 10,000 and -10,000 <= j <= 10,000". Then if in your calculator you do 1+1 and get 3, then that is clearly a bug per the spec. Bugs vs. bad design is a useful distinction to make imo.

▲

gavinsyancey a day ago | parent | prev | next [-]

The trouble is, there are three different "versions" of "the search didn't work," only one of which I would say is definitely a bug:

- The thing the user searched for doesn't exist, so it wasn't found. This is not a bug.

- The user did a good job of searching, using relevant keywords etc, but the relevant thing (which exists) didn't come up. This is a bug.

- "Search didn't read my mind" -- if search is a core competency this is a bug, but otherwise I would consider it a deficiency or a missing feature.

▲

chrisjj 17 hours ago | parent | prev [-]

> At what point does search quality degrade to the point where is becomes a bug?

It depends entirely on the commitment made by the service, so e.g. my desktop file search program results has bugs whereas Google's has none.