I’ve been involved in online publishing for the past thirteen or so years (yes, back before the word Blog even existed), and i’m still puzzled at how web developers always underestimate the amount of testing and knowledge that goes into producing an effective XHTML/CSS-based newsletter.
I often get the response, “It’s just a XHTML template right? No big deal.” Well, yes and no. Yes, you could just build a beautiful XHTML/CSS-based template and use that in your email newsletter. But the ratio of your readers who’ll actually receive your newsletter anywhere outside of their junk folder is miniscule at best. If you take this approach, you’re better off sending a ASCII text-only version of your email newsletter—It’ll reach more readers.
I don’t stand alone in my thinking here. Several people who are deeply involved in designing, maintaining, and sending XHTML email newsletters have written about these issues before.
One of my favorite pieces is Véro Pepperrell’s article on The Seven Deadly Sins of Email Marketing Management. Another is one of Ben Chestnut’s articles, which covers 10 Tips For Your First Email Campaign. And of course there is also a whole string of articles on the Campaign Monitor blog. I especially like the articles in their Articles/Tips area, which cover everything from choosing what CSS and markup to use (learn to love those inline styles!), to avoiding spam filters (fond of all-caps in your comments? That’s a no-no). There are also articles on meeting legal requirements that are set upon sending emails (hint: don’t auto-subscribe anyone!).
Today, the folks at Freshview who make Campaign Monitor and MailBuild have put out A guide to CSS support in email through their research via the Email Standards Project (yes, it’s a group to help advocate for standards in email clients).
So the next time your client or co-worker says “We can just use a regular XHTML/CSS template for the newsletter, right?”, point them to this post.
Thanks for the mention, Nick!
Couldn’t agree more that it’s a challenge/ frustration explaining how much more finesse there is in a quality email design, clever marketing and organised segmentation as opposed to chucking a pretty-but-dumb template out there.
Will bookmark your post for those times where I can’t get the point across to someone.
:) Vero
You make a good point Nick, and one that needs to be reiterated constantly - designing for email is not the same as designing for the web.
There are big rendering differences (which is where our CSS support guide comes in) and context differences between browsers and email clients.
Newsletter design doesn’t always get a lot of designer respect, but it certainly brings in results if you do it right.
At this time a year ago, I was just about completely comfortable marking up an email template as XHTML. Not in the same way I’d build out a web site in XHTML, of course, but comfortable with the principles of using CSS in the header for layout and styling. Comfortable that the combination of XHTML and CSS could get the message looking decent to nineteen out of twenty users in whatever our client’s target demographic happened to be — unless that target was the Government (Lotus Notes), and then we hoped the client would go for plain text.
Then Outlook 2007 happened, and all of that has completely changed. Now, the surest bet is some bizarre sense of progressive enhancement, using tables for the base layout and tip-toeing through the CSS to try to make it look at least reasonable in O‘07 and good in everything else.
Email design takes a lot of attention from both the person doing the design and the person doing the markup, and I greatly respect folks who are able to do either of those well.
The biggest pain when coding HTML email is that so many different software tools are available for reading email. Each of these email software tools can display the same email in vastly different ways. One has to take many things into account when designing a newsletter template. It’s an arduous job, very often undervalued.