I’ve written two other posts specifically dealing with designing email blasts but one designed exclusively to answer the question “How to design an HTML Eblast for Outlook” inevitably became blogworthy because of a recent client assignment.
Here’s why I took this topic on.
Recently, a client came to us with the objective of reworking some of their standard templates for use with a proprietary enterprise email sender. The project seemed simple enough, except for the following:
- The blasts were intended principally for proper display by Outlook based email clients. Need I say more? Outlook is notoriously finicky about the way it renders content and there have been changes to the Outlook renderer over the years which has made a tough task even tougher.
- The blasts were templated by hand but are edited, on a per piece basis, by company employees in Dreamweaver. Dreamweaver’s tendency to add a little extra code is sometimes problematic for Outlook.
- The addition of a proprietary enterprise email sending platform further complicates matters. After developing and testing the template repeatedly, we still encountered issues when we put the ‘completely tested’ template into the client’s sending application.
Rather than run through an exhaustive recounting of all the issues we faced, though, I thought I’d offer a list of “dos and don’ts,” collected from our experience
Do code by hand.
This is just a general rule of thumb and based only on personal experience. Third party “graphical” coding environments can be a little risky because they can add spacing or unwanted code. Stick to a text editor.
Do use tables.
I’ve touched on this in my previous posts, so I won’t beat this one to death. Suffice it to say that structuring your content with DIV tags is not gonna fly in HTML email. Although they’re Old School; table layouts are your friends in this medium.
Forget about anything except inline CSS.
Obviously an external style sheet is out of the question for email but, likewise, you can forget about declaring CSS in the STYLE tag as well. There is wholesale lack of support across email clients for this practice and, although it may seem tedious, declaring styles inline is the best way to go. Here’s a sample code snippet, with actual CSS markup:
[xml]<p style=”color: #000000; margin: 0px; font-size: 1.0em; font-family:’Times New Roman’, Times, serif; margin-right: 30px;”>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam et laoreet velit. Aliquam tellus turpis, accumsan semper malesuada et, vehicula ac sapien. Sed iaculis gravida ipsum, sed luctus nulla dignissim venenatis. Sed ac augue a lectus aliquet semper..</p>[/xml]
Forget about universal support for CSS at all.
The world of coding email templates doesn’t stop at just restricting your use of only inline CSS. Lots of CSS declarations themselves are out of bounds in the retro world of email. Campaign monitor has a great chart of support across email clients for CSS.
Think you’d like to use margins or padding to get space around those images? Think again!
Declaring margins or padding around images isn’t supported in Outlook. And, depending on who you believe, Outlook 2010 may not be supporting the deprecated HSPACE and VSPACE declarations, either. So what’s a coder to do? Well, in my blast, I actually resorted to the use of spacer GIFS. I know it seems Neanderthal but — I’ve got news for you. They work and reliable and get around the limitations of Outlook.
Don’t expect too much in the way of validation tools.
When I first started this exercise, I thought I’d be able to rely on something like like the W3C validation tool but, much to my surprise, these tools are of limited usefulness. Why, you might ask? The answer is simple and shocking. Most email clients are not standards compliant. (Gasp!) What I did find these tools useful for were for checking for closed tags and other obvious, standards-neutral problems.
DOCTYPES are of limited use.
This comment sort of follows from the validation remark. If you don’t have standards compliance in the email client, how can you really code to a standard? Well, you can’t with certainty. However, there were two that were most frequently suggested. Those were either HTML 4.01 Transitional or XHTML 1.0. In the end, I went with XHTML. Either way, your code (placed right at the top of the document) should like this one of these two declarations:
[xml]<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”>[/xml]
or this
[xml]<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>[/xml]
SUMMARY: So what does it all mean?
It occurs to me, now that I’ve written it, that I’ve spent a lot more time talking about what you can’t do rather than what you can do when you’re tasked with designing an HTML eblast for Outlook and other clients. But, I think there’s actually a positive takeaway from all this.
Having worked in design and marketing for many years, one of the things I’ve always believed is that restrictions create opportunity. Once you understand what the parameters for HTML eblast design are, it’s actually somewhat liberating. After all, the fact that most email clients don’t support CSS 3.0 actually means you don’t have to worry about it, right? As Art Thompson mentioned in his post, markup for email is really just “Coding Like It’s 1999…”
And we all could brush up on our Old School techniques, couldn’t we?
A number of sources and articles I found have been instrumental in completing the client work profiled above and this post. What follows is a list of some of the great posts I’ve found: