251296 - implement "favorite/favourite" folders

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, enhancement)

Description

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

implement "favorite/favourite" folders

instead of, or in addition to, a most recently used folder view, mscott and I
were talking about doing a favorite folder view.

changes to make:

1)  change the "folders" label above the folder pane to be something clickable,
maybe some text with an icon, where the text cycles between "all folders" and
"favorite folders".  clicking would alter the <conditions> in the folder pane
xul template (or how ever david is doing the global inbox stuff)

2)  add to the folder context menu "Add to Favorites", which would have a check
mark.

3)  for showing things in the folder pane when in "favorites" mode, the logic
would be:  "the current folder is a favorite, or any of it's children are
favorites, but it's not being hidden because it's a global inbox".

4)  perhaps "isFavorite" would be a bool attribute on nsIMsgFolder, persisted in
panacea.dat

5)  this context menu would not appear for accounts (we'd follow the logic in #3
to determine to show accounts or not)

6)  by default, we'd make all special folders as "favorites" or something.

Comment 1

[Scott MacGregor]

I just thought of another improvement we could make to this idea.

What if we created a new data source or took the existing account manager
datasource and applied a template rule to only show folders that were marked as
favorites?

When the user goes into Fav Folder view, we would end up with a view like this:

+ Favorite Folders
  Inbox
  Sent
  netscape.public.mozilla.org.mailnews
  My Work RSS Feeds

i.e. it looks like there is only a single account called "Fav Folders"  with the
favorite folders as child nodes. 

My thought / hope is that this wouldn't break too much of the existing UI /
command updating. Most of the UI is driven by which folder is selected and we
aren't mixing and matching types within the folder (which is one complication of
real virtual folders), so hopefully none of that would have to change. 

Comment 2

[David :Bienvenu]

so instead of a view (favorite folders), it would be a new virtual account, 
with the favorite folders as sub-folders. Our datasource, in either case, 
would have to make sure that we never returned children from the favorite 
folders, so in case we had a favorite folder that also had a bunch of 
children, we wouldn't show the children. (at least I assume that's what we'd 
want). But if we're showing sub-folders as if they're top level folders, then 
we could get some ambiguity if two sub-folders have the same name...just 
rambling out loud...

I really don't think true cross-folder virtual folders are going to be that 
hard. Command updating will be a little bit tricky, but most commands just 
care that there is a message selected, not what kind of message it is or what 
kind of folder its in. 

Comment 3

[Scott MacGregor]

Implementation ideas from David:

mscott: would you envision a new class that maybe replaces nMsgFolderDatasource?
mscott: a favorites data source?
mscott: or something that integrates with the exsting stuff
David: I think Seth's idea was just a new rule
mscott: but uses a rule for hiding
David: yeah
mscott: but does that new rule scale for showing all Folders under a Favorite
Folder fake acct?
David: I think the rule approach, if we can get it to work, would be a lot easier.
David: ah, no
David: I'm not an expert, but I think the rule thing would only work if we
showed them in their existing hierarchy
mscott: yeah
mscott: that's what i thought too
David: the thing is, it might be really easy
David: I don't remember how far Seth got...
David: the separate account thing doesn't even really need to be a different
data source, I don't think...
David: just a new root folder object
mscott: and that object knows how to get the list of folders to show
David: yeah, it just has a root folder with mSubfolders
David: like any other root folder
David: it just knows how to populate mSubfolders
David: so it overrides GetSubfolders
David: so it would be a new folder class, I guess...
mscott: where do you think this implementation would live?
mscott: nsMsgFavoriteFolders.cpp
mscott: something like that?
mscott: in base\src
David: yeah, I think so.
David: and I suppose a favorite folders server
David: so we'd need a new URI base for it..
David: for the root folder
David: favorite folders would be pan protocol, right?
mscott: yeah anything could be a favorite folder
David: so populating it would probably involve querying all the account root
folders for their "favorite folders"?
mscott: the URI base would be just for the folder
mscott: for the root folder
mscott: every child folder uses it's own uri
David: righyt
mscott: do we need a nsMsgFavoriteFolder at all or can we do it all in the server?
David: oh, you know...
David: the parent folder thing is a problem
mscott: don't we do folder.server?
David: right now, folders know their parent.
David: and then get the root folder?
David: probably in most cases.
David: but there are times we do folder.parent
David: and then we stop when we get to the server...
David: it might not be a problem, but we'd definitely have to check.
mscott: yuck
David: definitely a break down of the Model View stuff
David: it's probably not that bad.
David: I don't think we can do it all on the server
David: there has to be a root folder object that overrides getsubfolder
David: unless we rearrange a lot of code
mscott: ok
David: although, here's an idea :-)
David: use an nsMsgDBFolder
David: and preflight the population of the mSubFolders
David: maybe the parent thing is ok
mscott: so no fav folder subclasss?
David: if we can get away with using nsMsgDBFolder...
David: when we create the fav folder server object
mscott: keep typing...brb
David: so we have a new account type for favorite folders, and a new server
object (or can we use nsMsgIncomingServer?...need to go 

look at how the server objects are created when we load accounts...)
David: I have a feeling might go down the path of trying to use the base
classes, and then we'll find some place where having 

