556213 - Global Search: Adding several "must involve" becomes OR when it should be AND - should offer choice between logical operators [facet search]

Status: NEW

(Thunderbird :: Search, defect)

Description

[Jakob Malm]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.15) Gecko/2009102704 Fedora/3.0.15-1.fc10 Firefox/3.0.15
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; sv-SE; rv:1.9.1.5) Gecko/20091209 Remi/fc10 Lightning/1.0b1 Thunderbird/3.0

Adding several persons to the search filter using "must involve" should require _all_ selected persons to be involved in each mail in the results (AND). Instead, all mails involving _any_ of the selected persons are displayed (OR).

Either 1) the "must involve" should be rephrased and logic preserved, or 2) "involving any of:" should be rephrased, e.g. to "involving all of:", and the logic be changed to AND instead of OR

Reproducible: Always

Steps to Reproduce:
1. Do a global search
2. In the filters sidebar, select a participant and choose "must involve <person 1>"
3. Select another participant and choose "must involve <person 2>"
Actual Results:  
All mails involving _either_ person 1 _or_ person 2 are obtained, and listed under "involving _any of_:"

Expected Results:  
Both person 1 and person 2 should have to be in each mail in the results. These selected persons should be listed under "involving all of:", or something similar.

Theme: iLeopard Mail

Comment 1

[Wayne Mery (:wsmwk)]

Jakob, What you describe is not part of the design. And, I don't recall hearing anyone report this behavior. Do you still see this problem?

Comment 2

[Wayne Mery (:wsmwk)]

I think the "OR" part of this is wonfix. 

however, regarding the wording, if one chooses to pay close attention it does seem slightly confusing

Comment 3

[Thomas D. (:thomas8)]

We will continue to get AND vs. OR bugs until we finally give the user a choice... Same problem with the tag quickfilter when you filter on several tags...

Comment 4

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk) from comment #2)
> I think the "OR" part of this is wonfix. 

I'm confused about this statement, in several respects.

1) This is current behaviour:
Must involve Peter + Must involve John = Must involve (Peter *OR* John)
So how can the current OR behaviour be wontfix?

2) This is the expected behaviour of comment 0:
Must involve Peter + Must involve John = Must involve (Peter *AND* John)
Why should this be wontfix? Iow, what reason do we have to assume that (Peter Or John) is more useful than (Peter AND John)?

3) Even if we assume that for whatever Reason OR is the more useful/frequent usecase than AND, it's obvious that we are drastically reducing the usefulness of search for no good reason by NOT offering a choice between AND and OR. Iow, without choice, about half of the possible use cases are simply not covered by design, which is what I call incomplete design. So if anything, this needs to be morphed into a request to implement free choice between AND and OR, which imho should be relatively simple and straightforward both in the code and the UI.

(In reply to Thomas D. from comment #3)
> We will continue to get AND vs. OR bugs until we finally give the user a
> choice... Same problem with the tag quickfilter when you filter on several
> tags...

And of course, the same problem for the tags filter criteria in faceted search results.

> however, regarding the wording, if one chooses to pay close attention it
> does seem slightly confusing

Faceted search results in general are definitely among the less useful parts of the UI. I'll try to elaborate on Wayne's hypothesis that the language might be confusing here:
- User first clicks on "must involve Peter"
- User then clicks on "must involve John"
From a language/logical point of view, I think the more natural assumption from those two clicks would be to assume that this turns out as
- "must involve (Peter AND John)".
Yet in the current design, it does not. However, we could argue that user cannot assume anything since the logical connector is simply missing when user clicks on the constraint. We do give an indication *after* adding a constraint, in the form of the resulting caption "involving *any* of" which describes OR in natural language. So the missing alternative is really "involving *all* of" to represent AND.

UI proposal

With as little changes as possible to the existing UI and code (for pragmatic reasons only):
What if the user could just toggle the boolean operator *after* setting one or more constraints? It could be as simple as a dropdown choice:

| involving any of: |v|

Then you can click on the dropdown marker to get a menu choice:

| involving any of: |v|
| involving all of:   |

And you may choose the alternative boolean operator, which is *all*:

| involving all of: |v|

Wayne, what do you think about that proposal?

(btw, I wonder if this would require more than a dozen lines of code changes, and perhaps another dozen of lines for the UI change...?)

Comment 5

[Wayne Mery (:wsmwk)]

I am in favor of adding choice. I defer to others how to accomplish :) Although I think I'd prefer radio button over drop down that requires extra clicks. Radio is perhaps less visually appealing/clean, but it makes somewhat more obvious to users that there is a choice.