518944 - [faceted search] remove the all / or choices from the auto-complete entry

Status: RESOLVED FIXED

(Thunderbird :: Search, defect)

Description

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

using the auto-complete to choose searches that match all of your terms or any of your terms will be bit confusing for many users.

Faceting for the most part is about pruning results after the fact and this upfront choice doesn't present enough information for a person to decide if the AND is going to be too restrictive.  At the same time a good search system should handle the ANDing and ORing of terms for the user mostly without their explicit knowledge.

Future systems could realize small numbers of results and offer to expand the search by ORing the terms.  Often when search results are large ORing the terms is a useless operation that only expands the result set beyond what was already usable.

Comment 1

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

setting myself up for failure

Comment 2

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

or setting david up FTW!

Comment 3

[David Ascher (:davida)]

Attachment: patch v1

This patch needs to land after the patch in Bug 518946, as I'm removing the back-end logic to deal with AND/OR differences (we just do AND) (and that patch removes the only client)

In addition to the change specified in comment #0, I'm also:

1) increasing the # of characters for which we offer full-text search to 3.
2) using a slightly tweaked version of the "build-phrases-through-quotes" algorithm in msg_search.js, as suggested by asuth.  The only difference is that I'm stripping commas from the term list, as otherwise they pollute the display.  The backend strips commas anyway so there's no non-visual impact. 

This means you can search for "david loves" and it will return messages that include "david loves emily" but not messages that include "emily loves david".  

This patch does change a string ID.

Comment 4

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

Attachment: patch v2

r=asuth with the attached minor changes.

Our reuse of richlistitems was running into trouble when the type of a display node was changing.  Because of the change in the minimum count for the autocomplete hint, such a transition could occur during the change from 3 letters to 4 letters where an identity XBL binding would think that a search string was an identity.  This would throw an exception and result in wackiness.  We now no longer reuse items and change the height adjustment logic slightly because we use multiple types of display widgets.

Comment 5

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

Comment on attachment 402990 [details] [diff] [review]
patch v2

looks good, thanks!

Comment 6

[Phil Ringnalda (:philor)]

http://hg.mozilla.org/comm-central/rev/b6429ed2604f