4

I saw a question on Main which looked like a duplicate, so I tried to search for the previous question I remembered. To do this, I entered oven temperature sugar into the search box at the top-right of the page. The search automatically taggified all of my terms and took me to https://cooking.stackexchange.com/questions/tagged/oven+sugar+temperature , which has no results.

This seems to me to be a clear violation of the UX principle of least surprise. Not only is it rewriting my search in a way which makes it useless, but it takes me to a page which isn't a normal search results page and hence doesn't have the advanced search tips that make it possible to actually get results by searching for "oven" "temperature" "sugar".

I found the page I was looking for via Google before coming back and attempting various things in the search box. The fact that I felt it necessary to use an external search is a failing of this site.

I don't expect a request for a major overhaul (like making the search box always search and simply weighting tags much higher than occurrences in text) to get much traction, hence this reduced proposal:

When a search which doesn't use the advanced search [tag] markup would be autoconverted to a tag search which has no results, can it instead be left unconverted?

1 Answer 1

2

I agree that the current behaviour violates a basic usability principle, i.e. never modify a user's input to something that can actually produce worse results than his original input.

Personally, though, I don't see the request gaining much traction, because it involves doing multiple searches on the back-end. Speaking as someone who has been working on a search-based product for several months, "cascading searches" are something that raises alarm bells, especially because they have an unpleasant tendency to morph into 3- or 4-level searches over time.

I can think of two behaviours that would be preferable for both users and developers:

  1. Search by tag and keyword unless the [tag] syntax is explicitly used, and sort results by the number of matching tags. Lucene is capable of doing this in a single search. It really isn't that hard, you can do it by boosting or facets or both.

  2. The current behaviour auto-promotes keywords to tags only if they're above a certain frequency, which guarantees reasonable results when the entire search is just one tag, like [cheese] or [food-safety]. Extend this to not auto-promote if it would result in multiple tags (conjunction), because this is what has the potential to be worse than the original query. It won't produce as many results as #1, but its advantage is that it requires no changes whatsoever to the search algorithm, just the query comprehension.

I know I'm being a bit technical here but search is a hard problem and people who haven't actually worked in that area can tend to have strange ideas about what's possible or practical.

1
  • I understand your worry, although I think that I kept the request tight enough that it wouldn't actually make performance worse because the cascaded search is one that the user will do from the front-end if they can work out how. Upvoting because either of your suggestions would also solve the problem. Oct 23, 2013 at 10:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .