Open Bug 562050 Opened 14 years ago Updated 4 months ago

Not Junk button in the mail viewer may be confusing to some users

Categories

(Thunderbird :: Mail Window Front End, enhancement)

Product:
Thunderbird
Component:
Mail Window Front End
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: ccurtis0, Unassigned)

References

(Depends on 2 open bugs, Blocks 1 open bug)

Details

Attachments

(4 files)

A screenshot of the current TB3 in case the site in the initial report goes away.
72.95 KB, image/jpeg
Details
These are all the pieces that would go away with the closure of this bug.
79.49 KB, image/jpeg
Details
A relatively simple UI change to use the generic bayesian tag backend.
68.30 KB, image/jpeg
Details
A brief peek into a future of "bayes tags = folders"
71.37 KB, image/jpeg
Details 
User-Agent:       Mozilla/5.0 (compatible; Konqueror/4.4; Linux) KHTML/4.4.2 (like Gecko) Kubuntu
Build Identifier: 

I just reinstalled the released Seamonkey (2.0.4) for my grandfather and watched him use it for a while.  What I see as a big problem is this:  There is a large icon in the icon bar that toggles between "Junk" and "Not Junk".

When he clicks on a message, if it is NOT junk, this button says "Junk".  If the message IS junk, the button says "Not Junk".  As you might imagine, he is marking all of his spam as "Not Junk" and vice-versa.

