540257 - Make it more obvious global search/quick search widget has switchable modes

Status: RESOLVED INVALID

(Thunderbird :: Search, defect)

Description

[Andrew Sutherland [:asuth] (he/him)]

A surprising number of people seem to think that Thunderbird 3.0 has eliminated quick search entirely.  We should probably consider at least cribbing the styling from Firefox's search box; the gray background and larger down-arrow with segmented line (at least on linux) make it look more like a combo-box.

(This could be a dupe, but I checked everything in Thunderbird/Search and nothing popped out at me.)

There are behavioral things we could do to reduce the annoying need to constantly switch modes too, but we should probably improve the UX styling no matter what.  (For example, I think it has been mentioned that we could just trigger quick-search behavior if the user doesn't hit enter or the like.  If we do this after all the autocompleter helpers have completed we can do this without creating contention that slows the return of the autocompletion results.  Although we will have the new problem of people being frustrated that the autocompletion results are occluding their filtered results.)

Comment 1

[Wayne Mery (:wsmwk)]

Yes, yes, yes! this is a big pain point noted in every forum. (cc roland to supply gsfn references)

I'd go beyond wanting this for 3.1, to say this needs to be driven into 3.0.<whatever comes before flipping v2 updates> - I think even in v2 not enough people know they can alter the search method in that field

thinking sideways, we also need a vehicle to deliver a solution for Bug 500747 -  need hint for short cut key in quick search input field - emptytext of "<selection> (ctrl-k)"

Comment 2

[Thomas D. (:thomas8)]

Yes, yes, yes!

(In reply to comment #0)
> There are behavioral things we could do to reduce the annoying need to
> constantly switch modes too, but we should probably improve the UX styling no
> matter what.  (For example, I think it has been mentioned that we could just
> trigger quick-search behavior if the user doesn't hit enter or the like.

e.g. see Gerv's proposal here:
http://groups.google.com/group/mozilla.dev.apps.thunderbird/browse_thread/thread/cb2d7c5ec0379fe5/

Bug 526221 - Pressing Enter after quicksearch filter terms should do global search (combine the best of quick filters and "Search all messages")

> Although we will have the new problem of people being frustrated that
> the autocompletion results are occluding their filtered results.)

Bug 516543 - [faceted search] Quick Search Box: For quickfilter modes, show "search everywhere" autocomplete suggestions when entering search terms (always offer "search all messages")

Comment 3

[Andreas Nilsson (:andreasn)]

Attachment: more obvious dropdown patch

Only tested on Linux so far, I can test it on Vista, but my Mac is currently on repair. :(

Comment 4

[David Ascher (:davida)]

For 3.1 I kinda wonder whether we want to rethink this -- I find that toggling between what i 'glogal search' and what i'd call 'filter current view' is a fairly frequent task, and the merged UI doesn't work that great in practice.

I think we want to move beyond just a css change, and something more obvious that gerv's proposal.  Not sure what that is.

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to comment #4)
> For 3.1 I kinda wonder whether we want to rethink this -- I find that toggling
> between what i 'glogal search' and what i'd call 'filter current view' is a
> fairly frequent task, and the merged UI doesn't work that great in practice.
> 
> I think we want to move beyond just a css change, and something more obvious
> that gerv's proposal.  Not sure what that is.

I agree, it has been annoying. This would be mentioned in a bug where I advocated for two widgets.  The discussion there may be useful but haven't found those bug comments yet.

also a pain partly because it's not quick via keyboard (no, no, no mouse) to switch even between quick search filters :( 
ctrl-k
F4
hit S 5 times to get to Subject
smack forehad

Comment 6

[Wayne Mery (:wsmwk)]

(In reply to comment #5)
> I agree, it has been annoying. This would be mentioned in a bug where I
> advocated for two widgets.  The discussion there may be useful but haven't
> found those bug comments yet.

bugger, I have totally failed to find any email/bugmail comments of mine referring to wanting both search widgets in the toolbar using both bugzilla or gloda search. (I don't think it was on newsgroup or private mail)

Andrew, Bryan, do you recall this?  In the time frame when search toolbar items were being refined, but probably before being reduced to one widget.  I ran Thunderbird for several weeks with both gloda and quick widgets on my toolbar before the two were irrevocably merged.  It worked very nicely.  

At the time I didn't see much point in pressing the issue because I agreed with the theory that having both can be potentially confusing for users.

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

I don't think we want this bug to turn into a re-hash of the existing discussions that have already taken place on the UX for quick/global search, especially since my raising of the point was an aside about the greater issue that should be dealt with elsewhere.  We mainly know where to look for them, and I know I at least have read and digested most of the points already.  I will take the action of trying to bring some action/closure to the issue which may just mean making it someone else's problem to work.  Look for a bug and/or MDAT discussion in the future.

(In reply to comment #4)
> For 3.1 I kinda wonder whether we want to rethink this -- I find that toggling
> between what i 'glogal search' and what i'd call 'filter current view' is a
> fairly frequent task, and the merged UI doesn't work that great in practice.

Unless we do away with the search widget modality entirely (which might not be a bad idea), I think it's still a useful change.

Comment 8

[Wayne Mery (:wsmwk)]

I'm not suggesting rehash, but it is a problem for some of us. I'd be happy with a toolbar that showed both widgets. regardless, workflow issues should probably be a different bug - it just seemed timely to mention here.

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

I think this will be fixed by 545955, so marking it as depending on that one.

Comment 10

[Dan Mosedale (:dmosedale, :dmose)]

Bug 545955 is already on the blocker list.  Having this there too just makes the list harder to manage.

Comment 11

[Andrew Sutherland [:asuth] (he/him)]

This is mooted by the landing of bug 545955.