717261 - Move Gloda search input into tab toolbar to reduce search confusion

Status: RESOLVED WONTFIX

(Thunderbird :: Mail Window Front End, defect)

Description

[Mike Conley (:mconley) (:⚙️)]

Attachment: Placement proposal

As part of our ongoing effort to ease the confusion of the Gloda search input and the Quick Filter, Blake and I were discussing moving the Gloda search input into the tab toolbar.

It'd look a bit like the attachment - though we'd likely want to make it a bit wider (to match the QFB which would be below it).

Comment 1

[Mike Conley (:mconley) (:⚙️)]

CC'ing a few people who might have input on this.

I'm CC'ing squib in particular, because I seem to recall that he had objections to this idea in IRC a few weeks back, but I don't remember exactly what they were.

Care to refresh my memory, squib? :)

Comment 2

[Jim Porter (:squib)]

I don't see how this is going to make things less confusing for users. We'll end up with the gloda box right next to the QFB toggle button, which will probably be even *more* confusing. This also won't really help much when we ultimately merge the QFB and the Gloda search, and I think we should try to minimize UI churn. When the two *are* merged, they'll pretty much have to go in the 3pane, since the QFB doesn't work in message tabs. Thus, we'll probably end up putting the new omni-search-box right back where we started with the gloda box.

While I can see some arguments for putting the gloda box in a tab-neutral area (i.e. not in the 3pane toolbar) so that you can access it from a message tab, I think this is probably a relatively rare use case (and people who really want it can do this manually anyway). I think it would be better to instead add a toolbar to the gloda tab with the search box and maybe a couple other useful buttons (e.g. "open in list").

Comment 3

[Jim Porter (:squib)]

On some level, this harkens back to asuth's experimental toolbar, which had just a "write" button and an enhanced gloda box. Both of those could reasonably be used from any tab (e.g. I'm in a message tab and decide I want to send a new email), but again, I think that this isn't very common (all the reply/forwarding functions are available in the message tab, which are the most likely actions).

You could also see this as being similar to the add-on tab in Firefox: it hides the location bar and the search bar (but adds its own search bar instead), since while you *might* want to Google search something while looking at add-ons, it's pretty rare and it's easy to get to a regular tab anyway.

Comment 4

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

