Closed Bug 498448 Opened 15 years ago Closed 1 year ago

improve the reply all, reply list, and reply labels

Categories

(Thunderbird :: Message Reader UI, defect, P5)

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: clarkbw, Unassigned)

References

Details

This is a spin off of bug 45715 coming from bug 45715 comment 155; fixed up and mostly pasted below for reference.

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 sender@example.com   |
 '-------------------------------'

single recipient, w/ reply-to
( reply | v )____________________
 | reply to reply-to@example.com |
 |-------------------------------|
 | reply to sender@example.com   |
 '-------------------------------'

multiple recipients, no reply-to
( reply all | v )_______________________
 | reply to sender and recipients       |
 |--------------------------------------|
 | reply only to sender@example.com     |
 | reply only to recipients (#)         |
 '--------------------------------------'

multiple recipients, w/ reply-to
( reply all | v )________________________
 | reply to sender and recipients       |
 |--------------------------------------|
 | reply only to sender@example.com     |
 | reply only to reply-to@example.com   |
 | reply only to recipients (#)         |
 '--------------------------------------'

mailing list, no reply-to
( reply list | v )________________________
 | reply to mailing list list@example.com |
 |----------------------------------------|
 | reply only to sender@example.com       |
 | reply only to recipients (#)           |
 '----------------------------------------'

mailing list, w/ reply-to
( reply list | v )________________________
 | reply to mailing list list@example.com |
 |----------------------------------------|
 | reply only to sender@example.com       |
 | reply only to reply-to@example.com     |
 | reply only to recipients (#)           |
 '----------------------------------------'

mailing list, w/ multiple mailing lists
( reply list | v )_________________________
 | reply to mailing list list1@example.com |
 |-----------------------------------------|
 | reply to mailing list list2@example.com |
 | reply to mailing list list3@example.com |
 | reply only to sender@example.com        |
 '-----------------------------------------'

mailing list, w/ multiple mailing lists and other recipients
( reply list | v )_________________________
 | reply to mailing list list1@example.com |
 |-----------------------------------------|
 | reply to mailing list list2@example.com |
 | reply only to sender@example.com        |
 | 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.
I think this is great, all of it.

I like that you use concrete names/email addresses instead of labels, I agree that's easier and faster to grasp. I like that the alternatives are still there and easily accessible, even more than before, but we guide them the right way, and it's clear what it does (with the button label), and you subtly explain it further using the drop-down, too.

Some small nits and comments:
- Where you say "single recipient", I'd say "no recipients other than me" (where me are the configured identities). I think that's also what happens when I click Reply now (I don't get made a recipient).
- Use Real name instead of email addresses, by the same rules (i.e. if in address book) as used in the message header viewer (Recipient list and From).
- If two addresses are the same, e.g. Reply-To matches the mailing list address, or Reply-To matches From, show only one (mailing list option trumps From trumps Reply-To).
- Where you do use the label "Sender", please use the term "Author" instead, as they are different per RFC822, see bug 40934 (From = author != Sender. You mean From/author).
- If we can use a rich menu, we can use bold for the default choice, instead of making the default choice the first drop-down item and separated by a separator. Of course, that won't work when native menus as used, e.g. on Mac?
awesome points Ben, all of them.

I really would like to use a rich menu as I couldn't agree more that the separator is a bit of a hack because we couldn't style the items.
Assignee: nobody → bwinton
Blocks: 513553
Flags: wanted-thunderbird3+
A smart Reply-All|List button is a good idea. However, The single "Reply" button should be a separate button to avoid errors and embarrassment. Please see bug 516141 for more detailed reasons and a related but slightly different approach.

Also, note that a drop-down button either has a tiny target (the sliver on the right) or, if the whole button yields a drop-down menu, it forces users to click the button twice *every* time (once to bring down the menu, and once to make the selection. Not good options. Two buttons is the way to go:

   [Reply] [Smart Reply to All|List \/]
> a separate button to avoid errors and embarrassment

That's something we considered above (I had the same concern), but the label clearly says [Reply all] V , so there's little room for confusion.
Priority: -- → P5
(In reply to comment #4)
> but the label
> clearly says [Reply all] V , so there's little room for confusion.

I don't think non-expert users and those in a hurry or who are otherwise distracted will recognize that distinction very well, especially since it's always the same button, in the same place, and with the same primary text ("reply"). Additionally, I think many people will choose the icon-only view, and the Reply and Reply-all icons are very hard to tell apart, especially since the icons are now smaller than they are on the Mail Toolbar.

Not to mention the extreme difficulty in targeting the tiny sliver on the button to access the other reply modes, and that non-expert users (e.g., my parents) don't even know that there even is a drop-down menu. Plus it forces two clicks for when Thunderbird guesstimates wrong (my personal pattern is that I will sometimes choose Reply and sometimes Reply-all for the same type of message, depending on the situation, and not related at all to the type of message or the recipients).
(In reply to comment #0)
> * refer to people / email addresses instead of header types like reply-to,
> sender

Great!

(In reply to comment #0)
> mailing list, w/ multiple mailing lists and other recipients
> ( reply list | v )_________________________
>  | reply to mailing list list1@example.com |
>  |-----------------------------------------|
>  | reply to mailing list list2@example.com |
>  | reply only to sender@example.com        |
>  | reply only to recipients (#)            |
>  '-----------------------------------------'

I believe that in the case of multiple recipients, the default action should be "reply all", even if there is one or more mailing lists involved. I feel this to be more consistent. If you take the user point of view, you only see a list of recipients, not the mailing list header. Furthermore, both mailing lists and recipients feel unordered to me, so there is no easy way to choose one of them over the others. As any other choice here might seem arbitrary, let's choose "all" as default, and give the other options together in the dropdown, where they are all on the same level.

Your suggestions had no "reply all" entry at all if there was a mailing list. I guess you'd still want that entry, even if you decide not to make it the default. I also suggest it should reply to all to, cc and list addresses, as communicating a subset of these might be difficult, and users can still edit their address list in composer if they really need to.

(In reply to comment #1)
> - Use Real name instead of email addresses, by the same rules (i.e. if in
> address book) as used in the message header viewer (Recipient list and From).

Rather in addition to than instead of email addresses, I'd say. The reason is that From and Reply-to in particular are likely to be different addresses associated with the same person. Reading the same name twice doesn't help.
We should consider newsgroups (including Followup-To, which is the newsgroup-equivalent to Reply-To) in the above options, too. See bug 95623 and bug 533077.
I agree with Martin von Gagern's comment on 2010-01-15: in the case of multiple recipients, the default action should be "reply all", even if there's a list involved. The problem comes when a message is sent to a list plus some individual recipients who aren't on the list. The default multiple reply action is "reply list", which sends the reply to the list but not to the individuals. That's rarely what you really wanted to do, and has bitten me several times. Can we get this fixed? Thanks.
Please have into account bug 516128 when deciding when Reply, Reply-All buttons should appear or not (specially my summary comments 9 and 10).
For various mailing lists I am on, the function does not work correctly:

- I get a "Reply" and "Reply List" button (and a "Reply All" context menu). 
- the "Reply All" and "Reply List" work (reply all uses TO/cc list+sender; reply list uses to: list)
- the "Reply" button/menu uses the List Address instead of the From: sender.

Here is how the ML sends the headers. Answering to "From" only works with "Reply all" and manually editing.

Return-path: <list-bounce@domain>
Envelope-to: user@domain
Delivered-To: list-id
X-Envelope-To: list@domain
From: Sender <sender@domain>
To: list@domain
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: list@domain
List-Id: list-id
Sender: list-bounces@domain
Errors-To: list-bounces@domain
...
Truthfully speaking, I'm not going to have time to work on this anytime soon, so I'm freeing it up for someone else to take.
Assignee: bwinton → nobody
Severity: normal → S3

The message reader is being largely rebuilt for version 115. So this issue is will not be fixed for the current version 102.

If the problem exists in version 115 when it becomes available in July please file a new bug. You can also evalute the rebuilt reader in 3-4 weeks by trying a beta build.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.