User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 MultiZilla/188.8.131.52b Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 MultiZilla/184.108.40.206b When filing a message from the message viewing window, and having multiple accounts, it is generally true for me (and I imagine for most people) that the most typical filing operation that takes place is moving messages from the Inbox to other folders for archival. Perhaps 2nd most typical is moving messages from the Sent folder to other folders for archival (to keep complete topics together). 99% of the time, I file folders from Inbox or Sent to other folders defined in the same account. The dropdown menu from the "File" icon, the flyout menu from either the menu bar's Message/Copy, Message/Move, or from the right click popup menu's Move To or Copy To selections are all structured in the same way (consistent! good!) so this issue refers to all of them. The current structure is to show a first level menu listing the accounts, and then once an account is chosen, the top level folders for that account, and then you can dig deeper. This structure is not as optimal for me as some alternative structures I describe below. My preferred alternative would be for the first level menu to list, first, an entry named "other accounts", and below that, the top level folders for the current account. This would allow one-step-quicker access to all the folders of the current account, which are the likeliest targets. The "other accounts" entry would, if chosen, then give the current structure. This slows access by one step to all folders in other accounts, but for me (most?) that would yield a net improvement in folder selection speed. Another alternative, which would not slow the other accounts, but would speed up the current account nearly, but not quite, as much, but would also be a little more confusing, would be to list in the top level menu all the individual accounts, plus all the folders for the current account. Folders for the current account would be a little less easier to get to than for my first alternative, because one would have to move the mouse past all the other account names to get to the folders for this account. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Interesting that I didn't come up with any of those bugs when doing a search, glad you did, somehow. It shows that the issue is not unique just in my own experience and the experience of my friends and clients. I wouldn't think this bug is quite a dup of bug 105062... that bug is suggesting reordering the accounts in the current top level menu, this bug is suggesting replacing them with the folders of the current account. All the bugs you listed are related to the inefficiency of folder selection, though, and are all suggesting different ideas for solutions. Perhaps all these ideas could be grouped under one bug, with a description of the various ideas, maybe some pros and cons for each idea, and perhaps unifying some of the ideas into a comprehensive solution, if one can be gathered from the individual parts. This bug, bug 105062 and bug 139237 all offer solutions based on folder structure. Bug 202031 suggests a distinguished folder, for "most frequent" saves. Bug 207070 suggests reordering the selections to give priority to "most recently accessed" folders. Bug 227162 suggests that the priority should be given to a particular folder depending on the sender of the message. So they are some very different concepts here. I know a number of people with large numbers of folders organized by sender; I know a number of people with large numbers of folders organized by topic. I have correspondents with whom I correspond on different topics (being a topic organized guy myself), so I can see that one doesn't subsume the other. And the "recently used" business could be helpful if the you get lots of related emails together, but if they are scattered, it is only helpful if the number of "recently used" selections is large enough to cover the collection of topics (or senders, or whatever organizational structure is used). In light of all the other bugs, and in an attempt to subsume them all under one umbrella, I'll add to the suggestion in this bug... The top level menu from the File icon, and other ways of generating the list of folders for saving messages to, should contain 1) My favorite folders > 2) Recently used folders > 3) Other accounts > 4) folder for this Sender (name) 5) Nearby folders > ------------------------------ 6-n) folders from the current account (I've capitalized the letter that should be used as the "hotkey" for the menu entry, since I don't know how to underline in this forum, like Windows does (if you turn the option on). Entry 1 should only exist if the user has defined "favorite" folders in some manner that would have to be invented. Entry 4 should only exist if the user has defined a folder for this sender. Entry 5 should only exist if the user has turned on "relational folder navigation". I guess this option would be most useful in conjunction with filters, because it is exactly the same as the original idea of this bug, when the source folder is Inbox for a given account. I think this subsumes the concepts of everything in the other bugs, so they could now all be marked as dups of this one, eh?
(In reply to comment #2) > I wouldn't think this bug is quite a dup of bug 105062... that bug is > suggesting reordering the accounts in the current top level menu, this bug > is suggesting replacing them with the folders of the current account. Whatever. The actual results are going to depend on whoever might actually write the code to fix this someday. That could be you, in which case the menu will look just the way you want it to. > I think this subsumes the concepts of everything in the other bugs, so they > could now all be marked as dups of this one, eh? Uh, no. Put a bag over that ego, eh?
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
The latest SeaMonkey still doesn't seem to have any new options in this area.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050901 SeaMonkey/2.0a1pre Reporter: In menu "Move To -> Recent" - is it?
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 251296
You need to log in before you can comment on or make changes to this bug.