(In reply to Jim Porter (:squib) from comment #2)
> I don't see how this is going to make things less confusing for users. We'll
> end up with the gloda box right next to the QFB toggle button, which will
> probably be even *more* confusing.

There's another bug to remove the QFB toggle button, which should make it less confusing.

> This also won't really help much when we
> ultimately merge the QFB and the Gloda search, and I think we should try to
> minimize UI churn.

While I normally agree with you, we're making the situation worse with tabs-on-top, and so now would be a reasonable time to attempt to fix this.

Here's what we currently have:
http://dl.dropbox.com/u/2301433/Screenshots/CurrentQFBGloda.png
Notice that the QFB toggle is beside the Gloda bar, and the Gloda bar is directly beside the QFB.  Those both seem like they're going to cause problems.

Here's the proposal:
http://dl.dropbox.com/u/2301433/Screenshots/ProposedQFBGloda.png
There's now some space between the QFB and the Gloda bar, and there isn't a third spyglass to confuse users.

(I also don't think that minimizing UI churn alone should prevent us from making changes that we feel are for the better.  We should definitely try to reduce UI churn, and you can certainly disagree that this change is for the better, but in general I believe we should be able to change the UI if we feel we have good reasons.)

> When the two *are* merged, they'll pretty much have to go
> in the 3pane, since the QFB doesn't work in message tabs. Thus, we'll
> probably end up putting the new omni-search-box right back where we started
> with the gloda box.

I disagree, since I think we'll be able to have the omni-box act as a filter on the message list, and as a global search box in other contexts.  (That may end up being too complicated, I admit, but I _think_ we can pull it off.)

> While I can see some arguments for putting the gloda box in a tab-neutral
> area (i.e. not in the 3pane toolbar) so that you can access it from a
> message tab, I think this is probably a relatively rare use case (and people
> who really want it can do this manually anyway). I think it would be better
> to instead add a toolbar to the gloda tab with the search box and maybe a
> couple other useful buttons (e.g. "open in list").

It's not just the message tab (and gloda tab), it's also the chat tab, and in the future the address book tab.

(In reply to Jim Porter (:squib) from comment #3)
> You could also see this as being similar to the add-on tab in Firefox: it
> hides the location bar and the search bar (but adds its own search bar
> instead), since while you *might* want to Google search something while
> looking at add-ons, it's pretty rare and it's easy to get to a regular tab
> anyway.

That's more compelling, but it still doesn't fix the the problem where the QFB toggle is beside the gloda bar, and the gloda bar is beside the QFB, and we have three magnifying glasses on the left of the screen.  Assuming we want to fix that, do you have any suggestions?

Thanks,
Blake.

Comment 5

[Jim Porter (:squib)]

(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #4)
> There's another bug to remove the QFB toggle button, which should make it
> less confusing.

I'm not sure how many people toggle the QFB on and off when starting/stopping to search; I know I always use it that way. It might be worth doing an informal poll at least.

> > This also won't really help much when we
> > ultimately merge the QFB and the Gloda search, and I think we should try to
> > minimize UI churn.
> 
> While I normally agree with you, we're making the situation worse with
> tabs-on-top, and so now would be a reasonable time to attempt to fix this.

I do agree that it's worse, though some of that is probably force of habit, since I'm used to thinking "the filter button is below the search box". It doesn't help that I'm switching between 9.0 and trunk on a daily basis. I do have some ideas to help with that, though (see below).

> I disagree, since I think we'll be able to have the omni-box act as a filter
> on the message list, and as a global search box in other contexts.  (That
> may end up being too complicated, I admit, but I _think_ we can pull it off.)
[snip]
> It's not just the message tab (and gloda tab), it's also the chat tab, and
> in the future the address book tab.

This gets more confusing for other tab types, though. What should the omni-box do in an addon-manager tab? A content tab? An OpenSearch tab? An address book tab? A tab added in an add-on (e.g. Lightning tabs)? For some of these, it's probably sufficient to make it run a gloda search, but the address book tab in particular would either need to make the omni-box do an address book search, or we'd be back to the same old problem of having multiple search widgets onscreen at once based on the mockups[1].

If the omni-box has too many different modes, I think we'll run into problems with ux-natural-mapping and ux-feedback. That is, how would I know if an arbitrary tab type overrides the omni-box to do a certain specialized kind of search? We could add empty-text to it to say, e.g. "Search all addresses", but then we run into essentially the same problem as Firefox before they switched to tabs-on-top: for certain tabs, the omni-box would clearly be tab-specific, but it's not positioned that way in the UI.

> (In reply to Jim Porter (:squib) from comment #3)
> > You could also see this as being similar to the add-on tab in Firefox...
[snip]
> That's more compelling, but it still doesn't fix the the problem where the
> QFB toggle is beside the gloda bar, and the gloda bar is beside the QFB, and
> we have three magnifying glasses on the left of the screen.  Assuming we
> want to fix that, do you have any suggestions?

Short version: Make the QFB icon be a funnel.

Long version: One thing we could do is to make a clear distinction between the different kinds of "searching" we have. Right now there are three (more-or-less): global search, two kinds of folder search (QFB and Ctrl-Shift-F), and message search (the find bar); I'm excluding stuff like the Advanced Address Book Search for now. Right now, these are conflated in really weird ways. Global search and the QFB use the same icon (a magnifying glass). Ctrl-Shift-F search is listed under Edit -> Find. We should fix this.

Here's my proposal: "search" means "starting from nothing, give me a list of things matching my query"; "filter" means "starting from an already-existing list, give me a sublist of things matching my query"; "find" means "starting from anything, iteratively select a series of things matching my query". Thus, global search and Ctrl-Shift-F are Searches, the QFB is a Filter, and the find command is - obviously - a Find.

In practice, this means giving the QFB a new icon and moving Ctrl-Shift-F out of the Edit -> Find menu (maybe to Tools?). I think a funnel would express the idea of filtering pretty well. It's already well-established as the filter icon (just Google Image Search "filter icon" to see how common it is), and would help distinguish the two.

The downside of this is that there's also "Message Filters" for categorizing email, but we already crossed that bridge in 3.1 when we added the "Quick Filter". We may want to consider calling message filters "Rules" a la Outlook. Still, message filters do fit the above definition of a "Filter", so it's not so bad.

[1] http://s3.amazonaws.com/data.tumblr.com/tumblr_ltl9gnCUUD1qkoea4o1_1280.png?AWSAccessKeyId=AKIAJ6IHWSU3BX3X7X3Q&Expires=1326392955&Signature=b4vMNC0IvCKqnanHUlLBzs1aM%2B8%3D

Comment 6

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

(In reply to Jim Porter (:squib) from comment #5)
> (In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #4)
> > There's another bug to remove the QFB toggle button, which should make it
> > less confusing.
> 
> I'm not sure how many people toggle the QFB on and off when
> starting/stopping to search; I know I always use it that way. It might be
> worth doing an informal poll at least.

Would you like to post this bug in mozilla.dev.apps.thunderbird and mozilla.support.thunderbird, and we can see what (some) people have to say?

> > > This also won't really help much when we
> > > ultimately merge the QFB and the Gloda search, and I think we should try to
> > > minimize UI churn.
> > While I normally agree with you, we're making the situation worse with
> > tabs-on-top, and so now would be a reasonable time to attempt to fix this.
> I do agree that it's worse, though some of that is probably force of habit,
> since I'm used to thinking "the filter button is below the search box". It
> doesn't help that I'm switching between 9.0 and trunk on a daily basis. I do
> have some ideas to help with that, though (see below).

I think it's also because the Gloda bar is between the QFB toggle and the QFB.

> > I disagree, since I think we'll be able to have the omni-box act as a filter
> > on the message list, and as a global search box in other contexts.  (That
> > may end up being too complicated, I admit, but I _think_ we can pull it off.)
> > It's not just the message tab (and gloda tab), it's also the chat tab, and
> > in the future the address book tab.
> This gets more confusing for other tab types, though. What should the
> omni-box do in an addon-manager tab? A content tab? An OpenSearch tab? An
> address book tab? A tab added in an add-on (e.g. Lightning tabs)? For some
> of these, it's probably sufficient to make it run a gloda search, but the
> address book tab in particular would either need to make the omni-box do an
> address book search, or we'd be back to the same old problem of having
> multiple search widgets onscreen at once based on the mockups[1].

Yeah.  I think it _might_ be okay if the filtering happened before the global search, but I do see your point.

> > (In reply to Jim Porter (:squib) from comment #3)
> > > You could also see this as being similar to the add-on tab in Firefox...
> [snip]
> > That's more compelling, but it still doesn't fix the the problem where the
> > QFB toggle is beside the gloda bar, and the gloda bar is beside the QFB, and
> > we have three magnifying glasses on the left of the screen.  Assuming we
> > want to fix that, do you have any suggestions?
> Short version: Make the QFB icon be a funnel.

That still leaves us with two similar fields right beside each other, and I'm not convinced a funnel is understandable by people to mean "search in the shown list"…  (Wording chosen for maximum pessimality.  ;)

> Long version: One thing we could do is to make a clear distinction between
> the different kinds of "searching" we have. Right now there are three
> (more-or-less): global search, two kinds of folder search (QFB and
> Ctrl-Shift-F), and message search (the find bar); I'm excluding stuff like
> the Advanced Address Book Search for now. Right now, these are conflated in
> really weird ways. Global search and the QFB use the same icon (a magnifying
> glass). Ctrl-Shift-F search is listed under Edit -> Find. We should fix this.

I like this, in theory.  I would like to see some examples of ways we could expose this to the user (hopefully without making it too confusing for them).  I guess, I'm not sure how easy it will be to let people use Thunderbird without having to understand that the thing they thought of as "search" is actually three different things.  Because I don't think that trying to tell them that will work out well…

> Here's my proposal: "search" means "starting from nothing, give me a list of
> things matching my query"; "filter" means "starting from an already-existing
> list, give me a sublist of things matching my query"; "find" means "starting
> from anything, iteratively select a series of things matching my query".
> Thus, global search and Ctrl-Shift-F are Searches, the QFB is a Filter, and
> the find command is - obviously - a Find.
> 
> In practice, this means giving the QFB a new icon and moving Ctrl-Shift-F
> out of the Edit -> Find menu (maybe to Tools?). I think a funnel would
> express the idea of filtering pretty well. It's already well-established as
> the filter icon (just Google Image Search "filter icon" to see how common it
> is), and would help distinguish the two.

(Using Bing's image search, I see a lot of icons, but I don't see any of them being used in applications, much less used in email applications.  I also don't see any other email clients trying to make the distinction between the three types of search.)

> The downside of this is that there's also "Message Filters" for categorizing
> email, but we already crossed that bridge in 3.1 when we added the "Quick
> Filter". We may want to consider calling message filters "Rules" a la
> Outlook. Still, message filters do fit the above definition of a "Filter",
> so it's not so bad.

Yeah, the more I think about it, the less convinced I am that trying to split the idea of searching up into three different cases is a good idea.  It seems more complicated, and less useful for the things I think people want to do.

(I think when people are searching in the 3-pane tab, they want to find a message, and so we should start by filtering the currently shown list and let them scan through it, and then if it's not there, return a new list collated from all the items we know about.  When they're searching in the address book, they probably want to find a contact.  Does that mean that we should go with a "global" search in each toolbar?  Perhaps it does…)

Thanks,
Blake.

Comment 7

[Jim Porter (:squib)]

(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #6)
> Would you like to post this bug in mozilla.dev.apps.thunderbird and
> mozilla.support.thunderbird, and we can see what (some) people have to say?

Sure.

> I think it's also [worse] because the Gloda bar is between the QFB toggle and the
> QFB.

We could move the QFB toggle to the right of the gloda box and give it a new icon. That would fix the hierarchy issues with it. Of course, this negates what I was saying about Lightning in the "remove the QFB toggle" bug, but on reflection, the QFB as a distinct thing is probably going away anyway.

> > This gets more confusing for other tab types, though. What should the
> > omni-box do in an addon-manager tab? A content tab? An OpenSearch tab? An
> > address book tab? A tab added in an add-on (e.g. Lightning tabs)? For some
> > of these, it's probably sufficient to make it run a gloda search, but the
> > address book tab in particular would either need to make the omni-box do an
> > address book search, or we'd be back to the same old problem of having
> > multiple search widgets onscreen at once based on the mockups[1].
> 
> Yeah.  I think it _might_ be okay if the filtering happened before the
> global search, but I do see your point.

That's why, for simplicity (of code and UX), I think putting the search box below the tab bar makes more sense. It makes it more obvious that they're different widgets, so there's no surprise when the search you perform in the address book is different from the search you perform in the 3pane.

> > Short version: Make the QFB icon be a funnel.
> 
> That still leaves us with two similar fields right beside each other, and
> I'm not convinced a funnel is understandable by people to mean "search in
> the shown list"…  (Wording chosen for maximum pessimality.  ;)

Well, I think people would pick up on it pretty quickly, and at least it distinguishes the two visually, but this is still just a temporary measure, since I doubt the "merge-qfb-and-gloda" bug is going to get fixed in the short term.

> > Long version: One thing we could do is to make a clear distinction between
> > the different kinds of "searching" we have. Right now there are three
> > (more-or-less): global search, two kinds of folder search (QFB and
> > Ctrl-Shift-F), and message search (the find bar); I'm excluding stuff like
> > the Advanced Address Book Search for now. Right now, these are conflated in
> > really weird ways. Global search and the QFB use the same icon (a magnifying
> > glass). Ctrl-Shift-F search is listed under Edit -> Find. We should fix this.
> 
> I like this, in theory.  I would like to see some examples of ways we could
> expose this to the user (hopefully without making it too confusing for
> them).  I guess, I'm not sure how easy it will be to let people use
> Thunderbird without having to understand that the thing they thought of as
> "search" is actually three different things.  Because I don't think that
> trying to tell them that will work out well…

I think just keeping consistent naming/icons would be enough. We don't need to shove it down users' throats.

> (Using Bing's image search, I see a lot of icons, but I don't see any of
> them being used in applications, much less used in email applications.  I
> also don't see any other email clients trying to make the distinction
> between the three types of search.)

Well, I know that Excel used a funnel for their filtering of rows in spreadsheets, which works essentially the same way that the QFB does.

> > The downside of this is that there's also "Message Filters" for categorizing
> > email, but we already crossed that bridge in 3.1 when we added the "Quick
> > Filter". We may want to consider calling message filters "Rules" a la
> > Outlook. Still, message filters do fit the above definition of a "Filter",
> > so it's not so bad.
> 
> Yeah, the more I think about it, the less convinced I am that trying to
> split the idea of searching up into three different cases is a good idea. 
> It seems more complicated, and less useful for the things I think people
> want to do.

I don't think we should split this up in the long term, but in the short term, we're already there, so we should try to make it minimally bad. :) Eventually, we can probably pare things down to two kinds of searching: search and find.

> Does that mean that we should go with a "global" search in each toolbar?  Perhaps it does…)

Since the kind of search that's relevant to each tab type is probably going to be different, I think it makes more sense to make the search boxes appear below the tabs. That way, the layout of the UI suggests that this is a different kind of search box, so there won't be confusion when it behaves differently.

Comment 8

[Jonathan Protzenko [:protz]]

Just chiming in, and sorry if this has been mentioned already. One workflow that I have is:
- in a 3-pane tab, type in some search terms in the global search box,
- hit enter,
- find out I didn't get the query quite right, so
- correct the search terms and hit enter again,
- witness the tab being refreshed with the results of the second query.

Now that the global search box is tied in to the 3-pane tab type, I have to insert an extra step (i.e. switching back to a 3-pane tab), which I could live with, but I guess it's going to be extra confusing for users.

Again, sorry if this has been mentioned already, but there's a lot of text in that bug :).

Comment 9

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

protz: We could also add a global search box to the search tab, which might not be a bad idea…

Comment 10

[Jonathan Protzenko [:protz]]

That sounds like a very sensible thing to do :)

Comment 11

[Jim Porter (:squib)]

Yeah, I've suggested before that the gloda tab have a toolbar with a gloda search box and some useful buttons (e.g. "View as List"). Doing that would also probably let us get rid of some of the content in the tab (e.g. the "Search <query>" heading), which would let us clean the UI up a bit, I think.

Comment 12

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

(In reply to Jim Porter (:squib) from comment #11)
> Yeah, I've suggested before that the gloda tab have a toolbar with a gloda
> search box and some useful buttons (e.g. "View as List"). Doing that would
> also probably let us get rid of some of the content in the tab (e.g. the
> "Search <query>" heading), which would let us clean the UI up a bit, I think.

This sounds like a pretty good idea to me

Comment 13

[Andreas Nilsson (:andreasn)]

(In reply to Bryan Clark [:clarkbw] from comment #12)
> (In reply to Jim Porter (:squib) from comment #11)
> > Yeah, I've suggested before that the gloda tab have a toolbar with a gloda
> > search box and some useful buttons (e.g. "View as List"). Doing that would
> > also probably let us get rid of some of the content in the tab (e.g. the
> > "Search <query>" heading), which would let us clean the UI up a bit, I think.
> 
> This sounds like a pretty good idea to me

clarkbw!

Opened bug #719008 about being able to search from the search tab.

Comment 14

[Thomas D. (:thomas8)]

(In reply to Bryan Clark [:clarkbw] from comment #12)
> (In reply to Jim Porter (:squib) from comment #11)
> > Yeah, I've suggested before that the gloda tab have a toolbar with a gloda
> > search box and some useful buttons (e.g. "View as List"). Doing that would
> > also probably let us get rid of some of the content in the tab (e.g. the
> > "Search <query>" heading), which would let us clean the UI up a bit, I think.
> 
> This sounds like a pretty good idea to me

+1!!!

With tabs on top, adding a customizable toolbar to the global search results tab, as suggested by Jim, could really help to streamline & improve the UI.
To begin with, some interesting elements for that toolbar:

* Gloda global search box, to refine existing search, or start new search: 
bug 719008, bug 596212, bug 716058, and new bug needed for Ctrl+global search from search results to open in a new tab
* "View as list": something like bug 518336
* Dateline toggle: to this day, this poor creature does not even have a tooltip to tell what it does (bug 516797), so making that a proper toggle buttom for showing/hiding the dateline would certainly help...

Comment 15

[Thomas D. (:thomas8)]

Notwithstanding the benefits of having a toolbar for global search results which includes a global search box (per comment 11,12,13 and comment 14), imo Bug 719008 can very well co-exist with this bug. The resulting UI for the faceted search results tab would be very similar to the FF UI on a Google results page:
- have an ever-present global search box in the upper right corner of the screen (both in FF and TB, this bug)
- allow in-place refining of search terms in a central search box above search results (both in FF-google-results, and in TB, bug 719008), which at the same time acts as a headline for search results.

Comment 16

[Wayne Mery (:wsmwk)]

Version 115 cements that we are not headed in this direction.