User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.2 (KHTML, like Gecko) Chrome/6.0.447.0 Safari/534.2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 Attachments UI is severely outdated. It has several problems: * save all is impossible to discover for a normal user. It requires right-clicking on an empty area in the attachments area below the message and selecting 'save all...'. * it requires way too many clicks. two clicks to display the "select folder" dialog. that dialog starts by default in the users' profile folder, which is NOT the place to store email. besides, saving each time to a completely different path * the attachments pane uses a 'list view' to present the files. It makes a suboptimal use of the screen (view below). * the 'list view' doesn't show the whole attachment filename. It shortens them using "..." in the middle, even if you have a single attachment in an insanely wide monitor. The attachments area should follow Gmail's example by: * listing all email in a table (or something similar to the 'details view' in the OS file browser). show attachment size in each case. * for each file (or row in the table), put three buttons with: ** open ** save ** another different button for the "save as.." action with folder selection. * if more than one file is attached then, for all the attachments: ** show total size ** add an option to store the files with a single click. In a related bug (https://bugzilla.mozilla.org/show_bug.cgi?id=575875) I suggested creating a "saved email attachments" folder under "my documents". In this case the "save all attachments" button should create a subfolder under the "saved email attachments" folder, its name being the message's subject. E.g. I'm viewing a message called "birthday pictures" with several attachments. Clicking on "save all" creates a "birthday pictures" subfolder within the "saved email attachments" folder located in "my documents". * the same goes for detach all. Gmail-style is just an option. This issue should be considered alongside https://bugzilla.mozilla.org/show_bug.cgi?id=575874 Reproducible: Always Steps to Reproduce: N/A Actual Results: N/A Expected Results: N/A N/A

Thomas can you sort this one out ?

(In reply to comment #0) Hello ponzonik... First of all, thank you for your feedback, which provides a good overview of attachment UI related problems, and a suggestion for enhancement/renewal of the existing UI. Both the bug reports and the proposed enhancements are valid and interesting, and personally, I agree with many aspects. However, the multitude of bugs and proposals makes it impossible to act on this bug. What we really need on the bug side is "one problem per bug" (specific and confined). Similarly for the enhancements, small and specific enhancements are more likely to get attention, and they should generally be separated from bug reports. For brainstorming and developing enhancement ideas, mozilla.dev.apps.thunderbird or http://www.getsatisfaction.com/mozilla_messaging might be better. Furthermore, many the specific problems und enhancements of comment 0 have already been filed. Please ensure to search for existing bugs before filing new ones. Instead of commenting, you may wish to vote for existing bugs. > Attachments UI is severely outdated. It has several problems: > * save all is impossible to discover for a normal user. It requires > right-clicking on an empty area in the attachments area below the message and > selecting 'save all...'. Bug 466060 - show "Save All", "Detach All", "Delete All" context menu items when one or more attachments are selected, like in Thunderbird 2 Bug 541336 - Implement / add "Save All Attachments" button in attachments pane Bug 436555 - attachment presentation in received messages needs improvement > * it requires way too many clicks. two clicks to display the "select folder" > dialog. that dialog starts by default in the users' profile folder, which is > NOT the place to store email. besides, saving each time to a completely > different path Please check if there's a bug for this, if not, pls file new bug with much more details: * Conditions (e.g. Are you working on a brand new default profile?) * Steps to reproduce (pls list every little step, every click 1...,2...,3...,4...) * Actual result: ... * Expected result: ... It is absolutely essential to follow that structure, and be as concise as possible while providing necessary details. > * the attachments pane uses a 'list view' to present the files. It makes a > suboptimal use of the screen (view below). It's not clear what you mean. Maybe "view below" means "see next point": > * the 'list view' doesn't show the whole attachment filename. It shortens them > using "..." in the middle, even if you have a single attachment in an insanely > wide monitor. Pls research and, if needed, file a new enhancement bug with all required details as described above. Proposed enhancement of Bug 360647 might be a sufficient solution. > The attachments area should follow Gmail's example by: > * listing all email in a table (or something similar to the 'details view' in > the OS file browser). show attachment size in each case. It's not very clear which aspects of Gmail's attachments you'd like to see in TB. Gmail treats images different from other attachments. Gmail's attachments table isn't very tabular, and it's a web UI. It's probably best to visualize your proposal with handmade mockup screenshots of Thunderbird attachment area depicting the exact changes you want. As for the 'details view': Bug 360647 - Need configurable view for list of attachments (implement alternative view modes, should have view for attachment details as pictured in Bug 446452, screenshot attachment 330616 [details]) Bug 384331 - Implement "All attachments" view (grid-style: filename/type/date/size/from) to folder pane views [explorer-style list with attachment details] > * for each file (or row in the table), put three buttons with: > ** open > ** save > ** another different button for the "save as.." action with folder selection. Again, visualization needed (mockup screenshot). Multiple buttons permanently reduplicated for each attachment is unlikely to happen (too much button clutter). Similar approaches: Bug 436555, screenshot attachment 363274 [details] (IMHO, still lots of button clutter, and pretty non-standard UI) Bug 436555, screenshot attachment 426857 [details] (IMHO, apart from the futuristic preview, the general approach here seems right: more like a file dialogue - select file(s), then click one out of few action buttons, less frequent actions in button dropdown) Bug 541336 - Implement / add "Save All Attachments" button in attachments pane > * if more than one file is attached then, for all the attachments: > ** show total size Bug 559559 - Show the file size of attachments in attachment panel of *any* messages (received/sent/deleted etc.) Bug 195702 - attachment size should be visible in compose window Bug 430288 - For composing, show additional tooltip information on mouseover of attachment filename (modify timestamp, file size) > ** add an option to store the files with a single click. IMO, this is an interesting idea to explore. You can mimic that behaviour by setting a download folder in "Tools > Options > Attachments > Save Files to". But then you can never choose another target folder for saving until you change that option again - bad. In fact, this points to a bigger can of worms where our UI for saving multiple attachments is not very versatile, at all. Ideally, we should have a UI where free combinations of the following matrix are possible: - pre-defined folder (set in options) - user-chosen folder (save to...) - use existing file names (one-click to save all) - ask for each file name (checkbox?) > In a related bug > (https://bugzilla.mozilla.org/show_bug.cgi?id=575875) I suggested creating a > "saved email attachments" folder under "my documents". In this case the "save > all attachments" button should create a subfolder... <snip> In bug comments, please use the following syntax to simplify your bug links (while taking full advantage of autolinkification): bug [space] id, like this: bug 575875 I sometimes add the summary so as to keep a record of it, and so that folks can see and know the summary without hovering over the bug link. bug 575875 - attachments default save location is desktop, should be downloads folder > Gmail-style is just an option. This issue should be considered alongside > https://bugzilla.mozilla.org/show_bug.cgi?id=575874 Separate issue, reminds me of some nice features of Postbox email client that Thunderbird should consider in the long run. Bug 575874 - contacts / list all attachments by contact or group OK, extraordinary bugs require extraordinary actions, so finally, do NOT imitate the length of this comment ;) or other flaws that I might have been lured into by the plain albeit known truth of this bug's current summary: Attachments area UI badly needs improvements...

Short summary of comment 2 (FTR, and for the hasty, and to avoid Ludo pulling his hair in despair ;) ): 1) this bug rightly points out multiple problems of current attachment UI 2) this bug proposes several useful ideas for enhancement 3) most, but not all of these problems and proposals have already been filed (see links in comment 2) 4) this bug isn't actionable, thus cannot be confirmed (although it's a good overall picture of badly needed attachment UI improvements) 5) before resolving this bug (perhaps as a duplicate of Bug 360647, or Bug 436555), ensure that it has been fully dissected (till then, leave unconfirmed)

Thanks for considering my suggestions. Please pardon my lack of experience on bugzilla. A few comments about some of your statements: > What we really need on the bug side is "one problem per bug" (specific and confined). Similarly for the enhancements, small and specific enhancements are more likely to get attention, and they should generally be separated from bug reports. > Again, visualization needed (mockup screenshot). These are contradictory. I could go on and file a bug for every single little problem of the attachments UI, but what would that accomplish? You already know (since at least nov-2006, bug 360647) and agree to this (and ask for mockups). So, little fixes probably won't cut it (and be a waste of time). Maybe the best would be to take all the bugs or enhancement requests here and start a discussion among the rest of the developers / people involved. I've uploaded a balsamiq mockup of what's on my mind. I'm also posting the xml file needed to recreate the mockup.

