719008 - Add toolbar to global search results tab, with gloda search box to refine existing faceted search or start a new search

Status: RESOLVED FIXED

(Thunderbird :: Search, defect)

Description

[Andreas Nilsson (:andreasn)]

Spinning off #717261
Right now if you fail to find any results for what you're searching for, you just get a error message and needs to go back to the 3-pane tab and do a new search (that will open in a new tab, bug #716058). This becomes a lot of jumping back and forth. It would be great if it was possible to search from the search tab itself.

Comment 1

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

Attachment: WIP Patch v1

Here's my first run at this patch so far.  Here are the major changes:

1.  Instead of an iframe as the search tab panel, we open a vbox, and use the same technique that chromeTab/contentTab uses for cloning a dummy node appended to the tabmail element (defined in the specialTabs.xul overlay).
2.  A class .remote-gloda-search is assigned the glodaSearch binding.
3.  The tab monitor defined in searchBar.js determines whether or not we've opened up a glodaFacet tab.  If so, it finds and populates the .remote-gloda-search element with the search query.
4.  The keyboard shortcut for searching (Ctrl-k) is mapped to the .remote-gloda-search element if a glodaFacet tab is currently selected.

asuth:  am I walking into any traps here?  Any suggestions or comments?

Thanks,

-Mike

Comment 2

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

Comment on attachment 589897 [details] [diff] [review]
WIP Patch v1

Seems like it should work; for some reason I thought the gloda autocomplete stuff was more than a hack than it is.  I must have been thinking about the original exptoolbar gloda prototype...

I would suggest getting rid of GlodaSearchBoxTabMonitor in searchBar.js.  It only existed because the gloda search box lived outside the 3-pane.  Since it apparently now lives inside the 3-pane again, it can be managed entirely in the 3-pane tab logic.  And then the gloda special case you are inserting can just live in the gloda tab too.

