Skip to page content or Skip to Accesskey List.

Work

Main Page Content

Html Email Isn T Rich

Rated 4.11 (Ratings: 18)

Want more?

 
Picture of mynameismonkey

Jaz-Michael King

Member info

User since: 16 May 2002

Articles written: 5

I know, I know, the subject has been beaten to death. However, I think that while the community has expressed its moral concerns and standards-based objections, we haven't explained it in a way THEY can understand. THEY think about such things as money, readership, service, branding, image and openings - not RFCs. So, this essay will look at how corporate types might be brought to understand the inherent evils of HTML email. I address the following to middle management everywhere.

Privacy

Soon, more and more of your readers are going to wise up that you're tracking them without their consent. Those pictures you sneak in there to count how many people open your email is an incredible intrusion into your readers' privacy, how many of them would complain or unsubscribe if you headed each email with the message "By opening this email you consent to inform us of your doing so, and possibly force a connection to the Internet"? Chuckle if you want, but I dare you to do so.

Many people read their email offline once downloaded, and your hidden images force a connection to be established. The old read receipts were annoying but honest, your average lay reader could tell what was going on, but hiding the count in "rich content" is way out of line.

Just because it's Internet technology doesn't make it right. It's an invasion of privacy, and you'd never conceive of doing something similar with paper-based outreach. Customers who feel invaded drop you like a hot brick, and stop spending their...

Money

It's highly probable you're paying for metred bandwidth. Send out two million emails, you get charged. Email isn't free, it consumes commercial bandwidth and your company pays for it.

HTML email is easily twice the size of its text only equivalent, but often up to ten times larger in size. Let's say your HTML email is a conservative four times larger than if you sent plain text email. Now, let's say you send a half million mails a day to subscribers. That's not much for most large companies. For the sake of argument, let's say an email costs one tenth of one cent to send.

So, we have a half million emails times two hundred fifty working days (I dropped ten days for public holidays and such) equals 125,000,000 emails sent. That's $125,000 US per year sending the email.

Now, if you had sent plain text email, you would have spent a quarter of that, saving your company $93,750 US. There's probably a raise in there for you somewhere. Even if an email cost a hundredth of a cent, you've saved ten grand, not bad for days work. Plus, you've upped your...

Readership

So you want pictures? Links? Attachments? Not a problem, the email infrastructure is willing and able to handle that for you. Most email clients can display attached pictures without problem, excepting the ones that are pure text clients. So why format your mail in HTML? If you want your readers to see HTML, send them a link to a nice web page, that's what HTML is for.

How many of your readers can't display HTML email? Do you care?

Let's stick with the half million emails. More and more people, ISPs and individuals, are employing spam filters. Spam is getting way out of hand. Did you know that estimates put 93 to 97 per cent of all spam being HTML formatted? Did you further know that most spam filters score HTML email as bad, marking it as possible spam? Imagine if one per cent of your emails are delivered with "***WARNING - POSSIBLE SPAM*** Widge Co News" in the subject line; that's five thousand emails a day with your name on and the word SPAM plastered all over it. If it gets looked at. Most spam filters consign spam to unopened trash folders.

Some readers don't have the latest, greatest computers. You might have a shiny new iMac, but your readers' four year-old AMD K6 with 32 MB of RAM can only handle one browser at a time. HTML email might be crashing their systems. You think they'll open your email after they reboot? What do you think all this is doing for your...

Corporate Image

More readers can't even open HTML email. If you're lucky, they'll see a big page of meaningless code. If not, they'll see a big, blank page. Would you knowingly send audio to deaf people? Videos to the blind? No, of course not, yet somehow it's simply okay to send HTML email to thousands of people who have no hope of opening it. Not to mention, is your HTML even any good? Have someone validate the HTML for accuracy. Again, I dare you. Better yet, go tell your boss that ten to fifteen per cent of your readers can't open your email, would he like you to do anything about it?

Wait, he says. Who are these people who can't open our email?

  • Pegasus Mail users. One of the top three highest-rated email clients in the world.
  • AOL users who haven't upgraded since 5.0. Even 6.0 had problems. If you send a multipart email, upgraded AOL users see both versions.
  • Text-only email clients (Pine, Mutt etc)
  • Most Lotus Notes and Novell Groupwise users have incredible difficulty reading HTML email.

Most surveys show 78-80% of email is read by HTML capable software. Of your half million emails, up to 100,000 are not presenting your company in a favourable light. I don't know about your company, but where I work, if one in five customers weren't getting the message we wanted them to, we'd change something. And if one in five were told we didn't care, it was their problem, not ours, I'd get fired.

Do yourself, your customers, and your company a favour. Use the right tools for the right job. Email is for text and attachments, the web is for HTML.

Reading Material

http://www.webfoot.com/advice/email.format.html - A Beginner's Guide to Effective Email

http://www.nngroup.com/reports/newsletters/ - Email Newsletter Usability

Jaz is currently the senior director of eservices and health care transparency for IPRO. He is also Welsh, something he is not likely to let you forget. His favourite things are beer, cheese and monkeys (in that order). Jaz co-chairs Medicare's SDPS Web Strategies Workgroup, and serves as judge for the WWW Health Awards. His portfolio of recent work is available at eservices.ipro.org.

The access keys for this page are: ALT (Control on a Mac) plus:

evolt.org Evolt.org is an all-volunteer resource for web developers made up of a discussion list, a browser archive, and member-submitted articles. This article is the property of its author, please do not redistribute or use elsewhere without checking with the author.