ietf-822
[Top] [All Lists]

Re: Understanding response protocols

2004-10-18 13:15:17


I'll probably regret getting back into this thread, but I wanted to 
amplify something Keith said a while back about typical users:

I suspect that when people hit "reply to all" to a message from a
list they generally want the reply to go to everyone who received
the original message, not "just" to the list.  They don't want to
worry about which of those recipients are on the list and which ones
are not.

I'd go further and claim that the typical user lacks the 
interest/attention to deal effectively with more than 2 reply choices,
which the user will naively think of as "the sender" and "everyone."  
 
Trying to get most users to handle a third choice -- e.g. "reply to 
all" vs. "followup" -- is asking at least as much of the user as 
expecting them to simply edit out the duplicates by hand.  

I agree.  But I think a lot of the problem is that most MUAs expect
users to make this choice from the "read" or "browse" environment
rather than the "compose" environment.  Adding more buttons in the
"browse" environment only makes things worse.  

Another part of the problem is that most MUAs don't provide a better way
to alter the recipient list of a reply than to edit the list "by hand" -
and even then, without an effective means of viewing the recipient list
of the subject message.

Especially these days, in the browse environment the user is often in
"whack-a-mole" mode - he's got various kinds of stuff in his inbox,
including maybe important personal messages, trivial personal messages,
important "work" messages, trivial "work" messages, list traffic, spam,
and viruses -all jumbled together.  His main goal is to keep the list of
things that haven't been looked at from getting too long.  Some things
get deleted unseen, some get looked at and then deleted, some get
forwarded, some may get refliled if the user is sophisticated enough. 
Basically the user is performing triage.

Even though a lot of messages do get terse replies, the "compose" screen
at least gives the user a chance to shift gears and focus on the message
he's composing.    That's why I think that the  selection of reply
recipients needs to be part of the compose  environment.  To be
effective the compose environment needs to make it easy to reference,
quote, and or incorporate portions of the subject message - and this
includes making it easy to reference, quote, and/or incorporate portions
of the recipient list from the subject message into the recipient list
of the reply.

Note that a similar problem exists for reply body text.  We find it
quite useful for an MUA to be able to include the  subject message text
in a reply, but quite tedious to edit out the irrelevant portions.  So
just like we get a lot of replies that cc too many recipients, we also
get a lot of bloated replies that copy too much text from earlier
messages in the thread.  Cut-and-paste doesn't work as well as we'd like
to believe - it's sort of effective for small portions of text, less so 
for large chunks.  We need to be able to see text in a subject message
while we're replying to it (and even have the right part of that text on
the screen while we're replying to that part) without actually having
to have that text copied into the reply, and we need to be able to 
include that text in our replies without having to drag it from another
window.