Notes on when and how to do html email

20 March 2006 by Rod McLaren

Notes from a 2005 customer project on html and plain-text email. Sometimes customers really want to do emails and newletters in rich, shiny html rather than plain text. This post summarises a lot of good advice on the internet on the principles, costs and benefits of html and plain email, and the methods of achieving html mails that (kind of) work.
—-

1. Summary

• if you really care about making sure that all your users can receive, read and use the emails you send them and you want to do it cheaply, then use plain text email only and avoid html mail.
• if you don’t care about whether some users can’t read your mail, or whether some ISPs filter you into spam folders, then you can use plain text or html, and you can write your html any way you want. (Though we don’t recommend this.)
• if you’re not sure about html vs plain text, read 2 below.
• if you want to use html mail and want to make sure that users receive the html and have a consistent experience, then read 3 below on how to do html mail well (but it’s painful).

The golden rules of html mail are:

1. always have a text-only version, and let your user choose which they want, both at the point of sign-up and after having signed-up.
2. include a link to a version of the newletter on the website (in case the html email is broken on the user’s email client)
3. keep the html version as simple as possible, to reduce the risk that it might “break” catastrophically.

2. HTML email vs plain-text email: Why use html mail? Why avoid it?

Your client:

• Your client might be paying you to do html mail.
• It might be appropriate for your/your client’s userbase.

Branding:

• With html you can present a branded and more “professional” look
• But html doesn’t always display the way you’d like it to in your user’s email clients (ie: there are many ISPs and email clients, and they can display it very differently), so for guaranteeable consistency, plain-text is better.

Can the user read the html? And how readable is it?:

• Not all email clients will read/display html, including webmail providers. (Remember also that these days you don’t know if the email you’ll send is going to a desktop client, or to a client that ignores html, like a BlackBerry or a mobile phone.)
• On the other hand, everyone can receive and read plain text mails.
• Many corporates will strip the html out of an html-email (in which case you might as well send text), or block it at the firewall, or filter it to junk/spam folders, where it isn’t going to be read. Webmail providers (Hotmail, Yahoo, AOL) will alter your html, and/or filter it to junk/spam folders. Both may not deliver an email whose size is too large (AOL’s 500k limit historically – still in force?)
• html makes it easier to present e.g. 4 main topics as you can do it graphically; it can also be more pleasing to read for the user, particularly if it’s a long email. (Against this, there’s some research suggesting that users do prefer text, see below)
• On the other hand, accessibility is a problem with html. There’s no easy way for users to adjust the appearance of your html email to their choice, nor do screen readers handle html mail inside email clients well (for visually impaired users). This might be an important factor if you, or your client, or your users are in a jurisdiction that requires compliance with accessibility law.
• Html mail usually “falls apart” when you forward it to a friend.

Bandwidth:

• html costs you (the sender) bandwidth: an html mail is plain text, plus the same again, plus the markup, plus the images: at least three times the size of a plain text email. If you’re sending a lot of mail, this could be a significant cost factor for you.

Security:

• malware can exploit vulnerabilities in html code. Evidence from spamcop?
• Further, html can force-open a connection to the internet
• This risk is one reason that mail filters reject html mail, or filter it to spam/junk folders, where it isn’t going to be read.

Response-rates: choice at sign-up, and click-through response rates:

• Given the option roughly between 80 and 90% of people will opt for HTML (we were told by someone in the ad/marketing industry)
• However, research contra 53% of total respondents prefer to receive plain text messages; plain text consistently generated a better response – and at times more than 100% better – internetnewsbureau 2003
• Click-through responses: there’s evidence either way (the only thing that stands out in plain text is the url – a benefit?)

Other stuff:

• Track click-throughs with text, whereas you can track opens etc with HTML (though nb security risk)
• More reasons against html-mail are listed eg here and here (good points made though nb there’s a certain amount of ‘html mail is evil’ hyperbole)

Conclusions:

• It’s massively easier to send plain-text. However, some clients and some users may prefer html-email. So be aware of the pitfalls of html-email, and offer the users a choice. (And note that it’s painful and potentially expensive to generate html mail that’s receivable/readable/usable.)
• There are some common-sense approaches to html mail, outlined below. Most important of which are: keep the html simple, keep a version on your website, and always offer a text-only alternative.

3. If you have to do html mail, how to do it

First, if you don’t care about whether some users can’t read your mail, or whether some ISPs filter you into spam folders, you can use plain text or html, and write your html any way you want. (We don’t recommend this.) If you want to make sure that users receive the html and have a consistent experience, read on below.

Making the html mail: technical and design issues:

• Good general sources: Campaignmonitor’s articles and tips, Email Marketing Reports articles and marketing news, advice and best practices blog from which many of the following have come:
• Formatting plain text emails – the 4 golden rules (2004) – In short: line lengths (suggest 65 chars with automatic hard returns), links (and not breaking them), characters (some, such as £ might not display), justification (you can’t guarantee that adding spaces will make something centred).
• Elizabeth Davies’s HTML Email and Using Style (2005?) – Useful article has useful info on what tags etc different email clients strip out.
• Mark Wyner’s Optimizing CSS presentation in HTML emails (2005) – Useful article updates Mark’s previous, for ALA.
• How To Code HTML Email Newsletters (2004) – Note that this approach is very different to the css approach in Davies and Wyner above.
• How HTML Code Affects E-Mail Deliverability (2005) – In short: both ISPs’ (particularly Hotmail) email filters will drop stds-uncompliant into the bulk email folder. As do tracking beacons etc. Unfortunately so do url redirectors, which are sometimes genuinely useful.
• Max width for html mail (2005) – In short: keep your emails to a fixed width of no more than 550-600 pixels; and for height, average email client’s preview pane is around 300-500 pixels high, so make sure you include any important bits of your email in this area [Note that Wyner (I think?) advocates fluid width with CSS instead].
• Using forms in HTML emails (2005) – In short: Use GET not POST, won’t work for Hotmail users.
• How can I ensure all my campaigns are CAN-SPAM compliant? (2005) – Relevant if you’re sending to users in the USA.
• Six Steps to Avoid Spam Filters (2005) – In short: send email people want to receive; send more slowly; get whitelisted; look legitimate; send the message addressed to the recipient; don’t try to “trick” spam filters.
• B-to-B [email] Delivery Checklist (2005?).

Content:

• The Art of the Subject Line (2005) – “I have seen one line outperform another by close to fifty percent.”

Managing and sending the mail:

• You may want to use your own tool. Alternatively: Campaignmonitor is very good: easy to use, simply priced. Recommended.

name		Remember
email
http://
Message
	Textile Help

BlackBerry futures BlackBerry 8700 and 7730 comparison