I know there's people who spent a lot of brains and work to make the new combined reply button more intelligent by offering changing / adaptive default commands. I appreciate that work, but personally, I'm not happy with the usability, at all. I never want "reply all" to be the default, because I rarely ever need it. For 95% of all mails with multiple recipients, I only reply to the sender. So the new intelligent default of "reply all" in the case of multiple recipients is just completely wrong for me. Maybe for others it's right. I can think of loads of scenarios, both business and private, where making "reply all" the default just because the mail has multiple recipients is just useless and wrong, even compromising privacy. Boss sends mail to employees (e.g. asking for personal feedback), society asks members for personal membership data update, grandma writes to her grandsons, Peter sends out birthday invitations to all his friends asking for reply if I'll come, you name it. Again, we are lacking the large-scale data to tell what most users really need and prefer. So we probably need a pref to optionally have a drop-down-button that has the normal "reply [to sender]" command as a non-changing default, i. e. always on top of the dropdown list. Alternatively, design a separate "less-intelligent" dropdown button that has "reply" as a persistent default, and let me customize the buttons and pick the button that best suits my needs. And a pony, please... ;)

Same problem was mentioned in bug 466025, comment #86. When Bug 465138 implements the buttons on a toolbar, offering two alternative combi-buttons (with different default behaviour) that user can pick from while customizing the toolbar might be easy to implement.

This bug would solve part of the problem of having the Reply and Reply All functions combined in one button. I would add that the icons for Reply and Reply All should be more distinct from each other (e.g., the two envelops could be more separated from each other on the Reply All icon). The better solution IMO would be to keep the two buttons separate. This will be especially necessary for the (huge number of) less experienced users. And it clearer from a general UI usability perspective.

