Re: current/modern email netiquette

Troy Piggins <usenet-0711@xxxxxxxxx> wrote:

First - html emails. I'm getting hounded by work colleagues to
allow them to send html emails so they can format them with
coloured text, bold etc. I have resisted this for 8 years, but
when asked why not, and my answer is because of extra bandwidth,
html mails look more like spam/scams/viruses etc I get these
blank looks. I honestly don't believe the bandwidth factor any
more, considering the volume of traffic these days, and bandwidth
hogs like youtube etc far outweigh emails.

I think HTML in mails gets a lot of bad press, and I'm surprised you
haven't been scorched to the eyebrows already by people flaming you
for even daring to ask the question. On the bandwidth issue, I think
you are right to say it isn't an issue any more, especially
considering the amount of bandwidth lost to YouTube etc during working
hours. I'm not so sure it ever was a real issue though, just an excuse
dreamt up by the techies.

Emails already contain a lot of extra info in the form of headers
which very few people look at or need to look at. Look at the typical
email and as well as all the routing info, you are likely to find a
clutter of headers such as mime versions and content types and
X-headers and so on.

Then there are signatures with those oh-so-witty sayings and
disclaimers which add a lot of extra bloat. Some of those disclaimers
go on and on and on and on, and people use them because everyone else
does, so they think its some sort of standard, but I've yet to meet
someone who has taken legal advice on their signature.

And quoting of pervious messages. So many people these days think that
top posting your reply above the previous mail is "the accepted
standard" and the idea of quoting just the parts you are interested
in, putting them into context, and trimming the rest seems to be an
idea of a bygone age. I guess the problem here is that Microsoft don't
provide a one-click button for intellignet quoting and a lot of people
these days don't expect to have to do any work themselves to make
themselves understood. The onus these days is on other people to
understand you. Or for a wizard to do it for you. Communication skills
are a dying art.

So for all the above reasons, I think the bandwidth argument against
HTML mails is a failure, but even if it wasn't, there is an even
bigger bandwidth argument to deal with. If you don't allow people to
send HTML emails, they send attached Word documents, spreadsheets,
PDFs or even, god help us, Powerpoint files, because then they can
highlight the document the way they want to. These attachments are a
lot bigger than any HTML would be, a lot less convenient to use than
an email, and have a lot more potential to carry viruses etc, so by
banning HTML mail you may actually be increasing the bandwidth problem
and the security problem.

Some people wave the security flag, that HTML can contain viruses,
spyware, webbugs and so on. First off, if you cannot trust your users
to look at a HTML formatted message in their email client then you
sure as hell shouldn't trust them to run around the web clicking on
pages at random from Google. Email clients which render HTML can do so
without running any scripts, they can often be configured to not load
images, external style sheets, etc, and there is no reason at all why
an email client should be allowed to run java, javascript, ActiveX and
so on. Even simple Outlook Express can be configured to run in the
Restricted Zone and block off web bugs etc.

I know a lot of spam filtering systems score HTML mails badly but
these systems are created by techies who seem to want to live back in
1980. Just because spammers use HTML mail doesn't mean no-one else
should be allowed to use it. If I wantr to send HTML email AND if the
people I'm sending it to want to receive HTML email from me, then it
is no business of a system admin to tell me that we shouldn't be
allowed to do that.

HTML is about formatting text and it is a perfect language for adding
simple formatting to text documents in emails. In the past we have
often seen people use text conventions such as using *asterisks* or
_underscores_ to emphasis a bit of text, or WRITING IN CAPITALS to
make one bit stand out, or S P A C E D O U T L E T T E R S for
headings, dashes to underline things, and so on. Those are just poor
substitutes for using italics and bold etc. Nobody would dream of
using those old fashioned ASCII artefacts if they were writing a memo
using a modern word processor, so why should they use them when
writing an email? There is also the accessibility issue. If you use a
voice synthesiser to read out your mails, it should be able to handle
HTML markup much better than those ASCII conventions.

We've all got out coloured pens at some time or another and marked up
different parts of a complex document so we could more easily see who
had to do what, and HTML makes it possible to do those sorts of things
in email just as easily. When we need to use diagrams in a memo it is
so much more readable if you have a diagram inline with the text
instead of having to get people to refer seperately to an attachment
or an external image. Laying out information in rows and columns is
something we do all the time on paper, so why not in email? (And yes,
I can do columns in ASCII, but I have a life)

As I see it, the real problem with HTML is not the people who use it
to communicate, its the people who use it to look cool. I see a lot of
people decide to write all their email in blue ink which makes it
harder to pick out the links. I've had emails where people use green
lettering on a pink or orange background, which is painful on the eye,
people who type in giant yellow letters on a black background, which
was made worse since the black background was an external file which
sometimes didn't get attached so it came through as yellow on white,
people who use backgrounds looking like scottish tartan so every third
word was lost in the background. There are people who use a different
font and a different colour on every line, sometimes even within the
same word, not because it helps the reader understand what they are
trying to say, but because they think its fun, and I'm an old stick in
the mud when I complain that it makes their mails very confusing.

And then there are the over-paid corporate image tossers who think
HTML is a way of making their emails look like the company headed
notepaper, with exactly the right sized corporate font, and the right
colour scheme, and all the other garbage that they think is oh so
important to the world. They create some of the most illegible mails
of all and do more damage than good to their corporate image. They
also seem to create the templates they use in MS Word or something and
so they really are bloated with a collossal amount of CSS style
information and Microsoft oddities when simple HTML tags would have
fared much better.

So I'd suggest that you should allow your users to send HTML mail if
they wish, but only after they've done an induction course on
communication. Use HTML formatting in cases where it improves the
clarity of communication, where it is for the benefit of the reader.
Don't use it for the entertainment of the letter writter, or as a way
of them forcing their "individuality" onto the reader.

I have my own email client set to both write and read in plain text by
default and there are very few incoming HTML emails which cannot be
read as plain text, even when it is HTML only with no matching text
part. If it is from a known sender and if it is apparent that the
formatting is important then I'll switch to HTML rendering for that
one mail. But that's my choice. No one can force HTML formatting onto
me if I don't want it.

However, the same cannot be said of messages sent as Word or Excel
documents to get around the no-HTML-mail rules set by their sys
admins. When that happens, I am forced to use the document in exactly
the format that it was sent, no matter how illegible that may be.

I find the neater formatting of HTML mail is especially welcomed in
things like invoices where the tabular layout makes things clear and
the scalability of HTML means it renders well both on screen and on
the printer. We've done systems where we've converted old ASCII
formatted reports into HTML formatted reports which are emailed to the
various users and they are absolutely deleted with the clearer
formatting, think its the best thing since sliced bread. Yes, a couple
of external users found they couldn't get them to start with because
their sys admins were blocking them purely on the basis of the mails
being HTML only, and those sys admins tried to say that we needed a
duplicate text version and foolishly tried to blind us with techie
jargon. I've also been told that the "correct" way to handle this
would have been to put the report on a web server and give each one a
password protected link so they could read their report. Talk about
wanting us to jump through hoops for the sake of a bit of dogma. These
intransigent techies do themselves no favours by their posturing.

I fully admit there are drawbacks to giving HTML formatting
capabilities to users with no communication skills, but that's no
reason to say no-one else should be allowed to use it.
.