446306 - New Mailbox centric folder pane

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, enhancement, P1)

Description

[Bryan Clark (DevTools PM) [:clarkbw]]

As a part of the experimental message view we need a new folder pane that doesn't focus on the individual accounts but instead focuses on messages and mailboxes.

See the wiki page for design considerations.  

Here is a basic ascii layout of the new folder pane with accounts named Gmail, Mozilla, and Rogers.  

+----------------------+
| [+] Inbox            |
| [+] Drafts           |
| [+] Starred          |
| [-] Sent Mail        |
|  |--¤ Gmail          |
|  |--¤ Mozilla        |
|  +--¤ Rogers         |
|                      |
| [+] Junk             |
| [+] Trash            |
|                      |
|                      |
| [+] Gmail            |
| [+] Mozilla          |
| [-] Rogers           |
|  |-- My Folder (1)   |
|  +-- My Other Folder |
|                      |
+----------------------+

Comment 1

[Heribert Wettels]

In my current setup I am handling four accounts that actually represent two users (my wife and me) with two different accounts each. (We are not using separate OS users for each person for various reasons.) While I embrace the idea of a mailbox/folder centric view in general, I would like to see each user's accounts as separated as possible. Something like this:

Joe
[-] Inbox
  |-- Gmail
  |-- Mozilla

Jane
[-] Inbox
  |-- Gmail
  |-- Yahoo

Heribert 

Comment 2

[Magnus Melin [:mkmelin]]

Heribert: even if you don't use OS profiles, you can still have two thunderbird profiles. (thunderbird.exe -P) 

Comment 3

[Kent James (:rkent)]

In the wiki page https://wiki.mozilla.org/Thunderbird:Folder_Pane you propose a "Possible junk" folder. Here are some comments on that, since I've been running such a folder for several months using a custom extension. Generally I like the concepts you present for Possible Junk.

That folder will be based on a junkpercent filter. The upper limit of that filter should coincide with the setpoint for automatically flagging messages as junk. But how about the lower setpoint?

The way that I run, and the way I would recommend, is to have the main viewing folders also filter on junk percent, but at a lower setpoint than the automatic value. So for example if the automatic junkpercent value is 90, the main viewing folders would show messages with junkpercent < 50.

It is tempting then to have the Possible Junk folder then show all missing items from the main viewing folders, that is 50 < junkpercent < 90  But it would be best not to do this. Why? One of the points of the Possible Junk is to encourage users to train the bayes filter on both Spam and Ham of an uncertain value. If the Possible Junk limits are 50 < junkpercent < 90, then the folder will be almost all junk, and very little ham will be trained. So from the bayes perspective, better limits would be 10 < junkpercent < 90.

So what I suggest is this compromise. Set the junkpercent limits in the Possible Junk to be automatically set to 100-x < junkpercent < x, where x is the value that is used for automatically marking as junk. Allow the user to set those limits though, with a choice of "Automatic (recommended)" but still allow them to set a different lower limit manually.

Comment 4

[David Ascher (:davida)]

Having this in place would make calendar integration easier, in addition to making usability sense in my view.

Comment 5

[Magnus Melin [:mkmelin]]

Since the msgs in the "Junk" folder isn't somehow "ensured to be junk" I don't think it's a good idea to have a "possible junk" top level folder. A couple of saved searches as sub folders of the junk folder might be interesting though.

Comment 6

[Kent James (:rkent)]