sub-classes would be helpful.... but the whole thing could be fairly easy - all
we're doing is aggregrating
David: I think a new server class/object is the easiest way to go.
mscott: cool
mscott: i'll add your notes to the bug
David: nsMsgAccountManager::createKeyedServer creates a contract id for the
server object
David: then, calls GetRootFolder on the server object
David: our sub-class can check an initialized flag, and in GetRootFolder,
calculate all the sub-folders there, the first time its asked
mscott: and that's mSubFolders
David: right
mscott: don't we still need a fake favorites folder sub class so we actually
have a fake acct entry in the folder pane?
mscott: or are you thinking we fake it by having the server 
mscott: make up a dbfolder instance for the root
mscott: plus mSubFolders
David: I'm not sure what the account entry is based on...
David: but doesn't that happen in js?
David: in which case, we can just check the account type

Comment 4

[Scott MacGregor]

pushing off

Comment 5

[Peter Lairo]

(In reply to comment #2)
> ambiguity if two sub-folders have the same name

How about adding the root's name to the end of the folder's name:

+ Favorite Folders
   - Inbox ([e-mail])
   - Inbox ([e-mail])
   - netscape.public.mozilla.seamonkey
+ [e-mail]
   - Inbox
   - Templates

Of course, this will not help if there are several favorits from sub-folders
wihin one root folder that have the same name, but that would hopefully be
pretty rare. Perhaps a *tooltip* with the *full path* would help:

[ [e-mail] / Work Stuff / Downloads ]
[ [e-mail] / Home Stuff / Downloads ]

It would also be nice to be able to *sort* the favorites via drag/drop.

This could be really cool. :-)

Comment 6

[Curtis Buys]

(In reply to comment #1)
> i.e. it looks like there is only a single account called "Fav Folders" with
> the favorite folders as child nodes. 

The main reason I like Outlook's Favorite Folders is because they are "stuck" in
the UI -- no matter how far I scroll up and down in the list of accounts and
folders my favorite folders (and their mail counts) are still right there at the
top, only one click away.

If a Favorite Folders virtual account was implemented could it somehow be
anchored to prevent it from being pushed out of view when scrolling down?

Comment 7

[Curtis Buys]

Attachment: Outlook Favorite Folders screenshot

(In reply to comment #5)
> + Favorite Folders
>    - Inbox ([e-mail])
>    - Inbox ([e-mail])
>    - netscape.public.mozilla.seamonkey
> + [e-mail]
>    - Inbox
>    - Templates

Outlook handles this (for comparison):

1) When a folder is part of the primary personal folders account only the
Folder Name is displayed ("Inbox", "For Follow Up", and "Unread Mail" in
screenshot).  Thunderbird could do the same thing with folders in the "Local
Folders" account.

2) When a folder is in some other account, the Folder name is displayed
followed by "in [Account Name]" ("New in RSS Feeds" in screenshot -- "New" is a
Search Folder name and "RSS Feeds" is the Personal Folders account name).

I also wanted to suggest that Favorite Folders support drag and drop.

(In reply to comment #5)
> Perhaps a *tooltip* with the *full path* would help:
>
> [ [e-mail] / Work Stuff / Downloads ]
> [ [e-mail] / Home Stuff / Downloads ]

I think such a tool-tip is an great suggestion.

Comment 8

[WADA:World Anti-bad-Duping Agency]

To all developers of this new feature:
Please avoid using "Favorite" when this feature will be implemented.
Please don't import too many MS/IE only terminology to Mozilla family.
There is another reason why I hate "Favorite(s)".
 - Japanese translation of "Favorite(s)" is stupid on Japanese MS Win and IE :-)
Simple "Selected folders" is far better for me than "Favorite folders" as a
partner of "All folders".

Comment 9

[Peter Lairo]

(In reply to comment #8)
>  - Japanese translation of "Favorite(s)" is stupid on Japanese MS Win and IE

To be consistent with firefox, how about "Bookmarked Folders"?

The workflow / UI could be like this:

1. Right-click (or File / New / ...) "New Bookmarked Folders"

2. +----------------------------------------+
   | Add <foldername> to Bookmarked Folders |  <-- Dropdown to select other?
   |  [ ] include subfolders                |  <-- Default: deselected
   | Name: [                              ] |  <-- Defaults to <foldername>
   |                    [[ OK ]]  [Cancel ] |
   +----------------------------------------+

3. +------------------------------+
   | Name                         |
   | -----------------------------|
   | Bookmarked Folders           |  <-- click collapses/opens BF section
   | -----------------------------|
   | o Inbox (<account1>) (x)     |  <- "o" = folder's icon, "(x)" = unread
   | o Inbox (<account2>) (y)     |
   | o Project 1                  |  <-- from Local Folders
   |   o Invoices                 |  <-- Subfolders possible? Stays with parent.
   | o Project 2                  |
   | o Planet Mozilla (RSS Feeds) |
   | o Recent Messages            |  <-- Search folder
   | o n.m.thunderbird (z)        |
   |------------------------------|
   | All Mail folders             |  <-- click collapses/opens section
   |------------------------------|
   | o <account1>                 |
   |   o Inbox                    |
   |   o Templates                |
   |   o ...                      |
   | o <account1>                 |
   |   o ...                      |
   | o RSS Feeds                  |
   |   o ...                      |
   | o Local Folders              |
   |   o ...                      |
   | o news.mozilla.org           |
   |   o ...                      |
   +------------------------------+

4. D&D of Bookmarked Folders would be great. :-)

5. Right-click on any Bookmarked Folder allows to "Remove from Bookmarked
Folders List".

How are Bookmarked Folders updated? In real time (as other accounts are
updated)? By clicking on "Get new messages" button?

Comment 10

[Frank]

Just adding a couple of comments here..

I think having the subfolder implementation in the favorites/bookmark folders/whateveryoucallit will just make the things less useful..  

Oh, how about 'shortcuts' as a name for em, since that is really what they are..

The point is to make em one click affairs, NOT click on grandparent..click on parent...click on desired shortcut folder..

these new shortcuts should have all of the current folders context items and the ability to recieve message drops ( to move messages from one folder to another )
drag and drop reordering should also be implemented.

Renaming should also be allowed since it is possible for a shortcut to point to a news folder and the user might not need the shortcut to read "netscape.public.mozilla.mail-news".. and forcing an abbreviation on the user is not the answer here..

I have created a less-than-ideal implementation of this as an extension..  Read about it here..  http://forums.mozillazine.org/viewtopic.php?p=1865571

