In <20040928164338(_dot_)3bc71d25(_dot_)moore(_at_)cs(_dot_)utk(_dot_)edu>
Keith Moore
<moore(_at_)cs(_dot_)utk(_dot_)edu> writes:
Yes. The more I look at the problem of replies, the more it looks
like the problem is 90% UA construction and 10% protocol. Which
probably means that adding more protocol isn't the most important
part of a solution. And since adding more protocol tends to mean
more complexity, doing so could easily make the situation worse.
The thing to do is to get UA functionality right, _then_ to see what
new protocol frobs (if any) are appropriate.
But the situation seems to be that you can't get the UA functionality
right without some extra protocol, because the information for the UA
to do a decent job just isn't available at present (I think few of us
are convinced by Bruce's claim that Reply-To can be made to do it
all).
I don't think that's true at all. The way they tend to be implemented,
these extra header fields just make things more confusing.
Actually, is is not display of Reply-To and MFT by agents that is
essential (though it is highly desirable). What is essential is for
compose windows to exhibit clearly the To: and Cc: for the reply (with
alerts and bright red colours if they are not what the user might have
expected, if you like). And the user MUST have the ability to edit
those fields before committing the reply.
That's not sufficient. At a minimum, the replier needs to be able to
edit the recipient fields AND see the fields of the subject message
while he's composing the reply. More realistically, the replier needs
to
a) Know (probably via an alert of some kind) when the sender of the
subject message requested that replies go to some non-default set of
recipients
b) Be able to easily select from "reply to author" "reply to all" and
"reply to where the author of the subject message recommended"
(in addition to being able to add or delete recipients from this list)
_at any time before sending the reply_
I think it would be better if no "logic" were needed. The decision
of who to reply to belongs to the person composing the reply. For
the UA to make it easy for that person to "fill in the blanks" is
reasonable. For the UA to try to emply "logic" to _decide_ (or
equivalently, _guess_) where the message should go is not reasonable.
The ultimate decision certainly belongs there, but the average user
will surely be happy to go along with the what the original author of
the list expander asked for or whatever is the "culture" of the list.
The user will be happy with it until he embarasses himself by sending a
reply to the wrong address(es). Even if the user remains happy, the
discussions he participates in may be less effective because too many
people have blindly replied to everyone who was a recipient of the
subject message, because their MUAs encouraged them to do this. He
may be annoyed that "the other people on the list send too many
messages" without realizing that the real problem is that everyone's
MUAs discourage users from thinking about where they send replies.
Moreover, the
average user just wants a quiet life. He just wants to hit one button,
compose his reply, and hit 'send'.
Yup. But he wants _other_ users to not send him replies that (for
whatever reason) he doesn't want to see.
He does not want to be "filling in any
blanks" in the case of what he regards as routine replies.
My argument is that it's possible to make an MUA user interface that is
more effective than current ones, but still "user friendly".
Yes, just occasionaly he will want to do something different, and some
users may want to do something different all the time, but MUAs should
be designed to make life convenient for the average user (though by
all means let them be configurable to do special things for users who
want to be different).
The issues associated with sending replies to the wrong place
affect average users as much as anyone else. "Average users"
get embarassed when they send messages to the wrong place.
"Average users" get annoyed when too much traffic is generated
because everyone replies to too many recipients. "Average
users" suffer when the signal-to-noise ratio of their discussions
degrades due to too many replies to all.
And if you design an MUA only for the "average user", you
degrade everyone's capabilities. Because even the average user
sometimes needs capabilities beyond his "average" use.
What is really needed is not to dumb down the user interface, but to
help users be aware of what they're doing, make the most frequent cases
work with a minimum of effort, while still making the less frequent
cases easy to use when that's what the user wants to do.
Keith