667246 - multiple search fields are confusing (quick filter/QFB and global search)

Status: RESOLVED WONTFIX

(Thunderbird :: Search, defect)

Description

[Asa Dotzler [:asa]]

The primary search field and the Quick Filter search are confusing. Their functions overlap but some things can only be done on one of them. This needs to be rethought. I think that ideally the QuickFilter toolbar with it's toggles and search field would be the only search in the primary UI.

Comment 1

[David :Bienvenu]

we tried having a single search field; it was more confusing, and less useful. But two search fields are confusing as well, I'll grant you.

Comment 2

[Blake Winton (:bwinton) (:☕️)]

It's not really two search fields as much as a search field and a filter field…

But yeah, I've got longer-term plans to try to unify them again in a less confusing way.

Comment 3

[Wayne Mery (:wsmwk)]

in the status quo, it would help some if they were more visually distinct. one bit they share the same spyglass icon, which seems silly. but even changing them visually may not be sufficient. 

reunificiation is also echoed in Bug 526221 - Pressing Enter after quicksearch filter terms should do global search (combine the best of quick filters and "Search all messages"). But beware unification, especially as long as gloda yields sometimes incomplete results. And also that qfb seems well suited to be tab-specific. (although there are plenty of users that also don't use tabs)

So it would be good to see bwinton's ideas posted, i.e. long before any implementation decision is made.

xref: bug 628075 - Search all messages oversees mails that quick filter can see
Thomas may be aware of others

footnote: not the right model IMO (and perhaps should be wontfix), but for completeness see Bug 570815 - (qfwidget) Make Quickfilter optionally available as simple searchbox widget+stickypin

Comment 4

[Jim Porter (:squib)]

(In reply to comment #3)
> in the status quo, it would help some if they were more visually distinct.
> one bit they share the same spyglass icon, which seems silly. but even
> changing them visually may not be sufficient. 

Changing the QFB's spyglass icon to a funnel would certainly be a start...

Comment 5

[Blake Winton (:bwinton) (:☕️)]

I think, for the long term, moving to something like http://breakingtheegg.tumblr.com/post/6289948309/i-think-it-would-be-awfully-cool-if-we-did along with the "hit enter to search globally" would let us unify the filter and search in a reasonable manner.  The other thing I noticed is that the global search opens up a new tab, so perhaps the winning move is to make it easy to open up a search tab, and have the user perform their searches from there.  In that case there would be no search box on the 3-pane, only one in the search tab.

But those are all longer term plans.  In the short term, changing the spyclass to a funnel (in both the field and on the tab) would help a little.  And I'm definitely open to further suggestions on how to make them more distinct.

Comment 6

[Wayne Mery (:wsmwk)]

sounds good, as long as qfb remains "full featured". dumbing it down is potentially bad because 
a) there are people who use filters more than gloda for various reasons (perhaps a subject to be explored), and 
b) there are lots (unquantifiable) who turn off gloda.

Comment 7

[Wayne Mery (:wsmwk)]

per IRC, bug 526221 might help, but is not the only solution (or may not be one at all).  so, there are slightly parallel tracks here.

it seems like some ux principal applies here, so I pick ux-minimalism, but I'm nto sure if it the only or most appropriate one.

Comment 8

[rsx11m]

> (comment #3) not the right model IMO (and perhaps should be wontfix), but for
> completeness see Bug 570815 - (qfwidget) Make Quickfilter optionally
> available as simple searchbox widget+stickypin

Could you expand on what you consider wrong with the approach suggested there and presented in a XUL demo versus the other discussed alternatives?

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to comment #8)
> > (comment #3) not the right model IMO (and perhaps should be wontfix), but for
> > completeness see Bug 570815 - (qfwidget) Make Quickfilter optionally
> > available as simple searchbox widget+stickypin
> 
> Could you expand on what you consider wrong with the approach suggested
> there and presented in a XUL demo versus the other discussed alternatives?

Current fx won't render bug 570815 xuls ("Remote XUL - This page uses an unsupported technology that is no longer available by default in Firefox.") and I'm headed on long vacation, so it may be some days before I post a coherent response. (bug 570815 is quite long)

my I statement is partly about bug 570815 standalone (I'm am undecided if like attachment 459049 [details]), and partly about my greater concern is using just one search field. For me, 9<something>% of people would have to be made happy for reunification to be viable. And I'm all for testing possible solutions as an add-on, but sadly I am not optimistic, given that qfb wasn't public until really late in development cycle and gloda version 1 UI. 

But hopefully there is a genius solution waiting to be found that will satisfy a wide range  of use cases.

To list a few of my concerns :

a) version 1 of gloda UI which gave us one field left a bad taste - it was bold, gutsy, but bad in practice, and perhaps more disturbing is the very log beta period did not expose how bad (were people not vocal enough??)
b) two fields feels like I have more control over what I do, i.e. the precision of the results - even if I do have to tax a couple grey cells to chose which field to use - filter or gloda
c) to quote what I posted on IRC "many times i want gloda, and making me first do a filter seems obstructionist"
d) many people don't use gloda at all, or don't use it often because some use cases it's harder to narrow the results to what's wanted.
e) lastly, important core UI such as this needs to be tested hard, with the right population of people. And i'm not sure our typical beta users adequately fit the bill.

I do however acknowledge -
- gloda is great (even can be greater with improvements)
- UI with two "search" fields seems like overkill, and makes for busier UI - which makes us look visually goofy AND come off as not being very innovative

Comment 10

[Wayne Mery (:wsmwk)]

(In reply to comment #9)
> - gloda is great (even can be greater with improvements)

OT, and not a great representation of issues, is http://getsatisfaction.com/mozilla_messaging/tags/search?sort=most_me_toos&style=topics

Comment 11

[Thomas D. (:thomas8)]

(In reply to comment #9)
> (In reply to comment #8)
> Current fx won't render bug 570815 xuls ("Remote XUL - This page uses an
> unsupported technology that is no longer available by default in Firefox.")

to allow local file://xul in current FF, goto about:config and set
dom.allow_XUL_XBL_for_file -> true

> my I statement is partly about bug 570815 standalone (I'm am undecided if
> like attachment 459049 [details]),

attachment 459049 [details] is not very representative of bug 570815's most favoured solutions, which can be found in my XUL demos, esp. the last one.

> and partly about my greater concern is
> using just one search field. For me, 9<something>% of people would have to
> be made happy for reunification to be viable. And I'm all for testing
> possible solutions as an add-on, but sadly I am not optimistic, given that
> qfb wasn't public until really late in development cycle and gloda version 1
> UI. 
>
> But hopefully there is a genius solution waiting to be found that will
> satisfy a wide range  of use cases.

> To list a few of my concerns :
> 
> a) version 1 of gloda UI which gave us one field left a bad taste - it was
> bold, gutsy, but bad in practice, and perhaps more disturbing is the very
> log beta period did not expose how bad (were people not vocal enough??)

yes, the right way of connecting the two searches is crucial.
V1 of combined gloda-qfb UI was too gloda-centric. Imo we need to be more qfb-centric as a default, with gloda-global search coming in when needed or on request (Ctrl+Enter).

> b) two fields feels like I have more control over what I do, i.e. the
> precision of the results - even if I do have to tax a couple grey cells to
> chose which field to use - filter or gloda

somewhat true, but not solving the confusion of two fields

> c) to quote what I posted on IRC "many times i want gloda, and making me
> first do a filter seems obstructionist"

no, even in combined UI solutions we could have immediate gloda-global search, eg. via Ctrl+Enter, or respective dynamic button.

> d) many people don't use gloda at all, or don't use it often because some
> use cases it's harder to narrow the results to what's wanted.

+1
 
> I do however acknowledge -
> - gloda is great (even can be greater with improvements)

+1

> - UI with two "search" fields seems like overkill, and makes for busier UI -
> which makes us look visually goofy AND come off as not being very innovative

+1

Comment 12

[Thomas D. (:thomas8)]

(In reply to comment #11)
> (In reply to comment #9)
> > (In reply to comment #8)
> > Current fx won't render bug 570815 xuls ("Remote XUL - This page uses an
> > unsupported technology that is no longer available by default in Firefox.")
> 
> to allow local file://xul in current FF, goto about:config and set
> dom.allow_XUL_XBL_for_file -> true

To allow the xul demos from bugzilla's attachments directly, you need
https://addons.mozilla.org/en-US/firefox/addon/remote-xul-manager/
then add https://bugzilla.mozilla.org/ to that xul-whitelist.

Comment 13

[WADA:World Anti-bad-Duping Agency]

(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #2)
> It's not really two search fields as much as a search field and a filter field…

Currently, "two fields in Quick Filter Bar" is externally two Filter fields in single "Quick Filter Bar" box.
  Left one  = Quick Filter: Unread, ..., Has attachment
  Right One = Filter these messages ...
              after type text, Filter messages by: Sender, ..., Body
I think "change terms (back) to Filter and Search" is a simple short/mid term solution for less confusion by users.
  Filter these messages => Search these messages
                          (search messages after filtering by Quick Filter)
  Filter messages by: => Search messages for:
IIRC, text search box at there was called "Quick Search" at some places.
(primary search=Search in context menu of folder, or Edit/Find/Search messages)
And, "magnifying glass" icon is usually used for "Search" instead of "Filter" in many software. So, calling the text box "Search" is better for users. 
As Quick Filter is placed at left side, current main concept is "filter by Quick Filter first, then search by Quick Search", although there is no problem in "search by Quick Search first, then filter by Quick Filter".

"Quick Filter Bar => Quick Filter/Search Bar(or Quick Search/Filter Bar)" may be needed to avoid complaints. 

Icon of "Toggle the quick filter bar" button may be better changed.
However, if position of Quick Filter and Quick Search is swapped, I think there is no need to change the icon, as far as change of name to "Quick Filter/Search Bar" is done, because left one is primary one and right one is secondary one in many cases.
If position is swapped, "search by Quick Search first, then filter by Quick Filter" becomes ordinal concept of "Quick Filter/Search Bar".
If position is swapped, "Keep this search when switching folder" for Quick Search, Quick Search version of "Keep filter applied when switching folder" of Quick Filter, may be better implemented for user's convenience in mail/folder house keeping work.
If position is swapped, string of "Search these messages" can be changed to "Search messages quickly". "Quick Filter: => Quick Filter on found messages:" is needed?

Comment 14

[Mihovil Stanic [:Mikeyy - L10n HR]]

I'm all for 1 search box, just leave filtering since it's one of best TB features.

Comment 15

[Wayne Mery (:wsmwk)]

been using https://addons.mozilla.org/en-US/thunderbird/addon/unified-search-187593/ mentioned in bug 570815 - looks promising but unfortunately the results are mixed

Comment 16

[Alessandro Castellani [:aleca]]

Now the QFB is below the message header and more contextual, creating a better separation to remove the confusion of 2 search bar.
We're also considering hiding the QFB by default, but nonetheless we're not merging these 2 fields together since they have very distinct purpose and context.