Putting the entries in the folders datasource is a much better idea than what I have done, since those shortcuts would then exist in any of the folders dropdowns in the rest of the app ( like message...move... and (message context)..copy to...

Just my A$0.02

Comment 11

[David :Bienvenu]

taking, work in progress patch coming up in the next day or so.

Comment 12

[David :Bienvenu]

Attachment: backend work in progress

this adds backend support for folders with unread, and favorite folders - there's still some cleanup work to do, but it works fairly well as is. I'll attach some front end changes for completeness sake, though I'll leave the actual UI to Scott :-)

Comment 13

[David :Bienvenu]

Attachment: front end workd

This makes it so clicking on the name column header in the folder pane cycles between folder views (normal -> unread -> favorites). It also adds a folder pane context menu item to add/remove a folder from the favorites list, which we will probably want to keep.

Comment 14

[David :Bienvenu]

*** Bug 318103 has been marked as a duplicate of this bug. ***

Comment 15

[David :Bienvenu]

Attachment: backend work

This cleans up the last patch, gets rid of unused overrides, and fixes drag drop to work in folder views. I think this is ready to checkin, so we can add a front end and shake out the remaining issues. I haven't figured out how to implement recently used yet but I'll work on that after I drive some other patches in.

Comment 16

[Peter Lairo]

(In reply to comment #10)
> I think having the subfolder implementation in the favorites/bookmark
> folders/whateveryoucallit will just make the things less useful..  

The user doesn't *have* to use it. In fact "[ ] include subfolders" should be *off* by default. However, there will likely be cases where users need access to an entire subtree (e.g., a current largish project).

(In reply to comment #13)
> This makes it so clicking on the name column header in the folder pane cycles
> between folder views (normal -> unread -> favorites).

Does this mean that while in "favorites" view, the user can't see his other folders? That would be unfortunate, at least for when the user wants to drag/drop a message from a favorite folder (Inbox) to some non-favorite folder (Local Folders / Project X / Invoices). If so, I liked my sugggestion in comment #9 step 3 better.

Comment 17

[Scott MacGregor]

Comment on attachment 204560 [details] [diff] [review]
backend work

what about changes to mailnews\build\nsMailModule.cpp?

Comment 18

[David :Bienvenu]

the changes to mailnews\build\nsMailModule.cpp are in the patch (and in my tree, or nothing would work :-) )

Comment 19

[David :Bienvenu]

Attachment: implement mru time setting

this patch makes it so we set the mru time of a folder when the folder is opened, a message is copied into it, or its new flag is set. I put the MRUTime string in a central place as well.

Comment 20

[David :Bienvenu]

Attachment: fix saving of mru time in panacea.dat

whenever you delete a folder, I was blowing away panacea.dat, but that loses the mru time. So I've changed it so we remove the element from the folder cache that corresponds to the deleted folder, instead of blowing the whole thing away.

Comment 21

[David :Bienvenu]

Attachment: front end work including mru view.

Comment 22

[Peter Lairo]

(In reply to comment #21)
> front end work including mru view.

Screenshot?

Comment 23

[Scott MacGregor]

Attachment: front end patch (work in progress)

updated front end patch so I can save off some of my work. Still a work in progress.

Most of the changes are to the default folder pane header view so David won't notice much of a difference from his original patch. :)

Lots of context menu work including some cleanup, adding a menuitem to the Edit menu for adding a folder as a favorite folder.

Comment 24

[Scott MacGregor]

Attachment: screen shot

Comment 25

[David :Bienvenu]

backend work landed on the 1.8.1 branch

Comment 26

[Scott MacGregor]

Attachment: front end patch

The front end is far enough along that it's time to let people start using this feature. I'm planning on doing a cross-commit on this patch so we see the UI on the trunk and the branch.

There are a lot of little things going on in this patch. Here are some of the highlights:

1) New menu item under View called Folders with the following options:
All
Unread
Favorites
Recent

Based on the current folder pane view, the appropriate option will have be checked. This menu item is hidden in the stand alone message window.

2) The Edit menu has a new menu item above folder properties called "Favorite Folder". This menuitem toggles the favorite folder property for the selected folder in the folder pane. You should see a check box next to the menu item.

3) The sidebar header right above the folder pane is now a toolbar button, hovering over the header text should show a hover border state. Clicking the button cycles through the folder views. The text of the button changes based on the folder view: All Folders, Unread Folders, Favorite Folders, Recent Folders.

4) The folder pane context menu has a new menu item right above the properties menu item called Favorite Folder which has a check next to it when the folder is a favorite. The entire context menu has undergone some simplification and cleanup as well.

5) The folder pane view setting is persisted across sessions. We store the folder view in a pref and restore the view on startup based on the value of the pref. 

6) I added some 'smart code' to generically figure out when to show/hide menu separators from our context menus and then changed the message and folder pane context menus to use this new routine instead of trying to hand check if various menu items were visible before showing/hiding a separator.

7) loadFolderView(aNewFolderView) in msgMail3PaneWindow.js is the core routine that changes the folder pane view.

Comment 27

[Scott MacGregor]

I would point out that, this patch doesn't mean we are done with the front end work. I'm not happy with the toolbarbutton CSS for the sidebar header and I'd like to tie in a menu popup (in addition to the current cycler) when you right click on the sidebar header. I'm sure more things will come up.

But it's a good start in exposing this new feature so we can start collecting feedback.

Comment 28

[Scott MacGregor]

the front end has now landed on the branch as well. 

Comment 29

[Mike Cowperthwaite]

Pretty neat.  So far, appears to work as described -- altho, like Grouping, I expect I won't use it much in the long run.


(In reply to comment #26)
> 2) The Edit menu has a new menu item above folder properties called "Favorite
> Folder". This menuitem toggles the favorite folder property for the selected
> folder in the folder pane. You should see a check box next to the menu item.