I think that will make more sense, especially because right now its onTabSwitched is going to be persisting incorrect information for gloda tabs.  (And the persistence is not needed because the UI widget already carries all the state we need, the goal having been to not lose the user's edits to the search box when they change tabs.)

Comment 3

[Thomas D. (:thomas8)]

Adjusting summary to be more clear about the good things we are doing here, and make this more retrievable

Comment 4

[Thomas D. (:thomas8)]

(In reply to Thomas D. from bug 717261, comment #15)
Ftr, imo, the benefits of having a toolbar for global search results (this bug)
can very well co-exist with bug 717261.

> 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, bug 717261)
> - allow in-place refining of search terms in a central search box above
> search results (both in FF-google-results, and in TB, this bug 719008), which 
> at the same time acts as a headline for search results.

Comment 5

[Thomas D. (:thomas8)]

Mike, could you attach a screenshot with current wip patch applied?

Comment 6

[Thomas D. (:thomas8)]

This bug fixes the regression that currently, as a result of tabs on top (bug 644169), we can no longer refine existing global search results.

The minimal fix for this regression would be something like bug 717261, or, ideally, do both bug 717261 and this one, as explained in comment 4.

Comment 7

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

I've been pulled off of this to work on BigFiles.

This is an *excellent* bug for a new contributor, and I'm willing to mentor.

Comment 8

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

(In reply to Andrew Sutherland (:asuth) from comment #2)
> Comment on attachment 589897 [details] [diff] [review]
> WIP Patch v1
> 
> Seems like it should work; for some reason I thought the gloda autocomplete
> stuff was more than a hack than it is.  I must have been thinking about the
> original exptoolbar gloda prototype...
> 
> I would suggest getting rid of GlodaSearchBoxTabMonitor in searchBar.js.  It
> only existed because the gloda search box lived outside the 3-pane.  Since
> it apparently now lives inside the 3-pane again, it can be managed entirely
> in the 3-pane tab logic.  And then the gloda special case you are inserting
> can just live in the gloda tab too.
> 
> I think that will make more sense, especially because right now its
> onTabSwitched is going to be persisting incorrect information for gloda
> tabs.  (And the persistence is not needed because the UI widget already
> carries all the state we need, the goal having been to not lose the user's
> edits to the search box when they change tabs.)

Hm - we may want to stick with the GlodaSearchBoxTabMonitor actually... the search input *can* exist within the 3-pane tab, but it can also exist outside of it (in the tabbar-toolbar for example).

Comment 9

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

Attachment: Patch 1

Un-bitrotted.

Comment 10

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

Attachment: Wireframe for toolbar layout

So my latest patch simply inserts a thin toolbar and a text input that kicks off Gloda searches in the same tab.

It works, but visually, it's a little strange to just have the text input up there.  I've attached what I'm proposing.

Or is there a better solution?

Comment 11

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

Attachment: Wireframe for toolbar layout

Just fixing a small detail - but otherwise the same.

Comment 12

[Thomas D. (:thomas8)]

(In reply to Mike Conley (:mconley) from comment #10)
> Created attachment 598351 [details]
> Wireframe for toolbar layout
> So my latest patch simply inserts a thin toolbar and a text input that kicks
> off Gloda searches in the same tab.
> It works, but visually, it's a little strange to just have the text input up
> there.  I've attached what I'm proposing.
> Or is there a better solution?

Some ideas:

(In reply to Thomas D. from comment #14)
> (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
> button on the toolbar for showing/hiding the dateline would certainly help...

Comment 13

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #12)
> (In reply to Mike Conley (:mconley) from comment #10)
> Some ideas:
> 
> (In reply to Thomas D. from comment #14)

The ideas quote in comment 12 was taken from Bug 717261 Comment 14.

Comment 14

[Jim Porter (:squib)]

Attachment: Mockup

Here's what I was thinking for UI. This gives us a fair bit more space for results (the important bit), since things are moved into the toolbar, and the "Search <query>" heading is gone. With the query in the tab title and the text box, we really don't need it in the page, too.

Comment 15

[Thomas D. (:thomas8)]

(In reply to Jim Porter (:squib) from comment #14)
> Created attachment 598581 [details]
> the "Search <query>" heading is gone. With the query in the tab title and
> the text box, we really don't need it in the page, too.

That looks great to me, definitely a step into the right direction.
However, due to the unfinished nature of Global search, removing the query caption from the search results page will cause some new problems:

STR

1) Global Search, type in "Blake", choose "Blake Winton (bwinton(at)mozilla.com)" *from Autocomplete*
2) Global Search, type in "bwinton(at)mozilla.com", press Enter

Actual Results

after 1) Global search results tab title is "Search", and results page headline is "Search involving bwinton(at)mozilla.com"; 36 msgs found

after 2) Global search results tab title is "bwinton(at)mozilla.com", and results page headline is "Search bwinton(at)mozilla.com"; 213 msgs found

Now this is where we run into trouble if we just remove the page headline, and it's not easy to get this right. Some caveats:

a) For cases of 1) (involves...), we cannot just leave "bwinton(at)mozilla.com" in the search box because we didn't do a fulltext search for that string, we don't have a syntax for indicating "involves" in the search box, and we definitely need to distinguish between the two, because they yield completely different result sets.
So lest we find a syntax which actually works, we cannot leave anything in the search box, so it must be blank as is current behaviour.
Maybe in the tab title, we could have "Involving bwinton(at)mozilla.com", but even for small numbers of tabs, that tab title will be truncated due to its length (and it might be worse in other locales).
So practically, there would be no fully visible caption to inform the user about the current query -> bad!

b) for cases of 2)(fulltext), we do the correct thing which is just putting "bwinton(at)mozilla.com" into both tab title and search box. No problem here.

More considerations about removing the page header with information on the current query:

c) Currently, global search for "tourist attraction" (without quotes) will do fulltext search for messages containing tourist AND attraction (and as a matter of fact, at least for EN, we also find tourist AND attracted). So it's enough for the mail to have variants of both words anywhere in the source, and the actual string "tourist attraction" is not required. The result for that is different from searching "tourist attraction" (with quotes), where we correctly take it as one string, so there are less results (and it's even correctly documented in (1) on SuMoMo). Furthermore, you can combine the two and search for [new "tourist attraction"] (without brackets), and we'll create a correct results headline from that: Search *new* AND *tourist attraction*. In the tab title, we just show what the user entered, including the quotes.

