Comment 207 for bug 52667

Revision history for this message
In , Bryan Clark (clarkbw) wrote :

In bug 461098 we added a ( reply | v ) button with the reply all menu item as a first step toward this and to help get the styling correct.

In the next, b3, release I'd like to get this button to react to the message being displayed, showing "what we consider to be the best default" as the button face and still having other reasonable actions in the popup menu. Sorry for the huge bug comment.

Here's the set of default / popup menus I have been working with for each situation.

My goals have been this.
* use the correct default button in the appropriate situation
* refer to people / email addresses instead of header types like reply-to, sender
* provide a reasonable set of actions in the popup to balance a confusing list of all possible and an unhelpful list of too few.
* create an easy understanding of what the default action will do (as expectations obviously vary)

single recipient, no reply-to
( reply | v )____________________
 | reply to <email address hidden> |
 '-------------------------------'

single recipient, w/ reply-to
( reply | v )____________________
 | reply to <email address hidden> |
 |-------------------------------|
 | reply to <email address hidden> |
 '-------------------------------'

multiple recipients, no reply-to
( reply all | v )_______________________
 | reply to sender and recipients |
 |--------------------------------------|
 | reply only to <email address hidden> |
 | reply only to recipients (#) |
 '--------------------------------------'

multiple recipients, w/ reply-to
( reply all | v )________________________
 | reply to sender and recipients |
 |--------------------------------------|
 | reply only to <email address hidden> |
 | reply only to <email address hidden> |
 | reply only to recipients (#) |
 '--------------------------------------'

mailing list, no reply-to
( reply list | v )________________________
 | reply to mailing list <email address hidden> |
 |----------------------------------------|
 | reply only to <email address hidden> |
 | reply only to recipients (#) |
 '----------------------------------------'

mailing list, w/ reply-to
( reply list | v )________________________
 | reply to mailing list <email address hidden> |
 |----------------------------------------|
 | reply only to <email address hidden> |
 | reply only to <email address hidden> |
 | reply only to recipients (#) |
 '----------------------------------------'

mailing list, w/ multiple mailing lists
( reply list | v )_________________________
 | reply to mailing list <email address hidden> |
 |-----------------------------------------|
 | reply to mailing list <email address hidden> |
 | reply to mailing list <email address hidden> |
 | reply only to <email address hidden> |
 '-----------------------------------------'

mailing list, w/ multiple mailing lists and other recipients
( reply list | v )_________________________
 | reply to mailing list <email address hidden> |
 |-----------------------------------------|
 | reply to mailing list <email address hidden> |
 | reply only to <email address hidden> |
 | reply only to recipients (#) |
 '-----------------------------------------'

Alternate attempt

To explain why I made some of the choices made above, here's one of my simple original alternate attempts.

( reply all | v )________
 | reply to sender |
 | reply to reply-to |
 | reply to mailing list |
 '-----------------------'

Here's why I changed from this model.

When using just the "sender" or "reply-to" we force an understanding of email headers on to people who might not understand the difference. Instead, by using people or addresses as the identifiers we can allow people to choose what they feel is correct. I don't think this is ideal, ideally we'd have a richer widget that could capture both pieces of information in a way that makes sense. Perhaps it's possible to use a rich list widget in a popup menu? This design assumes the constraint of a regular menu.

The first item in the list is always the default action, with a separator to the other actions. I think Magnus brought up something to this effect in the other bug. I think this will help teach people who are unsure of what our default actions are and allows us a great space to explain what the default action is doing. After seeing the full default menu item users who were untrusting of what the short version of "reply list" or "reply all" might learn by seeing it written out.

First reply button even has a drop down. This was done so that there wasn't a possibly confusing case where a person sees a reply with no options. People tend to relate these events to the people that are sending the mail. One person could set a reply-to and your mother might not. When your mother mails you you only get the one option to reply. I want to avoid that "it's not a dual button sometimes" scenario and just always be a dual button.

Avoid the what to default to discussion for now, for several reasons. For one it's really easy to change a default, spending days discussing what it should be means that just picking one is not the right solution. When you're down to arguing default choices you need to broaden your scope of the problem and figure out a new solution, choosing default should be relatively easy when the rest of the system is healthy. Second is that we have a lot of other things to discuss, how to improve the layout of the menu. Can we have a better popup that allows for a better display of information than a regular menu popup? How do we best limit the size of the menu when displaying email addresses?

Reply All vs. Reply is a common default battle and trust me that I understand the consequences of this default choice either way. While you're debating this in your head, try to mix in that the answer is not in picking one or the other, but changing the entire system of interactions such that the default is less relevant; less of a fork in the road.

bug 248681 is an excellent part of the broader scope of the problem. Reply All vs. Reply starts with how the messages is presented to the user in the list, how the message is displayed in the reader, how they choose to reply, and how they compose that reply. Improvements in those areas changes the default choice from a fork in the road to a simple road sign.