Junk Mail controls dialog is a mess

RESOLVED INVALID

Status

RESOLVED INVALID
16 years ago
12 years ago

People

(Reporter: sfraser_bugs, Unassigned)

Tracking

Bug Flags:
blocking-seamonkey1.1a -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

16 years ago
The Junk Mail controls dialog has grown with the addition of lots of options,
but a serious lack of UI design. See the url for a screenshot.

Some suggested changes:
1. Put the wording at the top. It's what you want to read before seeing the
   account popup.
2. Is the account popup necessary? Can't it just apply to the current account?
3. The 'Enable junk mail controls' checkbox needs to be outdented to the left,
   since it overrides all the other settings, and is not a peer to the
   other checkboxes.

4. Eliminate the two somewhat redundant folder choices under the "Move incoming"
   checkbox. Add a pseudo 'Junk' folder to the popup, and, if they choose to
   use that, create it.

   That also reduces the ambiguity involved with the "Automatically delete junk
   messages older than N days from this folder" (which folder?)

5. Move the 'Junk mail log' button to the lower left of the dialog.

Possible redwordings:

 ... if the sender is in my address book: ->
 ... if the sender is in the address book:

 Move incoming messages determined to be junk mail to: ->
 Move new junk messages to:

 When I manually mark messages as Junk: ->
 When I mark messages as Junk: (if I do it, it's manual)

Decide if it's "junk" or "Junk". And why not use "spam", since that's what
everyone calls it?
the spec (http://www.mozilla.org/mailnews/specs/spam/) calls for a better UI
than the one I've currently implemented.

what we've got now is definitely a rough draft.

I'm to blame for the current "worse-is-better" UI.

Comment 2

16 years ago
This dialog has always gotten under my skin too =). I'm in the process of
re-desiging it for Mozilla Thunderbird. Depending on what I implement, I may
back port it to mozilla mail too. 

I have a *very* rough spec posted here (should show up in 15 minutes or so):
http://www.mozilla.org/projects/thunderbird/specs/junkmail/junkmail.html

I just put this together tonight before I discovered this bug. 

I need to read Simon's suggestions and look at the original junk mail spec and
then look at incorporating some of that information into my current spec.
Feedback is always welcome.

Comment 3

16 years ago
I believe the current total separation of user model and dialogs for Junk Mail
Controls and Message Filters contributes to UI bloating. (Further, it's clear
there's scope for classifiers being of use outside of junk mail. Are these going
to result in yet another set of menu picks and dialogs?)

Long term, I'd like to see these two (three) features more or less unified.

Short term, what about using separate variants of the same general dialogs for
both Junk Mail and Message Filters?

An initial junk version of the Tools / Message Filters / Filter Rules dialog
could omit the "Match all of the following" and "Match any of the following"
radio buttons, and the More and Less buttons, and the Subject, Body, etc. "is",
"contains", etc. filter criteria drop-downs and fields, and replace that lot
with appropriate junk specific replacements, eg a drop-down list with "Message
looks like spam", "Origin is blacklisted", "Origin is blacklisted (confirmed
spammer)", etc., plus entries for selecting a whitelist address book and a
blacklist, er, list.

-- 
ralph 

Comment 4

15 years ago
This is to address a UI issue that came up in bug 214782:

The setting at bottom of the JMC dialog reads:
 [] When I manually makr messages as Junk:
   () Move them to the "Junk" folder
   () Delete them

The first option's wording, it turns out, is a little misleading: the reporter 
of the cited bug read it to mean moving the message into a folder called "Junk" 
for the account, where it actually targets "the junk folder for this account as 
specified by the previous option."  This could be fixed easily, if a little 
verbosely, by changing it to:
   () Move them to the "Junk" folder specified above
                                     ~~~~~~~~~~~~~~~
I prefer "Enable the Junk Mail Control Log" choice in option setting panel to
one in Junk Log View panel, if "Junk Log Control" means Enable/Disable only.
This is applicable to Mail Filter Log too. 

Comment 6

15 years ago
Would it make sense to put junk mail controls as an account manager panel?

Comment 7

15 years ago
yes

Comment 8

15 years ago
Maybe not all the options.  Some of the JMC options could be considered global, 
and should have a page Preferences|Mail&News.  Such as:
[] Do not mark as junk if the sender is in my address book
[] Move incoming messages when (auto-) detected as Junk
[] Move message when (manually) marked as Junk (and the accompanying radios)

These options (to me) seem to be candidates for global preferences; it seems 
unlikely that a user would want different behaviors on these points for 
different accounts.

Whether JMC is enabled for the account certainly should be account-specific.  
Whether the log is enabled also (as, I believe, it currently is).

Which folder to use is maybe more complex.  I use one Local Folder for Junk from 
four different POP accounts.  But if I had an IMAP account, I'd probably want to 
leave those messages on the server for handling, and so want an account-specific 
folder for that.  Maybe one Junk folder (probably on the local storage) could be 
specified as a global preference, and the per-account setting would be:
  ( ) Default Junk folder
  (x) Other:  [folder dropdown]
(I don't really see why the option    "Junk" folder on [account dropdown]    
exists in the current setup.)

On the other hand, maybe a global-folder designation should be part of 
bug 30057.

Finally, I think the selection of which addressbook to use as a whitelist is too 
limiting.  In my case, I'd like ALL my addressbooks to be used.  Maybe this 
setting should be in the address book, rather than in the JMC.

Comment 9

15 years ago
Moving settings into an Account Settings page is bug 180087.

In my comment 8, it looks like I'm suggesting the Junk Log should be 
account-specific, but I intended to say it should be a global setting, which I 
believe it is currently.  Cut-and-Paste fumble there.

Comment 10

15 years ago
xref bug 179012
Product: Browser → Seamonkey

Updated

14 years ago
Assignee: sspitzer → mail

Comment 11

13 years ago
This should get some attention before the Seamonkey builds make a "real" debut, but I won't mark to block.

Updated

13 years ago
Flags: blocking-seamonkey1.1a?

Comment 12

13 years ago
This should depend on:
Bugzilla Bug 323159 "Trust junk mail headers set by:" should be consistent in UI and log location/access

Not sure if this goes with "junk mail controls", but it sort of does.
Bugzilla Bug 253268 add message read , junk status to search results window


While here, junk mail could use better documentation:
Bugzilla Bug 328847 Junk mail needs documentation

Comment 13

13 years ago
Bugzilla Bug 180087 Junk Mail Controls from Menu can be moved in Mail Account Settings should block this bug

Comment 14

13 years ago
add polish keyword

Comment 15

13 years ago
Is this one fixed or at least partially fixed by Bugzilla Bug 335846
Need a Junk Preferences Panel in Seamonkey?

Comment 16

12 years ago
I don't see a clear bug or plan here, and the restructuring we had looks good enough for me for SeaMonkey 1.1, so this bug is not not blocking that release in my eyes - I'm not even sure there's something left to do here after bug 180087 and bug 335846 have landed.

Karsten, is this resolved with those checkins?
Flags: blocking-seamonkey1.1a? → blocking-seamonkey1.1a-

Comment 17

12 years ago
Well, as we no longer have a junk mail controls dialog, is this RESO INVA?
(In reply to comment #17)
> Well, as we no longer have a junk mail controls dialog, is this RESO INVA?

-> INVALID, I doubt this bug has anything more to give...
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.