A peeve of mine regarding menus is when top-level menu items disappear based 
on context, as the 'Favorite Folder' item does when an account is selected.  
(See also the Message menu's Watch/Ignore items when a non-News message is selected.)  I think overall it would be cleaner if the "Favorite" setting were 
a checkbox on the Properties dialog, along with a special icon or text styling for the folder if it's a favorite.  (Of course, those icons are pretty crowded already, but that problem could be left up to the theme designers.)


> 3) The sidebar header right above the folder pane is now a toolbar button,
> hovering over the header text should show a hover border state. Clicking the
> button cycles through the folder views. 

This button activates on a right-click, which maybe it shouldn't.

Comment 30

[Mike Cowperthwaite]

*** Bug 216909 has been marked as a duplicate of this bug. ***

Comment 31

[Alex Ihrig [:Thunderbird_Mail_DE]]

Using 1.8_Branch build 20060216, folder pane shows the new header only if the expanded columns (Tools > Options... > Advanced > General) are NOT activated.

Comment 32

[David :Bienvenu]

Attachment: fix imap mru time setting when msg copied into folder.

duh, no wonder it wasn't working for Seth - Seth checked and that logic was right in the other places, just not for the imap folder case...

Comment 33

[David :Bienvenu]

Attachment: fix setting mru time for imap and local folders, and similar screwup with handling of noselect folders.

actually, the local mail folder code had the same bug, and the imap folder code had a similar bug. Thx for pointing these out, Seth.

Comment 34

[David Rogoff]