(In reply to comment 5) Clarification of my role here: I'm a volunteer in bug triage, i.e., I am not a developer nor working for Mozilla (but there's a strong sense of belonging and a considerable and recognized level of experience). Mozilla Messaging itself unfortunately only has a handful of staffers (who work with a larger global community of contributors, like us): http://www.mozillamessaging.com/en-US/about/staff/ Therefore, we need to be patient and cooperative, and not expect miracles, even though it hurts to see some things unadressed for years while solutions have already been laid out. In view of the legacy, there's bugs that are 10 years old, so Nov. 2006 for bug 360647 may not be very old yet... ;) The best thing is if you can code patches yourself.

(In reply to comment #0) > Attachments UI is severely outdated. It has several problems: > * save all is impossible to discover for a normal user. It requires > right-clicking on an empty area in the attachments area below the message and > selecting 'save all...'. Fixed in bug 282068 > * it requires way too many clicks. two clicks to display the "select folder" > dialog. that dialog starts by default in the users' profile folder, which is > NOT the place to store email. besides, saving each time to a completely > different path Dupe of bug 575875 > * the attachments pane uses a 'list view' to present the files. It makes a > suboptimal use of the screen (view below). Not really an issue on its own > * the 'list view' doesn't show the whole attachment filename. It shortens them > using "..." in the middle, even if you have a single attachment in an insanely > wide monitor. Fixed in bug 282068 (and further improved by the patch in bug 646032) Since all of the issues in this bug are resolved (though not in the way suggested in comment 0), can this be closed?

I don't think all of the issues of this bug have been solved. E.g. this one: > > * the 'list view' doesn't show the whole attachment filename. It shortens them > > using "..." in the middle, even if you have a single attachment in an insanely > > wide monitor. > Fixed in bug 282068 (and further improved by the patch in bug 646032) This is fixed only for the case of *one* attachment (where since fix for bug 282068, we show full file name on attachment pane header bar), but not for multiple attachments: attachment names are still truncated even though attachment pane has enough space to show more of the file names. Windows 7 has a better behaviour which actually always shows all filenames in full length, in list mode.

But that's exactly what that says: "even if you have a single attachment". As it stands now, that part of the report is pretty vague, and there should just be a new bug filed for the "all attachments" case. The fact that this bug violates the "one issue per bug" guideline doesn't help either, and I'd probably call the proposed solution WONTFIX, since I don't think the attachment pane is moving in that direction.

(In reply to comment #11) > Created attachment 529540 [details] > comment 10 I know that's what things look like in 3.1, but that's already been fixed in the nightlies. Again, see bug 282068 and bug 646032.

I've just tried Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0a2) Gecko/20110502 Thunderbird/3.3a4pre and it's not fixed below the header, with either one or more attachments. Sorry for the error in the attachment of comment 11. That is, the issue is NOT fixed. Also, >> * the attachments pane uses a 'list view' to present the files. It makes a >> suboptimal use of the screen (view below). >Not really an issue on its own Still don't see the benefit of using a list view instead of a details table if you're not going to use all the horizontal whitespace.

(In reply to comment #13) > I've just tried Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0a2) Gecko/20110502 > Thunderbird/3.3a4pre and it's not fixed below the header, with either one or > more attachments. Sorry for the error in the attachment of comment 11. That is, > the issue is NOT fixed. Again, as I've already said, this issue should go in a new bug, since 1) the proposed solution in this bug is probably WONTFIX (I really doubt we're going to move to a more Gmail-like UI), and 2) as a result, this bug isn't actionable since it has more than one issue. There should only be one issue per bug. That's not to say that tracking this as a separate issue will get it resolved any faster, but at least it'll be properly trackable. The attachment bugs in Thunderbird are a mess, since there are several bugs that cover the same things, multiple bugs that propose a redesign of how attachments are laid out, etc. Unless these bugs are broken down into their component parts, tracking fixes to the attachment area will remain unmanageable. I've been attempting to improve the UX for attachments, but it's a constant source of frustration trying to keep track of what bugs I can resolve since they're so unorganized. There are currently 70 open bugs being tracked under bug 579473 (the attachment meta bug), but about half of those could probably be duped to the other half. Anyway, I've filed bug 654222 to track the remaining issue in this bug. Resolving this as duplicate.