(In reply to comment #0) > So we probably need a pref to optionally have a > drop-down-button that has the normal "reply [to sender]" command as a > non-changing default, i. e. always on top of the dropdown list. Alternatively, > design a separate "less-intelligent" dropdown button that has "reply" as a > persistent default, and let me customize the buttons and pick the button that > best suits my needs. The defaults for this option are always incorrect for some set of users in some large percentage of use. I believe the reply all default "intelligent button" behavior is going to be correct for the largest set of users. Though like you point out none of us have the real large scale data needed to back this up. If we had a pref to change the default back I think we would have the problem in an opposite manner where that 5% of the time you'd end up replying to just one person instead of the group. That makes me think your suggestion of a pref for always having a ( reply ) button and including the intelligent reply ( iReply ) as needed might work. The set of people who want more control on the reply / reply all could find that pref and have that option available. It is going to require even more horizontal space so I wouldn't want that option on by default. Perhaps we could try this in an extension to see how it works. > And a pony, please... ;) Now that's easy! Check your mail, a pony is on it's way :) (In reply to comment #2) > The better solution IMO would be to keep the two buttons separate. Are you finding the buttons in the headers useless because of this issue? I had assumed you thought they were useless because of the location in the header vs. the toolbar but I don't feel like I understand.

(In reply to comment #3) > (In reply to comment #2) > > The better solution IMO would be to keep the two buttons separate. > > Are you finding the buttons in the headers useless because of this issue? I > had assumed you thought they were useless because of the location in the header > vs. the toolbar but I don't feel like I understand. That's because you're confusing two separate issues. Here's an attempt to clarify: WITHIN the horrible decision to put the buttons into the header pane, having separate Reply and Reply All buttons there (or anywhere) would be better than having a combined button. BTW: This is especially true since (a) many/most screens have enough width (high-res & wide-screen) and (b) when the buttons are images without text (as they should be), then the one additional button doesn't cause significant "damage" (especially compared to how much confusion and embarrassing mistakes it will avoid). The fact that we are even discussing which mistake (accidental reply or accidental reply all) will be the less frequent or severe should be a clear and loud warning bell against combining these two related yet distinct yet easily confused functions.

Bug 248681 contains a discussion about adding the ability inside the compose window to toggle between "Reply" and "Reply to All" while composing a reply message. On the one hand this might reduce the demand on the intelligence of the reply/reply all button in the header pane of a message. One the other hand: If there were two individual buttons an incorrect click on one of them could easily be corrected when composing the message. In the present state you have to discard your answer and start over again.

(In reply to comment #5) > In the present state you have > to discard your answer and start over again. Or just copy/paste the reply into a new message. I think there are FAR more important things to invest time on.

(In reply to comment #3) > > And a pony, please... ;) > Now that's easy! Check your mail, a pony is on it's way :) Hooray! Thanks for the pony!! I'm already enroled for the ride. :))) > (In reply to comment #0) > > So we probably need a pref to optionally have a > > drop-down-button that has the normal "reply [to sender]" command as a > > non-changing default, i. e. always on top of the dropdown list. ... > If we had a pref to change the default back I think we would have the problem > in an opposite manner where that 5% of the time you'd end up replying to just > one person instead of the group. Exactly, and I'd much prefer 5% wrong replies without private data leakage over 95% wrong including private data leakage! :) > That makes me think your suggestion of a pref > for always having a ( reply ) button and including the intelligent reply ( > iReply ) as needed might work. The set of people who want more control on the > reply / reply all could find that pref and have that option available. It is > going to require even more horizontal space so I wouldn't want that option on > by default. hmmm, I'm afraid I was thoroughly misunderstood here, let me try again: Alternative 1 (pref that changes behaviour of existing button) - add a pref that ensures that "reply" (behaving like current reply button from main toolbar) is always the default option at the top of the combined dropdown reply button on header pane. In other words, you need to add code to the existing combined button to obey the pref. - probably the pref should also be in the UI if this approach is to make sense; that's even more code to add Alternative 2 (no pref; two separate <combined reply buttons> with different behaviour to choose from, using toolbar customize) - leave the existing combined button alone and just code another XUL button where "reply" (behaving like current reply button from main toolbar) is always the default option at the top of the combined dropdown reply button on header pane. - let users customize their header pane toolbar as per bug (can't find right now), so they can swap current against alternative combined button by ticking which button they (don't) want on the header In other words, you don't need the pref, I presume this is just a matter of some extra xul for the other button. (In reply to comment #2) > > The better solution IMO would be to keep the two buttons separate. I don't think that's a good default solution, because of probable space problem for many users, as Bryan points out.

Alternative 2 should be less ambiguously labelled: (no pref; two separate <combined reply buttons>, with different default behaviour: pick one using toolbar customize) So out of two different dropdown buttons, users can choose one, or both if they so wish (don't know if that would make sense): Combined Button 1 default: intelligent reply Combined Button 2 default: plain reply (always)

(In reply to comment #5) > Bug 248681 contains a discussion about adding the ability inside the compose > window to toggle between "Reply" and "Reply to All" while composing a reply > message. > > On the one hand this might reduce the demand on the intelligence of the > reply/reply all button in the header pane of a message. One the other hand: If > there were two individual buttons an incorrect click on one of them could > easily be corrected when composing the message. In the present state you have > to discard your answer and start over again. Exactly, 100% agree! (In reply to comment #6) > Or just copy/paste the reply into a new message. This is not an easy task for a large number of users. Copy and paste can't be a solution to a problem we've created. The solution in bug 248681 not only helps people avoid replying in the wrong manner but also helps people switch from that prevented mistake to the correct option. (In reply to comment #8) > Alternative 2 should be less ambiguously labelled: > (no pref; two separate <combined reply buttons>, with different default > behaviour: pick one using toolbar customize) > > So out of two different dropdown buttons, users can choose one, or both if they > so wish (don't know if that would make sense): > Combined Button 1 default: intelligent reply > Combined Button 2 default: plain reply (always) I like this alternative 2 approach as it seems to solve a number of different problems at once. Though I have no idea what kind of work it would take to make it happen; I'm assuming we initially avoided it because of that problem.

Let's try to detemine the shortest path to the release here. I think at minimum we could offer a reply "multiple" vs. reply sender default in an advanced pref checkbox.

Please see bug 516141 for a better solution (no pref clutter/confusion needed).

I'll jump on making a pref happen here. Not much time before the string freeze...

I'm scrambling to get this working but not having much luck. Lets see if some time on Saturday proves fruitful.

What is the status here? We need to gt to this ASAP because of the upcoming string freeze for TB3 tomorrow night.

I don't have a working patch ready yet. Once I get my review queue flushed I'll look into this again. Likely late tonight (Pacific Time)

Here's the first stab at this pref. I'm building on top of dan's bug 465138 patches to get a better feel for what this is like when you have the new button customization. Right now this adds a checkbox to the Adv. -> General prefs page for "Always offer Reply to Sender button". Checking that pref on will force the reply to sender button to always show in the header even when the smart button offers reply all or list. I haven't tried to clean up the drop down available in the smart button so currently the reply all / list button will also have options for reply to sender even though the user had a button available to do that. Will attach screenshot next

This screenshot is of the message header at 1024px wide with the new header customization layout patches applied in text+icons mode. There is just enough space here but likely this additional reply button wants to use the icons only mode.

Still building off of the latest of dan's patches in bug 465138 This latest version adds a menuitem to the context menu provided in bug 465138 for adding in a reply to sender button. This context menu is instead of the a preference item which was getting hidden in the advanced prefs section. The interaction feels pretty good to me, all the toolbar customization prefs are in one section instead of spread out. I used the onpopupshowing method instead of integrating with dan's initToolbar function because I wanted to stay one (1/2 really) step ahead of someone mucking with the pref in about config and then getting into an odd state. I'm not watching the pref though so if they are voiding their warranty the jokes on them. The rest of the header view overlay js code is playing hot potato with the 'checked' attribute because we can't actually use .checked. The UpdateReplyButtons change is pretty straightforward. We check for the pref value and then force the reply to show if the value is true. The other buttons will continue to show as they were intended to before. I'm not cleaning out the drop down list of the reply-multi buttons; it seems a bit excessive but possible to clean up after the string freeze. I landed the new pref in all-thunderbird.js as that's where I normally land these things. I can update the all prefs value once suite has had a chance to see what this has done and we get some sr's. Again, this won't apply without the latest of the patches (at least v1) from bug 465138 Will add screenshots in a moment.

Here are some links instead Option checked ( reply to sender button shown ) http://www.grabup.com/uploads/fba94a58e0eea0f370cf4175a4feee5c.png Option unchecked ( only smart reply button shown ) http://www.grabup.com/uploads/79911c0287f5dce7430565fc0daf87a9.png

Capital S in show please.

With Show, some wrapping, and s/'/"/.

(In reply to comment #19) Please add "button" to the menu-item to make it clear what it does: Always Show Reply to Sender Button Can we *please* make this selection the default? (see reasons in bug 516141)

Bryan, thanks for addressing this. It's definitely a step forward in the right direction. However (FTR), you have NOT implemented any one of the two alternatives I suggested in comment #7, which are both basically *single*-button solutions. You are now forcing a second button onto users who want to have reply-to-sender always available (whereas in my alternative 2, having two buttons was optional). I'm surprised, because you're deliberately forcing those users to sacrifice a lot of horizontal space for a full button, whereas in bug 465138, comment #55, you are breaking UI consistency for the sake of saving 32px horizontal space. (In reply to comment #23) > (In reply to comment #19) > Please add "button" to the menu-item to make it clear what it does: > Always Show Reply to Sender Button Peter is right, without "Button" in the menu label it's not clear what this does. "Always Show Reply to Sender" could also mean that "Reply to sender" becomes the default option for the i-Reply dropdown button (which is my proposal). > Can we *please* make this selection the default? (see reasons in bug 516141) Now that's tricky with Bryan's current solution. Again, I agree with Peter that users should always see a "Reply to sender" button by default (e.g. for privacy protection against accidental reply-all). However, I don't want a two-buttons default (and surely Bryan doesn't want that, either). That's why both my proposals are basically single-button. I'm not against /optional/ two-buttons, but that's probably most work to implement, for which it's not the right time now. Bryan, my original intention was like this, for a mail with multiple recipients: Alternative 1 (pref to change the default of existing iReply button): a) with "Always Show Reply to Sender" = false: [reply all]v [forward] [archive] [junk] [delete] +------------------+ | Reply all | |------------------| | Reply | +------------------+ That's the current I-Reply button, with behaviour as we have now. b) with "Always Show Reply to Sender" = true: [reply]v [forward] [archive] [junk] [delete] +------------------+ | Reply | |------------------| | Reply all | +------------------+ That's still a single i-Reply button, but user set the pref to always have "reply to sender" as default, and so it happens. i-Reply button code respects the pref. Peter, would you be happy if there's a single dropdown button that however respects your pref to always have "reply-to-sender" as default option? In other words, is it ok for you if "reply all"(!) is only accesible from the dropdown, rather than wasting space as an extra button? Alternative 2 ...is mainly a technically different implementation (with the advantage of /optional/ two-buttons), but it's based on full toolbar customization dialog where you can pick buttons, so it's unlikely to happen at this time. This would provide users with two buttons to choose from: Button 1 (drag this onto your toolbar to use it): [reply all]v - i-Reply dropdown button with behaviour as in a) (reply-all is used as intelligent default where applicable) Button 2 (drag this onto your toolbar to use it): [reply]v - i-Reply dropdown button with behaviour as in b) (reply-to-sender is always the default of this dropdown button) Of course you can also pick BOTH buttons for your toolbar (Peter's favourite solution) [b2:reply]v [b1:reply all]v [forward] ... Bryan, instead of adding a separate button when "Always show Reply to Sender"=true, why not just change default value of i-Reply button if user so chooses? That would save considerable horizontal space for those users. (And could well be the default. Let those expert users switch off the pref if they want to "reply-all" all the time.)

(In reply to comment #24) > Peter, would you be happy if there's a single dropdown button that however > respects your pref to always have "reply-to-sender" as default option? > In other words, is it ok for you if "reply all"(!) is only accesible from the > dropdown, rather than wasting space as an extra button? If we must have only one reply button, then having Reply-to-sender as the default is clearly the lesser of two evils. However, I still think two buttons is by far the better choice. Let's keep in mind that: - The buttons are already smaller than the toolbar buttons (i.e., harder to aim at targets). - Most users (e.g., my parents) do not understand the concept of a drop-down menu as a sliver along the side of a button. Let's also remember that targeting that sliver is extremely difficult, even more so for elderly, very young, and handicapped users. So we are essentially preventing those (and many other) users from selecting between reply-to-sender and reply-all, no matter what default is chosen. We are at minimum creating a huge obstacle. BTW: Having drop-downs on both buttons is just horrible UI (it reminds me of Lotus Notes <spit>). At minimum, the logic should detect when there are two buttons, and then remove the drop-down from the reply-to-sender button. These are a yet more good illustrations of how bad the idea of single-reply button is, and also of how forcing the buttons into the already cramped header was a bad idea. PS. If part of the motivation to displace the buttons into the header was to have space on the toolbar for other "apps" (like Lightning), then why don't you do it the way WordPerfect did (at least until v12): Make the tool-bar's button context-sensitive. If another app tab is visible, then swap the toolbar for that app's toolbar. Buttons that are relevant to both apps (e.g., e-mail and calendar), then show those buttons on both tool-bars.

1. The reply-to-all icon is nearly indistinguishable from the reply-to-sender icon, especially at that too-small-size. 2. The reply-all button disappears when there is only one recipient. This makes the reply button's location vary, which is bad. It would be better if the reply-all button just became disabled (gray). This is made even worse by #1. 3. Selecting multiple messages: The buttons are always icons+text and don't respect the user-chosen setting (e.g., icons only). 4. The Archive and Junk buttons are taller than the others in icon+text mode (WindowsXP). (in the unlikely case that hasn't been mentioned/noticed yet) 5. The "Other Actions" menu opens "up" although there is plenty of space below the button.

6. It's not possible to mark multiple selected messages as junk (the button disappears for multi-selections). 7. There are no tool-tips for the buttons when multiple messages are selected. 8. The tool-tip for the delete button doesn't say "undelete" for mark-as-deleted messages.

All we need now is the option to not show *any* buttons in the header. e.g.,: View / Headers / All Normal -------------- x Show buttons Of course, the other remaining header elements should then be able to use the (thankfully) vacated space (e.g., longer Subject line).

And what is going to happen with this nightmare once bug 464309 is fixed?

Peter: please try to keep the emotion out of your bug comments. It's not helping your cause.

David: Please try to focus on the stated important issues and not get distracted by emotions. It's not helping Thunderbird. ;-) So, what about the issues I pointed out? For the good of Thunderbird...

(In reply to comment #24) > Bryan, thanks for addressing this. It's definitely a step forward in the right > direction. However (FTR), you have NOT implemented any one of the two > alternatives I suggested in comment #7, which are both basically > *single*-button solutions. You are now forcing a second button onto users who > want to have reply-to-sender always available (whereas in my alternative 2, > having two buttons was optional). Thomas, I'd really like it if you opened a new bug starting with this comment. I'm not satisfied with the current approach yet either. I think with the current string used, lacking the word "button", we could still try an alternate implementation using single button. I'd be willing to work on making a single button happen but as I said in comment #18 I didn't dig into the button drop down at all. But now we have the pref and text that could possibly work for it. But we need a new bug as this is fixed (with a solution) and currently being comment bombed by Peter, who should know better.

(In reply to comment #32) > this [bug] is fixed [..] and currently being comment bombed Yeah, sorry about that. I'll summarize all the issues with single-button reply UI and the header in general raised here into a newsgroup post - when and if I have the time.

Newsgroup post created: news://news.mozilla.com:119/4AC4BB93.6030302@Lairo.com mozilla.dev.apps.thunderbird "Re-evaluating putting the Buttons in the Headers, and other Header-related stuff"

I liked the old behavior. This fix for this bug makes bug 520249 considerably worse, sometimes leaving only 2 characters of the "From" (Author), due to the extra button.

Blake Winton pointed me to bug 523254, which changed the default.

The CompactHeader add-on (https://addons.mozilla.org/de/thunderbird/addon/13564) should solve your problems: You can customize the header pane to show any of the normal reply, reply all, reply to list buttons and the new inteligent reply button.