[Mailman-Users] text-only versus graphical

[Stephen J. Turnbull]

Daevid Vincent writes:

 > I don't know why everyone is all down on graphical HTML email.

Developers and administrators (ie, the great majority of the people
who answer questions on a list like this one) use email to communicate
ideas.  When you want to motivate somebody, a picture may be worth a
thousand words (NB, it requires 10,000 times the bandwidth!)  But how
do you express a Mailman error message in pictures?

You're right, those of us who say "HTML email is evil" probably are
projecting when we generalize (but be very careful about applying that
estimate to someone like Brad Knowles, who is a very professional
admin and likely subject to such biases but who also has worked in the
pioneer in the mass-service end of the industry == AOL---he knows
about the difficulties of serving a varied audience).

 > The way I see it, I would much prefer HTML if it's a newsletter or
 > something. It's cleaner. Easier to read with formatting.

Newsletter, sure.  As somebody else mentioned, in an announce-only
list, the publisher can control the format, and if users complain, he
can tweak the carefully designed style until everybody is satisfied.
For that purpose, "email" is a distribution channel; the communication
medium is something different, a "newsletter".  To my mind, that's no
different from having a plain-text email with a link to the newsletter
on a web page---except that it's far more convenient for the user
since he doesn't need to click on a link or wait for the page to
download.  (I would often consider using PDF instead, though.)

People who denounce "HTML email", however, are thinking of email as a
communication medium characterized by heterogeneity of both sender and
receiver, and high interactivity.  HTML simply isn't designed to adapt
to that, and many common generators produce terrible code.

 > Links aren't these huge URLs.

That's a deficiency in the MUAs, not in text/plain email.  My MUA has
abbreviated URLs for a decade.  It turns a bare URL like
"http://turnbull.sk.tsukuba.ac.jp/Tools/Attitude/" into "[Attitude]"
and highlights it, and it's clickable.  (It also recognizes the anchor
element in otherwise plain text, and completely suppresses the tags and
href in that case.)  Pass the mouse over it and the full URL appears
as a tooltip.  This is not rocket science; AFAIK any reasonable recent
MUA can do that.  Certainly the GUI MUAs available for Linux do.
Similarly, many other conventions of conversational email can be
attractively formatted: quoted text, smilies ;-), /emphasis/, etc.
This doesn't require HTML at all.

Sure, if your monopolization strategy requires integrating the browser
into the OS, as Microsoft's did, then it makes sense to use the
integrated browser to render HTML in email.  Similarly if your
business is trying to turn your browser into a desktop, as with
Netscape.  It's not surprising that they were happy to force formatted
email into HTML instead of trying to deduce format from unstandardized
conventions.

 > And adds a certain amount of professionalism (assuming it looks
 > good and isn't crappy circa 1988 looking).

Brad's point is that you can't make that assumption, unless you own
the reader's MUA (and probably her monitor as well).  Works inside a
company---maybe.  I know that most of my university's pages look like
something the cat dragged in when using any browser other than very
recent IE on Windows at approximately 1024x768 resolution.  That
includes all popular browsers on the Mac (Firefox, Safari, Netscape,
and IE-for-Mac).  And they spend millions of dollars on those pages.

 > The only time HTML email is "evil" is when it's from an unknown
 > source that is most likely a phisher, or it is coded so horribly
 > that it's painful to read.

No, it's "evil" as a rule because it an accessory before the fact to
worms, phishers, and rank amateurs lacking in subtlety and taste.  It
doesn't make ordinary email look any better than plain text does in an
MUA that has an attractive "style sheet", and for users with special
needs (small screen, large font, or text-to-speech) it can be very
detrimental.

 > I think this "plain-text" only mentality is antiquated and fostered
 > from die-hard zealots who still use, nigh, prefer the command line
 > over GUI tools which take most of the tedious guess-work and
 > fat-fingering out of administration of a server.

Prefer, yes.  Zealotry, no, not for the majority of GUI naysayers.
All too often I've discovered that a GUI tool doesn't do what its
documentation led someone to think it should, or that the desired
configuration simply can't be achieved via the documented interface.
It's true that by reducing your field of choice the GUI takes
guesswork out of administration, but if something does go wrong, that
saved guesswork is often reimposed 100-fold.