Designers and coders alike talk about web standards and coding web pages using CSS-based layouts to separate design from content. The norm for web development makes everything easier to update and faster to load amongst other benefits – what we would call the right way of doing things or at least the idea of designing with standards as Zeldman’s book is titled. However, when it comes to HTML email blasts and newsletters – the current foundations of proper web development go out the window. It’s back to the old school ways of coding…HTML tables, baby!
People use an array of different programs to check up on email communications. Most corporate environments have Microsoft Outlook as an email client and it’s often hooked up to your blackberry or iPhone as well. There’s also the web clients like Yahoo and Gmail to name a few, which all interpret and render your coding a bit differently. Just as your website might look slightly different in the various browsers and platforms, your HTML email can look even more drastically different between email clients. That is probably because the evolution of email clients is a bit behind that of web browsers. Standards and compliance are still wishy washy amongst the most popularly used email clients. A masterpiece on one computer could also be a beautiful mess on another.
Microsoft’s release of Outlook 2007 actually took the industry a bit backwards when it seemed that email clients started trending towards standards compliance. I found out first hand with a client who had major issues with an email campaign they regularly used. Suddenly the design looked way off because all the background images were not rendered by Outlook 2007. Even worse, recipients would have seen these mistakes all along since it was only recently that the client’s office was updated to the 2007 version of Outlook!
Knowing that the playing field is different for HTML email, realize that certain design solutions might be more work that its worth. Certainly we don’t want to resign to the extreme of colored boxes in a column, but remember the trade offs and balance required. Coders have to work with the rules they are bound by, but certainly designers still have ample freedom to create wonderful graphical layouts for any email campaign.
Important considerations when it comes to designing and building HTML emails center around how accessible we want to be and what we would trade off for a lot less coding. There are always many different possible solutions – we have to choose the right one for our specific needs, requirements and restrictions. From my experience using the old school methods of HTML tables works pretty much everywhere (if coded properly and neatly of course) but the use of colspan and rowspan does not render in Lotus Notes. Is that a major factor for the client? Is it really that much more difficult to not use colspan or rowspan? Web professionals surely remember how they used to code years back, so it’s not an issue of skill or new tricks in HTML. Ultimately, the best rule to keep in mind is KISS. Keep it simple stupid.
Emails are meant to provide quicks snippets of information that lead a user to a specific call to action. So, we shouldn’t waste too much of the reader’s time if we want them to go elsewhere in the end. Also note that the reader might only see the subject and very top portion of your email depending on how quickly they usually spin through their email boxes – so it is important to be as direct and concise as possible without any fluff, in my opinion.
I think it is an eventuality that standards will be set to push the industry forward and help everyone get more work done and faster. Designers and developers are left to fend for themselves at this point, although there are organizations pushing forward for standards and a great community to help as issues arise. Take note that technology changes constantly and we just have to roll with the punches!