Look at this screenshot of TB 3.3.0.4 (why can't I find one like this at mozilla.org?): http://www.top4download.com/thunderbird-3/screenshot-qytqcxic.html

There is a huge button that says "Not Junk" and it has a very specific icon.  Now look at the message list - every message has this same icon.  Clearly, the application is telling us that all of these messages are not junk -- right???


I think this giant icon needs to either go away, or at least for now become a dropdown that says "Junk Status" with the options "Mark as Junk" or "Mark as Not Junk".  This is a relatively simple change with low impact.


However:  The oft-duped bug 181866 asks for bayesian filters to apply to things other than junk mail.  I would like to see the "Junk" column (Ø) be labeled "Classify" (for instance) and then instead of an icon, there is a text label with a dropdown list.  Teaching Mozilla about the message is as simple as clicking the dropdown and selecting the type.

Initially, using "Unclassified", "Junk", and "Not Junk" might eliminate some of the confusion, and address some other bugs I've seen regarding this or indicating that this value should be a tri-state (bug 321655, bug 310635, and bug 273223 as examples).


Reproducible: Always




Filing this as a bug instead of an enhancement because of the severe usability impact.
While I have never been a fan of the single junk button, it is for a different reason - it discourages users from training some messages as not junk, which is important for performance of the spam engine.

If you want both junk and good buttons, then my JunQuilla add-on provides separate buttons, called "Is Junk" and "Is Good". Whether that will help your user or not, I do not know.

We need to decide what to do with this bug. It needs to be narrowed to a single request, probably to have separate junk and good buttons. There's probably a dupe of that somewhere. But given that this can be easily done in an extension, I don't think it is likely to change.
Hi Kent,

I did see your extension, but I am not a fan - it is far too confusing (green dot plus {flag|checkmark|summation|stick-figure} or fire plus same ... huh?).  The geek in me likes seeing the percentage, but what value does that really add for "Aunt Tilly" (Grandpa Tony?)


I've found that providing options always confuses people, yet I still do it.  I did it in the summary above.  Here's what I really want:

Confusing Junk/Not-Junk button goes away.  Concept of "Junk" goes away.  Replace with a generic "Classifier".  Do not add "junk" and "good" (or any other) buttons.

When a message comes in, it is run through the Classifier, which performs a Bayesian analysis on the message.  For each Classifier corpus, a value is assigned, as it is done for junk mail today.

However, there can be many corpi besides "junk", such as "important" or "taxes" or "family" or "bills" or "not junk".  The classifier would calculate a probably for each corpus and select the highest rank.  If the highest rank is less than 40% (for example), the message is not marked at all ("Unclassified") and it is left for the user to classify into either an existing or new corpus, or to ignore.

I see the UI working something like the "labels" dropdown in GMail, but I am sure there are more clever UI people around than I.  Ultimately, I'd like to see virtual folders in which messages can be filtered based on this classifier.



Now, having said that, the UI piece can be fixed prior to making the Bayesian filter broader -- except it will only have the three existing classifications (junk, not junk, and unclassified).  I can open a separate request for that, but somehow that should then "obsolete" or "conflict" with some of the existing Junk Mail Control bugs.  At that point, this bug then becomes something like a request to add the UI portion of the implementation in bug 181866.

Adding depends-on: bug 181866
Depends on: 181866
Christopher,

You really need to narrow this bug's definition. It can't just be a collection of all the things that you want done.

Concerning the issue of multiple uses of the bayes filter, the backend work to do that is all in place. My TaQuilla extension is an experimental use of that. The reality though is that it is not easy to get a bayes classifier to do subtle classification. In particular "important" or "interesting" is a lost cause. I have been able to make it work effectively on removing sports and lottery related articles from an RSS feed of my local newspaper. But the training problem is not trivial. I probably will not be doing much more work on that in the near future.
Hi Kent,

I don't think what I've written is much of a collection; if the backend work is done it would predominantly be a UI change.  The "important" and "interesting" tags are merely examples of a user-created tag, just like "family" or "junk" could be.

Re: the backend work being done, am I correct in assuming that (bug 453885, bug 506397, bug 461479) are this Bayesian core update?  The wiki page listed in bug 181866 (https://wiki.mozilla.org/Bayesian) seems to imply that the coding hasn't yet started, and the wiki page history shows no activity since 2008.

In bug 181866 comment 58, you suggest that the bug now refers to the action of dragging a message to a folder in order to add it to a corpus - I'd suggest closing 181866 and opening that as a specific enhancement as the title of 181866 says something very different.  There are multiple bugs which are marked as dupes of that bug, and from what I can tell they are dupes of it's title, not of folders and message dragging.


But back to the topic at hand:  The "classifier" and "corpi" I mention you seem to have already implemented, using what you call "traits".  I am thinking that the result of the multiple "classifier" runs is something like the set [2% 'junk', 8% 'bills', 94% 'family'] - at which point the 'family' trait would automatically be assigned.  Removing this as a label from the UI would then provide the anti-trait that appears to be required for Bayesian filtering to work well.

If my assumptions are correct, what I'm asking for then is just (1) the removal of the junk/not-junk button and (2) a change from the 'junk' column (and icon) in the message list to become a drop-down selector of GMail-label-style 'traits'.

Does that help clarify?
"If my assumptions are correct, what I'm asking for then is just (1) the removal
of the junk/not-junk button and (2) a change from the 'junk' column (and icon)
in the message list to become a drop-down selector of GMail-label-style
'traits'."

OK fine that is two bugs. The first is a dupe of "Bug 262623 - Make Junk and Not Junk buttons separate" so I will not discuss it further here. So the current bug is "a change from the 'junk' column (and icon) in the message list to become a drop-down selector." I suggest that you change the summary to reflect that.

Concerning that issue, you're just way ahead of where the application currently is. That is, there is no UI support at all for any "traits" beyond junk, and what you suggest makes no sense until that UI is provided (for training, filtering of views, enabling, etc.). The only UI support that I am aware of is in the experimental TaQuilla extension. For the foreseeable future, I think that multiple traits will remain an extension-only feature.

So, no disrespect intended, but the goal of a bug is to define some doable work, and I don't see that here. So this bug as defined would be marked as "INVALID" since it really does not apply to the current code.
I do not understand why you keep reiterating:

> The first is a dupe of "Bug 262623 - Make Junk and
> Not Junk buttons separate"

I absolutely, in no way shape or form, want any junk or not junk or anything with even a concept of junk.  There is no junk.  The string "junk" is just an arbitrary sequence of four characters that could just as easily be replaced with "stop".

Any mention of any activity other than the complete and wholesale removal of that button is not pertinent to what I want this bug to represent.  After this bug is implemented, there is no such thing as Junk Mail Controls.  There is simply a Bayesian or Bayesian-like filter, called above a "classifier", which automatically assigns labels ('tags', 'traits', whatever) to a message based on the content of the message, and learns how to classify email based on the manual tagging or corrective tagging performed by the user.

It is exactly this:  GMail labels.  Automatically assigned based on bayesian training.  Limit one per message, unless multiple labels can be made to work _intuitively_.

As such, I believe the title is correct:  *Junk*Mail*Controls* are confusing and limited.   (Replace them.)


Bug 453885 is "Generalize bayes code to support multiple traits" and it is RESOLVED FIXED.  From what I saw scanning the report, with your changes we can have up to 1024 traits.  What is it that I do not understand?

Regarding the UI, if you have a drop-down selector that initially looks like:

+-------------+
| No Tag  | v |
+=============+
| [ New ... ] |
+-------------+

And someone clicks "New ..." and it prompts them for a name and they type "junk" or "spam" or "feebleblartz" - you've just created the necessary UI.  Now it can look like like:

+--------------------+
| Junk           | v |
+====================+
| [Remove Tag: Junk] |
| [ New ...        ] |
| Hi Mom             |
| Feebleblartz       |
+--------------------+

Right??
(In reply to comment #6)
> 
> I absolutely, in no way shape or form, want any junk or not junk or anything
> with even a concept of junk.  There is no junk.  The string "junk" is just an
> arbitrary sequence of four characters that could just as easily be replaced
> with "stop".
> 
> Any mention of any activity other than the complete and wholesale removal of
> that button is not pertinent to what I want this bug to represent.

I understand that you want the junk button removed, and replaced with a more general concept, (using a column?: "I would like to see the "Junk" column (Ø) be labeled "Classify" (for instance) and then instead of an icon, there is a text label with a dropdown list.  ")

While I am sympathetic toward generalizing the bayes filter (given that I did the backend work to support it), Junk is by far the most common use. I cannot see changing the dominant position given to Junk in the core application. I recommend WONTFIX.

Christopher, I seem to be generally failing to adequately interpret your requests in a way that is meaningful to both of us, so I probably won't continue to reply in this bug. Perhaps you could raise this issue in a more general forum if it still interests you.
Hi Kent,

Please don't give up on me yet.  If I can't express myself clearly in words, let me try some screenshots markups.  I am going to attach the screenshot I mentioned in my initial report.  I will highlight the stuff I think needs to go away.  I will then show a mockup of replacing the icon with a dropdown and removing the button.  You seem to not understand "using a column"; this should help clarify the ASCII-art in comment 6.
This screenshot shows a possible future where multiple tags can be assigned to a message.  The tags, in this case, are automatically assigned based on bayes scoring.

Adding a tag to the system is as simple as adding a folder.  Adding a tag to a message is as simple as dragging that folder onto the message (or vice-versa).  I'm not sure how to remove a tag this way, but ultimately I'd like to see an interface more like this.

And please don't take these screenshots too literally -- I am not trying to give you a specification to implement, but some requirements for a bayesian-tagging system.  These mockups are to help explain the concept, not to provide the implementation of this concept.  There may very well be better ways to convey this function to the user.

And this *specific* mockup may very well belong with another bug that I haven't searched for.  I'm attaching it simply to show that I'm not specifically asking for the exact UI shown in attachment 3 [details] [diff] [review].
(In reply to comment #6)
>(Proposal of new UI by you)
(In reply to comment #11)
> A relatively simple UI change to use the generic bayesian tag backend.

My understandig is next.
Christopher W. Curtis(bug opener) and Kent James (:rkent), is it absolutely wrong?

(i) Initil comment #0 is request for solution for next issue.
    Current "Junk" or "Not Junk" button in horizontal box between thread pane
    and message header box is very confusing.
    - Which of Action or Status is never clear
(ii) Kent James's understading of your request;
    (1) the removal of the junk/not-junk button
        - For (1) there is a solution and it's already requested.
          Bug 262623 : Make Junk and Not Junk buttons separate
    (2) a change from the 'junk' column (and icon) in the message list
        to become a drop-down selector of GMail-label-style 'traits'."
(iii) Kent James's comment on (1) in (ii) is WONTFIX because Bug 262623 exists.
(iv)  Your answer to (iii) is that your request is not Bug 262623.
(v)   Kent James's comment on (2) in (ii) is that such enhancement as
      replacement of current confusing button of "Junk" or "Non Junk" etc.
      is too expensive compared to gain by the change.
      It should be done after future enhancemet will be done.
      It may be achieved by extension/add-on.
      Note: I abosolutely agree with Kent James, if my understanding is right.
(vi)  You proposed UI of drop-down selector in your comment #6 again with
      screen shot, with requesting  enhancement again which is relevant
      to bug 181866 and some others.   

Question:
Will original issue of "confusing button" never be resolved if UI you are requesting will not be completely implemented in very short term?

If not, Christopher W. Curtis(bug opener), please keep this bug only for initial problem of confusing "Junk" or "Not Junk" button in horizontal box between thread pane and message header box(and, if required, for confusion and waste of space due to "Junk" or "Not Junk" icon/button in multiple places).
Here is bugzilla.mozilla.org to resolve bug of Mozilla familiy. Here is not discussion forum.
Please don't add request for future enhancements or improvements(relevant to bug 181866 and some others) which never directly relates to issue of confusing current "Junk"/"Not Junk" button itself, even though your proposal can be a solution of the issue of confusing because your proposal will kill "Junk" or "Not Junk" button completely.
Please keep "one problem per a bug".

(In reply to comment #6)
> As such, I believe the title is correct:  *Junk*Mail*Controls* are confusing
> and limited.   (Replace them.)

Aha! You are talking about Control(s)/Button(s)/Equipment(s) to control/CNTL around Junk status setting of mail in bug summary. I accepted "Controls on Junk Mail" or "controling of Junk Mail" then I imagined Junk related Settings in Options or Account Settings and so on.
To answer your question: I am emphatically not proposing any specific UI.  Attachment 445394 [details] is merely a suggestion that I consider a decent solution, so that specific UI change is not necessary to satisfy this request.  Short term/long term makes no difference; I've been waiting for bug 181866 and bug 218258 for about 7 years (and bug 9942 for 11).

However, I do believe that the change would close this bug and would also close bug 181866.  I believe this would also close bug 262623 as WONTFIX because resolving bug 262623 makes this bug worse: adding another button makes things more confusing and this is about eliminating confusion (and enhancing functionality).

Regarding (v), I would like to hear from Kent what kind of work is needed to support this.  I believe that it can already be done because bug 453885, bug
506397, and bug 461479 are all RESOLVED FIXED, as I mentioned in comment 6.

If the backend work really isn't complete - that is, it really knows nothing besides 'junk', 'not junk', and 'unknown' - changing the UI as I showed can still be done except there are only three fixed options: "Junk", "Not Junk" and "Unknown".  I think this would also resolve another bug I can't find at the moment describing the tri-state nature of junk controls.

If it makes people happier, we can limit the scope of this bug to that one UI change, and when it is resolved a new bug can be opened to add the "New..." dropdown item.  Of course, if someone choses to implement a UI like attachment 445400 [details] the whole issue becomes moot.  Similarly for an even better idea.  But splitting this into a series of 'n' steps with a new bug for each step simply removes the option of coming up with something more clever than what I described, which benefits nobody.
Are you saying issues in current "Junk" or "Not Junk" button are next?
(a) It's hard to know which of next at a glance, so it's very confusing.
 - represents current status of the mail, then is button to toggle the status
   == friend of Junk column button of a mail at thread pane
 - is for status change action, so string on button is status after change
   == friend of Mark as Junk/Not Junk in menu
(b) Wasting valuable space of UI, as similar ones are defined at multple places.
(c) tri-state nature of junk status of a mail is not properly reflected on UI.

If my understandig of (a) is right, I agree with you on that displaying both current "Junk" and current "Not Junk" at same time won't resolve problem of (a).
Clearly I'm having problems communicating.

Please tell me what makes you think I'm talking about a junk button at all, aside from removing it from the UI completely.

If lists help:

(a) Remove any button having anything to do with junk.
(b) Make it clear that a message is junk by putting the word "junk" in the
    message display pane.  Same for "Not Junk".  Same for "Unknown".
    See attachment 445394 [details]
(c) Allow the user to change the word from 'Value A' to 'Value B' by clicking
    on the word (e.g: "Junk") in the message display pane.
(d) Clicking on the word presents a drop-down menu from which to select
    other options (e.g: "Junk", "Not Junk", or "Unknown".

With this complete, this bug can be closed.  I will then open another bug:

(a²) Add the word "[New...]" to the message label dropdown.
(b²) When "[New...]" is chosen, prompt the user to enter a custom word
     (something other than "Junk" or "Not Junk" - "Family" maybe).
(c²) Adding the custom word adds that word to the dropdown.
(d²) Adding that word also applies that word as a 'trait' of the message.
(d²) Add the command "[Not: <current_label>]" to the drop down.
(e²) If a label is removed, display "Unknown" as the label in the message pane.

From there, I can open yet another bug:

(a³) For every label in the message label dropdown, display that label as
     a folder beneath the Inbox.
(b³) Dragging a message to such a folder automatically applies a label to
     the message that is the name of the folder.
(c³) Close all the bugs and remove the prefs about moving tagged (formerly
     known as "junk") messages around.
(d³) Etc.

Does that make any sense?
(In reply to comment #16)
> Please tell me what makes you think I'm talking about a junk button at all,
> aside from removing it from the UI completely.

I didn't think you are talking about junk button only, because you referred to "tri-state nature of junk status of a mail", but I thought issues around current Junk/Non Junk only, because of next bug summary written by you.
> Junk controls are confusing and limited
I believe "bug summary" is similar to title or abstract of reaserch paper.

> If lists help:
>(snip)

It helped me very well to understand this bug.

> With this complete, this bug can be closed.  I will then open another bug:
>(snip) 

If you add summary of problems of current "Junk" or "Not Junk" button based on your observation on behavior of your grandfather, and if you add list like (a) to (d) which states what kind of improvements are required, your claim on best changes as solution of the problems will be understood by many developers.
I couldn't understand why start point of "your grandfather was confused" instantly produces request of "kill Junk or Not Junk button completely".

> From there, I can open yet another bug:
> Does that make any sense?
>(snip) 

Yes.
I think process of UI change like next is better;
  Discussion on what UI is best, what change is best, and create design of
  new UI, then statrt implementation of it based on the design.
than;
  Some one generates new UI, testers like us test it, and new UI is released
  as official release to general users, and bugs of complaint are opened at
  B.M.O by users requesting change if users dislike UI.
Please note that user's request is usually "an UI is not fit for me, change it to what I want" without "what should be". It's very hard for us, helper of QA people, to explain such user about why current UI is selected.
By the way, I don't think your proposal is only solution of problem.
Design change of some buttons only can be a simple solution(externally, not internally) for problem of bug summary.
  <button><img src="icon_source"> => <span>...new_status...</span></button>
   Where;
    icon_source : icon1=Neutral, icon2=Marked as non-Junk, icon3=Marked as Junk
    new_status  : for icon1=Junk, for icon2=Junk, for icon3=Not Junk
For "not determined yet", both "Not Junk" and "Junk" was required for learning.
>  <button><span>Not Junk</span> <= <img src="icon1_left"></button>
>  <button><img src="icon1_right"> => <span>Junk</span></button>
(In reply to comment #17)

> I couldn't understand why start point of "your grandfather was confused"
> instantly produces request of "kill Junk or Not Junk button completely".

Well, it didn't, specifically.  In my initial description, I also said that one immediate improvement would be to change the button.  Right now when you click the button, it toggles between "Junk" and "Not Junk" and resizes the button bar in the process (bug 233791 resurfaces?)

The change I mentioned would be to label the button "Junk Status" and when you click the button, a dropdown window appears that has the options "Label Message 'Junk'", "Label Message 'Not Junk'", or "Remove Label".

This fixes my grandfather's immediate problem but I don't think it is a good solution.  "Remove Label" makes no sense to users.  Not having "Remove Label" limits the spam/ham training.  And we're still stuck with this ambiguous icon and visual noise.  I see so many problems when I look at it that I think the best solution is to simply remove the button altogether.

> I think process of UI change like next is better;
>   Discussion on what UI is best, what change is best, and create design of
>   new UI, then statrt implementation of it based on the design.

Very well.  I propose something like attachment 445394 [details] as this UI -- with the exception that the only labels in the dropdown list are 'Unclassified', 'Junk', and 'Not Junk'.

> Please note that user's request is usually "an UI is not fit for me, change it
> to what I want" without "what should be". It's very hard for us, helper of QA
> people, to explain such user about why current UI is selected.

Understood.  However, I wanted to avoid giving any specific implementation because, in my experience, half the fun of programming is coming up with the solution.  I simply wanted to explain how it is a problem, and give some ideas on what might be better ...

(In reply to comment #18)

> By the way, I don't think your proposal is only solution of problem.

... and avoid comments like this.

(In reply to comment #19)

> >  <button><span>Not Junk</span> <= <img src="icon1_left"></button>
> >  <button><img src="icon1_right"> => <span>Junk</span></button>

If my complaint that junk mail controls are confusing adds more complexity to the interface, and the complaint that they are limited ties the interface more tightly to junk mail, it will make me very sad indeed.
(In reply to comment #20)
> > >  <button><span>Not Junk</span> <= <img src="icon1_left"></button>
> > >  <button><img src="icon1_right"> => <span>Junk</span></button>
> If my complaint that junk mail controls are confusing adds more complexity to
> the interface, and the complaint that they are limited ties the interface more
> tightly to junk mail, it will make me very sad indeed.

No, no. it's merely an example of next improvement for issue of your grandfather's confusions, based on your bug summary of "Junk controls are confusing and limited".
  - Explicitly show current status of "tri-state nature of junk status of a
    mail", which is one of not-determined-yet/Marked as Non Junk/Mrked as Junk,
  - and, explicitliy shows meaning of "Change to" or "Mark As" by "=>" or "<=".
I believe this is one of a simplest solution for issue of "your grandfather's confusions", without adding complexicity to the interface. 
It's never opposite opinion to your proposal on improvements of UI which is not only for current Junk/Not Junk button.
I'm asking you to clearly isolate requests for improvement on "your grandfather's confusions due to confusing current Junk/Not Junk button" and your opinion/claim on "improvements of UI including current confusing Junk/Not Junk button".
Hmm.  Please don't think that this bug is to try to fix my grandfather.  He is happily marking all of his ham as junk and all his spam as ham.  That is merely background information.  If I felt that two (or more) buttons were the correct response, I would have voted for bug 262623.  I simply feel that what is proposed there is completely the wrong approach.

I'm not sure if I completely follow what you're saying, but it sounds like multiple buttons with one of them marked/highlighted, something like a fancy radio button group.  I admit I would not have thought of this.  To me, a dropdown seems clearer.
Blocks: junktracker
See also:
Bug 323159 - Make obvious that "Junk mail log" is only for the "adaptive junk mail control" ("Trust junk mail headers set by:" should be consistent in UI and log location/access)

Bug 328847 - Junk mail needs documentation
Summary: Junk controls are confusing and limited → Junk mail controls are confusing and limited - replace with generic classifier UI
Severity: normal → enhancement
I'm going to confirm this, but with some limitations on this exact bug. This definitely is an issue, but not to the extent of when the bug was originally filed.

Currently we have three "junk" UI elements. Here's what I think of them:

Junk toolbar icon - At least on OS X, we only have one visible mode for this (meaning it only shows one icon, which magically changes the mail's state). This does need to be replaced with a toggle-like interface that allows it to either be pushed on or off. Similar to the filter button.

Message list icon - Not an issue. On OS X it is shown as a toggle-like item. Either you make it a "junk" icon, or it's a "non-selected" circle. Perfectly acceptable UI and would work even better if the toolbar icon matched.

The "Not Junk" button - This is a little confusing. However, this could probably be fixed by simply changing the title to: "Not Junk?" Or perhaps a little more playful: "Well, Thunderbird's wrong". The later's probably too lengthy though.

I'm going to make this bug specifically about changing the "Not Junk" button. I will file another on the toolbar icon.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Junk mail controls are confusing and limited - replace with generic classifier UI → Not Junk button in the mail viewer may be confusing to some users
Toolbar button issue filed as bug 898798...
Depends on: 898798
Severity: normal → S3
See Also: → 326542
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: