Domainmonster.com Domain Editorials
Should You Be Using HTML Email?
The use of html email is a matter of some controversy. On the one hand, many businesses claim that html email is indispensable to their marketing strategy; on the other, ever since its inception, web users and developers alike have been complaining that it's a really bad idea. In my opinion, it *is* a bad idea, but I'll give you a few arguments in favour before I tell you why.
- Any combination of colours and fonts is possible.
- It's possible to embed images, forms and Flash.
- Huge links can be hidden behind snappy hyperlink anchor text.
- Effective layouts, headings and other design elements can be used.
- Plaintext emails look boring.
And so on, and so forth. These may look like excellent reasons to use html in emails, especially if you're thinking about sending marketing emails. Unfortunately, there are serious problems with html email, both technical and aesthetic.
Email Client Compatibility is Not Universal
There is no universal standard which governs how different email clients (not to mention webmail applications) display html emails. Your html email may look lovely in Outlook, but hideous in Hotmail, Eudora, Thunderbird, Gmail What's more, Outlook 2007 has very limited support of CSS, Flash, GIFs, and a whole host of other features. If you want to send html emails, you have to ruthlessly test them in every possible medium you can think of, and there are a lot of email clients.
Your Recipients May Have Turned Off HTML
Many email users just uncheck the box that allows their email client to display html emails. Sometimes this is because of a general loathing of html email, but they may also be concerned about the security risk that html email poses; html emails can contain executable code. Also, when you view an html email, embedded images and stylesheets are downloaded from a remote web server. This means that information such as your IP address, the date and time you read the email, and your browser type, can all be recorded by the sender of the email.
Even though you're presumably not a spammer and aren't recording any of this information, many of your recipients may have turned of html to be on the safe side. That could mean that your emails look very ugly when they see them. Their spam filter might also flag your email as spam, which could mean it never gets read. Even if it does, having your correspondence denounced as spam could tarnish your reputation with the recipient.
On the matter of security, it's much better to tell your recipients to visit your website and fill in a form there (give them a link and directions for how to navigate to the form from your homepage) than to embed a form in the email itself. This is because phishing sites have received a lot of publicity lately, and many people are very careful about avoiding fraudulent sites. It's best to encourage them to navigate to your forms or any sort of login pages themselves.
Sending HTML Emails is Inconsiderate and Impolite
Emails containing html have larger file sizes than plaintext emails containing the same text. This is pretty much common sense. Of course, nowadays, most of us have broadband, and an html email doesn't take much more time to download than a plaintext email. But don't forget that some of your recipients may be paying a rate which is related to their data transfer usage. It's just rude to your recipients to inflate the size of your emails more than is strictly necessary, especially if they're receiving thousands of emails a day.
Things like Flash applets make html emails even bigger. What's more, they can cause all sorts of horrible problems for people trying to read your email. Usually the Flash app will keep playing in the preview window when the recipient opens the email in a separate window.
It's also rude to tell your recipients how they *should* view your email. Many html emails make it very difficult for the recipient to do things like change text size, colour and font.
Many people just don't much like to receive html emails. They take a while to render, it's often difficult to find the actual content of the email, and it feels like an imposition to be forced to visit what is essentially a mini-website when you didn't opt to do so.
Designing Reasonable HTML Email is Really Difficult
I'm sure you've been annoyed by really naff html emails before. Sometimes they're even sent by companies you're sure should know better. The problem is that writing html emails that are easy to read and reasonably attractive is really difficult. Not only is the cross-browser compatibility a serious (and oft-overlooked) problem, but html emails often end up looking like websites not a good idea when the window that many people are viewing them in is much smaller than a normal browser window.
There's all sorts of other problems to consider: a plaintext email is readable forever, but if you send email after email in html with new graphics in every one, you'll have to keep hosting the images for these emails somewhere if you don't want the images in your emails to be broken six months down the line. It looks very bad when you look at an older email in your inbox and all the image links are broken. The same goes for hyperlinks.
Jeffrey Zeldman offers a hideous example of
HTML Email Looks Like Advertising
Whenever I receive an html email, it's all I can do to hold off spontaneously hitting the delete button before even reading the first line. eBay is the worst offender for me at the moment; its circular emails are so spammy-looking and cluttered that I can barely bring myself to scroll down and find out what the actual point of the email is. The fact is that html emails look like advertising. When eBay sends me an email I actually need to read (like an invoice) it's still in html, but it's far less cluttered. (Safe to say, both spammy and important emails from eBay look hideous with html email turned off.) So whenever I see an over-designed email, I assume I don't need to read it.
I never get html emails from people I actually want to hear from. Everyone from whom I like getting emails sends them in plaintext. Why's that? Because the people I like to receive emails from value content over design. They have something to say, and they don't need pictures or frilly fonts to say it. As far as I'm concerned, the more designed an email is, the less valuable its content.
Solutions to the HTML Email Problem
- If you really think html emails are necessary, give your recipients the option of a non-html version too. Make sure your html-free version looks good, in its own efficient, plaintext, non-spammy way. Also, your html version should have a link at the top to the email hosted on your website, so that if the recipient finds it doesn't display properly, they can view it in full in their web browser.
- If you must send html emails, test them to death in every email client you can think of (including various versions of the same client).
- Any html emails you send should also be simple, design-light and readable. Make sure the text is large enough for visually impaired readers, or better still, that they can change the font size to whatever they like. Whatever you do, don't put Flash in them.
- I used to recommend standards-compliant design for html email that is, for example, CSS designs which degrade gracefully in email clients that don't support CSS. The problem is that Outlook 2007 renders some CSS but not all, meaning that you end up with an ugly mess. Therefore your options are to send emails that are not standards compliant and have table-based layouts and inline CSS (which won't display well in every client), or to send emails with no html.
- If you need your recipient to be able to print something, so that layout is important, consider directing them to a printable web page, or attaching an image, word processor document or PDF to your plaintext email.
- You can make plaintext emails look good. Spacing, quoting, trivial markup (using characters to represent /italics/, *emphasis*, BOLD and _underlined_ text) and ASCII can all be useful. Your recipient can decide whether to tell their email client to render trivial markup in rich text.
By Brian Jackson