Closed Bug 474711 Opened 11 years ago Closed 10 years ago

search facets bar above search results tab

Categories

(Thunderbird :: Search, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b4

People

(Reporter: clarkbw, Assigned: asuth)

References

(Depends on 1 open bug)

Details

(Whiteboard: [has l10n impact][b4ux])

Attachments

(1 file, 1 obsolete file)

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.
Flags: blocking-thunderbird3+
This sounds like an asuth kind of thing; handing off to him for now.
Assignee: nobody → bugmail
Component: Mail Window Front End → Toolbars and Tabs
QA Contact: front-end → toolbars-tabs
Whiteboard: [b3ux]
Whiteboard: [b3ux] → [b3ux][m3]
Whiteboard: [b3ux][m3] → [b3ux][m5]
Depends on: 474701
Whiteboard: [b3ux][m5] → [b4ux]
Target Milestone: Thunderbird 3.0b3 → Thunderbird 3.0b4
Whiteboard: [b4ux] → [b4ux][has l10n impact]
Blocks: 511587
Blocks: 511588
Blocks: 511590
Depends on: 511602
Andreas and I will be working on some mockups this week.
Depends on: protovis
Duplicate of this bug: 507688
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.
Linux and OS X try builds are available:

Linux:
http://s3.mozillamessaging.com/build/try-server/2009-09-03_16:12-asutherland@asutherland.org-facet-v5/asutherland@asutherland.org-facet-v5-mail-try-linux.tar.bz2

OS X:
http://s3.mozillamessaging.com/build/try-server/2009-09-03_16:12-asutherland@asutherland.org-facet-v5/asutherland@asutherland.org-facet-v5-mail-try-mac.dmg

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.
Status: NEW → ASSIGNED
Discussion of what to test w/ these try server builds will happen at https://wiki.mozilla.org/Thunderbird/FacetedSearch:Testing
(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)
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.
(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 #8: Argh.  I had no idea the addressbook used that widget.  Nice catch.
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.
(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.
(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.
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.
Attachment #399098 - Flags: review?(bugzilla)
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.
Attachment #399098 - Flags: review?(bugzilla) → review-
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 .../>
Whiteboard: [b4ux][has l10n impact] → [has l10n impact][b4ux]
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.
Attachment #399144 - Flags: review?(bugzilla) → review+
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
Attachment #399144 - Attachment description: v2: Fix for bugs in Comments #8 and #9, but safe to apply on trunk → [checked in] v2: Fix for bugs in Comments #8 and #9, but safe to apply on trunk
Blocks: 454010
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.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Depends on: 515648
Depends on: 515855
Component: Toolbars and Tabs → Search
QA Contact: toolbars-tabs → search
You need to log in before you can comment on or make changes to this bug.