474711 - search facets bar above search results tab

Status: RESOLVED FIXED

(Thunderbird :: Search, defect)

Description

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

With bug 474701 replacing the existing quick search with a new search entry that doesn't contain the same pre-facets ("subject or from", "to or cc") system we need a facets system that helps people filter their mail in a similar, but better way.  Pre-facets that are used in the quick search are problematic interfaces that often leave people with empty search results because their search started small due to facets already being selected.  If we can assume (and we are with gloda) that search over all facets is fast then we want to start searching broadly over all facets and then allow people to filter large result sets down with the use of facets after the fact.

It's a recognized problem that having search facets after the fact can slow down power users who are more aware of the facet system.  This can be mitigated in several ways w/ the use of syntax and auto-complete to be described in further bugs.

---

A search facets bar should exist above the search results (thread view) list, containing the necessary facets. Ascii art example below...

+------------------------------------------+
|              toolbar    [ search entry ] |
--------------------------------------------
|            |  search facets bar          |
|            |-----------------------------|
|            |                             |
|  folder    |     search results list     |
|   pane     |                             |
|            |-----------------------------|
|            |                             |
|            |                             |
|            |       message reader        |
|            |                             |
|            |                             |
+------------------------------------------+

The search facets bar should contain the following options.

[ facet type | v ]     [ location | v ]   ( Save... )

* facet type
** Everything
** Subject
** Involves (from,to,cc,bcc)
** To, CC (bcc)
** From
** Message Text

* location
** {{Folder in Focus when search was launched}}
** ---
** {{Folder List}}

( Save... ) saves the search as a Saved Search, similar to the option in the current quick search entry.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

This sounds like an asuth kind of thing; handing off to him for now.

Comment 2

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

Andreas and I will be working on some mockups this week.

Comment 4

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

Development work for this feature is happening using pbranch in:
http://hg.mozilla.org/users/bugmail_asutherland.org/comm-central-pbranches/

Information on pbranch can be found here:
http://arrenbrecht.ch/mercurial/pbranch/

pbranch is basically just magic to help automate merges (and getting patches out) when working with branches.  So if you were to pull from the above repo without having pbranch installed, you would still see a "gloda-facet" branch that you could use "hg up gloda-facet" to switch to and build/run with.

Comment 5

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

Linux and OS X try builds are available:

Linux:
http://s3.mozillamessaging.com/build/try-server/2009-09-03_16:[e-mail]-facet-v5/[e-mail]2

OS X:
http://s3.mozillamessaging.com/build/try-server/2009-09-03_16:[e-mail]-facet-v5/[e-mail]

The windows try server is under the weather and not producing viable builds.

The try builds *will* blow away your gloda database.  If you stop using the try build, it may be advisable to manually blow away your global database (global-messages-db.sqlite in your profile), but things should still work if you don't.

Comment 6

[David Ascher (:davida)]

Discussion of what to test w/ these try server builds will happen at https://wiki.mozilla.org/Thunderbird/FacetedSearch:Testing

Comment 7

[Peter Lairo]

(In reply to comment #0)
> +------------------------------------------+
> |              toolbar    [ search entry ] |
> --------------------------------------------

Will the "Search Entry" box have a drop-down to select common searches, like "Tags" or "Last 5 Days" or "Subject or From"? Similar to QuickSearch and MailViews. Or will users always be forced to launch a "full search", which opens a new tab, and then add filters via the "search facets bar"?

Also, it seems the "Search Entry" box does not need to be any wider than the current "Quick Search" bar. Thus, the main reason for displacing the Reply, Forward, Delete, etc. buttons from the toolbar into the message header is not valid. Thus, please WONTFIX bug 474523. (I know this is only peripherally related to this bug, but this bug is the only place I could find with a mock-up for the new search bar)

Comment 8

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

There's a weird "Name or Email" widget in Address Book's search box with v6 of asuth's tryserver patch - that I don't see in a nightly.

Comment 9

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to comment #8)
> There's a weird "Name or Email" widget in Address Book's search box with v6 of
> asuth's tryserver patch - that I don't see in a nightly.

Also, with v6 of asuth tryserver build, importing a .csv address book results in a blank import (this doesn't happen with compiled opt builds off c-c tip, thus assuming a nightly).

Comment 10

[David Ascher (:davida)]

Comment #8: Argh.  I had no idea the addressbook used that widget.  Nice catch.

Comment 11

[David Ascher (:davida)]

Comment #9: I suspect much of the addressbook is borked as a result of the bug that's mentioned in Comment #8.  But it'll likely be a fairly simple fix.

Comment 12

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

(In reply to comment #7)
> (In reply to comment #0)
> > +------------------------------------------+
> > |              toolbar    [ search entry ] |
> > --------------------------------------------
> 
> Will the "Search Entry" box have a drop-down to select common searches, like
> "Tags" or "Last 5 Days" or "Subject or From"? Similar to QuickSearch and
> MailViews. Or will users always be forced to launch a "full search", which
> opens a new tab, and then add filters via the "search facets bar"?

I don't understand what you are asking for here.  If you try out the new search via the try builds I think you'll get a better sense of how it currently works.

Keeping 'previous recent searches' in the auto-complete is something I would like to try but I don't think that is what you are talking about.

> Also, it seems the "Search Entry" box does not need to be any wider than the
> current "Quick Search" bar. Thus, the main reason for displacing the Reply,
> Forward, Delete, etc. buttons from the toolbar into the message header is not
> valid. Thus, please WONTFIX bug 474523. (I know this is only peripherally
> related to this bug, but this bug is the only place I could find with a mock-up
> for the new search bar)

Reasons for the search entry size change have been discussed in bug 474523 Comment #43 and were supposed to continue on the newsgroup; if you want to pick that up now we could continue it further.

Comment 13

[Peter Lairo]

(In reply to comment #12)
> I don't understand what you are asking for here.  If you try out the new search
> via the try builds I think you'll get a better sense of how it currently works.

Sorry, wasn't accurate: By "Tags" or "Last 5 Days" I meant the *filter* that is available from the "Mail Vies" bar (as in: show all messages with Tag "Personal"). The "Subject or From" cam from the QuickSearch bar. I'd like to see both remain easily accessible.

I don't have the nerve/time for a try-build right now, so it would be great if someone could post a screen-shot(s) of the current UI in this bug.

Comment 14

[David Ascher (:davida)]

Attachment: Fix for bugs in Comments #8 and #9, but safe to apply on trunk

This patch fixes the issues in comment #8 and #9 (as seen on the pbranch), but are IMO a good thing for trunk anyway, as a) it uses the new "search" type autocomplete, which takes care of managing emptyText for us.  The menu (which was odd, as it only had one selected or selectable entry) is gone, which I think is a good thing.

Asking standard8 for review.

Comment 15

[David Ascher (:davida)]

A side comment about the size of the search field: the code in pbranch (but post-dating the try-server builds) has it have a "flex" size, so people who configure their toolbar w/ lots of buttons end up with a small textbox, and people who configure their toolbar w/ few buttons end up with a large textbox.  This seems to work well for Firefox, and strikes me as a flexible solution which fits various habits nicely.

Comment 16

[Mark Banner (:standard8)]

Comment on attachment 399098 [details] [diff] [review]
Fix for bugs in Comments #8 and #9, but safe to apply on trunk

Almost, but not quite.

Whilst we're here let's sort out the one in the contacts sidebar as well (compose msg -> View -> Contacts Sidebar) - abContactsPanel.*

Then we can drop the onSearchInputFocus,  onSearchInputBlur, onClearSearch and restoreSearchFocusAfterClear functions from abCommon.js.

(onAbClearSearch is still required).

Note, you can also combine the textbox into one element statement:

<textbox ...></textbox>

versus

<textbox .../>

Comment 17

[David Ascher (:davida)]

Attachment: [checked in] v2: Fix for bugs in Comments #8 and #9, but safe to apply on trunk

Comment 18

[Mark Banner (:standard8)]

Comment on attachment 399144 [details] [diff] [review]
[checked in] v2: Fix for bugs in Comments #8 and #9, but safe to apply on trunk

Excellent, some nice tidy up. r=Standard8.

Comment 19

[Mark Banner (:standard8)]

Comment on attachment 399144 [details] [diff] [review]
[checked in] v2: Fix for bugs in Comments #8 and #9, but safe to apply on trunk

Checked in: http://hg.mozilla.org/comm-central/rev/2824295d861c

Comment 20

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

The gloda-facet branch has been merged down to the default branch and the history pushed.  I have used Mercurial's "--close-branch" option to mark the branches (add-protovis, add-jquery, gloda-facet) as closed.  hgweb does not appear to understand this, but "hg branches" does.  I presume hgweb will join the party later on.

pushed:
http://hg.mozilla.org/comm-central/rev/0e087e095585

Marking fixed.  Please create new bugs for problems caused by the new functionality and the new hybrid quick-search/gloda search bar.