(In reply to comment #5)
> Since the msgs in the "Junk" folder isn't somehow "ensured to be junk" I don't
> think it's a good idea to have a "possible junk" top level folder. A couple of
> saved searches as sub folders of the junk folder might be interesting though.
> 
Junk management should be configured so that it is extremely rare for the junk folder to contain non-junk, and all of the uncertainty is confined to the "Possible Junk" folder (which I call Uncertain on my system). The Uncertain folder is also where you ask the user to do training, so they will interact with that folder daily. Junk however is rarely looked at. So however you accomplish visibility, Junk needs lower visibility than Uncertain. I assume that making Uncertain a subfolder of Junk decreases its visibility, so that is not a good move IMHO.

Im not sure this is the best bug to be carrying on this discussion though.

Comment 7

[Magnus Melin [:mkmelin]]

Well, I don't think training junk filters is something users in general do (or want to do), and marking false positives in the Junk folder would seem far more important than the other training anyway, as that's already recognized.

Comment 8

[Kent James (:rkent)]

(In reply to comment #7)
> Well, I don't think training junk filters is something users in general do (or
> want to do), and marking false positives in the Junk folder would seem far more
> important than the other training anyway, as that's already recognized.
> 
This is precisely a serious weakness of TB bayes filtering at the moment. The bayes algorithm relies on having representative samples of both spam and ham. In normal usage as currently designed, users will train far more spam than ham. That does not lead to good spam filter performance. Perhaps the answer lies in some form of automatic training rather than manual training, but that will never be as reliable as manual training.

This is not something we should force on unwilling users, but for people who are willing to use the bayes filter as it should be used, then we should make it easy and convenient for them to do so.

Comment 9

[a_geek]

After reviewing https://wiki.mozilla.org/Thunderbird:Folder_Pane and https://wiki.mozilla.org/Thunderbird:Message_Archive, I'd like to comment.

First off, I really don't think that this is actually an improvement. On the contrary, I find mail handling options in TB already/still inferior to mutt, with the exception of being able to handle UTF8 email.

In particular, I find that the account centric view should be available in TB3, too.

Reasoning:

#1 No need for "Archive" folders:

I can already create any amount of folders below "Local Folders", where I move messages from my various inboxen. This structure is quite similar to what is possible in an IMAP account. I didn't try searching everything below "Local Folders", but doing so should not be a problem. In any case, I want to preserve the context of messages in that I keep them in separate folders, which, automatically, have unlimited storage (preservation) times. What I really don't want is being forced to lump all messages about highly disparate themes into one big folder. If searching across a number of folders is a problem, then that should be fixed instead. I'm not opposed to have "saved queries" or something like that to find emails meeting some set of conditions, but please keep the regular folder structure intact (and no, Apple's Mail.app is NOT the holy grail of email munging - I'm rather displeased with it's inflexibility and simple-mindedness).

Summary: I don't see the novelty or usefulness of the approach.


#2 Keeping account-centric views

Accounts are a natural way to organize mail. Eg. my mail accounts, or news accounts, carry individual meaning for what I use them, how I attribute reliabity or retention policies etc. with them. I want to have all this in one place. This is also convenient because, when I write, or answer, an email, TB immediately knows which identity to pick. Inverting the structure and scattering the folders for one account under like-named global folders makes it impossible to get a quick overview. Also, the folder structure will change in "non-continuous" ways if I choose to eg. rename a folder. Will they then get renamed in all accounts (ie, upstream)? What if this isn't possible? Currently, I can rename a folder in an IMAP account, and the rest of the folder structure that I'm accustomed to use, will stay the same.

Summary: This feature will be hard to implement, on the programmer's side as well as on the user's side, and imho makes only sense for people who only handle small amounts of email, in simple structures.

Comment 10

[Magnus Melin [:mkmelin]]

I'm not so sure I'll like it either, but I have an open mind :) I do think a lot of people won't like it at all, partly because - like comment 9 says - accounts are quite a natural way to organize oneself.

"Archive" + tags might work for gmail esp on the web but there are fundamental problems if I want to use that with thunderbird and imap currently. The prime one being tags created on one client are stored server side (most of the time, some servers don't support tags at all), but the labels do not show up on other clients unless you manually go and set up exactly those tags again. Bottom line, I don't (and can't) trust them the same way i can with a folder.

Maybe this could be implemented as a folder view? Then people can choose how they want the folder tree shown.

BTW, how are newsgroups and feeds fitted in here?

Comment 11

[Heribert Wettels]

As I said before on comment 1 I could imagine a user-centric design. But obviously this is complicated from a technical point of view, and also people seem to dislike the idea because there are already profiles available for this. I understand and accept this.

But then I agree with comment 9 and comment 10: Please keep the current account-centric view. I cannot see any advantages of the proposed folder-centric view for the way I use TB.

Comment 12

[Bryan Clark (DevTools PM) [:clarkbw]]

Marking this Target TB3, however I don't think we're going to block on this unless other items fail.

Comment 13

[Bryan Clark (DevTools PM) [:clarkbw]]

I'm going to mark this fixed since bug 305340 essentially implemented this