182386 - [threadpane] unknown state should look like not junk state

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[(not reading, please use [e-mail] instead)]

[threadpane] unknown state should look like not junk state

I've discussed this with most of the people on the cc list.

here's the reasons why this is good.

1)  people feel compelled to train messages in the "unknown" state
2)  people are confused by the "unknown" state
3)  all "existing" mail (before this feature) is in the "unknown" state
4)  training is free (example, for imap we'll fetch the body)

by making unknown look like not junk, it will encourage people to train:

(spam) to (not spam)
or
(not spam / unknown) to (spam)

but people won't feel the need to do this:

(unknown) to (spam) to (not spam)

fix in hand.

Comment 1

[(not reading, please use [e-mail] instead)]

accepting.

Comment 2

[(not reading, please use [e-mail] instead)]

Attachment: patch

Comment 3

[(not reading, please use [e-mail] instead)]

landed.  I'll log a follow up bug to remove the unnecessary icon(s).

Comment 4

[(not reading, please use [e-mail] instead)]

icons still in the tree, but removed from jar.mn, so we aren't shipping them to 
the end user.

Comment 5

[Peter Lairo]

Are you essentially eliminating the unknown state? I kind of like the unknown
state icon. It quickly allows me to see which mails still need to be categorized.

Doesn't the following quote from comment #0 support *my* point?

1)  "people feel compelled to train messages in the "unknown" state": Isn't that
a *good* thing? How would they "feel compelled" if they couldn't tell (via UI)
which mails are in the unknown state?

2) "unknown state is confusing": It's pretty clear to me: "Mozilla could not
tell whether the mail was spam or not". What's so complicated about that?

3) "old mail all unknown state": So? That is the correct and accurate
description of old mail's state. And the UI should reflect this. The user should
be informed of where mozilla needs "training".

4) "training is free". So? Mozilla will not always be able to determine what
mail is/is not spam, and the UI should give this info to the user, so he/she can
make the appropriate evaluation. Isn't this the way the filter "learns"?

Sorry, but i suggest WONTFIX (or am I completely missing something here?)

Comment 6

[Robert Kaiser]

If showing no difference between unknown and not junk is really the way to go
(and I'm not that sure it is), you should also remove that comment that "An
unknown icon is shown if the message might be junk mail"...

Comment 7

[(not reading, please use [e-mail] instead)]

> Are you essentially eliminating the unknown state? 

no, the state is there.  we just don't show it to the user.

the reason the state must be there is because when a message goes from
"unknown -> good" it does different things to training.dat than when you go from
"junk -> good".  (same for unknown -> junk and good -> junk)

> It quickly allows me to see which mails still need to be categorized.

that's the problem.  those mails don't need to be categorized.  you don't need 
to categorize all your email.  you just have to correct it when it is wrong.

> How would they "feel compelled" if they couldn't tell (via UI)
> which mails are in the unknown state?

when *new* mail arrives, it will either be marked as junk or marked as good.
you train that email.

this change is also good for people who don't enable the junk mail controls, as 
they will only see the "dot" in that column in the thread pane.

> "training is free". 

whoops.  I meant to write:  "training is NOT free".  in addition to getting the 
message again (hits the network), and growing training.dat on disk, we don't 
need to encourage the user to train every piece of mail they have.

Comment 8

[(not reading, please use [e-mail] instead)]

> If showing no difference between unknown and not junk is really the way to go
> (and I'm not that sure it is), you should also remove that comment that "An
> unknown icon is shown if the message might be junk mail"...

fixed.  thanks for catching that, robert.

Comment 9

[Michael Heisig]

But if there is no state for unknown nobody will train Mozilla which mails are
definitely "no spam". I know the concept of the spamfilter not very good but I
think if people train it which mails are definitely not spam the danger of
incorrekt deleting is not so big. When nobody teaches mozilla which mails are
not spam mozilla will not mark mails as not spam (intern) so the not-junk-status
is superflous. 
But for me the unknown-status is very useful. When I have received new mails
firstly I delete the Spam-mails, then I open the unknown mails that are normally
spam-mails and mark them. Now it firstly seemed for me that there is a bug
because very much spam-mails were marked as not-spam. I think it is very
confusing. When there is no-spam I expect that this is really no spam and not
maybe no spam.

Comment 10

[Dylan Schiemann]

This confused me for two weeks, and I have a degree in math. I thought all
messages were listed as not spam, encouraging me to never train a message as not
spam, until I started looking around to find out why mozilla would no longer set
any messages as spam.  It is very confusing because it seems to work for a day
or two, but once you've trained mozilla with a few hundred spam messages, and
zero not spam messages, nothing is detected as spam.

Comment 11

[laurel]

OK using 2003-01-13 commercial trunk: win98, linux rh8.0, mac OS 10.2
UI shows not junk or junk state; doesn't indicate Unknown state to user.

Any issues with training state or other junk mail in general will be logged
separately.

Comment 12

[Jonathan Eunice]

IMHO, the decision to visually equate non-junk and junk-status-unknown mail
is a bad user interface decision.  

As I have argued in http://bugzilla.mozilla.org/show_bug.cgi?id=192153, the 
user would be better informed (and, I believe, visually encouraged to actively
train the junk mail filter, thus giving them the best results/user experience)
if there were clear "this is NOT junk" and "I don't really know if this is junk"
icons/indicators.  

I know that at least for me personally, not knowing whether Mozilla has (i) not
looked at/classified a message, or (ii) it has looked, and simply can't classify
as junk, is annoying.  I would like more than an idiot light on my dashboard; I
would like a clearer indication of what in the heck is going on.  

Comment 13

[Jason Airlie]

Spam is the single biggest complaint when it comes to email. So why make the
anti-spam features less informative and less powerful? The more information and
control users can have over their spam filters the better.

The value of the 2 different states is almost completely negated by not letting
the user even know there ARE 2 different states.

This was a big step backwards in my view. We need all the help we can get when
fighting spam.

Please reconsider.

Comment 14

[Rob Stow]

I am seeing over and over again in the newsgroups that with both Mozilla and
TBird, eventually the user's Junk Mail Control appears to stop working.  

If they are told that they need to start marking "unknown" messages as Not Junk,
then after a sufficient number of unknown messages are marked as Not Junk, then
their JMC starts working again.   A big problem with that is that the user can
only guess which messages are unknown.

Spitzer's own statement in Comment #7 illustrates precisely why the unknown
state needs to be indicated to the user:  
      when a message goes from  "unknown -> good" it does different 
      things to training.dat than when you go >from "junk -> good".  
      (same for unknown -> junk and good -> junk)

Those (unknown -> good) transitions are CRITICAL.  If the user never does them,
the JMC *WILL* eventually effectively cease to function.   However, by
concealing the unknown state from the user, he is misled into thinking that they
have been classified as not-junk and he never knows that he needs to correct
this.   He does not need to *always* correct this, but if he never does then the
JMC will eventually become useless.

Lying to the user is never a good thing.  If the junk status of a message is not
known, tell him.  Don't lie to him by using the same visual indicator as you do
for not-junk.

I would suggest using the little dot as the unknown indicator instead of the
question mark that was originally used.  For "Junk" we already have an icon: 
for not-junk lets simply put a stroke across the Junk symbol - just like a
no-smoking sign puts a stroke through a circle.

Comment 15

[Olivier Godart]

Please,
That's NOT good at all!

"Unknown state" is needed.

I can understand that some people won't understand what's that "unknown" state,
but at least, please, let more advanced users turning it on in the preferences.

Thanks

Comment 16

[Johann Gail]

I can only admit the previous writers.

Removing the third state (unknown) wasn't a good idea. I use thunderbird in combination with the SpamBayes pop filter, only for the reason of this third state.

With this unknown state I'm able to ignore the spam folder, because i can be sure there will be never false positives. All false positives will be in the unknown folder. It saves me a lot of work to only check the small number of unknown mails. Otherwise I'm forced to check the spam folder for false positives.

Please restore the old case.

Or would it be at least possible to write a plugin for this? 

Comment 17

[Karsten Düsterloh]

JFTR: Mnenhy (http://mnenhy.mozdev.org) restores the unknown junk state, as do simple CSS rules like those specified there: <http://www.mozdev.org/source/browse/~checkout~/mnenhy/src/bin/chrome/mnenhy/content/mnenhy/junk/mnenhy-junk-icons.css>