User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0 Build ID: 20110811165603 Steps to reproduce: In the Quick Find toolbar, press "Tags". My tags in use in the folder are shown correctly, but I want an option to see what messages are NOT tagged at all. For example, tags may be "Word", "Personal"; a new pseudo tag of "Untagged" may be useful. Actual results: As a work around, I added the Tag column to the message list, and then sorted on this.

+1 My workaround: Tag all messages using , using message filters. This adds extra processing and delay. New proposal: In the last versions (24.2.0), "Any of" and "All of" have been added to the quickfilter regarding tags. A "None of" has to be added as well, so if somebody selects all his tags and the "None of", only the untagged messages will be shown.

Let's at least confirm this, since the "None of" suggestion in comment 1 is one of my top missing features to make tagging useful. Simple example" I'd like to have a simple tag of "Later" in the inbox to show messages that I don't want to review again, or perhaps "OneWeek" to be messages I want to check weekly for followup issues. For that to work, I have to be able to display an inbox with no "Later" tags showing. I suppose I could workaround it with a saved search, but it would be good if we did not all have to develop workarounds.

After hours of experimenting with this, and years of trying to use this feature, in reviewing the existing code in detail I learned for the first time that there is existing functionality where you can right click a tag, and that results in the particular tag being excluded from results, which is similar to this request but not the same. But it does change how to implement it. What we need is a pseudo-tag "Untagged" that could be selected rather than a "None of" option.

This attachment is a TB 45 addon that implements what I am proposing. I think this should be included in core.

Comment on attachment 8764047 [details] notagfilters.xpi Hi Richard, Could I get your opinion on this UI? This is a TB 45 extension that implements the proposed change. I would like to put this in core. How to use (after installing in TB 45): enable Quick Filters, select tags. There is now a new pseudo-tag showing, "Has Tags". It is selected initially, so that the qf tags option behaves as previously when first selected. But now you can manipulate the "has tags" like you do the other tags. Deselect, and all messages will show. Right click on it, and only untagged messages will show. This can also be combined with other tagging selectors. I also added a tooltip "click to include, right click to exclude" because after all of these years, it never occurred to me to right click here! (In the final I probably need an OSX-specific version that says "control-click" instead). Use case: I would typically tag messages with ways such as "followup" or "Later" which are categories that I do not want to see. What I DO want to see are the messages that still need processing, that is those that are untagged. That is not possible with the current UI.

Comment on attachment 8764047 [details] notagfilters.xpi I think, we shouldn't add this button when we have the menulist "Any of, All of". This option should go into this menulist as "Not of", and when chosen, then all tags are selected. Naturally you are the native English speaker and if you have a better name for it, go on. Or we could change this menulist to a radio group, but this could use too much space, especially for some locales. I don't see what's the difference between the strike through tag and the not selected tag. I think this makes the UI unneeded complicated

"I don't see what's the difference between the strike through tag and the not selected tag. I think this makes the UI unneeded complicated" You do realize I hope that this is the existing UI and not some new proposal? I did not know that (see comment 3) until I examined the internal code, saw the support in the backend, and looked for the UI that did it. That's why I added the tooltip to help others on the path to discovery. The extra tag is proposed in comment 0, a "None of" to the dropdown is proposed in comment 1. Initially I coded with the "None of" dropdown, later after I discovered the actual existing UI, I switched that to the "Has tag" pseudo-tag similar to the OP's suggestion. Having now used both, I would say that I find the "None of" somewhat more aesthetically pleasing, but the pseudo tag is easier to understand and more functional. I can switch the generally tagged/untagged messages on and off very quickly with a pseudo button. Using "None of" changes the meaning of my existing tags, is more cumbersome to select, and really make no sense with the existing UI (Like what does "None of" NOT tagged Important mean? The double negative becomes cognitively straining). I'd ask you to think about this again in the light of these comments.

Ah now I see, the "strike through" works also without your extension. I thought this from comment 3 needed to be implemented. I think a "Untagged" or "No tag" pseudo tag would be easier to understand because the "Has tag" needs two right clicks to set the "no tag". If it would go directly to exclude on the first right click then it could be clearer for the user. This pseudo tag should also be the first tag to be always at the same position with different amount of tags.

OK that's fine, and putting this in the first position is a good idea. If we follow the conventions and startup in the current default state (with only tagged messages selected) then the initial state of "Untagged" will have a strike through it. Though that might appear odd, it will help highlight that there is more available to this UI than most of us realized.

I'll redo the extension with the suggested changes.

This version moves the pseudo tag to the front, and reverses the sense to Untagged.

Comment on attachment 8764401 [details] revision 2: Untagged pseudo tag in first position Looks good. Would it be possible when a tag is included (selected) and I then right click it, the tag is directly excluded and vice versa? Now I need to right click twice to exclude it. To unselect a included tag left click unselects it, like it is already. And right-click a excluded tag would unselect it.

(In reply to Richard Marti (:Paenglab) from comment #12) > Comment on attachment 8764401 [details] > revision 2: Untagged pseudo tag in first position > > Looks good. > > Would it be possible when a tag is included (selected) and I then right > click it, the tag is directly excluded and vice versa? Now I need to right > click twice to exclude it. > > To unselect a included tag left click unselects it, like it is already. And > right-click a excluded tag would unselect it. I had the same objection, and I'll try this change to see what I think.

Let's get some code review. Although this version used the "Untagged" pseudo tag, after working with this I do not think that is best. In general double negatives are hard to grasp, so the version with the strikeout is "Not untagged". I think it would be easier to understand with the "Tagged" instead. Also I added changes to make this accessible, I hope that is OK.

Comment on attachment 8764788 [details] [diff] [review] Untagged version Review of attachment 8764788 [details] [diff] [review]: ----------------------------------------------------------------- I like this :) There are quite some changes, not all of which I understand. But you are the expert on building search terms and is seems to work for me. So I just have some tiny nits: Typo in commit message (psuedo). ::: mail/base/content/quickFilterBar.css @@ +19,5 @@ > text-decoration: line-through; > } > > +.qfb-tag-button { > + -moz-user-focus: normal Why is this? I get focus outline in the last clicked tag now. That wasn't there before. Is this to enable/visualize keyboard movement over the tags? Activating the tag with space works, but also triggers the "move to next message" command. ::: mail/base/modules/quickFilterManager.js @@ +672,5 @@ > value = term.value; > value.str = ""; > term.value = value; > + > + var untagged; let? @@ +693,5 @@ > term.booleanAnd = true; > aTerms.push(term); > > // we need to perform faceting if the value is literally true. > + // (that is, this is the initial setup, and we want to use a first That? @@ +695,5 @@ > > // we need to perform faceting if the value is literally true. > + // (that is, this is the initial setup, and we want to use a first > + // search to detect which tags exist to show in the UI, so we return > + // ourself as a listener for further processing in OnSearchDone). ourselves? @@ +768,5 @@ > if (tag.key in aKeywordMap) > outKeyMap.tags[tag.key] = aKeywordMap[tag.key]; > } > + // add a fake tag to UI to represent notag, false because initially we > + // only want messages with tags Uppercase start and dot at the end. Also, "notag" is not a plain word, maybe make it "no tag" (also with the quotes). @@ +769,5 @@ > outKeyMap.tags[tag.key] = aKeywordMap[tag.key]; > } > + // add a fake tag to UI to represent notag, false because initially we > + // only want messages with tags > + outKeyMap.tags["_untagged_"] = false; Trailing space. @@ +834,5 @@ > qbm.value = aState.mode; > else > aState.mode = qbm.value; > > + // Processing of click (command) and right-click (contextmenu) events surplus space before "click" @@ +842,5 @@ > + if (aEvent.target.checked) > + buttonState = !(aEvent.target.getAttribute("inverted") == "true"); > + > + if (aEvent.type == "command") { > + // swap inverted if opposite button clicked Uppercase start and dot at the end. @@ +851,5 @@ > + else > + buttonState = true; > + } > + else { // type == "contextmenu" > + // swap inverted if opposite button clicked Uppercase start and dot at the end. @@ +860,5 @@ > + else > + buttonState = false; > + } > + > + // now update attributes with buttonState Uppercase start and dot at the end. ::: mail/locales/en-US/chrome/messenger/quickFilterBar.dtd @@ +112,5 @@ > + --> > +<!ENTITY quickFilterBar.tags.tag.tooltiptext.nonmac > + "click to include, right click to exclude"> > +<!ENTITY quickFilterBar.tags.tag.tooltiptext.mac > + "click to include, control click to exclude"> Other tooltips on the toolbar start with uppercase. Also, maybe there should be an object in the sentence, e.g. "Click to include tag, ..." @@ +119,5 @@ > + The label used for a tag button that signified that only messages without > + tags will be shown (or not shown depending on the sense) > + --> > +<!ENTITY quickFilterBar.tags.tag.untagged.label > + "Untagged"> Should this be vertically aligned under quickFilterBar?

(In reply to :aceman from comment #15) > Comment on attachment 8764788 [details] [diff] [review] > Untagged version > > Review of attachment 8764788 [details] [diff] [review]: > ----------------------------------------------------------------- > > I like this :) > > There are quite some changes, not all of which I understand. But you are the > expert on building search terms and is seems to work for me. > So I just have some tiny nits: > > Typo in commit message (psuedo). > > ::: mail/base/content/quickFilterBar.css > @@ +19,5 @@ > > text-decoration: line-through; > > } > > > > +.qfb-tag-button { > > + -moz-user-focus: normal > > Why is this? I get focus outline in the last clicked tag now. That wasn't > there before. Is this to enable/visualize keyboard movement over the tags? > Activating the tag with space works, but also triggers the "move to next > message" command. We shouldn't make this tag buttons tabable. No toolbar button is tabable, even not in the main toolbar and not in the main QFB toolbar.

Could I have some additional comments on my comment 14 "Although this version used the "Untagged" pseudo tag, after working with this I do not think that is best." I did that version because Richard wanted it as I understood, but I don't really like the double negative myself. Re comment 16 "We shouldn't make this tag buttons tabable." - what is the accessibility method for this toolbar? There are no keyboard equivalents for these functions.

Comment on attachment 8764788 [details] [diff] [review] Untagged version Review of attachment 8764788 [details] [diff] [review]: ----------------------------------------------------------------- Sorry for the review delay... I don't think it's really an "Untagged" button that we want here: - it's confusing to have the strike-through Untagged there to start with - it doesn't make sense if you choose "All of" What you want is a way to include untagged messages too, for both "Any of", and "All of". What I think would work is to have a checkbox (after the tags) | All of | [ToDo] [Later] [x] + untagged

(In reply to Kent James (:rkent) from comment #17) > Re comment 16 "We shouldn't make this tag buttons tabable." - what is the > accessibility method for this toolbar? There are no keyboard equivalents for > these functions. Not only this toolbar, also the main QFB toolbar has no accessible buttons.

I'm sorry, but I don't like your suggestion, Magnus. I implemented what Richard wanted, though I did not agree with it, and now we are getting even further away from the original propoposal. I'm going to return to my original proposal. That is, I will add a "Has Tag" button that looks like, and can be combined with, the specific tags. It's logical, it works with the current design, and it is relatively straight forward to do. I don't seen any support for this here though, so I suppose I'll just do it as an extension. I don't like "Not Tagged" (because of the double negative of not not tagged) and I don't like adding a new type of UI when the existing UI of a button with crossout can work just fine. It's really frustrating though. I've been with this project 10 years, served as the leader for awhile, and I still find it really hard to get UI that I have used and developed landed.

(In reply to Kent James (:rkent) from comment #20) > It's really frustrating though. It gets frustrating after cmt 200, we're on comment #21 here ;-) I was involved in two bugs like that: Bug 368915 landed at cmt 248, bug 769604 landed at cmt 188. The problem with these UI bugs is, that we implement first and discuss later. We should first reach a consensus and then implement that. I've looked at your add-on and I don't find the "Has Tags" button all that intuitive. The "Untagged" suffers from the double-negative when right-clicked off, but conceptually "Untagged" means it's invisibly tagged with a see-through virtual non-tag. However, especially after 2 AM when my brain doesn't work well any more, it's too hard to grasp ;-) I think this issue is worth another round for a good solution in the product and not some add-on. I don't think Magnus's checkbox can deliver only the untagged messages. How about this: Two states on a button which comes first: "Has Tag" (default). "No Tag", the opposite. No third state, button cannot be deselected, only toggled with either left or right click. So if "Has Tag" is set, it works like before. If "No Tag" is set, you get untagged messages, or you can mix in additional tags with "Any of". Of course "All of" with "No Tag" and "Work" gives nothing.

Richard, what do you think of my solution? One button, two states: "Has Tag", "No Tag". "Has Tag" gives the previous behaviour, "No Tag" gives untagged messages and can be mixed with other tags (to get "untagged" or "Work", for example). Sounds simple.

Hmm, it could be a "Has Tag" button (before the Any of / All of") dropdown, that when pressed looks like a pressed tag. [ Has Tag ] | Any of | [ Important ] [ ToDo ] ...

Well, it would be good to treat [ No Tag ] equivalent to a tag. So for example: | All of | [ Has Tag(*) ] [ Work(*) ] [ Personal(*) ] or | Any of | [ No Tag(*) ] [ Work(*) ] where (*) signifies "active".

(In reply to Jorg K (GMT+2, PTO during summer) from comment #22) > Richard, what do you think of my solution? > One button, two states: "Has Tag", "No Tag". > "Has Tag" gives the previous behaviour, "No Tag" gives untagged messages and > can be mixed with other tags (to get "untagged" or "Work", for example). > Sounds simple. The actual implementation (without this patch) can with a right click untag a tag and show it then stroked through. Maybe we could let the "No Tag" strike through all tags when activated. With this the user also learns this function. And position the "No Tag" button before the "Any of" menulist.

(In reply to Richard Marti (:Paenglab) from comment #25) > Maybe we could let the "No Tag" strike through all tags when activated. With this the user also learns this > function. I don't see why. If the other tags are not active, "No Tag" will get the untagged messages, no need to manipulate the others. > And position the "No Tag" button before the "Any of" menulist. Like Magnus said? I prefer it after the "All/Any of" since the "No Tag" is a special virtual tag at the same level of the others. We should scrap the whole thing and implement free form query, for example: Work and Personal. Work or Personal. Work and not Personal. Untagged or Work. etc. Sorry, wishful thinking.

In fact: We could have a display field after the buttons which gives what is selected in plain English, so: | All of | [ Has Tag(*) ] [ Work(*) ] [ Personal(*) ] gives "Work and Personal". | Any of | [ No Tag(*) ] [ Work(*) ] gives "No tag or Work". | Any of | [ No Tag(*) ] [ --Work(*)-- ] gives "No tag or not Work".

Let me rephrase my suggestion. It's basically what the patch does, but with three changes: 1) "--Untagged--(*)" (default start) becomes "Has Tag(*)" (activated). 2) "Untagged(*)" becomes "No Tag(*)" (to mirror "Has Tag"). 3) You can't deactivate that button.

(In reply to Jorg K (GMT+2, PTO during summer) from comment #26) > (In reply to Richard Marti (:Paenglab) from comment #25) > > Maybe we could let the "No Tag" strike through all tags when activated. With this the user also learns this > > function. > I don't see why. If the other tags are not active, "No Tag" will get the > untagged messages, no need to manipulate the others. Then the user learns this strike through function and can after clicking the "No Tag" button enable one tag how he could need it then. > > And position the "No Tag" button before the "Any of" menulist. > Like Magnus said? I prefer it after the "All/Any of" since the "No Tag" is a > special virtual tag at the same level of the others. With my approach, before the menulist would be more logical as this would be no "virtual tag". Your approach is like the actual patch, except your "virtual tag" doesn't work like a tag and more like a normal button.

(In reply to Richard Marti (:Paenglab) from comment #29) > With my approach, before the menulist would be more logical as this would be > no "virtual tag". Indeed. But placing it before the menulist leaves it unclear what is meant: Obviously: "Has Tag" AND (xx or yy) "Has Tag" AND (xx and yy and not zz). But what about "No Tag": "No Tag" AND/OR(??) (xx or yy) Looks like it needs to be "OR" "No Tag" OR (xx). So the logical conjunction of the "Has Tag"/"No Tag" with what follows isn't clear. If you use a pseudo-tag, the conjunction is clear.

(In reply to Jorg K (GMT+2, PTO during summer) from comment #30) > But placing it before the menulist leaves it unclear what is meant: > Obviously: > "Has Tag" AND (xx or yy) > "Has Tag" AND (xx and yy and not zz). For my proposal the button should be always labeled "No Tag". > But what about "No Tag": > "No Tag" AND/OR(??) (xx or yy) > Looks like it needs to be "OR" > "No Tag" OR (xx). > > So the logical conjunction of the "Has Tag"/"No Tag" with what follows isn't > clear. If you use a pseudo-tag, the conjunction is clear. A pseudo-tag that looks like but doesn't act like a normal tag (changes his label and has no strike through).

(In reply to Richard Marti (:Paenglab) from comment #31) > For my proposal the button should be always labelled "No Tag". Then I don't fully understand your proposal. Also, any additional binary control is like Magnus' proposal from comment #18, right? > A pseudo-tag that looks like but doesn't act like a normal tag (changes his > label and has no strike through). Yes, it's a special pseudo-tag that acts a little differently. Comment #0 asks for a pseudo-tag, we have a patch for a pseudo-tag, so why not embrace the pseudo-tag but make it a little more user friendly? Let me say it like this. *Every* message has a special pseudo-tag with a binary value: "Tagged" or "Untagged". So we take the existing patch and make these changes: 1) "--Untagged--(*)" (default start) becomes "Tagged(*)" (activated). 2) You can't deactivate that tag. Examples: | All of | [ Tagged (*) ] [ Work(*) ] [ Personal(*) ] ==> "Work and Personal". | Any of | [ Untagged(*) ] [ Work(*) ] ==> "Untagged or Work". | Any of | [ Untagged(*) ] [ --Work(*)-- ] ==> "Untagged or not Work"

Magnus and Richard: Can you please present your complete solution. Magnus, brief as always, only said: [ Has Tag ] _ | Any of | [ Important ] [ ToDo ] No idea where "No Tag" is and what the logical conjunction at the spot marked _ is, see comment #30. Richard said: And position the "No Tag" button before the "Any of" menulist. For my proposal the button should be always labelled "No Tag". What's the difference to Magnus': | All of | [ToDo] [Later] [x] + untagged How do you just get untagged messages using this approach?

(In reply to Jorg K (GMT+2, PTO during summer) from comment #33) > Magnus and Richard: > Can you please present your complete solution. > > Magnus, brief as always, only said: > [ Has Tag ] _ | Any of | [ Important ] [ ToDo ] > No idea where "No Tag" is and what the logical conjunction at the spot > marked _ is, see comment #30. > > Richard said: > And position the "No Tag" button before the "Any of" menulist. > For my proposal the button should be always labelled "No Tag". > What's the difference to Magnus': > | All of | [ToDo] [Later] [x] + untagged > How do you just get untagged messages using this approach? [ No Tag ] | Any of | [ Important ] [ ToDo ] After clicking "No Tag" it would be: [ No Tag ] | All of | [ -I-m-p-o-r-t-a-n-t- ] [ -T-o-D-o- ] "No Tag" has no active state, on click it negates the tags and sets the menulist to "All of". The only issue I'm seeing is that the QFB memorizes the "All of"/"Any of" state.

(In reply to Richard Marti (:Paenglab) from comment #34) > "No Tag" has no active state, on click it negates the tags and sets the > menulist to "All of". And how do you get untagged messages? You can do "All of" now and negate all tags but that doesn't give you untagged messages.

Stroked through tag means "not this tag". To become the effect of comment 34 you need the patch from this bug which enables the no tag filtering. Without the patch it filters only in the tags, untagged messages are always filtered out.

So you're changing existing behaviour without that being reflected in the UI, hmm. How about we run through some use cases. Let's assume we only have "Work" and "Personal": 1) "Work" and "Personal" 2) "Work" or "Personal" 3) Not "Work" and not "Personal" 4) Untagged. 5) Untagged or "Work" 6) Untagged or not "Work". Existing: 1) |All of| "Work(*)" "Personal(*)" 2) |Any of| "Work(*)" "Personal(*)" 3) |All of| "--Work--" "--Personal--" 4)-6) Can't do Jörg (which is Kent's solution): 1) |All of| "Tagged(*)" "Work(*)" "Personal(*)" 2) |Any of| "Tagged" "Work(*)" "Personal(*)" (oops, I need to deselect the pseudo, grrr, otherwise I get other tagged messages in the result. 3) |All of| "Tagged(*)" "--Work--" "--Personal--" 4) |Any of| "Untagged(*)" "Work" "Personal" 5) |Any of| "Untagged(*)" "Work(*)" 6) |Any of| "Untagged(*)" "--Work--". Hmm, this is really the existing solution from Kent's patch, with the only change to change the label "--Untagged--" to "Tagged". Richard: 1) |All of| "Work(*)" "Personal(*)" 2) |Any of| "Work(*)" "Personal(*)" 3) Can't do, since |All of| "--Work--" "--Personal--" will show untagged messages as per Richard's comment #36. An untagged message will fulfil "not Work" and "not Personal". 4) |All of| "--Work--" "--Personal--" 5) Can't do. 6) Can't do. Richard, unless I missed something, your suggestion doesn't fly. I come to the conclusion that the implemented solution is best, perhaps with the change in label from "--Untagged--" to "Tagged". Magnus, do you have a simple solution that covers the six cases?

You're right. But the button which changes between "Tagged" and "Untagged" isn't optimal. How should the user know that clicking the "Tagged" button it changes to "Untagged"? I'm still for the actual patch which shows the untagged pseudo-tag stroked through. With this the user sees the untagged are filtered out and with the tooltip he learns what the stroke means.

(In reply to Richard Marti (:Paenglab) from comment #38) > But the button which changes between "Tagged" and "Untagged" > isn't optimal. Agreed. But a button that has "Untagged" struck out as the first thing the user sees is not optimal either, in fact, it's absolutely frightening ;-( Kents initial proposal/add-on had "Has Tag", which is equivalent to "Tagged". > How should the user know that clicking the "Tagged" button it > changes to "Untagged"? Well, the tooltip says "right click to exclude", so if you exclude "tagged" you get "untagged". Naturally ;-) > I'm still for the actual patch ... Yes, I see no simpler solution, but I'd like to cut down on the surprise. A "Tagged" or "Has Tag" is conceptually much simpler than a negated "untagged", you must admit that. Anyway, it's all idle discussion now at comment #39 (far from 200). I think we need to see what Magnus is willing to approve and whether he has a simpler solution. Again, Magnus, do you have a simple solution that covers the six cases from comment #37? Richard and I and most likely Kent have been through it over and over and can't see anything better than what is presented here, perhaps with a small tweak.

I've actually hacked Kent's patch and got it to do this. How does this look?

(In reply to Jorg K (GMT+2, PTO during summer) from comment #40) > Created attachment 8782641 [details] > Some scenarios using Tagged and Untagged. > > I've actually hacked Kent's patch and got it to do this. > > How does this look? We can try it. But how should the button work? Does it only change to untagged with right click? What happens when you left click? Or does it toggle between the two states no matter if right- or left click?

I mean toggling between Tagged and Untagged. This button has no inactive state.

Richard, I was mistaken when I asked for a two state button, see comment #37, case 2) "Work" or "Personal" 2) |Any of| "Tagged" "Work(*)" "Personal(*)" (oops, I need to deselect the pseudo, grrr, otherwise I get other tagged messages in the result. The "Tagged/Untagged" button also needs three states: "Tagged(*)", "Untagged(*)" and unselected, I suggest also with the "Tagged" label. So I suggest to take Kent's patch with one change only to the button label/strike through: Kent ==> My suggestion --Untagged--(*) ==> Tagged(*) Untagged(*) stays. Untagged (deselected) ==> Tagged (deselected). My hack of Kent's patch can't fully do that, so that's why I can't attach it here and instead attached a picture of the cases that work. Anyway, I mocked up the deselect case as well.

Well, I kind of like it (Jörg's suggestion). Instead of thinking about tree-state for the "Tagged" button I'd suggest maybe we just make that button special, and just have a tag icon/struck through tag icon for it. That would make it small, but also make it not jump around due to the label change, and you wouldn't have to think about double negatives.

(In reply to Magnus Melin from comment #44) > Well, I kind of like it (Jörg's suggestion). Hmm, after sleeping over it, I don't like it any more. I find it confusing that in case 2) "Work" or "Personal" you need to deselect "Tagged" or else, you still get all tagged messages. Remember my "Tagged(*)" is really a "--Untagged--(*)", that is in |Any of| "Tagged(*)" "Work(*)" "Personal(*)" or originally |Any of| "--Untagged--(*)" "Work(*)" "Personal(*)" *all* tagged messages show up. How about Magnus' suggestion from comment #18?

This is Kent's patch with icons for untagged pseudo-tag for Linux and Win 7+. If this would be the way I create some for XP and Mac (and the existing could be improved). The pseudo-tag button has still 3 states and needs to be changed to two states but it's for a first test (right click to enable untagged and right click to disable).

Richard, thanks for the icons. That gets us out of the naming problem: "Has Tags", "No Tags", "Untagged", "Tagged" (which was really "Any Tag") and worst of all "-U-n-t-a-g-g-e-d-". The two states solution would be like Magnus' suggestion from comment #18 and it would be good-bye to the notion of an "untagged" (or any other) pseudo-tag (see last paragraph). If the option is unchecked, it would just mean: Business as usual, look at tagged messages only. With the option is checked it would mean: Include untagged messages and tagged ones that fulfil the given conditions only. That is: If no conditions are given for tagged ones, don't include any tagged one. Kent said in comment #20 (quote): I'm sorry, but I don't like your suggestion, Magnus. I'm afraid he won't like this suggestion either, but obviously we can't find anything that everyone likes. What I don't like about the pseudo-tag approach is case 2) where I have to deselect the pseudo, whatever it's flavour, to get "tag1 or tag2" since "or'ing" in the pseudo would always "or" in any other tag. So Richard and Magnus: Do we agree now on the "two state with icon" solution which would look like in the attached picture?

"two state with icon" would be okay for me.

If you apply this horrible hack on top of Richard's patch (attachment 8782858 [details] [diff] [review]) you get the "two state with icon" we discussed. Please clear any saved state before you start or the initial selection might be wrong. This is only mildly tested and it just hacks the desired behaviour into place but you can reproduce the the cases shown in my last picture (attachment 8782912 [details]). Don't tell me that some stuff doesn't work, this is to show the concept only. Magnus: Do you like it like this?

(In reply to Jorg K (GMT+2, PTO during summer) from comment #50) > Created attachment 8783083 [details] [diff] [review] > Hack Kent ;-) > > This is only mildly tested and it just hacks the desired behaviour into > place but you can reproduce the the cases shown in my last picture > (attachment 8782912 [details]). > > Don't tell me that some stuff doesn't work, this is to show the concept only. This is how it should work (in my opinion).

Didn't try it, but the pics look good to me!

Works like in the picture (attachment 8782912 [details]). Kent are you prepared to integrate my ugly hack into your solution? Even if you don't like the solution 100%, look at the bright side: We/you get the UI change landed in under 100 comments, maybe even less than 60 ;-)

(In reply to Jorg K (GMT+2, PTO during summer) from comment #50) > Don't tell me that some stuff doesn't work, this is to show the concept only. Actually, the hack doesn't work in all cases: "No Tag(*)" and "-W-o-r-k-(*)" gives the untagged messages and the tagged ones which are not "Work" (see picture), but now unselecting "No Tag" doesn't change the result although now the untagged messages shouldn't show any more. I won't hack it any more and leave this to the final solution.

Wow! Amazing stuff done here, I like it. Suggested tooltips for two-state iconic button: "Show untagged messages" (when button is inactive/up) "Hide untagged messages" (when button is active/down) (For the avoidance of doubt, let's tell the user exactly what this will do, depending on button state) Just a thought - how does the current layout work with "All of"? I.e., what if I have... > [All of] [Untagged(*)] [Work(*)] [Personal(*)]...? From reading the UI, this should result in: > Show all messages WHERE ((Untagged==true) AND (Work==true) AND (Personal==true)) Which doesn't make sense. As Magnus said, we want "plus untagged": > Show all messages WHERE (Untagged==true) *OR* ((Work==true) AND (Personal==true)) Proposed minimal tweak to get this right (UT = Untagged; | = Separator): Move the iconic Untagged-button before Any-of-button (similar to Magnus comment 23): >P1: [UT] | [Any of] [Work] [Personal] Alternatively, we might want to move it to the far end >P2: [Any of] [Work] [Personal] ... | [UT] If at the end, we could even use the full caption again, now without any double negatives: >P3: [Any of] [Work] [Personal] ... | [Untagged] Why? 1) ux-natural-mapping: Controls should be placed in the correct location relative to the effect that they will have. [All of] is not applicable to [Untagged], but the UI wrongly suggests that. 2) [Untagged] button is different type: As Magnus hinted in comment 18, this button in its current design effectively acts as a *two-state* checkbox: > (Show Untagged) == true | false Which does make it a slightly different animal compared to all those *triple-state* tags out there. E.g., right-clicking Untagged will probably do nothing, as opposed to other tags. 3) [Untagged] button has different behaviour: All tag buttons: If button not pressed, messages having that tag will show. Untagged button: If button not pressed, messages having "untagged" pseudo-tag will *not* show. Which means that per current design, it's NOT a pseudo-tag, but a simple checkbox which just shows or hides untagged messages *regardless* of (i.e. in addition to) any other combinations of tags currently chosen. Btw, with our new button we're also somewhat wronging the current tooltip of [Tags] filter button: "Show only messages with tags on them" Which we can probably ignore, but it's yet another hint that "Untagged" is a different animal which should live in its own cage.

In short, any of proposals P1, P2, P3 of my comment 55 fix the current UX-natural-mapping problem because they'll now be correct UI representation of filters involving "All of": > Show all messages WHERE (Untagged==true) *OR* ((Work==true) AND (Personal==true)) > P1: [UT*] | [All of] [Work*] [Personal*] > P2: [All of] [Work*] [Personal*] ... | [UT (*)]

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #55) > Alternatively, we might want to move it to the far end Depending of the count of tags the button wouldn't be always at the same position. It's better to place this static button before or after the menulist.

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #55) > Wow! Amazing stuff done here, I like it. Where have you been ;-) > Just a thought - how does the current layout work with "All of"? > I.e., what if I have... > > [All of] [Untagged(*)] [Work(*)] [Personal(*)]...? > From reading the UI, this should result in: > > Show all messages WHERE ((Untagged==true) AND (Work==true) AND (Personal==true)) > Which doesn't make sense. As Magnus said, we want "plus untagged": > > Show all messages WHERE (Untagged==true) *OR* ((Work==true) AND (Personal==true)) Good observation. > Proposed minimal tweak to get this right (UT = Untagged; | = Separator): > Move the iconic Untagged-button before Any-of-button (similar to Magnus > comment 23): > >P1: [UT] | [Any of] [Work] [Personal] That's been suggested before. I think before is best. Initially Kent started with a "pseudo-tag" at the same level as the others, so |All of| [Untagged(*)] [Work(*)] would of course come to nothing. With the solution introduced in comment #48 and following, we moved away from that. I don't think Kent will be pleased. <repeated stuff> In case you haven't read all the comments I'll repeat from comment #48: === What I don't like about the pseudo-tag approach is case 2) ("Work" or "Personal") where I have to deselect the pseudo, whatever it's flavour, to get "tag1 or tag2" since "or'ing" in the pseudo would always "or" in any other tag. === Example: [UT(*)] OR [Work(*)] OR [Personal(*)] isn't what we want. [-U-T-(*)] OR [Work(*)] OR [Personal(*)] isn't what we want either. Note that [-U-T-(*)] comes to "Has any tag". </repeated stuff>

(In reply to Richard Marti (:Paenglab) from comment #57) > (In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment > #55) > > Alternatively, we might want to move it to the far end > > Depending of the count of tags the button wouldn't be always at the same > position. It's better to place this static button before or after the > menulist. Fwiw, P2 and P3 assume that the [Untagged] button (iconic or not) will always be in a fixed position at the far right end of the tags toolbar. So it doesn't matter how many tags are there, if there are two many, they would scroll in their own container which ends just *before* the [Untagged] button.

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #59) > Fwiw, P2 and P3 assume that the [Untagged] button (iconic or not) will > always be in a fixed position at the far right end of the tags toolbar. So > it doesn't matter how many tags are there, if there are two many, they would > scroll in their own container which ends just *before* the [Untagged] button. On wide screens or with only few tags the button would be too far away from the other elements.

Now with all platform icons.

Wow, this stuff is brain-warping. Let me try to clarify what we have, pls correct me if I'm wrong. I'll also present my preferred proposal, which is a modified variant of Kent's original 3-state approach. Pls note: For ease of comparing, per my comment 55, I'll always place the new button to the front, before [Any of] selector; so I'm modifying the layout but not functionality of original proposals below. [UT] = iconic "Untagged" button [T] = iconic "Tagged/Has Tag" button (Richard's icon, but without the diagonal strike-through) 1) PLUS-UNTAGGED: TWO-STATE UNTAGGED PER MAGNUS COMMENT 18 * Show/hide untagged messages /in addition/ to whichever tag filters are active or not (current results plus untagged) * [UT(*)] | [Any of] [Work] [Personal] --> show untagged messages OR work OR personal (i.e. all messages) + Simple and intuitive + Allows *all messages* view (e.g. to then exclude only some tags) without exiting tag filter bar - No easy way to show untagged messages only (would have to explicitly negate all tags) 2) FILTER-UNTAGGED: TWO-STATE UNTAGGED PER JORG'S ATTACHMENT 8782912 [details], behaviour per comment 48 * Showing untagged messages will hide all tags which are not selected (<-- different from Magnus) * [UT(*)] | [Any of] [Work] [Personal] --> show untagged messages only; can add more tag filters + Easy "untagged messages only" filter (left-click) - No easy way to start out from showing *all* messages (e.g. to exclude only some tags); showing all messages requires exiting/closing tag filter bar completely which is not convenient 3) UN-TAGGED-NINJA: THREE-STATE *TAGGED* ADAPTED FROM KENT'S ATTACHMENT 8764047 [details] (but with new UI) * combines the best of both worlds: PLUS-UNTAGGED and FILTER-UNTAGGED * behaviour mostly as seen in addon attachment 8764047 [details] and described in comment 5 (but with new UI proposed here, and one odd behaviour changed**) * Fix ux-natural-mapping problem (see comment 55): Place new button *before* [Any of/All of] Selector because a) we can't have [All of] "not tagged" AND "someTag" and b) we are in a filter mode called "Show tagged messages only" so "untagged" messages is a different animal which should be clearly separate from tags. 1.1) [T(*)] | [Any of] [Work] [Personal] --> default: show tagged messages only (as before this bug) 1.2) [T(*)] | [Any of] [Work(*)] [Personal] --> tagged + filter: show "work" only (as before this bug)** 0.1) [T ] | [Any of] [Work] [Personal] --> unfiltered: "all messages view"; easy filter start (new!) 0.2) [T ] | [Any of] [Work(*)] [Personal] --> filter: show "work" only (as before this bug) -1.1)[-T-(*)]| [Any of] [Work] [Personal] --> FILTER-UNTAGGED: show "untagged" messages only -1.2)[-T-(*)]| [Any of] [Work(*)] [Personal] --> PLUS-UNTAGGED: show "untagged" plus "work" + Intuitive default state: [T(*)] = "Tagged/Has tags" filter is active; no double negatives, no default strike-throughs; logically correct placement at the *start* of tags filter bar + Easy "untagged messages only" filter: [-T-(*)] (right-click: Not Tagged = Untagged) + Integrated "All messages" view: Unselecting [T] conveniently allows returning to "all messages" view without exiting/closing tags filter bar; which is a good starting point for filtering by excluding/including specific tags - Filtering for "untagged only" by negating "tagged" via right-click may not be immediately intuitive (but tooltip can assist here) **Pls note there seems to be a bug / odd behaviour in the addon: [T(*)] | [Any of] [Work(*)] [Personal] --> should imo show only "Work", but is still showing "Personal", too Bottom line: My favorite is Variant 3) UN-TAGGED-NINJA, adapted from Kent's original proposal to address problems found in the discussion of this bug. * three-state for maximum functionality including convenient "All messages" view * repositioned, iconic "Tagged" button (improved!) * by default, not affecting current behaviour * avoid double negatives * reasonably intuitive using existic three-state logic of tag filter butons (which we need to expose more, probably using tooltips) Variant 2), Jörg's FILTER-UNTAGGEG, is totally good except that it doesn't feature "All messages" view, which imo is the key benefit of Kent's three-state approach. Users who actually need tag filters will also frequently need to swap back to "All messages" view, which is much more convenient without having to hide the tag filter bar each time. Variant 1), Magnus' PLUS-UNTAGGED, heads into the right direction by repositioning our new button as an external OR-condition outside tag-filtering, but imho it's a non-starter because it can't easily filter for "untagged only". @Kent, you may speak up now or remain forever silent ;) @Everyone (happy to see you guys from South Africa where I currently am): happy head cracking! ;)

Advanced philosophy: A new, binary "Untagged" button would really belong onto top-level quick filter bar, next to the main "Tags" button. So from top-level, you could pick either "Show tagged messages" or "Show untagged messages". However, imo we shouldn't put it there because we also want combinations like ("Untagged messages" OR "messages having certain tags"), but in the main QFB all conditions are force-chained using "AND". So it's better and required to have our new button on the secondary tag filter bar.

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #62) > Wow, this stuff is brain-warping. Yes. > Let me try to clarify what we have, pls correct me if I'm wrong. YES. > **Pls note there seems to be a bug / odd behaviour in the addon: > [T(*)] | [Any of] [Work(*)] [Personal] --> should imo show only "Work", but > is still showing "Personal", too That's not a bug, that's a feature. In Kent's solution there is a pseudo-tag. Let's call it "Has Tag" for the sake of the argument. Any message that has a tag *also* has pseudo-tag "Has Tag". So clearly: [T(*)] | [Any of] [Work(*)] [Personal] will show all tagged messages. It is: Give me all the message that (have any tag) OR (have tag "Work"). That's why for me the pseudo-attribute doesn't fly. You can't explain to the user the they have to deselect the pseudo to get "Work" only. I'm not sure I have to work through your comment #62 since it's (obviously?) not based on a full understanding on what is suggested. Let me repeat for the n-th time: === What I don't like about the pseudo-tag approach is case 2) ("Work" or "Personal") where I have to deselect the pseudo, whatever it's flavour, to get "tag1 or tag2" since "or'ing" in the pseudo would always "or" in any other tag. === Obviously I was confused, since you can simplify ("Work" or "Personal") to just ("Work"). P.S.: Kent was "away from the keyboard" for a few days, also, I don't believe he likes wordy discussions.

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #62) > Variant 2), Jörg's FILTER-UNTAGGED, is totally good except that it doesn't > feature "All messages" view, ... Correct. If you want all messages, simply switch the filter off. > ... which imo is the key benefit of Kent's three-state approach. The key down-side, which I tried to explain about 100 times now, is that you need to switch to the third state "inactive" to get "Work" alone or ("Work" or "Personal"). It's not a bug, it's a feature. 1.2) [T(*)] | [Any of] [Work(*)] [Personal] --> tagged + filter: show "work" only (as before this bug)** 0.2) [T ] | [Any of] [Work(*)] [Personal] --> filter: show "work" only (as before this bug) Clearly: NO. It would make no sense to expect the same result here. 1.2 will show *all* tagged messages.

In favor of three-state "Tagged" which I adapted from Kent's original model (see comment 62), let's have a second look at Richard's review comments against the original, most of which I believe are no longer applicable: (In reply to Richard Marti (:Paenglab) from comment #6) > Comment on attachment 8764047 [details] > notagfilters.xpi > > I think, we shouldn't add this button when we have the menulist "Any of, All > of". This option should go into this menulist as "Not of", and when chosen, > then all tags are selected. I think we have already agreed that "None of", while attractive at first sight, is actually a can of worms which doesn't make intuitive UI. We'd also have to force-change button states quite a lot, as Richard points out. > I don't see what's the difference between the strike through tag and the not > selected tag. I think this makes the UI unneeded complicated I think this review comment is obsoleted by Richard's own comment 8: > Ah now I see, the "strike through" works also without your extension. I > thought this from comment 3 needed to be implemented. Right-click to negate conditions (strike-through) is existing UI which is quite intuitive albeit currently not very discoverable. We should change that, probably using tooltips. As for the difference between strike-through and unselected, or, iow: WHY WOULD WE NEED A THIRD BUTTON STATE? #UNSELECTED means this filter is currently *not applied*, so any other filters set will override. - Note that in the default state of the tag filter bar, this means that top-level "Tags" filter is still active which means "Show only messages with tags on them". That's why initially all tagged messages are showing even though no tag filter is selected. - Same for proposed unselected state of "Tagged" iconic button: If "tagged" is NOT SELECTED, it's currently not applied, so "untagged" messages will initially show alongside all "tagged" messages, which is "All messages view". However, selecting any other tag filter will override that because it's not an explicitly selected filter, but just a bigger initial scope to filter from, so if I select "Work", "untagged" messages will go away and only messages tagged "Work" will show. Think about it, that's totally correct and useful behaviour for users who depend on tagging. #STRIKE-THROUGH means that the *negation* of this filter is currently applied, as in (NOT Condition). - For proposed strike-through state of "Tagged" iconic button: NOT TAGGED = UNTAGGED, so untagged messages are explicitly included in the filter, and will show up in results until user explicitly unselects or flips this condition. Again, nothing special here, behaves exactly as all other tag buttons. We only tweak the logical connection a bit because E.g. "untagged" AND "someTag" doesn't work, and "Tagged" and "someTag" should obviously only return "someTag". (In reply to Richard Marti (:Paenglab) from comment #8) > I think a "Untagged" or "No tag" pseudo tag would be easier to understand If we agree that three-state is useful as it adds integrated "All messages" view and allows convenient swapping to and from that view without exiting tag filter, then "Tagged" as in Kent's original proposal is easier to realize as we want to avoid "Not Untagged" default states (double negative). As a sidenote, personally, I don't perceive the notion of "Not untagged" as a double negative, because "untagged" is an easily understandable term with a fixed reference. However, when it comes to icons, "Not Untagged" isn't easy to visualize, whereas "Tagged" and "-Tagged-" icons work just fine. Note that we have moved away from the notion of pseudo-tag because it fails for "All of". > because the "Has tag" needs two right clicks to set the "no tag". > If it would go directly to exclude on the first right click then it could be > clearer for the user. Agreed! When "Tagged" icon is selected (pressed down, active filter), a single right-click must immediately flip this to "Not Tagged", i.e. strike-trough "-Tagged-" icon. That can be done! > This pseudo tag should also be the first tag to be > always at the same position with different amount of tags. Fixed position sounds good, and per ux-natural-mapping, it should be "first on toolbar" position, before [Any of/All of] selector (see comment 55). To sum up, these are the three button states as proposed in comment 62, Variant 3): 1) [T (*)] "Tagged" filter is selected/active: Show only tagged messages. Current default. 0) [T ] "Tagged" filter is unselected/neutral: Show untagged messages alongside tagged messages (i.e. all messages) as long as no other explicit tag filter is set. Convenient "All messages" view. -1) [-T-(*)] "NOT Tagged" filter is active: Show only untagged messages (if no other tag filter set), or untagged messages alongside selected tagged messages. The latter being highly useful to find messages that haven't been tagged yet but actually should have been tagged according to their category. So e.g. filtering for "Un-tagged" and "work" allows you to find work mails which just haven't been tagged as such yet.

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #66) > To sum up, these are the three button states as proposed in comment 62, Variant 3): > Variant 3): Sorry, I still don't think you've understood Kent's concept of a pseudo-tag: > 1) [T (*)] "Tagged" filter is selected/active: Show only tagged messages. > Current default. NO. This means: Show all messages that have *any* tag at all. > -1) [-T-(*)] "NOT Tagged" filter is active: Show only untagged messages (if > no other tag filter set), or untagged messages alongside selected tagged > messages. NO. Please try Kent's add-on. You will see that negated "Has tag" and "Work" comes to nothing since: Show messages that have no tag and have tag "Work" clearly is an empty set.

(In reply to Jorg K (GMT+2, PTO during summer) from comment #64) > (In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment > #62) Sorry Jorg, but unfortunately it's you who doesn't understand my suggestion, maybe because you didn't read my all of my comment 62, as you said... > > **Pls note there seems to be a bug / odd behaviour in the addon: > That's not a bug, that's a feature. So clearly: > [T(*)] | [Any of] [Work(*)] [Personal] > will show all tagged messages. It is: > Give me all the message that (have any tag) OR (have tag "Work"). As you correctly say, that would be annoying and it doesn't make sense. But it's totally up to us to change that behaviour (according to my suggestion), more so as I moved the [Tagged] button away from all the tag conditions. Please don't force your narrow interpretation onto everyone. > That's why for me the pseudo-attribute doesn't fly. You can't explain to the > user the they have to deselect the pseudo to get "Work" only. Exactly. That's why the don't have to deselect it in my proposal and it'll just work as expected. Try to understand [Tagged (*)] as a duplicate of the same button on the top-level quick filter bar, then my button has exactly the same icon and same behaviour. Duplicating makes sense because hiding the tag filter bar just to get back to "All messages", and then having to switch it back on for your next tag filtering, is certainly annoying to tag-affine users. > I'm not sure I have to work through your comment #62 since it's (obviously?) > not based on a full understanding on what is suggested. Thanks for the compliment, but rushing to wrong conclusions isn't helpful... > Let me repeat for the n-th time: > === > What I don't like about the pseudo-tag approach is case 2) ("Work" or > "Personal") where I have to deselect the pseudo, whatever it's flavour, to > get "tag1 or tag2" since "or'ing" in the pseudo would always "or" in any > other tag. > === > Obviously I was confused, since you can simplify ("Work" or "Personal") to > just ("Work"). No need for repetition... I wasn't ignoring or misunderstanding that comment; I addressed it. My proposal does not suffer from that problem. > P.S.: Kent was "away from the keyboard" for a few days, also, I don't > believe he likes wordy discussions. Please stop insinuating. Also: Pls let Kent speak for himself. Wordy or not, I was speaking up in support of a modified version of Kent's proposal after careful examination, because I think it has the best overall feature set. I haven't seen anybody else mentioning the advantage of integrated "All messages" view which comes with three-state, so no need to shoot at me at this point. Thanks.

(In reply to Jorg K (GMT+2, PTO during summer) from comment #65) > (In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment > #62) > > Variant 2), Jörg's FILTER-UNTAGGED, is totally good except that it doesn't > > feature "All messages" view, ... > Correct. If you want all messages, simply switch the filter off. Sorry, but imho that's not simple enough. It's actually annoying for tag-affine users because each time they want to see "All messages", they have to hide the entire tag filter bar, and then to show it again for the next tag filtering. Instead of just having the tag filter bar always visible and hide/show untagged messages as required, including "All messages" view. > > ... which imo is the key benefit of Kent's three-state approach. > The key down-side, which I tried to explain about 100 times now, is that you > need to switch to the third state "inactive" to get "Work" alone or ("Work" > or "Personal"). It's not a bug, it's a feature. > > 1.2) [T(*)] | [Any of] [Work(*)] [Personal] --> tagged + filter: show > "work" only (as before this bug)** > 0.2) [T ] | [Any of] [Work(*)] [Personal] --> filter: show "work" only > (as before this bug) > Clearly: NO. It would make no sense to expect the same result here. 1.2 will > show *all* tagged messages. Jorg, like it or not, but according to MY proposal, which was explicitly marked as "ADAPTED FROM KENT'S PROPOSAL, with new UI, and one odd behaviour changed", 1.2 will just do the sane thing which is: > 1.2) [T(*)] | [Any of] [Work(*)] [Personal] --> tagged + filter: show > "work" only (as before this bug)** If you understand the [T] button as a partial, deliberate duplicate of the main [Tags] filter button, there's nothing logically wrong about the behaviour I suggested: First, select "Tagged" messages only. Second, select "Work" to reduce result set from "All tagged" to "Tagged: Work". That's quite simply "Tagged" AND "Work". Who said the logical connection must be OR? If you so wish, my proposed behaviour dynamically toggles the logical link between [T] and the other tag filters between AND and OR. May sound strange, but the resulting behaviour is imo quite straight forward.

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #69) Sorry, I got confused since you called a *feature* of Kent's initial solution a bug/odd behaviour: > **Pls note there seems to be a bug / odd behaviour in the addon: This is *central* to the pseudo-tag approach. See also comment #20. I can see that we have three proposals here now: 1) Magnus/Jörg (as partly seen in Kent's patch plus Jörg's hack on top, in fact, the hack is completely wrong in its approach but works in some cases). 2) Kent *pure* pseudo-tag as seen in his add-ons or the proposed patch. 3) Full-blown Thomas approach (inspired by Kent, but dropping one central part). So you're saying in your approach that 1.2) [T(*)] | [Any of] [Work(*)] [Personal] --> tagged + filter: show "work" only 0.2) [T ] | [Any of] [Work(*)] [Personal] --> filter: show "work" only should show the same result? How many UX principles does this infringe? The user toggles a setting and nothing happens??? I can see three states for tags: - tag doesn't matter for the query (deselected) - messages with this tag (selected) - messages with a tag but not with this tag (struck out). For any other UX element I find a three states highly confusing. They were somewhat tolerable for the pseudo-tag, but led to logical but "odd behaviour". If you want all messages as an option, we should precede with *two* buttons. Untagged and Tagged. Untagged (not) active = (don't) show all untagged messages additionally. Tagged active: Show all tagged messages. Tagged not active: Show tagged messages according to tag conditions. All messages: Untagged and Tagged Active. All tagged messages only: Tagged Active. Previous behaviour: Untagged not active. Tagged active. Setting a special condition on tags automatically deactivates Tagged. Activating Tagged automatically clears the special tag conditions. Every click does something. Having "all tagged messages" (Tagged active) and setting special tag conditions is mutually exclusive. You can call this "Jörg Mark 2" inspired by Thomas ;-) Personally I'd say that the current implementation is already flawed. If you select nothing, you implicitly get (OR over all existing tags). Well, in my solution, if you switch both buttons off, you get nothing, and you can then add conditions.

(Midair collision, so this was written without considering Jorg's comment 70.) (In reply to Jorg K (GMT+2, PTO during summer) from comment #67) > (In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment > #66) > > To sum up, these are the three button states as proposed in comment 62, Variant 3): > > Variant 3): > Sorry, I still don't think you've understood Kent's concept of a pseudo-tag: Sorry, I think you still don't understand that I've never claimed to use exactly Kent's concept, but I explicitly *adapted* his concept, i.e. I changed it to become a different proposal of mine with different UI and slightly different behaviour. > > 1) [T (*)] "Tagged" filter is selected/active: Show only tagged messages. > > Current default. > NO. This means: Show all messages that have *any* tag at all. Huh? I don't see the difference between "Show only tagged messages" (what I said) and "Show all messages that have any tag" (what you said). Our wording differs, the result set is just the same. Kent's addon has this: [Any of] "Has tag (*)" "Work(*)" --> All tagged messages. While arguably logically correct, I'm not sure if that's a feature, but maybe Kent can clarify. Feature or not, imo it's odd and doesn't make sense, that's why my proposal begs to differ by relocating the button and changing the behaviour to something which imo makes more sense and is more efficient. If I overlooked something, I'll be happy to learn. I'm deliberately wordy hoping to avoid more misunderstandings such as seen with Jorg. > > -1) [-T-(*)] "NOT Tagged" filter is active: Show only untagged messages (if > > no other tag filter set), or untagged messages alongside selected tagged > > messages. > NO. Please try Kent's add-on. Please stop insinuating. I've obviously tried Kent's addon, but my proposal deliberately and explicitly changes some of Kent's UI and behaviour. Again, looks like you're rushing to conclusions because you don't understand my proposal. Also, your description of Kent's add-on behaviour is both incorrect and incomplete. Both the odd behaviour which I correctly described AND some of the behaviour described by you are present. It all depends on the state of [Any of] vs. [All of]. > You will see that *negated* "Has tag" and "Work" comes to nothing since: In my installation with Kent's addon: [Any of] "-Has-tag-(*)" "Work(*)" --> "Work" only. Which is perfectly correct, and NOT empty. [All of] "Has tag(*)" and "Work(*)" --> Indeed, that's an empty set. Also nonsensical, > Show messages that have no tag *and* have tag "Work" clearly is an empty set. Who said the logical connection is ^^ AND?? In my proposal, "Tagged" button is explicitly *outside* the scope of [Any of/All of] Selector, and there's no explicit definition of the logical connection in the UI, so we are free to dynamically change the logical connector so as to get the best overall behaviour. Jorg, please refrain from confusing people by twisting my proposal. Kent's addon-behaviour is NOT relevant for my proposal, because my design differs. My proposal for threestate behaviour remains exactly this (I'll add explanation for implicit logical operators): (In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #62) Note that | represents a toolbar separator, not a logical operator. > 1.1) [T(*)] | [Any of] [Work] [Personal] --> default: show tagged messages > only (as before this bug) > 1.2) [T(*)] | [Any of] [Work(*)] [Personal] --> tagged + filter: show > "work" only (as before this bug)** When "Tagged" has active state: For 1.1, logical operator doesn't matter because only one criterium selected. For 1.2, *in my proposal*, it's implicit "AND": --> "Tagged" AND "Work" > 0.1) [T ] | [Any of] [Work] [Personal] --> unfiltered: "all messages > view"; easy filter start (new!) > 0.2) [T ] | [Any of] [Work(*)] [Personal] --> filter: show "work" only > (as before this bug) When "Tagged" has unselected state: For 0.1, logical operator doesn't matter because no filter criteria selected. Hence we're showing all messages. Just that. For 0.2, logical operator doesn't matter because "Tagged" is unselected, so it's just the explicit tag filters, which work as usual, and same as Kent's addon. > -1.1)[-T-(*)]| [Any of] [Work] [Personal] --> FILTER-UNTAGGED: show > "untagged" messages only > -1.2)[-T-(*)]| [Any of] [Work(*)] [Personal] --> PLUS-UNTAGGED: show > "untagged" plus "work" When "Tagged" has negative state (strike-through): For -1.1, logical operator doesn't matter because no tag filter criteria selected. For -1.2, *in my proposal*, it's implicit "OR": --> "Untagged" OR "Work" (We can't use AND because it's nonsensical/empty: "Untagged" AND "Work") There's no need to look into [All of] because it just applies between the individual tag filters, so that should work the same way. So if you conflate those cases, it becomes very simple: 1 [T (*)] Tagged active state: --> "Tagged" AND "anyTagFilterCriteria" 0 [T ] Tagged unselected state: -1 [-T-(*)] Tagged negative state: --> "Untagged" OR "anyTagFilterCriteria" (<-- different from Kent's original proposal) Resulting behaviour is imo straightforward, and very versatile, improving Kent's proposal while keeping the full range of three-state functionality.

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #71) > Resulting behaviour is imo straightforward, and very versatile, improving > Kent's proposal while keeping the full range of three-state functionality. Check out "Jörg Mark 2" ;-)

(In reply to Jorg K (GMT+2, PTO during summer) from comment #70) > (In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment > #69) > Sorry, I got confused since you called a *feature* of Kent's initial > solution a bug/odd behaviour: Thanks for admitting your confusion about my proposal. > > **Pls note there seems to be a bug / odd behaviour in the addon: > This is *central* to the pseudo-tag approach. See also comment #20. Ah well, *central* or not, opinions might differ. > I can see that we have three proposals here now: > 1) Magnus/Jörg (as partly seen in Kent's patch plus Jörg's hack on top, > in fact, the hack is completely wrong in its approach but works in some > cases). > 2) Kent *pure* pseudo-tag as seen in his add-ons or the proposed patch. > 3) Full-blown Thomas approach (inspired by Kent, but dropping one central > part). I'm not dropping a central part, I'm just changing an implicit logical operator as explained in my comment 71, to avoid exactly those problems Jorg claims to have already mentioned 100 times (really??). > So you're saying in your approach that > 1.2) [T(*)] | [Any of] [Work(*)] [Personal] --> tagged + filter: show > "work" only > 0.2) [T ] | [Any of] [Work(*)] [Personal] --> filter: show "work" only > should show the same result? > > How many UX principles does this infringe? The user toggles a setting and > nothing happens??? Please stop exaggerating and insinuating. At first sight, this may seem to violate ux-userfeedback, and perhaps ux-mode-error; ux-control if we push it to the limits. Please note that Kent's original add-on has similar, if not same behaviour: In some situations, changing button status will NOT change the result set. User doesn't toggle a setting, user toggles *filter criteria*. After applying filter criteria in a predictable way, using predictable and sane logical operators, the correct and expected result set must be shown. There's nothing special about changing filter criteria and not getting a changed result set; it all depends on criteria and data. So I don't think we're violating any UX principles here, but let's check to make sure: ux-userfeedback: "interfaces should provide feedback about their current status. Users should never wonder what state the system is in." So if you switch from [T(*)] to [T ], and there's at least one other active tag filter, the result set doesn't change because although "Tagged" is unselected (hence irrelevant) on tag filter bar, the top-level active [Tags] button still enforces "Show only messages with tags on them". That's a minor but deliberate duplication of functionality. Please note that no matter how we design this, as [Tagged], or [Untagged], inside or outside the scope of [Any of/All of] Selector, we will *always* duplicate/interfere with the functionality of top-level [Tags] filter because just showing untagged messages at all while [Tags] filter is on, already violates the current tooltip description and default behaviour: "Show only messages with tags on them". ux-mode-error: "users should not encounter errors because the interface is in a different state than they expected it to be." I don't think this applies, no errors caused, on the contrary, we're trying to make things more efficient and intuitive, to improve ux-efficiency. ux-control: "users should always feel like they are in control of their software." Ah well. Dito. > I can see three states for tags: > - tag doesn't matter for the query (deselected) > - messages with this tag (selected) > - messages with a tag but not with this tag (struck out). > > For any other UX element I find a three states highly confusing. They were > somewhat tolerable for the pseudo-tag, but led to logical but "odd > behaviour". Thanks for acknowledging (exactly as I said) that some of Kent's current behaviour is actually odd. Oops, no, that came out wrong ;) It's some of the behaviour of Kent's addon which isn't ideal... If somebody could tweak Kent's addon to demonstrate my proposal, we could find out under real-life conditions how confusing or not this actually is. Given that I'm eliminating some of Kent's addon's odd behaviour, it should be less confusing than Kent's original addon behaviour, of which he was already convinced that it is actually intuitive because it works just like the other tag selectors. > If you want all messages as an option, we should precede with *two* buttons. > Untagged and Tagged. Located where? On top-level filter bar, or tag filter bar? After reading the full proposal, these buttons would probably be more correctly labelled: "All Untagged" and "All Tagged" > Untagged (not) active = (don't) show all untagged messages additionally. > Tagged active: Show all tagged messages. > Tagged not active: Show tagged messages according to tag conditions. I need more time to fully understand this, but having two buttons about essentially the same thing, that initially sounds a lot more confusing to me. If you spell out the exact behaviour and interaction of those buttons, maybe it'll make sense. > All messages: > Untagged and Tagged Active. > > All tagged messages only: > Tagged Active. And then you must also toggle "Untagged" to Inactive, or not? Can you please clarify the position of those buttons, their interaction, and the logical operators? > Previous behaviour: Is it really?? Previous to what? > Untagged not active. > Tagged active. > Setting a special condition on tags automatically deactivates Tagged. I almost lost you here... Jörg is trying to say that with a special tag condition set, it's now "Some tagged" and no longer strictly "All tagged", so "All tagged" button becomes deactivated. Is this really intuitive? I'll think about it... > Activating Tagged automatically clears the special tag conditions. Oh, because "Tagged (*)" is now strictly "Show all tagged" (see above for better button labels). > Every click does something. That's not a goal in itself for filter conditions. > Having "all tagged messages" (Tagged active) and > setting special tag conditions is mutually exclusive. You can call this > "Jörg Mark 2" inspired by Thomas ;-) > > Personally I'd say that the current implementation is already flawed. > If you select nothing, you implicitly get (OR over all existing tags). Maybe you don't understand the current implementation... But I admit it was also getting me irritated more than once... Current implementation is NOT flawed because user has explicitly activated top-level [Tags] button which per tooltip translates to "Show only messages with tags on them". So per definitionem, when you see the tags toolbar, we're working on the limited dataset of all "Tagged" messages, and all those unselected tags are the next selectors to narrow down your result. Thinking about it, that's perfectly correct. As long as we keep that definition on the top-level button, adding whichever variant of a (Un)tagged button on the tag filter toolbar is actually violating the primary logic. Dirty but useful. I already commented on that philosophical issue and its implications in my comment 63, where I explained why having two top-level filter buttons (Tagged, Untagged) would seem right at first but doesn't get us to the full filter feature set which we want, apart from having implied logical operator issues. > Well, in my solution, if you switch both buttons off, you get nothing, and > you can then add conditions. Interesting approach! Although most of the filters are designed to *narrow down* from a bigger search result, not to build up from zero, so this might appear ux-inconsistent...

FTR: If we find another icon for "Untagged" which perhaps does not already have a strike-through, using three-state "Untagged" may also become feasible again when the "-UT-" icon with strike-through wouldn't have a double strike-through. I was thinking maybe a dotted tag outline with no filling to indicate that there's no tag.

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #73) > > If you want all messages as an option, we should precede with *two* buttons. > > Untagged and Tagged. > Located where? On top-level filter bar, or tag filter bar? As I said: *Precede* with two buttons. So using your nomenclature: [All Untagged] [All Tagged] |Any/All| [Tag-1] ... [Tag-N] Mind you, I suggest to use icons for the first two buttons. Initial state could be: [All Untagged] [All Tagged(*)] |Any/All| [Tag-1] ... [Tag-N] > I almost lost you here... Jörg is trying to say that with a special tag > condition set, it's now "Some tagged" and no longer strictly "All tagged", > so "All tagged" button becomes deactivated. Exactly. Richard also suggested some button interaction at the bottom of comment #34. If you hit [All tagged] the individual conditions become reset and if your set an individual condition, [All tagged] is deselected. That gives you maximum clarity, flexibility, speed, you name it. Hence: "Mark 2" (inspired by Thomas D.). It also makes clear that there it is: [All Untagged] OR (any conditions on tags). > I'll think about it... Please do. > But I admit it was also getting me irritated more than once... > Current implementation is NOT flawed because user has explicitly activated > top-level [Tags] button which per tooltip translates to "Show only messages > with tags on them". Yes, but we're busily changing that. We want to show untagged messages and you even want an "all messages" mode. As you've pointed out in comment #55, that tooltip would have to change to something like: "Show messages based on their tags." Richard, what do you think of my suggestion?

(In reply to Jorg K (GMT+2, PTO during summer) from comment #75) > As you've pointed out in comment #55, that tooltip would have to change to > something like: > "Show messages based on their tags." > > Richard, what do you think of my suggestion? Yes, r what about "Show only messages based on their tags."? The "Show only messages" would be inline with the existing tooltips.

Here you can see what I mean. Clean, quick, flexible.

(In reply to Jorg K (GMT+2, PTO during summer) from comment #75) > [All Untagged] [All Tagged] |Any/All| [Tag-1] ... [Tag-N] > Exactly. Richard also suggested some button interaction at the bottom of > comment #34. > If you hit [All tagged] the individual conditions become reset and if your > set an individual condition, [All tagged] is deselected. That gives you > maximum clarity, flexibility, speed, you name it. Hence: "Mark 2" (inspired > by Thomas D.). My brain is fried, but I'm a fair fighter so I'd like to pay (preliminary) respect where respect is due: Jörgs latest "Mark 2" proposal having two iconic toggle buttons [All-UT] and [All-T] looks very interesting and promising to me (pending further reflection and specification). Here's why: For people with loads of different tags in complex combinations, having something like a "Reset filter" button for the individual tag criteria will certainly be most welcome and efficient. Apart from defining the initial scopes, Jörgs "All-T" button provides just that: "Reset tag filter" feature, without exiting tag filter toolbar. Let's say I've filtered for (set1): Work + ToDo + ProjektThunderbird + Feature + UX-efficiency And I want to continue on (set2): Private + ToDo + Friends + BirthdayParty, manually unselecting each of set1 tags can be quite cumbersome. Instead, I'll just click on Jörg's "All-Tagged" button (now active) and all existing tag filters will be reset, now showing all tagged messages. Then I select the tags of set2 to narrow down the result set of tagged messages. Then I click on Jörg's "All-Untagged" button to include all untagged messages for tagging some more Friends which should also be tagged BirthdayParty, now showing all untagged plus those msgs having tags from set2. If tagged messages are in the way, I can hide all tagged messages by unselecting "All-Tagged", so I remain with "All-Untagged". Button functionality would be straight-forward, with dynamic tooltips: [All-UT] -> "Show all untagged messages" [All-UT (*)] -> "Hide all untagged messages" [All-T] -> "Show all tagged messages" [All-T (*)] -> "Hide all tagged messages" [Tag-X] (any state) -> "Include messages having tag "Tag-X"; right-click to exclude this tag" Or, if we are lazy and concise, with generic tooltip, as Kent proposed: -> "Click to include; right-click to exclude" (yeah, that might be sufficient) As a minor disadvantage of Jörg's Mark 2 two-button approach, certain filters will now require two clicks, e.g. "Show all untagged messages" will typically require to "Hide all tagged messages", and then a second click on "Show all untagged messages". Compared to benefits like integrated "Reset filter" functionality, and more clarity, flexibility, speed, you name it (inspired by Thomas D.), that's a small sacrifice which is more than made up for. Interactive demo (addon) would be best for conclusive evaluation of the new look and feel. Ah cool, Jörg just added attachment 8783690 [details] with mockup screenshots...

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #78) > Interactive demo (addon) would be best for conclusive evaluation of the new > look and feel. No way, Josay ;-) I'm working full time here (at least today, fighting all sorts of fires, like bustage, test failures, discussing here for hours, etc.) You can see it in the mock up, you need to use your imagination for the cases not covered there, like: [All Untagged(*)] [All Tagged(*)] = All and the dynamic, that hitting "All Tagged" will reset tags to the right and hitting a tag to the right will reset "All Tagged".

(In reply to Richard Marti (:Paenglab) from comment #76) > Yes, what about "Show only messages based on their tags."? The "Show only > messages" would be in line with the existing tooltips. I'm all for consistency, but "Show only messages based on their tags" sounds somehow semantically odd/twisted to me. It suggests that we're a) always limiting the result set ('only') b) 'based on (all of?) /their/ tags', both of which isn't quite right. a) we are no longer always limiting the result set b) even if limited, it would rather be 'based on selected tags' or 'based on tag filters' or 'filtered by (their) tags'. So I'd prefer something like (in order of preference, most preferred on top): 1) "Show messages filtered by tags" (That's quite right, simple, precise, and still sufficiently consistent, plus probably easy to translate: "Nachrichten gefiltert nach Tags anzeigen"). 2) "Show messages based on (their) tags" 3) "Filter messages by (their) tags" 4) "Filter messages based on (their) tags" Or how about: 5) "Show only messages based on tag filters"? That sounds quite right, precise, and consistent, too. But it's probably harder to translate. Nah, I like 1) better. Just my 2 cents.

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #80) > So I'd prefer something like (in order of preference, most preferred on top): > 1) "Show messages filtered by tags" (That's quite right, simple, precise, ... Fine, but why don't we decide on the shape of the solution first before discussing the fine print? We're going for "Mark 2"?

Apologies for coming late to this, but this bug is one of 30+ my extension TotalQuickFilter addresses for the quickfilter bar. I don't think a separate button indicating negation is the best way to go; it adds visual clutter/confusion and every bit of real estate in Tb needs to be conserved. The paradigm already exists to right click negate any specific matched tag, so right click on the Tag button should simply show a strikethrough and mean 'Show all non tagged messages'. That's all this rfe is asking for - the solutions are veering into hypercomplexity. The extension implements right click negation (ctrl-enter for keyboard) for all the other non text filter buttons, and tokenizes text terms for right click negation too: Bug 349085 Can't search on negative terms in Thunderbird's Quick Filter box with NOT or minus Bug 744365 Quickfilter: inverse selection (thus inverse filter) https://addons.mozilla.org/en-US/thunderbird/addon/totalquickfilter/

Let's not over-complicate things. To reset the "tags" criteria you simply click the Tags button twice (tha's how it works today). I still something like attachment 8782912 [details] best.

(In reply to alta88 from comment #82) > Apologies for coming late to this, but this bug is one of 30+ my extension > TotalQuickFilter addresses for the quickfilter bar. Constructive input should always be welcome... > I don't think a separate button indicating negation is the best way to go; > it adds visual clutter/confusion and every bit of real estate in Tb needs to > be conserved. Please have a look at the user story which I wrote up based on comments and ideas in this bug. Having "Untagged messages only" filter is indeed the minimal feature set of this bug. However, I think while we are here, and looking at current proposals, we're trying to do a bit more than that. Latest proposal is much more than just a "button indicating negation" (of Tagged). One or two iconic buttons aren't visual clutter if they are needed, useful and intuitive. > The paradigm already exists to right click negate any > specific matched tag, so right click on the Tag button should simply show a > strikethrough and mean 'Show all non tagged messages'. Alta is talking about the top-level [Tags] button on quick filter bar, and he wants to right-click on that and get "Untagged messages" only. That's a worthwhile proposition, but it would cover only the minimum solution for this bug, is not very discoverable, and doesn't cover any of the other scenarios outlined in the user story of this bug. > That's all this rfe > is asking for - the solutions are veering into hypercomplexity. I disagree. Jörg's latest proposal "Mark 2" of attachment 8783690 [details] covers an amazing range of functionality with a very simple and straighforward binary design: Show/hide Untagged messages. Show/hide Tagged messages. I'm not yet totally sold on the latter, but let's just play with it and see where we get. Even the other solutions offered so far, as outlined in my comment 62, are not "hypercomplexity", but they differ in ease of use and feature set. > The extension implements right click negation (ctrl-enter for keyboard) for > all the other non text filter buttons, and tokenizes text terms for right > click negation too: > Bug 349085 Can't search on negative terms in Thunderbird's Quick Filter box > with NOT or minus > Bug 744365 Quickfilter: inverse selection (thus inverse filter) Those are all good but outside the scope of this bug. It's good to keep that in mind though as we design the solution here. If negating the top-level [Tags] button is a wanted feature, that might affect our options of implemention here. > https://addons.mozilla.org/en-US/thunderbird/addon/totalquickfilter/ Thanks for sharing this.

(In reply to Magnus Melin from comment #83) > Let's not over-complicate things. To reset the "tags" criteria you simply > click the Tags button twice (that's how it works today). Quite sub-optimal, really, since the tag filter bar gets removed and displayed again the whole message pane jumps twice. > I still something like attachment 8782912 [details] best. With the new icon moved to the right as in attachment 8783690 [details]?

(In reply to alta88 from comment #82) > https://addons.mozilla.org/en-US/thunderbird/addon/totalquickfilter/ Thanks. Yes, this can show untagged messages, but as far as I can see, it doesn't allow a combination of untagged plus some qualified tagged messages, so "untagged" + "Work". (In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #84) > Jörg's latest proposal "Mark 2" of attachment 8783690 [details] > covers an amazing range of functionality with a very simple and > straighforward binary design: Show/hide Untagged messages. Show/hide Tagged > messages. Indeed. And no hidden assumptions as the solution in attachment 8782912 [details] has. There the hidden assumption is that if untagged messages are shown, tagged message are not shown unless selected by individual conditions. "Jörg Mark 1" is "totally good", as Thomas said in comment #62, but "Mark 2" gives much more functionality with one icon more on the screen. Just to add to the alleged "hypercomplexity" of this, I suggest another feature: Simple click on "All Tagged" will select button and clear any individual selections on the right. Right-click on "All Tagged" will *deselect* button and clear any individual selections on the right, that's the "reset" functionality. Why? Say you want to get from selection ("Work" or "Personal" or "Important") to only untagged quickly. Click "All Untagged" - untagged messages appear. Right-Click "All Tagged" - tag conditions are cleared and "All Tagged" is also deselected. Without this feature, you'd have to click twice.

(In reply to Jorg K (GMT+2, PTO during summer) from comment #85) > Quite sub-optimal, really, since the tag filter bar gets removed and > displayed again the whole message pane jumps twice. Well, who's to say your next filtering was even going to involve tags... at least it's very intuitive to start over like that. > > I still something like attachment 8782912 [details] best. > With the new icon moved to the right as in attachment 8783690 [details]? Ah yes, having it before the dropdown gives you more flexible searches in the "All of" case.

(In reply to Jorg K (GMT+2, PTO during summer) from comment #86) > Simple click on "All Tagged" will select button and clear any individual > selections on the right. > Right-click on "All Tagged" will *deselect* button and clear any individual > selections on the right, that's the "reset" functionality. Why? > Without this feature, you'd have to click twice. I'm still searching for the alleged hypercomplexity or overcomplication and just can't find it. This is all quite simple and straightforward. Right-click proposal sounds good (not perfect), must be made discoverable with tooltip. Although if we need right-clicks, then we're almost back to three-state with right-click.

(In reply to Magnus Melin from comment #83) > Let's not over-complicate things. To reset the "tags" criteria you simply > click the Tags button twice (tha's how it works today). I still something > like attachment 8782912 [details] best. Hi Magnus, we need at least *one* extra button with hidden assumptions... so having *two* binary iconic buttons instead, which make things more predictable and intuitive, doesn't sound like over-complicating things to me. UX-efficiency is the brand core of Thunderbird, the reason for the existence of the product. Without Thunderbird's added value of ux-efficiency, I can just as well use Gmail web interface. So for any suggested improvements of ux-efficiency, I don't think we should be fast to just casually and superficially dismiss and discourage them. Which is also odd and disappointing, like when contributors invest lots of their precious time for serious development and discussion of improvements and then somebody just comes along with a two-liner to brush everything off the table (as has happened before). (In reply to Magnus Melin from comment #87) > (In reply to Jorg K (GMT+2, PTO during summer) from comment #85) > > Quite sub-optimal, really, since the tag filter bar gets removed and > > displayed again the whole message pane jumps twice. +1 > Well, who's to say your next filtering was even going to involve tags... at > least it's very intuitive to start over like that. Who's to say your next filtering was NOT going to involve tags? What are the odds for a tag filter user to use the tag filter again? Is it really intuitive to nuke the whole filter bar from another level of the UI just to get rid of some criteria? > > > I still something like attachment 8782912 [details] best. > > With the new icon moved to the right as in attachment 8783690 [details]? > Ah yes, having it before the dropdown gives you more flexible searches in > the "All of" case. More like: Having it before the dropdown is a *requirement of ux-natural-mapping principle* because of the "All of" case... Can we at least *try* principled approaches to UX-design? I know that there's a lot of room for interpretation and all, but imho we should avoid the impression that it's just a matter of personal taste where "anything goes" because we somehow "like it" (or not)... Also, I presented that requirement as early as comment 55 (3 days ago), and we're now at comment 88 (yeah, that's Jörg and me speeding things up, but still): Would it be possible to get your affirmative/constructive response to those smaller things which are obvious a bit earlier if you already know it? This would be helpful to narrow down on the requirements/desiderata of the solution, and avoid feelings of first being ignored and then discouraged...

How about we just compare the three solutions: 1 B 2 S = One button, two states (Mark 1, attachment 8782912 [details]). 1 B 3 S = One button, three states (TD solution) 2 B 2 S = Two buttons, two states (Mark 2, attachment 8783690 [details]). | 1 B 2 S | 1 B 3 S | 2 B 2 S | ----------------+---------+---------+---------+ Untagged only | yes | yes | yes | ----------------+---------+---------+---------+ Can show all | no | yes | yes | ----------------+---------+---------+---------+ Orthogonal | no (1) | no (1) | yes | (no hidden | | | | assumptions) | | | | ----------------+---------+---------+---------+ ux userfeedback | yes | no (2) | yes | ----------------+---------+---------+---------+ Quick reset | no | no | yes | ----------------+---------+---------+---------+ (1) Assumption: Button "Untagged" selected doesn't show tagged unless individually selected. (2) [T(*)] | [Any of] [Work(*)] [Personal] [T ] | [Any of] [Work(*)] [Personal] give the same result. Quite obviously I'd go for 5x "yes" instead of 2x "yes" at the cost of an additional button.

Let's revisit that and add Kent's original proposal, the pure pseudo-tag, one button, three states, but different to the T/D solution. | 1 B 2 S | 1 B 3 S | 2 B 2 S | pseudo-tag | ----------------+---------+---------+---------+------------+ Untagged only | yes | yes | yes | yes | ----------------+---------+---------+---------+------------+ Can show all | no | yes | yes | yes | ----------------+---------+---------+---------+------------+ Orthogonal | no (1) | no (1) | yes | yes (3) | (no hidden | | | | | assumptions) | | | | | ----------------+---------+---------+---------+------------+ ux userfeedback | yes | no (2) | yes | yes | ----------------+---------+---------+---------+------------+ Quick reset | no | no | yes | no | ----------------+---------+---------+---------+------------+ (1) Assumption: Button "Untagged" selected doesn't show tagged unless individually selected. (2) [T(*)] | [Any of] [Work(*)] [Personal] [T ] | [Any of] [Work(*)] [Personal] give the same result. (3) You really need to understand what the pseudo-tag does: "Has Tags(*)" == All tagged messages. "Has Tags(*)" or "Work(*)" == All tagged messages. "Has Tags" or "Work(*)" == Messages tagged "Work". T/D called that "odd behaviour", but it's a feature. I can understand that Kent writes in comment #20: === I'm going to return to my original proposal. That is, I will add a "Has Tag" button that looks like, and can be combined with, the specific tags. *It's logical* (yes!), it works with the current design, and it is relatively straight forward to do. === I can understand that for people who are fit in logic, Kent's proposal is attractive, but I have the feeling that the average user will find it odd.

(In reply to Jorg K (GMT+2, PTO during summer) from comment #86) > Simple click on "All Tagged" will select button and clear any individual selections on the right. > Right-click on "All Tagged" will *deselect* button and clear any individual > selections on the right, that's the "reset" functionality. Let's try to get this correct and complete: * If button state is false (unselected), (Either NO tagged messages shown, or tagged messages shown but tag filters set.**) Simple-left-click will - change button state to true (active) - show tagged messages if not yet shown, or otherwise - remove tag filters Simple-right-click will - keep button state false (unselected) - remove tag filters if present and - hide tagged messages if shown * If button state is true (active), (All tagged messages shown, no tag filters active) Simple-left-click or right-click will - change button state to false (unselected) - hide tagged messages I believe it's complicated only in writing, not in action. It would be really good to see this in action for testing purposes. **I'd think that according to Jörg's table, that is also a violation of ux-userfeedback! (imo, it's not, because the UI correctly displays the status that not "All tagged messages" are shown, either because there are none, or because there are some.)

Correction and additions: | 1 B 2 S | 1 B 3 S | 2 B 2 S | pseudo-tag | ----------------+---------+---------+---------+------------+ Untagged only | yes | yes | yes | yes | ----------------+---------+---------+---------+------------+ Can show all | no | yes | yes | yes | ----------------+---------+---------+---------+------------+ Orthogonal | no (1) | no (1) | yes | yes (3) | (no hidden | | | | | assumptions) | | | | | ----------------+---------+---------+---------+------------+ Orthogonal 2 | no | no | yes (6) | no (5) | (conditions | | | | | independent) | | | | | ----------------+---------+---------+---------+------------+ ux userfeedback | yes | no (2) | yes | no (4) | ----------------+---------+---------+---------+------------+ Quick reset | no | no | yes | no | ----------------+---------+---------+---------+------------+ (4) That's actually the "odd behaviour": With "Has Tags(*)" selected, click to select "Work" and nothing happens if "Any of" is selected. It's debatable ;-) (5) Or maybe it's not all so "orthogonal" since one condition includes others. (6) Forced orthogonality by switching other controls as per comment #92 (and earlier). (In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #92) > * If button state is false (unselected), (Either NO tagged messages shown, > or tagged messages shown but tag filters set.**) > ** ... a violation of ux-userfeedback! My definition of "ux userfeedback" is: "Click and something happens", as opposed to "click and nothing happens", so the user doubts themselves or the system since the control did nothing.

(In reply to Jorg K (GMT+2, PTO during summer) from comment #91) > Let's revisit that and add Kent's original proposal, the pure pseudo-tag, > one button, three states, but different to the T/D solution. > > | 1 B 2 S | 1 B 3 S | 2 B 2 S | pseudo-tag | > ----------------+---------+---------+---------+------------+ > Untagged only | yes | yes | yes | yes | > ----------------+---------+---------+---------+------------+ > Can show all | no | yes | yes | yes | > ----------------+---------+---------+---------+------------+ > Orthogonal | no (1) | no (1) | yes | yes (3) | > (no hidden | | | | | > assumptions) | | | | | > ----------------+---------+---------+---------+------------+ > ux userfeedback | yes | no (2) | yes | yes | > ----------------+---------+---------+---------+------------+ > Quick reset | no | no | yes | no | > ----------------+---------+---------+---------+------------+ > > (1) Assumption: Button "Untagged" selected doesn't show tagged unless > individually selected. > (2) [T(*)] | [Any of] [Work(*)] [Personal] > [T ] | [Any of] [Work(*)] [Personal] > give the same result. That is NOT in violation of ux-userfeedback: > Interfaces should provide feedback about their current status. > Users should never wonder what state the system is in. Any button represents a condition, isn't it? [T (*)] active means: condition "tagged" is set [T (*)][Any of][Work (*)] = Tagged AND Work --> Work [T ] unselected means: condition "tagged" is neither set nor denied; it's a non-condition. So initially, we show all messages, if there are no other conditions. 100% correct. [T ][Any of][Work (*)] = (leere Bedingung)(AND/OR) Work --> Work. 100% correct, correctly represented in the UI (Work is the only active filter), so where's the problem? State of the filter system is clear and predictable at any times. Due to the nature of filters, ux-userfeedback can NEVER mean that there's only one UI state to represent the same result set. Please correct your table accordingly. > (3) You really need to understand what the pseudo-tag does: > "Has Tags(*)" == All tagged messages. > "Has Tags(*)" or "Work(*)" == All tagged messages. > "Has Tags" or "Work(*)" == Messages tagged "Work". > T/D called that "odd behaviour", but it's a feature. I totally understand what you're saying about the strict interpretation of {All tags} OR {Work} = Result set {Work}, which is a logically correct result. However, if it's a feature, can someone please explain how this "feature" is useful? I start out from all tagged messages, then I explicitly select another hard filter facet (Work), and result set doesn't change, still seeing all tagged messages. Apart from being technically correct as long as "Tagged" is a pseudo-tag dominated by "Any of", but is this *useful*? Same for "All of" {Untagged} AND {Work} returning {Empty result}, it's correct, but is it useful? > I can understand that Kent writes in comment #20: > === > I'm going to return to my original proposal. That is, I will add a "Has Tag" > button that looks like, and can be combined with, the specific tags. *It's > logical* (yes!), it works with the current design, and it is relatively > straight forward to do. > === > > I can understand that for people who are fit in logic, Kent's proposal is > attractive, but I have the feeling that the average user will find it odd. I'm relatively fit in logic, but I wonder how attractive it can be when there are several "correct" filter states which return practically useless result sets, because of the pseudo-tag design which includes logical domination by [Any of][All of] selector. I also think that given Magnus agreement in comment 87 to our proposal of removing the "Tagged" button from domination by [Any of/All of] selector, we've gone beyond the exact original proposal of Kent already. As for me: Filter behaviour which is {Logically correct} AND {Practically useless} results in: {Odd behaviour}...

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #94) > Please correct your table accordingly. OK, instead of "ux userfeedback" make it "click and see change" or "immediate feedback". > ... we've gone beyond the exact original proposal of Kent already. Indeed. I don't find Kent's proposal so attractive for all the reasons mentioned (also see comment #21). <off topic> While you are in South Africa, I'm on "PTO" (personal time off), 500m away from the beach, where I can't go since I spend my afternoons discussing here (and my nights doing other pressing TB things). So I won't discuss here any more. The options are clear, the advantages and disadvantages as well. How you classify them is not so important. The problem is that according to comment #20, Kent might do his add-on to avoid the discussion which has five-fold since he last commented now nearing comment #100. If not Kent, no one will implement anything here, and even if they did, they'd have a problem getting it past Magnus who seems to favour "Mark 1". I personally don't use tags, so I'm not interested. I just started looking into the bug since Kent mentioned it in Thunderbird status meetings: https://wiki.mozilla.org/Thunderbird/StatusMeetings/2016-07-12#rkent </off topic>.

I've been thinking about this (at the beach). If there is much opposition to the two button solution, we're better off with the T/D solution since it has more functionality. Here a comparison: Case | Mark 2 | T/D | -------------------------+-----------------------------------+----------+ All messages | [All Untagged(*)] [All Tagged(*)] | [T ] | All untagged + sel. tag. | [All Untagged(*)] [All Tagged ] | [-T-(*)] | selected tagged | [All Untagged ] [All Tagged ] | [T (*)] | All tagged | [All Untagged ] [All Tagged(*)] | [T (*)] | I just suggest to force the button to [T(*)] when a specific condition is set, to avoid: 1.2) [T(*)] | [Any of] [Work(*)] [Personal] --> tagged + filter: show "work" only 0.2) [T ] | [Any of] [Work(*)] [Personal] --> filter: show "work" only 0.2 would be eliminated by force so [T] is reserved for "no filter" all messages. I'll do a mock-up in a minute comparing the three options, Mark 1, T/D and Mark 2.

With this at 96 comments, and me already losing patience at 20 comments, it's hard to see how I can further contribute. I'm happy that many people are commenting, and I claim no special insight into how this should be done. At this point I'm happy for my patch to be adapted according to whatever the UI people will accept, as long as there are ways of showing untagged messages. I'm really very focused on my C++->JS adaptation using JsAccount, so I'm happy to release others to work on my patch. Please don't take my lack of patience as a criticism of the discussion.

A picture is worth a thousand words ;-)

(In reply to Jorg K (GMT+2, PTO during summer) from comment #98) > Created attachment 8784085 [details] > Comparison of Mark 1, T/D and Mark 2. > > A picture is worth a thousand words ;-) Isn't for Mark 1 "All messages" also possible: [UT*] [Any of] [Important*] [Work*] [Personal*] ?

(In reply to Richard Marti (:Paenglab) from comment #99) > Isn't for Mark 1 "All messages" also possible: [UT*] [Any of] [Important*] > [Work*] [Personal*] ? Yes, if you switch all the tags on. I'll fix the picture. However, we lost our resource to implement this, see comment #97. I have the honour of completing comment #100 here.

Re "All messages" - you do get that by removing the filtering on Tag completely. That you'd have the tagging filtering visible but still the option of showing all seems redundant to me.

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #89) > Hi Magnus, we need at least *one* extra button with hidden assumptions... so > having *two* binary iconic buttons instead, which make things more > predictable and intuitive, doesn't sound like over-complicating things to > me. I'm yet to be convinced the second button would be all that useful. Bottom line, it's one more button you have to understand, and you ARE duplicating functionality that is present in another way.

So here is the full comparison. In September, when people are back at their desks, I'll ask for some user feedback as was done here: https://mail.mozilla.org/pipermail/tb-planning/2016-April/004683.html People on the list should be (semi-)advanced users who care, so perhaps we get some insight into how people are using tags and which enhancements could benefit them.

Survey here: https://mail.mozilla.org/pipermail/tb-planning/2016-September/004873.html http://goo.gl/PfLQWL

Result of survey: Mark 1: 6 votes (37.5%) Mark 1A: 4 votes (25%) Mark 2: 6 votes (37.5%) Observations: - Very poor participation, only 16 votes. - The simple solution, Mark 1, didn't get the majority. I think it is fair to say that people are looking for more control with solutions Mark 1A or Mark 2. To me, Mark 2 is the winner, since it can do everything the others can do, only in a much more simple, quick and logical way. I'm sure Thomas agrees. I had a long discussion with Aceman on IRC. Like myself, he thought that the current implementation is already flawed (quoting form comment #70): === Personally I'd say that the current implementation is already flawed. If you select nothing, you implicitly get (OR over all existing tags). === With Mark 2, when you first go in, no special condition will be set, the "All tagged" button will be active and all tagged messages will show. That will give the user better feedback on what's going on and somewhat mitigate this flaw. Magnus, are you prepared to accept Mark 2 or will you veto it, and if so, what would give you the right to do so? Aceman and I could implement/review, so you don't have to touch what you don't like. We could even get Kent, now also a TB peer, to review since he promoted this feature in the first place.

First of all, I don't think you can get good data from a survey with this much complexity. For it to have any significance you'd have to have many hundreds of respondents. So in the end, none of the options won, statistically it's just noise. If I'd voted I would have voted #1 and that would have "won". That the options are so hard to understand may also give a hint that we shouldn't add more than one button, so I'll repeat my comment 102. Many times less is just more. The issues you're trying to fix with the additional button have had zero complaints AFAIR.

(In reply to Magnus Melin from comment #102) > (In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment > #89) > > Hi Magnus, we need at least *one* extra button with hidden assumptions... so > > having *two* binary iconic buttons instead, which make things more > > predictable and intuitive, doesn't sound like over-complicating things to > > me. > > I'm yet to be convinced the second button would be all that useful. Bottom > line, it's one more button you have to understand, and you ARE duplicating > functionality that is present in another way. Let's make sure that we really understand the nature and requirements of this RFE. *Minimal requirements for this bug:* 1) Plain Vanilla Untagged Filter: Untagged-only (with as few clicks as possible) The need for a simple way to see only untagged messages. 2) The Kent Scenario: Untagged + Not Later + Not OneWeek (exclude less urgent messages, include untagged) The need to see untagged messages PLUS subset of tagged messages. Kent without negation: Untagged + [Any/All of] Work + ToDo Kent Query Logic: Untagged OR [Any of] Work OR ToDo Untagged OR [All of] Work AND ToDo Kent Query abstract: Untagged OR [Any/All of][Specific Tag Filters] *Essence of current proposals for implementation* All proposals involve adding: Untagged Button on secondary tag filter bar *A new paradigm for secondary tag filter bar* For *all* proposals, Untagged Button on 2ndary tag filter bar radically changes the nature of that bar, from a mere secondary tag filter selector towards a more independent tag filter bar. I'm totally convinced that understanding this is key to understanding and evaluating the UX proposals in front of us. Current Quick Filter Bar Query Logic: > Unread AND Starred AND KnownContact AND *HasTags* AND HasAttachment Note: a) Compulsary AND on primary qfb, we don't offer OR (yet). b) No negations on primary qfb (yet). Can't filter for "Not Starred" AND "Important". Can't filter for "Not Tagged" on primary qfb (yet). c) HasTags = "Show only messages with tags on them": [not] Work [AND/OR] [not] ToDo d) HasTags button triggers a plain and simple tag selector on the secondary bar The plain vanilla part of our new "Untagged" filter is nothing but the negation of the top-level "HasTags" button. We could simply allow negation on all top-level quick filter criteria buttons and that would cover the need for plain vanilla "Untagged-only" filter: > Unread AND Starred AND KnownContact AND *--HasTags--* AND HasAttachment The game changer is the "Kent Scenario" part of our new "Untagged" filter. You can't just put Kent in a box ;) Kent is a jack of all trades playing on *both* primary AND secondary filter bars. This would be the UI required for allowing both Kent and plain vanilla on primary qfb (these are buttons): > Unread AND Starred AND KnownContact AND (*--HasTags--* OR *HasTags*) AND HasAttachment Iow, it would need an *Untagged* button AND a *HasTags* button on primary qfb, where *HasTags* expands to individual tags as it does now. Please note: Kent on primary qfb requires *TWO* buttons!!! This is the inherent reason why two-button proposal is superior and required. Note: Kent Scenario with *two* buttons on primary qfb is another possible UI for what we're trying to implement here, and we can try to explore that, but at first sight it's not ideal: - unexpected special casing of having *two* tag-related buttons (whereas some users need none of them); the reason being that HasTags (after finetuning with specific tag filters) is the only condition where condition and negated condition can coexist for the same filter. - unexpected special casing of having an implicit *OR* condition, whereas the default for primary qfb is AND Note: It so happens from the inner logic of tags, that the default state of active (Untagged OR HasTags) combo-condition, without other conditions, effectively returns *all messages*. Again, these are the only filter criteria which can do that in active state. Any other active filter reduces the result set. We need to understand that the functionality which we are implementing on the secondary tags filter bar inherently belongs to and originates from the primary quick filter bar, with the following button states: Plain Vanilla Untagged: *Untagged(on)* HasTags(off) Kent's scenario: *Untagged(on)* *HasTags(on)* (where HasTags is really a placeholder for any specific combination of tags) Note: to go from Untagged + HasTags to Untagged-only (on primary qfb), you'd simply switch off HasTags. Jorg and I are proposing the same technique, only transposed to the secondary tag filter bar. Now most of the proposed implementations only go half-way and move the *Untagged* button from primary to secondary filter bar, leaving behind the *HasTags* button, out of Kent's minimal pair seen above: (Untagged OR HasTags). So in a way, they pretend that the "HasTags" button from primary bar is still doing the same job as before (which unfortunately isn't true). For those single-button solutions to realize both "plain vanilla" and "Kent", they start to dance around with unexpected behaviour: We are on secondary tag filter bar, which by default has "HasTags" on, showing messages with any tags, or some certain tags. We can't ask the user to switch off a potentially unlimited number of tag filters manually, just to get into "Untagged-only" mode. So those single-button implementations need to tweak the behaviour so that when you click "Untagged", all specific tag filters will suddenly be de-activated, to allow one-click access to plain-vanilla "Untagged-only". So initially it looks like Untagged excludes the presence of other tag filters. Then surprisingly, you can re-activate all those specific tag filters again and they'll stay, together with "Untagged", to allow for the Kent Scenario. This is the resulting UI State for Kent Scenario: *Untagged(on)* OR [Any/all of] *Work(on)* *ToDo(on)* *The key failure of single-button proposals* Absurdly, and violating several UX principles as I shall explain below, all single-button solutions produce different results depending on the *sequence* in which you activate the filter buttons. We're now talking about click sequences (numbered clicks): 1)Untagged + 2)Work + 3)ToDo --> Untagged + Work + ToDo 3)Untagged + 1)Work + 2)ToDo --> Untagged-only Results differ, but the UI-State you were going for is exactly the same!? This is totally counter-intuitive, error-prone, and inefficient if we really understand the Kent-Scenario: User wants to see important messages having Work AND ToDo. So he clicks [all of], Work, then ToDo. But oh, unfortunately, today's messages have not been tagged yet, or tagging skipped a relevant older message ("but there was this other important messages from boss, where is it?"). So the natural thing is to just add "Untagged" to expand the scope and start searching for more messages there which are inherently Work and ToDo, but accidentally not yet tagged. For our single button solutions, performing this perfectly natural click sequence will surprise you with eliminating your hand-picked tag filters first, only for you to add them again one by one. How very stupid. Curse Thunderbird. And rightly so: This type of behaviour violates several ux-principles. *How single-button implicit clear-filter behaviour violates ux-principles* * ux-consistency: All other filter buttons, even on primary qfb, are additive. It must never matter in which order they are clicked, and it doesn't. There's nothing special about Untagged which would make me accept such nonsense behaviour. For quick filter bar, imagine if you are searching for "foo" and you don't seem to find it in recipient, sender, and subject, then you clicked "Body" to expand your scope, and instead of expanding, it suddenly de-activates all of recipient, sender, and subject, forcing you to re-activate them again to get recipient, sender, subject AND body. That's nonsense of the highest order, and nobody would accept it. Why would we accept it here? * ux-error-prevention, ux-mode-error: because of general additive filter behaviour, user has no reason to expect that we'll wipe out his tag filters when Untagged is clicked. I can set 10 specific tag filters, and lose all of them by clicking "Untagged". That's a datalossy error which should never happen. * ux-efficiency: Forcing the user to start all over again just for adding "Untagged" to existing active tag filters is a time-wasting nuisance and highly inefficient. * ux-discovery: Kill-the-tag filters behaviour of single Untagged button makes it much harder to discover that Untagged+SomeTags is a valid combination. Plus we are forcing users to recall from memory that it will only work in the right sequence, but not if you start out from tags. Hard to discover, hard to remember, annyoing to use. Fortunately, we don't have to go that road... *The DUAL BUTTON approach: "Untagged" + "All Tagged"* The two-button solution advocated by Jorg and myself not only avoids all of these problems, but based on the inherent logics of what we are doing here (as explained above), goes all the way to evolve our current secondary tag selector bar into a full-fledged tag filter bar, packed with useful features for the our target group of users, namely (somewhat advanced) users of tag filtering. Jörg and I simply transposed the full combo of {Untagged OR HasTags} from primary qfb onto the start of secondary tag filter bar, as a full and independent combo *in addition* to the existing tag selector. Even though our default state maintains the original "Show only messages with tags on them" logic, we are more transparent about the fact that *all* proposals actually convert the top-level button into "Show me the tag filter bar, initially with only messages with tags on them". For the moment, try to think of the top-level button as a "Show tag filter bar" button. Wanna do stuff with tags, so let's go. What do I want? Dual button UI (*stars* indicate that button is pressed/activated) (Jörg/Thomas): 1) { Untagged *All Tagged* } [all of] Work Todo Plain vanilla scenario, I want untagged only, only 2 clicks to get there: Show "Untagged" (click, to select now seeing all messages), Hide "All Tagged" (click to unselect, safely assisted by dynamic tooltip, "Hide all tagged messages"). (It's 2 clicks owed to the fact that in default state, all proposals mimic the original "Show only messages with tags on them" behaviour). 2) *Untagged* All Tagged [all of] Work Todo From the default state 1), if I want Work and Todo, I'll click just that ("All Tagged" button will auto-deactivate, because it's now *some* tagged, no longer *all* tagged): 3) Untagged All Tagged [all of] *Work* *Todo* From there, for Kent scenario, I want to add Untagged messages alongside Work and Todo, so I just click "Untagged": 4) *Untagged* All Tagged [all of] *Work* *Todo* Note how the UI exactly reflects what you are seeing! And you are free to push your buttons which make your desired set of filters in any order which is convenient for your personal way of thinking and workflows. The only workflow which is minimally harder but still perfectly logical and doable, is to transition from a "Some specific tag filters (Work + ToDo)" scenario to "Untagged-only" scenario. Remember "Untagged-only" is two-click from the default state of secondary tag filter bar, so as Magnus always points out, you're free to hide and unhide your tag filter bar, then simply select "Untagged" and deselect "All Tagged" (that's a felt two-click, but really 4-click). When you have specific tag filters, and you click "Untagged", we can't tell if you want plain-vanilla "Untagged-only" or "Kent scenario" of Untagged PLUS your current filter set. For all the ux-reasons listed above, we have to err in favor of "Kent" and preserve your existing tag filters when you select "Untagged". So to get rid of your specific tag filters, you could first select, then deselect "All Tagged". That's a total of 3 clicks and still reasonable if you think about it, but perhaps not perfectly intuitive and efficient. We can be better, with this tweak: Right-click on inactive "All Tagged" button, i.e. negating "All Tagged", will clear all of your specific tag filters AND keep "All Tagged" button inactive, so "All Tagged" are now hidden. For safe and full discovery of this trick which mimics the right-click negation behaviour of other buttons on this tag filter bar, we'll offer a tooltip on "All Tagged" button, like this: "Click to clear tag filters and show all tagged messages, right-click to clear tag filters and hide all tagged messages." With that, the maximum for getting into "Untagged-only", even from your most sophisticated multi-tag filters, becomes two simple clicks: click "Untagged" to show all untagged messages right-click "All Tagged" to hide all tagged messages (auto-clear of any tag filters) That's the only minimal drawback of dual-button proposal. Otherwise, it's packed with goodness that tag-filter users will LOVE: *More benefits of dual-button tag filter proposal* 1) Clear-Filter functionality: single click on "All Tagged" will reliably clear your specific multi-tag filters (even those you don't see because they are hidden behind the end of the tag filter bar. Moreover, there's visual indication that you can trust: If "All Tagged" is active, you are really seeing "All Tagged" (for which there's no reliable indication so far, neither in current behaviour, nor in single-button proposals). 2) Convenient and reliable return to "All messages" view without hiding your entire tag filter bar: With maximally two clicks, you can temporarily look into "All messages" before proceeding with your next filtering session. "Untagged" + "All Tagged" = "All messages". So easy, so obvious, and easy to get and verify from just the dual buttons. Users of tag filtering will love this. Compare with Quick Filter Bar: There's no reason to hide the entire bar when you know you'll use it again in a minute. So you can just keep your quickfilter bar staying around, even when you're actually on "All messages". Which saves you that one click of unhiding the filter bar each time you need to use a filter. It's so convenient. And if you're the minimalist or clean-up type, you're still free to hide your tag filter bar with a single click whenever you feel like. 3) Clear status indication, transparent and predictable behaviour: At any time, no matter what you're up to, dual button UI will reflect exactly what you're seeing. If "Untagged" is selected, you'll see untagged. If "All Tagged" is selected, you'll see "All Tagged". If both of them are selected, you'll see exactly that, i.e. all messages. If "Untagged", "Work", and "ToDo" are selected, you'll see just that again. And, for your peace of mind and maximum free flow, there'll be no surprises no matter in which order you click your filter buttons. What you click is what you get. Promised. Enjoy! 4) The overall advantage is that tag filter bar, like quick filter bar, becomes a self-contained, full-fledged tag filter bar which has all of your tag filtering needs conveniently combined in one place, so for those who really need tag filtering, they can just keep it open always to access all the goodies on-the-fly.

(In reply to Magnus Melin from comment #106) > First of all, I don't think you can get good data from a survey with this > much complexity. For it to have any significance you'd have to have many > hundreds of respondents. So in the end, none of the options won, > statistically it's just noise. If I'd voted I would have voted #1 and that > would have "won". Yeah, as I pointed out on tb-planning, such surveys have limited value and consequence. > That the options are so hard to understand may also give a hint that we > shouldn't add more than one button, so I'll repeat my comment 102. Many > times less is just more. Unfortunately, this is not true for the case at hand. Do we agree that the minimally required feature set for this bug is Plain Vanilla "Untagged-only" (with as few clicks as possible), and "Kent's scenario" of "Untagged PLUS specific tag filters"? Then squeezing all of that functionality in a single button which unexpectedly vaporizes my tag filters on a perfectly natural click sequence towards the Kent scenario, is poor UX. In this case, two buttons disentangle the functionality and make it easier to understand, change, and verify the filter status from the UI. > The issues you're trying to fix with the additional > button have had zero complaints AFAIR. Following that logic, we could never implement any feature enhancements, so that's a non-argument. We're not "fixing" anything here, we're adding easy, inline "Clear Filter" and "All messages" functionality which evolves the current simple tag selector bar into a fully independent tag filter bar. Target user group are somewhat advanced users of tag filters. They'll certainly appreciate to have all functionality in one place, so that they can keep the tag filter bar open at all times, allowing immediate access to tag filtering with less clicks (just like quick filter bar). Furthermore, we avoid the ux-failures/shortcomings of the single-button approach with minimal cost, but much benefit: Simple toggle buttons, transparent UI status, predictable behaviour, more functionality.

(In reply to Thomas D. (needinfo?me) from comment #107) > Absurdly, and violating several UX principles as I shall explain below, all single-button solutions produce different > results depending on the *sequence* in which you activate the filter buttons. Of course not. And an implementation that did that would probably even be a bit hard to do. For the record, I do keep the quick filter bar open all the time, there's no pain points with that. Clearing the criteria is just one click... If you want to throw around ux-codes: having the second button is lacking ux-consistency with all the other things in the qfb (except text), and has ux-discovery problems + of course lacking in ux-minimalism.

(In reply to Magnus Melin from comment #109) The problem is in the current design, which in my opinion (and also Aceman's with whom I discussed this at length on IRC) is not logical. Currently you can get "all tagged messages" in two ways: 1) No special filter 2) Special filter: OR over all tags. Throwing a single button into that already faulty design would do this: All tagged messages with no special filter + pressing "Untagged" ==> Untagged messages only. All tagged message with OR over all tags + pressing "Untagged" ==> All messaged. Pressing the button would not change any of the special conditions, but it would switch off the hidden condition that shows all tagged messages if no special filters are set. As for throwing around UX terms: All things on the QFB work like this: Show all messages or show messages with attachments only. Show all messages or show unread message only. etc. With tags this UI is a problem since it is not fine enough as there can be many tags. That's why we're here. So *by definition*, whatever you do with tags is already *inconsistent* with anything else. Surely the two buttons have a *discovery* problem, but so has the single button, and it's worse, since there are hidden assumptions at play which the two-button solution would eradicate. And sure, one button is more *minimal* than two. But all those terms don't help us. What is important are the use cases or, as Kent calls it, workflows. What do people want to achieve and how many clicks are required to do it. For me as a mathematician "orthogonality" is important since it helps ux-discovery. If every UI element has a certain clear function, it is much better to have two such UI elements, than one that jumbles up functions. Surely the two-button solution is superior in these regards: Better functionality and more clarity.

(In reply to Jorg K (GMT+2) from comment #110) > Pressing the button would not change any of the special conditions, but it > would switch off the hidden condition that shows all tagged messages if no > special filters are set. The condition as such would not be switched off, it just happens that the result would be the same as if it had been. I think you're thinking too much like a mathematician in this case. Users care how you derived at the solution, they just want the solution. I also don't see why you call it faulty just because you can arrive at the same solution in two ways. Both ways are valid.

(In reply to Jorg K (GMT+2) from comment #110) > (In reply to Magnus Melin from comment #109) > The problem is in the current design, which in my opinion (and also Aceman's > with whom I discussed this at length on IRC) is not logical. Currently you > can get "all tagged messages" in two ways: > 1) No special filter > 2) Special filter: OR over all tags. I agree with Magnus that there's nothing illogical or faulty about the current design. The current "Tags" button on primary quick filter bar (qfb) works like all other conditions on that level: > ...AND (Has Tag == true) --> Show only messages with tags on them (per current tooltip) Then, as Jörg correctly explained, due to the unique and manifold nature of tags, we offer a secondary tag selector bar where the (Has Tag) condition can be finetuned: > ...AND (Has Tag == true) AND ((Tag X) AND/OR (Tag Y)) When "Tags" button is pressed, it means "Has (any) Tag == true". With that, it does not make sense to represent that query as "(Tag X) OR (Tag Y) OR (Tag Z) OR... for a potentially unlimited number of tags, while the individual tags don't even matter. If you want "any fruit", you don't say, I want {apple or pear or orange or pineapple or grapefruit or lemon or...}, even if it's logically the same. It only starts to matter and make sense when you pick selected fruits from the full set of fruits, i.e. to limit the choice: I want {apple or pears or oranges}. Again for practical UX reasons, we can't represent the query (Has Tag) by having all specific Tag buttons active. Because then, if you want to pick a specific Tag as a filter, you'd have to manually switch off all other tags to remain with your favorite tag active, which is obviously not feasible.

If we forget untagged messages for a moment, the current implementation could already be improved with an "All tagged" button. This would be initialised to active with no special tag filters selected. When you select a special tag filter, this button becomes inactive. If you click it again, any special filters are cleared and "All tagged" becomes active again. So it works like a reset button. There is also the special feature that right-clicking "All tagged" will also clear special filters but not activate "All tagged", so there's nothing shown. This feature makes sense together with the "All untagged" button, to switch from a special selection to showing untagged messages only in two clicks.

So I am confused about the state of this, and I have not had time t follow in detail. Is the only thing that is required to switch to a tag icon instead of words from my last r- patch? Are we REALLY accomplishing anything by arguing this to the point of doing nothing?

(In reply to Kent James (:rkent) from comment #114) > Is the only thing that is required to switch to a tag icon instead of words > from my last r- patch? No. We're not favouring your "pseudo tag" approach. There are now "Mark 1" and "Mark 2", see attachment 8784342 [details]. Magnus favours "Mark 1", but that's also different from your solution. > Are we REALLY accomplishing anything by arguing this to the point of doing > nothing? We're not accomplishing anything, it's NATO (no action, talk only). I guess is someone wanted to implement "Mark 1", we could get that landed.

(In reply to Magnus Melin from comment #109) > (In reply to Thomas D. (needinfo?me) from comment #107) > > Absurdly, and violating several UX principles as I shall explain below, all single-button solutions produce different > > results depending on the *sequence* in which you activate the filter buttons. > > Of course not. And an implementation that did that would probably even be a > bit hard to do. Alright, I stand corrected about the proposed behaviour of clicking "Untagged" button (or negating "HasTag" into "Untagged"). However, that just shifts the problems of your favored solution (Mark1) into another corner, they don't go away. > For the record, I do keep the quick filter bar open all the time, there's no > pain points with that. Clearing the criteria is just one click... Right, main quick filter bar (qfb) comes with *inline* "clear filter" functionality: - ESC or click on [x] clears text filter (without closing qfb) - Another ESC clears all other filters like Unread, Starred, etc. (again without closing qfb) So any filters can be cleared *without closing the filter bar*, so as to conveniently keep the bar open for the next filtering. So Magnus, if you love to keep your quick filter bar open all the time, and you appreciate its inline "clear filter" functionality which is what allows you to keep it open, I'm failing to understand why you are so much against having the same convenience for the *tag* filter bar? > If you want to throw around ux-codes: As Kent pointed out, it's about identifying desired workflows and then designing UI and behaviour to enable those workflows in the best possible way. I wouldn't know how to do that without evaluating the design using ux-codes, and, in case of conflicting principles, to try and find a balance. As I said before, we'd probably be biased in favor of ux-efficiency, which imo is the main reason for the existence of TB. An important indicator for ux-efficiency is the number of clicks required for a certain workflow, and how intuitive/discoverable these clicks are. Single button proposals Mark1 and Mark1A fail on that end, as I'll explain in my next comment. > having the second button is lacking ux-consistency with all the other things > in the qfb (except text), I'm not sure if I understand you, because you don't explain yourself... Having "clear filter" functionality is consistent with main quick filter bar, which has [x] and single/double ESC to clear filters. > and has ux-discovery problems As Jörg pointed out, having two buttons with clearly defined functions certainly makes them *more* discoverable. The buttons of "Mark2" proposal are simple and straight forward: [-T-] iconic "All-Untagged" button with dynamic tooltip: "Show/hide untagged messages" [ T ] iconic "All-Tagged" button with dynamic tooltip: "Show/hide all tagged messages" > + of course lacking in ux-minimalism. UX minimalism is not an end in itself, this needs to be balanced against other UX-principles. Convoluting one button with multiple functions and hidden assumptions might be minimalistic, but it's also less intuitive/discoverable and less efficient. Having two clearly distinct iconic buttons instead of one imo does not violate ux-minimalism, more so if it adds extra functionality and ux-efficiency.

(In reply to Kent James (:rkent) from comment #114) > So I am confused about the state of this, and I have not had time t follow > in detail. > Is the only thing that is required to switch to a tag icon instead of words > from my last r- patch? Unfortunately not, as Jörg explained. > Are we REALLY accomplishing anything by arguing this to the point of doing > nothing? If everybody would follow your proposed approach of defining workflows and then building best UI/behaviour to enable them, I think some single-button proposals would appear much less attractive as claimed. More specifically, if we'd systematically weigh the pros and cons in terms of ux-principles. Also if everybody would provide reasons for their preferences, and respond with a minimum of detail to reasons and objections presented by others... Not doing so is what results in communicative failure and repetitive comments when identified issues, pros and cons are continuously ignored. Or maybe we're still unaware about the key features of this RFE, and the true meaning of ux-efficiency... Kent, I'd love to have input from you: Would you agree with the following? 1) Minimal feature set for this RFE: a) Filter for Untagged-only (with as few clicks as possible) b) Filter for Untagged PLUS {specific tags} ("Kent-Scenario") c) Transitions from any set of filters to any other set of filters should be as efficient as possible (i.e. intuitive/discoverable, low number of clicks). User having to touch a potentially unlimited number of {specific tags} filters to transition between filter states is not efficient and must be avoided. 2) Untagged-only (1a) and Untagged-plus (1b) have conflicting needs: a) Untagged-only requires /excluding/ any active {specific tags} filters. However, auto-excluding {specific tags} filters would fail Untagged-plus (b). b) Untagged-plus requires /preserving/ any active {specific tags} filters. However, auto-preserving {specific tags} filters would fail Untagged-only (a). c) This is because of the unique nature of tags, where combining "Tagged" and its negation, "Not Tagged", is NOT a contradiction. If we were to implement our functionality on top-level qfb, it would require *two* (!) buttons linked with inherent OR, the existing "Tags" button and an "Untagged" button. d) It follows from a) and b) that when user filters for "Untagged", we can't tell if he's going for "Untagged-only" or "Untagged-plus", but we have to err in favor of "Untagged-plus" to avoid unexpected clearing of {specific tags} filters, and because the sequence of filter criteria clicks must not matter. So this might require an extra click here and there for user to get the right state. 3) Independent "Tag filter bar" with inline functionality is highly convenient for target user group a) The target user group for this RFE are somewhat advanced users of tag filtering. b) Such users are likely to use tag filtering more frequently and will hence appreciate to have all tag filtering functionality combined into a single tag filter bar at their fingertips, i.e. always open. We already offer the same convenience for users of the main quick filter bar (qfb), where double ESC will clear all filters without closing the qfb. c) Keeping "Tag filter bar" always open requires inline functionality to clear {specific tags} filters so as to see "All tagged", and to see "All messages". Proposal "Mark 2" is the only proposal to offer both. d) Workflows that require hiding the entire tag filter bar to achieve certain tag filtering effects are inconvenient and counter-intuitive. For details, see 4). 4) Single-button proposals "Mark 1" and "Mark 1A" require undesirable click acrobatics for certain filter state transitions a) Transitioning between {specific tags} filters and "Untagged-only" is a legitimate real-life scenario, so we should provide efficient and intuitive click paths for this (see 1c). b) For single-button proposals, this transition requires the following steps: - deselecting a potentially unlimited number of {specific tags} filters manually (which is undesirable, see 1c), OR - hiding the entire tag filter bar to clear {specific tags} filters (which is undesirable, see 3d), AND then - unhiding the tag filter bar to select "Untagged-only" filter (which is nonsensical and annoying because you've just hidden it yourself!). It gets worse when user intuitively click on "Untagged" first on tag filter bar, expecting to get "Untagged-only": - Selecting "Untagged" on tag filter bar (!) will effect filter state "Untagged-plus" {specific tags} filters (Kent-scenario per 1b, 1d), which in this case is not the desired filter state. - to get rid of {specific tags} filters, user needs to either deselect a potentially unlimited number of {specific tags} filters manually (undesirable, see 1c), OR - hide the entire tag filter bar to clear {specific tags} filters (also undesirable, see 3d), AND then - unhide the tag filter bar (which you've just hidden yourself, grrr) AND then - select "Untagged" again(!) which you had already selected before. GRRRR! c) The same transition is significantly easier with dual-button proposal "Mark 2", as favored by Jörg and Thomas: - Select "Untagged" on tag filter bar to show all untagged messages - Right-click "All-tagged" on tag filter bar to hide all tagged messages - DONE. Guided by dynamic tooltips. - Alternatively, click "All-tagged" twice to show and hide "All-Tagged" and remain with "All-Untagged". - no hide-and-unhide acrobatics, convenient inline functionality on tag filter bar which remains always open d) With single-button proposals, similar unintuitive and inefficient transitions occur for the following: - Untagged-plus {specific tags} filters --> Untagged-only - {specific tags} filters --> All tagged This is because single-button proposals lack one-click, *inline* "clear-specific-tag-filters" functionality. - Transitioning from any filter state into "All messages" requires hiding the entire tag filter bar (for single-button proposals). This is because single-button proposals lack inline "All messages" functionality (All-Untagged + All-Tagged = All messages). 5) Dual button proposal "Mark 2" comes with further advantages: a) clear and non-brainer filter state indicators at any time; e.g. if "All-tagged" is active you'll know for sure that all tagged messages are shown, and there's no hidden filter condition at the out-of-screen end of tag filter bar. b) orthogonal handling of "All-Untagged" and "All-Tagged" which is conceptually clear and simple. c) no hidden assumptions; single-button proposals switch off the hidden condition of "Tagged-only" when you select "All-Untagged" without {specific tags} filters set. Kent, fyi: I believe the inner reason why dual button proposal "Mark 2" is better is that it somewhat mirrors the minimal implementation if we were to place the "Untagged-only" and "Untagged-plus" functionality of this RFE on the top-level quick filter bar, which would require the following UI (indicating [Buttons] plus logical connectors of filter conditions): > [Unread] AND [Starred] AND [Contact] AND *{[Untagged] OR [Tagged-Selector]}* AND [Attachment]. - Note that this is an alternative working implementation of this RFE. But I think self-contained, feature-complete "tag filter bar" is better. - Note that this requires *two* buttons to allow for both "Untagged-only" and "Untagged-plus". - "Mark 2" essentially transposes those two buttons to the tag filter bar, with a minimal tweak.

ni?rkent for my comment 117 https://bugzilla.mozilla.org/show_bug.cgi?id=683809#c117

Sorry Thomas, but I do not have time to read and evaluate a long comment at the moment.

As to why I don't like the second button - it would appear unlikely that you are filtering on more than 2-3 tags at the time. So a "clear" button is not really needed. - you seem to want to make "all untagged" (only) a supported use case for the bar. It's about tags. If you don't want tags you turn of the "tags" button instead of leaving that open. - clicking tags would have to shift state of the other other buttons, which is unusual and might feel odd

(In reply to Magnus Melin from comment #120) Thanks for offering a minimum of explanation... > As to why I don't like the second button > - it would appear unlikely that you are filtering on more than 2-3 tags at > the time. So a "clear" button is not really needed. If I can choose between... - 3 clicks on specific buttons, at varying distance, some of which might be hidden at the far end of tag filter bar meaning I have to scroll there first to even see them, OR - 1 click on a dedicated fixed position button which will *always* reliably clear all of my individual filters, even those which are hidden, ... I'll definitely choose the latter. I don't know about you, but me I love TB because of its outstanding ux-efficiency. Otherwise I'd use gmail.com, but that's nowhere near TB features and efficiency. > - you seem to want to make "all untagged" (only) a supported use case for > the bar. It's about tags. If you don't want tags you turn of the "tags" > button instead of leaving that open. I'm losing you here... I can't believe that you're saying what I understand from what you're saying... Are you saying that "All-Untagged-only" should NOT be a supported use case for the secondary tag filter bar? If so, what is this bug about? The Kent-scenario only (Untagged + Specific-Tags)? Why? I see a summary saying "Quick Filter: Untagged messages", and comment 0 requesting "Untagged-only". Except myself, mostly in comment 107 and 117, nobody has ever mentioned nor proposed placing "Untagged" button on the primary quick filter bar. Are you proposing to place "Untagged" button on the primary quick filter bar? I explained that it would work and be logically correct but I also gave reasons why it's probably not ideal compared to self-contained tag filter bar. Plus I don't understand your workflow for "All-Untagged-only"... Are you saying that in order to get untagged-only, user can switch off (unselect) "Tags" button on main quick filter bar? That will offer "All-messages", but NOT "All-Untagged-only". Or maybe it's a misunderstanding because your references are not clear: "the bar": which one? leaving "that" open: what? Can you please be more specific? For other usecases, I think I've explained in extenso why keeping the tag filter bar always open is a usability advantage, and you yourself admitted to keeping your quick filter bar always open, for a reason, I guess. > - clicking tags would have to shift state of the other other buttons, which > is unusual and might feel odd That's not quite true. For "Mark 2" proposal, the default state is this (*btn* indicating selected button): > Untagged *All-Tagged* [all/any of] TagX TagY TagZ So from that UI-State it's perfectly clear that "All-Tagged" are shown. And before you complain about duplication, no it's not duplicated, because all proposals offered so far in this bug (Mark1, Mark1A, Mark2) change the meaning of the top-level "Tags" button on quick filter bar to "Show tag filter bar, with initial state of 'All-Tagged'". So for the top-level tags-button I proposed simple tooltip of "Filter messages by tags" or "Show messages filtered by tags" in comment 80. The "All-Tagged"-button on secondary quick filter bar becomes the new "Show only messages with tags on them" button, transposed from first to second toolbar. After selecting specific tags, it's no longer *All-Tagged*, so we simply deselect All-Tagged (not sure what's unusual or odd about that, and we're only shifting the "All-Tagged" button, NEVER the "All-Untagged" button. > Untagged All-Tagged [all/any of] TagX *TagY* TagZ So from that UI-State it's perfectly clear that only "TagY" is shown. If you click "Untagged" now, you'll get into Kent-scenario (Untagged + Specific-Tags): > *Untagged* All-Tagged [all/any of] TagX *TagY* TagZ So from that UI-State it's perfectly clear that Untagged + Specific-Tags are shown. I'm still failing to see your problem with Mark2, and I think the advantages of that proposal have not been sufficiently honored.

(In further reply to Magnus Melin from comment #120) > As to why I don't like the second button > - it would appear unlikely that you are filtering on more than 2-3 tags at > the time. So a "clear" button is not really needed. Without my lawyer and my crystal ball, I don't feel in a position to guess how many tags other users may or may not filter on, how long those tags are, and if they are even visible on the limited length of our secondary tag filter bar, where we're just adding more buttons at the front. That all depends on their very personal way of using tags. All-Tagged button is more than just a "clear" button. It's a reliable status indicator and fast switch for "All-Tagged"/"Any-Tagged" condition (which cannot always be deducted from UI because of hidden overflowing tags on the tag filter bar). It disentangles All-Untagged and All-Tagged which are inherently two different, orthogonal things. It also allows simple inline way of temporarily showing "All-Messages" without exiting quick filter bar, by intuitively combining "All-Untagged + All-Tagged = All messages".

(In reply to Thomas D. (needinfo?me) from comment #121) > > - you seem to want to make "all untagged" (only) a supported use case for > > the bar. It's about tags. If you don't want tags you turn of the "tags" > > button instead of leaving that open. Right, I meant primary use case, not supported. > Except myself, mostly in comment 107 and 117, nobody has ever mentioned nor > proposed placing "Untagged" button on the primary quick filter bar. Are you > proposing to place "Untagged" button on the primary quick filter bar? I No. > Plus I don't understand your workflow for "All-Untagged-only"... Are you > saying that in order to get untagged-only, user can switch off (unselect) > "Tags" button on main quick filter bar? That will offer "All-messages", but > NOT "All-Untagged-only". This is what I'm saying. Viewing all-untagged from under the Tags button is not a primary use case. I'd rather go the bug 744365 way for that - so that you just right-click the Tags button to get the inverse state instead. > > - clicking tags would have to shift state of the other other buttons, which > > is unusual and might feel odd > After selecting specific tags, it's no longer *All-Tagged*, so we simply > deselect All-Tagged (not sure what's unusual or odd about that, and we're > only shifting the "All-Tagged" button, NEVER the "All-Untagged" button. ... like I wrote, you're shifting state of one button by clicking another (tag button).

Clearly missed all deadlines.

WONTFIX due to lack of consensus.

Planning to revive this at some point.

Magnus, there was a very viable concept presented that even got approved by the community (small turnout), but you're blocking it. Maybe the ESC can finally come to a decision here: https://mail.mozilla.org/pipermail/tb-planning/2018-August/006131.html

You can't ask people very complex technical questions and think you get an informed answer. And in this case, basically you got a tie with total lack of any kind of statistical significance, so let's not pretend any given concept was approved. "How can people tell you what they want if they haven’t seen it before?" [Steve Jobs] People need to see it in action to say anything.

Yep, attachment 8784342 [details]. That's as close as I can get before writing a prototype. But we work too much for the trash can, so that's not going to happen. Those taking the decisions *were* informed enough and the concept of the two buttons was explained well enough.