Re: [Evolution] Bounce/remail command

Jeffrey P. Lanza wrote:

This isn't a problem, especially if the user can't edit the message before
resending it.  Here's why:

First, the original sender is never obscured because that's the point of
resending: to have the original sender's address there instead of yours.

Second, the original recipient is never obscured because (at least in
Pine) the headers should include "resent-by <ADDRESS>".  As an example,
I'm going to resend a message to the list right after I finish this

You may think that's not obscuring things, but I do.  Look, I've been
there -- when I am reading my mail, I generally assume that the person
listed in the From line has sent me a message!  Because that is true
99.995% of the time.  Yeah, maybe I'll notice that there's also a
Resent-From header there -- if I'm lucky and if I'm not in as much of a
hurry dealing with my mail as I always am.

There is a trade off here between which failure mode is more likely.
A sends mail to B, who passes it along to C:

  * Error 1: C replies to B instead of A;
  * Error 2: C replies to A, but doesn't notice that A didn't send
    the message to B in the first place.

I'm going by what we might as well call the "principle of least
embarrassment."  Error 1 is trivially inconvenient for B, in that B
stays in the loop for one more iteration.  Error 2 could easily result
in C making an ass of himself to A, because C thinks that A was talking
to C, when A was really talking to B.  If you get that wrong, it can
easily change the whole meaning of the conversation and the reply.

I think error 2 is much, much worse than error 1, which is why I think
the UI should very firmly guide people toward forwarding instead of
resending.  Because the failure modes of forwarding are not bad at all,
and the failure modes of resending suck mightily.

You mentioned this "template" message type before, but didn't provide an
explanation for it.

Imagine you're in tech support, and you spend all day answering mail
that people send to "help" and "info" addresses.  There are going to be
a dozen or so messages that you send over and over again, to lots of
different people, possibly with minor changes.  In Eudora, you can
compose a message, mark it as a template, and give it a name -- then it
shows up on your "reply" menu, as, say, "canned RTFM reply".  This
brings up a composition window with the body and some headers filled in
with the template.  

You can also accomplish this with an "edit as new" kind of command.
Or by having a bunch of post-it windows on your desktop and using cut
and paste.  But the "template" way of looking at it feels pretty
clean/convenient to me.  I've seen people using this in Eudora, and it's
really fast, they can just rip through those replies.

How does it differ from or replace the functionality of resend?

People who know about resend but don't know about templates sometimes
see "resend" as being the tool for this job.  It can be, but I don't
think it's the best one.

Templates don't directly address the "this message shouldn't have gone
to me at all" action.  Except in that they might share some UI
behaviors, like how the composition window works when some of its fields
have been pre-filled.

Ahh, but if A sends a message to you (B) and it was really meant for C,
wouldn't you like to get it to C in such a way that when he replies to it,
he doesn't include you in the reply? 

No.  What I would like is for C to Do the Right Thing.  I would also
like for C to use "Reply to Sender" when appropriate instead of always
hitting "Reply to All", and to not have an ASCII version of the USS
Enterprise in his .signature, and so on.  But I can't force C to do
these things.  I don't know what C is going to say in his reply or who
he is going to feel the need to address when he says it.

The job of helping C to do the right thing is the job of the designer of
the mail reader that C is using -- not the job of every person who
corresponds with C.

Jamie Zawinski
jwz jwz org   
jwz dnalounge com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]