Closed Bug 466060 Opened 17 years ago Closed 14 years ago

show "Save All", "Detach All", "Delete All" context menu items when one or more attachments are selected, like in Thunderbird 2

Categories

(Thunderbird :: Mail Window Front End, defect, P2)

Product:
Thunderbird
Component:
Mail Window Front End
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 3.0b2

People

(Reporter: steffen.wilberg, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: regression, ux-discovery, Whiteboard: [UXprio] [gs])

Attachments

(2 files)

v1
1.59 KB, patch
Details | Diff | Splinter Review
UI-proposal for dual menu button 'Select all' on attachment context, with action-all submenu
1.27 KB, text/plain
Details
I miss "Save All", "Detach All" and "Delete All" from attachments' context menu. I had to read msgHdrViewOverlay.js to learn that these context menu items are now 1) on the context menu of the *blank space* next to the attachments, and 2) only shown if there's no attachment selected; if there is one selected, you have to left-click in the empty space next to it. That's not exactly what I call intuitive... And it's impossible to find for Thunderbird 2 users. I want those context menu items back on the context menu of the attachments themselves, if there's more than 1 attachment in the message, and whether there are one, multiple, or all attachments selected. I'd ignore the use case of saving multiple, but not all attachments, and just save them all.
Flags: blocking-thunderbird3.0b1?
Flags: blocking-thunderbird3.0b1? → blocking-thunderbird3?
I agree that it's hard to find. I think we can do better than a context menu, though. I might poke at that if I get a free minute.
It'd be great to at least have the ( Save All ... ) button readily available, instead of in a context menu. We're likely tight on vertical space in the given attachments area so perhaps we could take up some space on the right side. The Other Actions can operate exactly as the one in the message reader does; it will hide the actions that are useful but can be confusing to some people. ex: +---------------------------------------------------------------------+ | .-----. |^| ( Save All ... ) | | | | | | | | '-----' | | [ Other Actions |v] | | attach1.jpg | | | | |v| | +---------------------------------------------------------------------+
Attached patch v1 — — Splinter Review
Here you go. I also poked around to do something about making the actions on the attachment icons easier to figure out, but I don't think an incremental patch is worthwhile. Best to figure out what we really want and throw away the existing binding, IMO. (the padding on the buttons is a bit off somehow, and causes a scrollbar to just appear -- TBD)
Whiteboard: [has early patch]
I think that will cause a lot of wasted vertical space if one has mailnews.attachments.display.largeView set to false, and the typical case of 1-3 attachments, which fit very nicely on one small row. (I'd prefer mailnews.attachments.display.largeView to default to false anyway.)
Comment on attachment 349375 [details] [diff] [review] v1 Just a small note to the early patch: >+ <button type="menu" id="otherActionsButton" >+ label="&otherActionsButton.label;" We are already using this id in the header pane: http://mxr.mozilla.org/comm-central/source/mail/base/content/msgHdrViewOverlay.xul#232 What about "otherAttachmentActionsButton" which even better bind it to the attachment box?
Comment: #4: I didn't even know about that pref. interesting. I think we really need to clean up the use of space in that pane anyway. Ideally we'd move it to scroll inline w/ the message, so it wouldn't take up space from the message display. In the meantime, with that pref false, we probably want save all and "other actions" to be side by side, so they don't take up more space. Or something. Comment #5: thanks, yes, bad id choice.
I don't think we'd block for this; blocking‑thunderbird3-
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
Priority: -- → P2
Target Milestone: --- → Thunderbird 3.0b2
I don't know when exactly this happened or why it was changed, but Thunderbird version 2.0.0.18 now has this same annoying behavior.
Rogers, please see bug 466016.
moreover to, as it has been said "Save All" should be displayed on any attachment selected (even one among multiple): thunderbird should allow attachment selection with Shift+mouseclick to select desired attachments to be selected. shift+click now does nothing! ctrl+a should work for selecting all attachments after attachment region (panel) had been clicked into.
I agree with comment #11 points: - Both 'Save' & 'Save All' should be enabled in context (same with delete & detach), no matter if one, none or multiple attachments are selected. It should be triggered by attachment pane focus; not by attachment selection. - Shift select on attachment pane focus. - Ctrl+A select on attachment pane focus.
The old functionality was maybe not ideal, but the new functionality is hardly much better, and it's definitely confusing, especially if you have used TB for a while. I had to find this bug to realize that "___ all" options were not simply gone since I used to always right-click on one of the attachments. Please revert this change to the old functionality... or improve further so that it is clear how to get to the "___ all" options... current functionality is not well thought out.
For an alternative take, see bug 436555.
Another little quirk with this: If you use the arrow keys you can still get to the grayed out items.
Why change it at all if it worked perfectly well? By all means add more buttons if it was hidden (or whatever the thinking was), but there was nothing in the least confusing about "Detach All", even if an attachment was active: the label says it all.
I can't believe this is still in discussion guys. The whole interface is getting "overbuttoned" already, why add another button for something that's in the main menu AND the attachment area's context menu? Isn't the attachment area defaulting to "small" already? Even without the additional buttons? Just show the persistent "all" menuitems in the context menu for user's sake :(
Why reinvent the wheel and break things that actually worked? And no, I don't need nor want that always-visible button wasting precious attachment pane real estate. (In reply to comment #17 and others) > Just show the persistent "all" menuitems in the context menu for user's sake :( Exactly! And that's the nice way of putting it. I'll post a new bug that right-clicking in attachment pane white-space doesn't deselect attachments and therefore even in whitespace you can't get the "save-all" context straight away.
Blocks: 521012
No longer blocks: 521012
The current summary suggests this is a regression. Regression-window can help find those few lines of code that went missing and are needed to fix this annoying everyday bug. Related bugs: (In reply to comment #12) > I agree with comment #11 points: > - Both 'Save' & 'Save All' should be enabled in context (same with delete & > detach), no matter if one, none or multiple attachments are selected. Bug 516294 - Right-click on attachment pane white-space does not deselect attachments, triggers wrong context menu > - Shift select on attachment pane focus. Shift selection and Ctrl selection works in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100119 Shredder/3.0.2pre. > - Ctrl+A select on attachment pane focus. Bug 281046: CTRL+A, with focus in the attachment panel, does not select all attachments > It should be triggered by attachment pane focus; not by attachment selection. I couldn't agree more. "Focus-gets-keyboard-input" is on of the most basic universal UI concepts that you can't ignore without making UI behaviour unpredictable, especially with regards to accessibility. In bug 516294 comment 2, Phil Ringnalda points out the reason for such user expectations: > Probably because that's what the Finder, the Gnome File Browser, and Windows > Explorer, where most people get their expectations for the behavior of icons > representing files, all do. Unfortunately, the actual degree of respect for focus can be very different even among developers (see e.g. the discussion in related Bug 315144: Pressing [Shift+]DEL on focused(!) attachment deletes message(s) instead of attachment). Please vote for bugs that aim at restoring respect for focus. Emotional side note: Thunderbird keeps surprising me that while in some corners we're really advanced (like showing attachment reminders when you type relevant keywords), some of the most basic email handling stuff like selecting or saving all attachments can drive you out of your mind as it just doesn't work in ways that any sane person is likely to expect.
Flags: blocking-thunderbird3.1?
Keywords: regression, regressionwindow-wanted
Ummm... I'm confused after reading all of this, as to what the problem is with just bringing back the old behavior? It was easy, simple, intuitive, and just worked. Buttons? Seriously? No offense, but please, that is just plain silly. Again - if no one can provide a sane, sensible argument as to why the old context menu behavior cannot be brought back, then consider this my vote to please, please, please bring it back in TB3. I'm really getting annoyed at all of the changes being forced on us old time users - first tabs and no easy way to eliminate them, no option to open the calendar in the current tab (why!?), no way to move the calendar toolbar buttons to a different toolbar (wjy!?), offline sync was set to everything for all accounts by default, which when combined with GLODA being enabled by default brought my freshly updated profile with 16 IMAP accounts and many, many GBs of email to its knees, crashing many times before I was finally able to disable all the auto stuff (yes, it was partly my fault, since I missed the Migration pane that would have allowed me to disable the offline syn for all accounts with one click - but it still started syncing immediately, rather than wait for me to tell it what to do), eliminating the compact header and extended folder columns code (yes I already have the extensions, but why!?)... Come on guys. One of the main reasons I love Firefox and Thunderbird is for their flexibility. Don't ruin it by trying to force your way on everyone else. I don't mind new features and *options*, but unless there is a good reason, there should almost always be a way to bring back old behavior.
While it would be great to get this for 3.1, the main yardstick we're using is whether it's likely to prevent folks from accepting a prompted major update from Tb2, and I don't think this quite rises to that level, though it comes close. Marking as blocking-; clarkbw, you should feel free to countermand that order if you disagree, particularly if you think the way forward is simply to change the attachments UX in some other way. That said, it would be great to get this whenever we get it, so wanted-thunderbird+.
blocking-thunderbird3.1: --- → -
Flags: blocking-thunderbird3.1? → wanted-thunderbird+
(In reply to comment #21) > While it would be great to get this for 3.1, the main yardstick we're using is > whether it's likely to prevent folks from accepting a prompted major update > from Tb2, and I don't think this quite rises to that level, though it comes > close. While I agree it will be nice when this is fixed, I don't thinks it's really close at all. This problem already exists in TB2, so why would the fact that it isn't fixed *stop* someone from upgrading? I can see where having it fixed might be a small incentive for a small percentage of people to upgrade, but I really don't see this being much of a 'deciding factor' for more than a few, if any. So, definitely agree it shouldn't block 3.1...
The problem did not exist in the first TB2 - it was introduced in one of the last upgrades. Don't know the code, but is it really, truly that hard to look back in the code and simply reverse the bit that screwed this all up? *sigh*
I know, but most people auto-update TB2. The workaround is not that bad, so I really don't see this as a blocker (but yes, I'd still like to see it fixed), just a minor annoyance. Once you understand what is required, you simply never right-click directly on an attachment if your desire is to 'Save All'...
(In reply to comment #21) > Marking as blocking-; clarkbw, you should feel free to countermand that > order if you disagree Bryan, this is basic everyday functionality, the lack of which is quite a workflow breaker for a supposedly large number of users. > particularly if you think the way forward is simply to > change the attachments UX in some other way. IMHO most users would be quite happy with the current attachment UI if it actually worked as it should, and had full and correct keyboard accessibility. This bug would be much less of an issue if at least Ctrl+A with focus in attachments pane would correctly select all attachments instead of selecting all messages (bug 281046), and DEL on focused attachments would would correctly delete attachments instead of deleting messages (bug 315144). > That said, it would be great to get this whenever we get it, so > wanted-thunderbird+.
Whiteboard: [has early patch] → [has early patch][UXprio]
There are two pieces to this bug that got conflated. 1) Currently the set of actions for all attachments are hidden in a right click menu which makes them accessible to a small amount of users who discover this. 2) The actions for all attachments used to be accessible even when 1 or more items where in focus in the attachment pane. Originally we wanted to try fixing (1) which would fix (2) at the same time. However I feel like the fix of making the "all actions" always available for every context menu is fairly easy and reasonable to do in this bug. Work on a more universally usable attachment pane can continue elsewhere. I'm going to mark this as a needed blocker. I have two different designs in mind. a) Add a simple menu-button to the right hand side of the attachment pane with no text to it which offers the "all actions" as a popup. This makes the attachment pane look like this: +-----------------------------------------------------+ | [I] attachment [I] attachment |(v)| +-----------------------------------------------------+ The menu button on the right hand side would take up about the same amount of space as the scroll bar does in the message pane. There would be a visible action to all the attachments in the pane without creating much of a new area. b) Add a sub-menu to each single attachment context menu for "all" actions. .--------------. | Open | | Save As... | |--------------| | Detach... | | Delete | |--------------| | All > | '--------------' The "All" submenu simply shows the current all actions popup menu which appears if you right click in an empty area without focusing on any attachments. This does not give an obvious and visible option for handling all attachments but does bring back some functionality that was lost such that work flows will be relatively the same as it won't matter if an attachment is focused or not.
blocking-thunderbird3.1: - → needed
Whiteboard: [has early patch][UXprio] → [UXprio]
Sounds reasonable to me... although, its not like this context menu is all that cluttered, so I'd prefer not having an All submenu - just provide 3 (or 4) more individual choices: Detach All, Delete All, and Save All (does anyone ever want to 'Open All')?
Agreed - the one I ever *by far* the most is "Detach All" - just pop it on the menu, three more lines in the menu are irrelevant in the grand scheme of things.
What about having the last entry in the context menu just be "select all"? Choosing this option would highlight all attachments (just like pressing "Ctrl-a" for select all). Then, in a second step, the user can choose among the 4 known options. That way, we would not clutter the menu, and provide all options. Btw: Pressing Ctrl-A (in TB 3.0.1) now selects all *messages*, even if I clicked inside the attachment area - I would expect that it should select all *attachments*.
(In reply to comment #29) > What about having the last entry in the context menu just be "select all"? > > Choosing this option would highlight all attachments (just like pressing > "Ctrl-a" for select all). Then, in a second step, the user can choose > among the 4 known options. Nah, too much 'work'... > That way, we would not clutter the menu, and provide all options. But that's the point - the menu isn't cluttered, even with these three additions. > Btw: Pressing Ctrl-A (in TB 3.0.1) now selects all *messages*, even if I > clicked inside the attachment area - I would expect that it should select all > *attachments*. There's a nasty/known bug about this (don't remember the number offhand), to do with selecting the attachment then pressing the delete key on the keyboard deletes the *message* instead of the attachment...
(In reply to comment #30) [...] > > Btw: Pressing Ctrl-A (in TB 3.0.1) now selects all *messages*, even if I > > clicked inside the attachment area - I would expect that it should select all > > *attachments*. > > There's a nasty/known bug about this (don't remember the number offhand), to do > with selecting the attachment then pressing the delete key on the keyboard > deletes the *message* instead of the attachment... Ok - you might mean bug #315144... Yes, seems to be the same kind of focus-problem.
Yep, that's it, thanks - I had forgotten to vote for it, so just did... :)
blocking-thunderbird3.1: needed → beta2+
We're resetting the blocking flag for 3.1 on this bug and instead setting the wanted-thunderbird+ flag. We have too many blocking-3.1 bugs, to the point where it doesn't mean much, and managing the list is making it hard to actually work on closing bugs, which helps no one. Thunderbird 3.1's primary purpose is to allow us to offer a prompted major update to Thunderbird 2 users, to ensure their continued ability to safely use Thunderbird. Thunderbird 2 is built on an outdated version of Gecko, and our long-term ability to maintain the users' safety for Thunderbird 2 users is limited. If you think this bug meets the requirements below, please renominate with a detailed explanation of how it meets the following two criteria, and we will reconsider. To qualify, this bug must either: a) make the upgrade experience from TB2 very painful for a large number of users or b) be a new, reproducible, severe quality issue (eg dataloss, frequent crashes) Just because this bug doesn't block TB3.1 doesn't mean it can't or won't make the release. Once they're done with their blockers (if any), we encourage developers to keep working on non-blocking bugs, and to try to land them as early in the cycle as possible, as non-blocking bugs will become increasingly difficult to land in the later stages of the cycle.
blocking-thunderbird3.1: beta2+ → ---
Blocks: 328293
For TB2, there's related Bug 466016 - [1.8 branch/Thunderbird 2] save all, delete all, and detach all attachments disabled
See Also: → 466016
URL: http://assets4.getsatisfaction.com/mo...
Whiteboard: [UXprio] → [UXprio] [gs]
May I draw your attention to the fact that this bug is more than 2 years old. As probably 90% (or more !) of the users I have thought that the "detach all" functionality has been suppressed. I just discovered (I searched "detach all" before filling an other bug) by reading this bug and others related that the functionality was still here but in the file menu. So I have been deprived from the use of "detach all" for 2 years ; I receive frequently mails from my children with pictures as attachments, I detach them to my picture_directory. This means easier repetitive views of them and smaller mailboxes that is good for the speed of TB. Detaching the pictures one by one is a big pain... It is fine to discuss for 2 years in several places (bugs) which is the best interface but during this time users should have an existing interface : a function without interface is equivalent to no_function ! Reinstalling the old interface dating from the time (TB 1.5 ?) this function was just an extension should have been rapidly used as a provisional/crash solution. To be positive after these recriminations : It exist inside Mozilla a "Pilot Test" used to ask questions to users, to make statistics on their configurations, etc.. The number of registered volunteers participating is more than 3 millions. Why not asking something like : "Do you know the work-around for bugs : 1) Bug 466060 - show "Save All", "Detach All", "Delete All" context menu items when one or more attachments are selected, like in Thunderbird 2 work-around : go to -> file menu -> attachment. With boxes for Yes or No. 2) to n) any other bugs and their work-around you can find... Please tell this to all other people that you know" You may be surprised by the small number of people knowing the work-around and more motivated to make a provisional patch. After this "test", the work-around will be known by millions !
Jean-Marie, this is probably going to get fixed in bug 282068 (by way of adding a button that shows all the relevant actions).
Good news ! I hope (for the other users) it will be soon ! I'll comment more in bug 282068 ...
Should this be marked fixed now that bug 282068 is done?
(In reply to comment #39) > Should this be marked fixed now that bug 282068 is done? go for it!
Fixed by bug 282068.
Status: NEW → RESOLVED
Closed: 14 years ago
Depends on: 282068
Resolution: --- → FIXED
This bug should be reopened. FTR: I strongly disagree that bug 282068 fixes this bug. I don't see how a useful button on the far right does away with the need for the comfort and efficiency of contextual / in-place actions, to be used intuitively from any attachment's context menu for those who expect it there. IMHO, as others have said before, just adding the 4 action-all commands to each attachement's context menu would be most efficient and still non-clutter. At least (as a compromise), let's go for Bryan's idea of comment 26 b): b) Add a sub-menu to each single attachment context menu for "all" actions. .--------------. | Open | | Save As... | |--------------| | Detach... | | Delete | |--------------|.--------------. | All > || Open | '--------------'| Save As... | |--------------| | Detach... | | Delete | '--------------'
I second that - this bug is NOT resolved. Grrr.
This bug was filed because the "____ All" actions were hard to discover. A visible button showing these actions is about as discoverable as you can get, so as far at comment 0 is concerned, this bug is fixed. It seems that most people are arguing for this behavior simply because that's how it used to be, which isn't a convincing argument in and of itself. Nearly every example of context menus I can find specializes the actions in this way (e.g. context menus for links don't contain any items from the context menu for a whole web page). The only counterexample I could find is the tab bar in Firefox, which doesn't distinguish *at all* between clicking on a tab and clicking on the empty space (this is in 3.6, since in 4.0 there is no empty space, really). However, that's a bit different, since it's impossible not to have a current tab, whereas it's certainly possible not to have a currently selected attachment. There is, however, an issue that right-clicking on empty space in the attachment area doesn't deselect the current attachment, making it harder to get at the "____ All" items. That's bug 516294. While I agree that that needs to be fixed in order for things to work properly, I don't think that changes the status of this bug.
(In reply to comment #44) > This bug was filed because the "____ All" actions were hard to discover. A > visible button showing these actions is about as discoverable as you can get, Jim, it is certainly true that your button offers maximum visibility for the action-all actions. However, maximum visibility is not necessarily the same as maximum intuitiveness (for different types of users), nor maximum efficiency. > so as far at comment 0 is concerned, this bug is fixed. That's simply not true. Comment 0 might have been influenced by lack of ux-discovery, and the button certainly helps to improve that, but comment 0 leaves no doubt about the desired solution: > I want those context menu items back *on the context menu* of the attachments > themselves, if there's more than 1 attachment in the message, and whether > there are one, multiple, or all attachments selected. Comment 0 also makes it very clear that right-clicking on white-space is NOT the desired solution (apart from the fact that it doesn't work properly, due to bug 516294). > It seems that most people are arguing for this behavior simply because that's > how it used to be, which isn't a convincing argument in and of itself. I don't know how you arrive at that assumption, I don't see that in the comments. I want the all-attachment actions back in the context menu for several reasons, e.g.: 1) I am in the habit of using contextual menus (not because that's how it used to be, but because it's efficient, as it works everywhere without wasting a second looking for and moving to the right button) 2) I see the attachments, and I want to act on them. So my intuition is to right-click right there on whatever attachment happens to be under the mouse pointer. Moving my mouse to the far-right to catch that button is not intuitive nor efficient for me (it might be for others). 3) Right-clicking on blank-space to act on objects outside the blank-space is not very intuitive, and I am not aware of exact UI models for that. Furthermore, it's inefficient as I might have to move the mouse pointer much further than just right-clicking on the next-best attachment. Finally, especially with very short file names like test.txt, right-clicking on what looks like whitespace will in fact select an attachment and show its context menu. > Nearly every example of context menus I can find specializes the actions in > this way (e.g. context menus for links don't contain any items from the > context menu for a whole web page). Exactly. We want the context menu of a single attachment to provide easy access to saving *that* attachment *and* its neighbours. We don't expect "delete this mail" on the context menu of attachments. Although if we press DEL on a selected attachment, that is what happens (Bug 315144), because the UX-lead thinks users are unable to handle focus, deliberately ignoring that focus is the fundamental principle of any interaction with any software. In any other application, we click on objects to select and focus them, then press DEL to delete them. Not so in Thunderbird, when it comes to attachments. Instead, the user's mail data will unexpectedly be deleted (sorry for OT, but IMO that is still one of the most incredible bugs of TB, and it will get worse again as soon as we re-allow focussing the attachment panel objects). > There is, however, an issue that right-clicking on empty space in the > attachment area doesn't deselect the current attachment, making it harder to > get at the "____ All" items. That's bug 516294. While I agree that that needs > to be fixed in order for things to work properly, I don't think that changes > the status of this bug. As explained above, the requests of comment 0 might have been alleviated, but they have not been adressed. This bug should be reopened.
I forgot to mention that the other intuitive alternative, simple selecting all attachments using Ctrl+A, then act upon them as a group, is currently prevented by Bug 281046, fixing which requires fixing Bug 573230, first, and probably more negotiations with the UX-lead (while others are starting to realize how badly we fail keyboard users in this area, cf. Bug 646171).
Of the comments that provide any reasoning for why the "____ all" items should be in the selected item context menu, most of them (#0, #13, #16, #23, #36) only argue that this is how it was, so it should be reverted. Only comments #17, #18, and #20 provide any other reasoning, which is that they're not a fan of adding a button, saying that it's too cluttered/takes up too much space (the new UI actually takes up *less* space when it's collapsed, even for a single attachment). That doesn't, however, provide any positive argument for adding the "____ all" items. It's essentially the XY problem: one wants X (be able to easily access the "____ all" actions for attachments), and thinks Y is the best way to do it (revert to Thunderbird 2 behavior), so they ask for Y instead of X. (In reply to comment #45) > Exactly. We want the context menu of a single attachment to provide easy access > to saving *that* attachment *and* its neighbours. We don't expect "delete this > mail" on the context menu of attachments. Although if we press DEL on a > selected attachment, that is what happens (Bug 315144), because the UX-lead > thinks users are unable to handle focus, deliberately ignoring that focus is > the fundamental principle of any interaction with any software. ... You're preaching to the choir here, since I already have a mostly-working patch in my queue to fix keyboard accessibility on the attachment list. I've discussed parts of this with clarkbw, and I have a pretty good understanding of his concerns (he's not opposed to keyboard focus, but essentially thinks that the default behavior should be like what happens when you ctrl-click on items*). However, I don't see how this is an argument in favor of your position here, since the proper solution would be to make the attachment list support keyboard focus. My goal is and has always been to get this fixed by 3.3, but I've been busy with some other things of late. When I get the last of the issues in my patch fixed, i'll upload it to bug 630759. In short, it sounds like adding the "____ all" items to the current attachment context menu is really a workaround for other issues in the attachment area; issues which I'm already working on fixing properly. In your case, you want to be able to work more efficiently, which is resolved by fixing keyboard accessibility. In other people's case, it was difficult to discover the "____ all" items, which has been resolved by adding a button to the attachment pane to make it more obvious. * I disagree with this, for what it's worth, but it's also pretty easy to change that behavior, and I'll probably make an addon to do things clarkbw's way so that we can test it out.
Bryan, with regards to making save-all etc. available again from single attachment's context menu: Another compromise solution, with added functionality, could be this: c) Implement a dual menu button (like the new FF4 print button on the compact menu): - main button part for "Select all", to do just that - hovering the main button or hovering/clicking the arrow part will show the action-all submenu: .---------------. | Open | | Save As... | |---------------| | Detach... | | Delete | |---------------|.--------------. | Select All | >|| Open | '---------------'| Save As... | |--------------| | Detach... | | Delete | '--------------' Benefits: - Select All is a reasonable action even when starting out from a single attachment - Select All is useful not only for subsequently applying action-all commands, but also for *dragging* all attachments to wherever they are wanted - The dual button provides a highly elegant and minimally intrusive solution to integrate the action-all context menu from the arrow part. Which mirrors the standard procedure of acting on all attachments, but is more efficient: select (all), then act (all). More efficient because user can perform action-all commands without leaving the context menu.
Attachment #524020 - Flags: feedback?(clarkbw)
(In reply to comment #47) > Only comment 17, comment 18, and comment 20 provide any other reasoning, > which is that they're not a fan of adding a button, saying that it's too > cluttered/takes up too much space (the new UI actually takes up *less* space > when it's collapsed, even for a single attachment). I am already starting to enjoy the attachment bar (well done, and thank you!), but let's not ignore that the new UI actually takes up *more* space for any number of attachments when it is NOT collapsed, and it adds another permanently visible button to the UI where there was no button before. As the reaction to the new message reader UI has shown very clearly, not all of us want the whole UI buttonized, because they feel that too many buttons are clutter that make it harder to discover/focus on the essentials (let alone the space they use). > That doesn't, however, provide any positive argument for adding > the "____ all" items. I'd probably consider established usage patterns a positive argument; otherwise, I'm sure there are some positive arguments in my comment 45. > You're preaching to the choir here, since I already have a mostly-working > patch in my queue to fix keyboard accessibility on the attachment list... > When I get the last of the issues in my patch fixed, i'll upload it to > bug 630759. Thank you, I am very much looking forward to that!
I agree with comments #42, 45 by Thomas D. I think that context-menu items should be available in the attachment area, and should pertain to attachments. In addition, having context menu items pertaining to "all" should not depend on the selection state of attachments, except that an item referring to "all selected" should of course pertain to those which are selected. I am not a fan of buttons. Buttons tend to come and go, and wander around the ui as versions change, making them both cluttering and annoying, but yet hard to find. I am also against some context menu based on mouse-hovering over some button. That just adds something hard to discover, annoying when you don't want it, and also will lead to a question of what the hover time should be before it appears. The only reason to make it the way it used to be with context menus is that it used to be simple and intuitive.
Comment on attachment 524020 [details] UI-proposal for dual menu button 'Select all' on attachment context, with action-all submenu Removing old request on a closed bug. If you feel this is still valid/needed, I recommend it is moved to a new/open bug and re-requested.
Attachment #524020 - Flags: feedback?(clarkbw)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: