541353 - [faceted search] need more information when "No messages match your search" if search terms include non-indexed data

Status: RESOLVED DUPLICATE of bug 523183

(Thunderbird :: Search, defect)

Description

[Wayne Mery (:wsmwk)]

[faceted search] need more information when "No messages match your search" if search terms include non-indexed data

two issues - maybe deserves two bugs.  might even be dups.

1. we should indicate that unindexed terms like "a" and "&" will cause a search to fail, so the user gets trained 
2. is it possible to indicate which search terms received no hits, or list the number of hits for each search term?

I know there was discussion of how to handle #1 in some prior bug, which ultimately resolved to us displaying "No messages match your search". Davida or asuth may recall the bug# or essence of the discussion.

Comment 1

[Thomas D. (:thomas8)]

What's worse, even when you search for part of a word that IS indexed, we return no results and no feedback at all what else you could try, and no obvious way of broadening the search (by using searchword*). This will confuse the user a lot because in the same search box, quick search filters work completely different (*searchword*). I think there's a bug about this, asking to change default searches to *searchword* or searchword* at least. Implications for this bug:

STR

1 search all messages for "bug"

Actual
--> we don't return "bugzilla" (but we do return bugzilla from the same search box when you use quick filters)

Expected
a) Instead of blank result, inform user that he can broaden the search for partial matches using "bug*"
b) in addition (optionally) provide a one-click way of broadening the search, e.g. a button with "Find partial matches", or:
c) alternatively, a dropdown that offers alternative search patterns similar to autocomplete, with actual search words filled in:

              [search word       |v] [Search again]
              |search* AND word*   |
              |*search* AND *word* |
              |search* OR word*    |
              |*search* OR *word*  |

Generally speaking, we lack intuitive ways of modyfying search terms right from the first results page.

Comment 2

[Wayne Mery (:wsmwk)]

(In reply to comment #1)
> What's worse, even when you search for part of a word that IS indexed, we
> return no results and no feedback at all what else you could try, and no
> obvious way of broadening the search (by using searchword*). 

right. that's different bug(s)

In this bug, I'm interested in what you suggest as "a)"
1. knowing whether I was anywhere near close to finding anything, 
2. have a hint as to what to change to get better results on the next go round.

your "b)" is hits part of the original design, but for v3.0 ultimately was simplified to "no results" ... for reasons I don't clearly remember, but iirc had to do with not having a model that would work for all cases without confusing the crap out of the user.

Comment 3

[Bryan Clark (DevTools PM) [:clarkbw]]

I feel like this is a dupe but I can't find it.  Another one was that we were going to have something on the page when you don't have gloda turned on.

Comment 4

[Thomas D. (:thomas8)]

similar to bug 523183