If we remove the headline, we'll remove any explicit explanation as to how we parsed the search terms. But maybe in this case, it's minor problem because users know from Google etc. how this works, and at least it can be reconstructed from the exact search terms with quotes in search box and tab title. Case of a) above is much worse.

Conclusions:

Because of a), I think we cannot remove search results headline, but we could make it smaller, more like smallprint information or a tooltip. Even if we keep the current format and size of headline, we can still save some vertical space with Jim's toolbar if we cut down the way too generous vertical offsets, including the offset on the right which is about 1cm too wide, just wasting my screen real estate. Furthermore, we'll still have the benefit that the toolbar removes a lot of visual clutter from the search results page, and it's a first step towards converting the completely alien design of global search back into something that blends in better with the rest of Thunderbird's UI.

Comment 16

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #15)
> (and it's even correctly documented in (1) on SuMoMo). Furthermore, you can

Global search documentation:

(1) https://support.mozillamessaging.com/en-US/kb/global-search

Comment 17

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

The gloda search UI precursor 'exptoolbar' promoted semantic objects into colored bubbles, which was a growing UI trend at the time and even moreso now: http://www.visophyte.org/blog/?p=112 and http://www.visophyte.org/blog/?p=117

A bubble display that also transformed fulltext terms and showed a more verbose-when-inactive display might be a workable option.  For example 'new "tourist attraction"' could be displayed as '("new") and ("tourist attraction")' in the bar when not focused.  If you click in the bar, the bubbles for the text would disappear and so would the and/or hints.

Although doing the bubble UI would itself be a medium-effort undertaking in itself, it could easily increase tension between "altering the search to find what I want" and "filtering the results to find what I want", especially if it caused the altering the search option to become more expressive/powerful.  This would be undesirable because the performance characteristics are such that it is likely far preferable to filter an existing search than issue a new search.  The exception is that an initial search that was far too generic or otherwise hit our LIMIT on results would probably want to re-issue the search.  (It is, of course, possible to cause the search box to trigger filtering where possible, potentially even refiltering as the user types, but that would be a large-effort undertaking.)

Comment 18

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

Comment on attachment 598352 [details]
Wireframe for toolbar layout

I mostly like this, and squib's mockup below.

The one thing I would change for consistency with other toolbars is to put the gloda search box on the right instead of the left…

ui-r=me with that, though.

Thanks,
Blake.

Comment 19

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

Jim:

That's an awesome looking mock-up!

However, I'm hesitant to do such a sweeping change when this alteration is supposed to be *released* in only 3 weeks.  Ideally, I'd like to change as little as possible to avoid introducing more bugs so late into the cycle.

So, if it's alright with you, I think we should scale back the patch for this such that we simply put a search input into the toolbar.  The rest can come later.

Does this sound reasonable?

-Mike

Comment 20

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

Attachment: WIP Patch v2

This patch puts us in a "functional" state - now we need to make this look pretty.

Comment 21

[Jim Porter (:squib)]

Well, my mockup has string changes, so it couldn't get in before 13.0 anyway (unless we wanted to annoy localizers). I'm ok with something basic for now.

Comment 22

[Andreas Nilsson (:andreasn)]

Attachment: Aero part of prettify

Ok, here is the first part of the prettyfication. Needs some testing first to make sure it will work with Personas and all themes. OSX and Linux coming up!

Comment 23

[Andreas Nilsson (:andreasn)]

Attachment: Windows + Mac styling

Like previous patch, + the pinstripe parts.

Comment 24

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

Comment on attachment 599169 [details] [diff] [review]
WIP Patch v2

Okay, the code seems fine to me, so next time I'll just review Andreas's additions.  If you wanted to get asuth to take a look at it too, that might be a good idea…

Comment 25

[Andreas Nilsson (:andreasn)]

Attachment: windows, mac and linux patch

And this part takes care of Linux too.

Comment 26

[Andreas Nilsson (:andreasn)]

Attachment: windows, mac and linux patch (v2)

Windows, Mac and Linux style patch (to be applied on top of Mike's patch)
Fixed slight bitrot.

Comment 27

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

Attachment: Patch v1

Aggregating my patch and Andreas' patch into a single patch.  I've also made the search input in the search tab be 1/3rd of the width of the toolbar, with a minimum width of 10em.

Comment 28

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

Attachment: Ubuntu - Gloda search tab with toolbar

Comment 29

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

Attachment: Windows Aero - Gloda search tab with toolbar

Comment 30

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

Attachment: Windows Classic - Gloda search tab with toolbar

Comment 31

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

Comment on attachment 599332 [details] [diff] [review]
Patch v1

Sure fine fine.

Comment 32

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

Attachment: Patch v2 (carrying over r+ from asuth)

This patch adds some padding to the height of the .remote-gloda-search container to make the toolbar equal in height to mail-bar3.

gnomestripe and qute-aero are taken care of.  Andreas will be taking care of pinstripe and qute-classic.

Comment 33

[Andreas Nilsson (:andreasn)]

Attachment: Patch v2 + pinstripe

Same as previous patch, but correct height for pinstripe search toolbar.

Comment 34

[Andreas Nilsson (:andreasn)]

Attachment: above patch in action

Comment 35

[Andreas Nilsson (:andreasn)]

Attachment: Amalgamated patch (r+'d by asuth, ui-r+'d by bwinton)

Patch v2 with all themes issues fixed.

Comment 36

[Andreas Nilsson (:andreasn)]

Attachment: screenshot of patch running under xp mode

Comment 37

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

Comment on attachment 599356 [details] [diff] [review]
Patch v2 (carrying over r+ from asuth)

Marking this as obsolete, since Andreas' patch contains it.

Comment 38

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

Committed to comm-central as http://hg.mozilla.org/comm-central/rev/fd98bca81bec

Comment 39

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

Attachment: Backport for comm-beta

Backport of attachment 599276 [details] [diff] [review] [diff] [review] for comm-beta.  Carrying forward r+/ui-r+.

Comment 40

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

Comment on attachment 599448 [details] [diff] [review]
Backport for comm-beta

This backport should be committed to comm-beta.

Comment 41

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

Attachment: Windows XP - Fat toolbar

Andreas:

I've noticed that there's a style problem in Windows XP for the Gloda tab search toolbar - it seems a bit too tall.

See attached.

-Mike

Comment 42

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

Attachment: Windows XP - Thinned toolbar

Andreas:

I fiddled with the CSS until I got it to be the same size as the default mail-bar3.  Patch is my next attachment.

-Mike

Comment 43

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

Attachment: Style fix for Windows XP

We'll want to apply this on top of attachment 599448 [details] [diff] [review] on beta, and then on top of attachment 599425 [details] [diff] [review] (already committed) for Aurora and Nightly.

Comment 44

[Mark Banner (:standard8)]

Pushed the main patches to aurora and beta:

http://hg.mozilla.org/releases/comm-aurora/rev/2464602e9a8f
http://hg.mozilla.org/releases/comm-beta/rev/b23b75bf76e8

Attachment 599463 [details] [diff] is still outstanding.

Comment 45

[Andreas Nilsson (:andreasn)]

As mentioned on IRC, when I tried with a fresh profile, Thunderbird had a fat toolbar due to large icons being the default. It seems it's still jumps 2px though, so writing a patch for that.

Comment 46

[Andreas Nilsson (:andreasn)]

Attachment: style fix for XP (v2)

This should give us a search bar that matches the toolbar height we get with a fresh profile.

Comment 47

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

Comment on attachment 599638 [details] [diff] [review]
style fix for XP (v2)

Looks good.

Comment 48

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

Attachment 599638 [details] [diff] was checked in to:

comm-central as http://hg.mozilla.org/comm-central/rev/acc5c71ae5a3
comm-aurora as http://hg.mozilla.org/releases/comm-aurora/rev/c06f0acf8326
comm-beta as http://hg.mozilla.org/releases/comm-beta/rev/c3b9327d2a21