[thelist] mailto: long body text

.jeff jeff at members.evolt.org
Tue Aug 14 17:16:40 CDT 2001


tyme,

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From: Tyme
>
> Well, I knew that _someone_ would give me the "don't
> use mailto:" lecture.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

well, if that side of the argument didn't apply, then it *would* be a
lecture.  however, as you're not able to get the mailto: link to work as
you'd like, then i'd say it's quite applicable.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> Not surprised that it was you...nothing personal.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

um, thanks i think.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> 1.  New users (some even "senior" users):
>      A.  Often more comfortable with sending messages
>          using their own mail clients, especially when
>          they might be editing/re-writing a significant
>          amount of text.  [I know that I would prefer
>          it for this reason.]
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

i agree with aardvark on this one.  my experience indicates exactly the
opposite of this.  new users are generally far more comfortable with
something that has fewer options and therefore fewer chances of them
screwing up.  newer users also usually already have experience with
web-based mail and are therefore more comfortable with it than a mail client
installed on their system.

something else to think about -- many newer users don't have their own
computer system.  they usually gain access to the net on an infrequent basis
from computers at friends, family, work, cybercafes, library, etc.   these
users are *highly* unlikely to have ever setup a mail client for themselves.
i'd say that if any of them have email that 99.99% of them with email have
web-based mail.

another point -- how many of us more experienced users have a computer that
goes everywhere with us?  how many of us rely on someone else bringing a
laptop along that the rest of the group uses to check email, surf, etc.?  in
this instance, nearly every one of these more experienced users has at least
one web-based mail account they use to check their email.

my experience has been that newer users do not write "a significant amount
of text".  many do not even sign their correspondence, include subject
lines, or open it with a greeting.  most jot down a few semi-coherent
sentences and hit the send button.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
>      B.  Gives user the flexibility to use the cc:
>          or bcc: fields as they would prefer for
>          this particular use.  Or to add emphasis
>          to the subject letter.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

depends on the type of correspondence.  usually that sort of functionality
is not necessary for the user.  however, if you as the developer deem it as
such, then include that functionality in the form online.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
>      C.  Saves me wasting tyme writing an explanation
>          about how to copy and paste text into a mail
>          message.  (Which I had to do anyone.)
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

they're going to have to do that anyway if they're using web-based mail.
they're going to have to do that anyway if their mail client doesn't
correctly interpret your mailto: link with all the extended attributes being
used.  or, they might just say screw it and move on.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> 2.  No-charge site.  Needed to put information up
>     quickly.  Did not want to spend the time to create
>     the email forms and code the ASPMail (especially to
>     build in the flexibility/functionality that I
>     wanted). And, form mail options were not
>     necessarily an option in this instance.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

and in the time you've spent arguing for a non-standard method, you could
have coded the entire functionality server-side.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> 3.  I personally _hate_ form mail options.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

+1 to what aardvark already said.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> I want a damn "sent mail" message sitting in my desired
> folder for record and follow-up.  [...] Ever tried to
> print out your completed mail form for record?  [...]
> And, of course, you don't know until you send the message
> whether you will be getting a cc: back or not. I _rarely_
> send email when a form is involved.  And, often, this
> keeps me from sending positive feedback to webmasters.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

for all of these reasons i stated:

  "[...] form by default with mailto: links available as
   a second option for the more advanced users."

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> So, basically, you do not know the answer.  :-)
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

oh contraire.  the answer is k.i.s.s.  that's why i expanded on the reasons
for using a form based solution and all the pitfalls of your attempted
solution.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> Regardless of the method that I end up with, I would
> like to know exactly what the limitations of mailto:
> are, if only for curiousity's sake rather than future
> reference.  That was my question, afterall.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

and i thought i did a fairly good job of highlighting those limitations.
here's a recap:

 - mailto: links do *not* work for web-based mail
   users unless they know how to copy/paste
   (probably not safe to assume)
 - mailto: links do not work for users who aren't
   using their default browser or who don't have
   their browser and mail client properly
   configured.
 - using anything more than the email address
   in the mailto: link is a recipe for disaster
   as the support for these extended attributes
   is spotty at best across various platform/mail
   client combinations
 - when a mailto: link with these extended
   attributes is presented to a web-based mail
   user, how in the heck are they supposed to know
   what goes where?  more than likely they're going
   to try to put it all in the to: field and it's
   going to fail.
 - when a mailto: link with these extended
   attributes is presented to a user with a properly
   configured mail client, but the mail client
   munges up the attributes and the placement of the
   various pieces, then what are they supposed to do?

at the end of the day it comes down to one thing -- if your site doesn't
work for a user they're going to blame *you* (the site) and not the tools
they're using.  if you want their business/use/loyalty/etc. then you'd
better do your best to make it work for as many as possible with as little
effort as possible on their part.

thanks,

.jeff

http://evolt.org/
jeff at members.evolt.org
http://members.evolt.org/jeff/








More information about the thelist mailing list