(In reply to comment #10)
> Just adding a couple of comments here..
> 
> I think having the subfolder implementation in the favorites/bookmark
> folders/whateveryoucallit will just make the things less useful..  
> 
> Oh, how about 'shortcuts' as a name for em, since that is really what they
> are..
> 
> The point is to make em one click affairs, NOT click on grandparent..click on
> parent...click on desired shortcut folder..
> 
> these new shortcuts should have all of the current folders context items and
> the ability to recieve message drops ( to move messages from one folder to
> another )
> drag and drop reordering should also be implemented.
> 
> Renaming should also be allowed since it is possible for a shortcut to point to
> a news folder and the user might not need the shortcut to read
> "netscape.public.mozilla.mail-news".. and forcing an abbreviation on the user
> is not the answer here..
> 
> I have created a less-than-ideal implementation of this as an extension..  Read
> about it here..  http://forums.mozillazine.org/viewtopic.php?p=1865571
> 
> Putting the entries in the folders datasource is a much better idea than what I
> have done, since those shortcuts would then exist in any of the folders
> dropdowns in the rest of the app ( like message...move... and (message
> context)..copy to...
> 
> Just my A$0.02

Sorry- coming in late to the discussion.  I just wanted to say that I use Outlook at work find that the Favorites/Shortcuts is a great, virtually indispendible feature.  In fact, I'm the one who bugged Frank to create his extension (much thanks!).  If the final implementation worked like his extension it would be great - it does everything I use this feature for in Outlook.

 David

Comment 35

[arwi]

Why favorite folders as it is much easier to add a searchbox above the folder pane (as above the message pane)and insert the folder you want to view in this box (with autocomplete)?

Comment 36

[Peter Lairo]

(In reply to comment #35)
> Why favorite folders as it is much easier to add a searchbox...

Because the favorites (a) point to specific and predefined locations, and the user doesn't have to think of the remembered names of (sub)folders, and (b) the user might want to copy messages from one favorite folder (e.g., Inbox) to another favorite folder (e.g., Project X Invoices). This would not be possible with a searchbox filter (because either the "inbox" or "Project X Invoices" would be hidden).

PS. I think this "search" (and "tag") everything trend has gone too far. Favorites folders (and bookmarks) have specific value too (IMO more than tags/searches). Having said that, I really miss a searchbox-filter in the Password Manager (much more so in Firefox).

Comment 37

[Peter Lairo]

Instead of having to *cycle* through all the views (all > Unread > Favorites > Recent > All) (feels like walking through a dark room: you don't know what is coming next), I would prefer if the views could be selected via a *dropdown* list:

   +------------------------------+
   | [ Favorite Folders        \/]| <-- Whole width clickable
   |  | All Folders              ||
   | o| Favorite Folders         || <-- After "All Folders"
   | o| Unread Folders           || <-- Unread&Recent=grouped (auto-generated)
   | o| Recent Folders           ||
   | o+--------------------------+|
   | o Inbox (<account1>) (x)     |
   | o Inbox (<account2>) (y)     |
   | o Project 1                  |

Comment 38

[Thomas Schade]

(In reply to comment #37)
> Instead of having to *cycle* through all the views (all > Unread > Favorites >
> Recent > All) (feels like walking through a dark room: you don't know what is
> coming next), I would prefer if the views could be selected via a *dropdown*
> list:

At least some sort of customization would be nice. Sort of 'Folders to cycle through' like you can do with 'Expanded columns in the folder pane'.

Comment 39

[Mike Cowperthwaite]

I agree with comment 37 that the cycle-thru model is less than ideal, and I 
also don't think the little left/right arrow icon is particularly clear.

Using a "menulist-compact"-class dropdown would be one possibility.  This is 
the sort of dropdown used in the compose window to change the To/CC/BCC labels in the addressing widget.  The appearance of those buttons that I have (with a modified userChrome.css -- see bug 301465) makes them look relatively flat.

The main problem with having a dropdown of any sort is that currently, 
dropdowns always require focus in order to work, and putting focus in a toolbar is always a source of problems (as can be seen in all the fiddling trying to 
get QuickSearch to behave).

Since the folder-view dropdown (and, for that matter, the mail-view dropdown) are both replicated in the menus, these could be replaced by a new mouse-only dropdown that doesn't grab focus (just as toolbuttons and the current widgets 
on the folder-view header don't).

Comment 40

[Ray Booysen]

Not sure if it is correct to add these bugs are blockers for this bug, please remove if incorrect but these are issues I think need to be resolved before this can be marked as fixed.

Comment 41

[quer]

hi,
(my english is bad )

nobody needs several - trash, junk and inbox folders

solution:
for junk and trashfolder set a general folder for all accounts

slution for inboxfolder:
set a virtuall folder for all accounts or 
minimum one virtuall folder for all email+imap accounts and separate one for news and rss

please set in the flolderpane the adressbook icon and open the adressbook in the main window

Comment 42

[Audun Myhra Bergwitz]

Looking at the current implentation I'd like to have more options than the 4 views. If I could create more user-defined Folder Views this would be a much better feature. For instance, I'd like to have a view of Favorite Folders with Unread, a folder view of all news folders and a folder view of all feeds folders.

Having a folder view for each account would also be neat (that's in addition to an "All accounts" view of course).

Comment 43

[David :Bienvenu]

marking fixed - we'll open new bugs for remaining issues.

Comment 44

[David :Bienvenu]

*** Bug 162566 has been marked as a duplicate of this bug. ***

Comment 45

[Georges-Etienne Legendre]

For those interested, I've created an extension that adds a new folders view above the standard view: http://legege.com/en/mozilla/afview

Comment 46

[Thomas P Morris]

(In reply to comment #10)
> Just adding a couple of comments here..
> 
> I think having the subfolder implementation in the favorites/bookmark
> folders/whateveryoucallit will just make the things less useful..  
> [...]
> The point is to make em one click affairs, NOT click on grandparent..click on
> parent...click on desired shortcut folder..
> 

I agree that the implementation ought to be as transparent to the user as
possible, but if the favorites don't include some form of folder heirarchy,
it might still be useful if they included at least to which account the 
folder belongs.

Why? Let me give an example:  we use IMAP, and users need to sometimes
archive data from the server-side IMAP store to a folder tree in the Local Folders tree.  They may not archive all the data. Under IMAP, some of our 
users have fifty or more folders, sometimes with complex but well thought
out structures. When they migrate archived data to Local Folders, they 
often keep the same structure and heirarchy and often the same folder names.

They would like to be able to see a subset of their folders.  The Favorites
implementation would be a way to do this, but without SOME way of identifying
to which account or heirarchy the favorite folders belong, it is difficult to 
know which folder in the list belongs where!  

Possibilities to help disambiguate:

 (1) have a separator in the Favorites list, for each "account" tree 
     to which the folder belongs, or
 (2) have a tooltip popup that identifies "account" for a 
     favorite folder when you hover, or
 (3) Show the skeleton structure of the folder heirarchy in the
     favorites list, or 
 (4) OUTSIDE of the favorites mechanism, provide a way to 
     "subscribe/unsubscribe" or "show/hide" particular folders
     even in POP and Local Folder account lists.