June 18, 2011 Posted by: cgalbornetti
Programmer’s Guide to Designing/Coding HTML Email Creative
Source: Beasley Direct Marketing, Inc.
The easiest way to design an email communication is also the riskiest: composing it in Word, choosing “save as a Web Page” then opening and sending from Outlook. In the interests of cross-application compatibility, Microsoft adds all kinds of formatting that can change the way a document will look in different browsers or even make it unreadable.
Using an HTML editor like Dreamweaver is somewhat better, but only if you work mostly in the “code” window and stay away from templates which add their own formatting. And the very best option is to work in a text editor, like Notepad, and hand-code your HTML (which you can then open in an HTML tool to check for open tags and other typos.) This is important because any extraneous information causes an accumulation of formatting tags that can cause problems in visual rendering or set off spam filters. According to Marketing Sherpa, even experienced web designers often don’t realize that email requires ‘super clean code’.
12 best practices for HTML email
- Ideal email width: 550-600 pixels. This allows full-width viewing on a variety of browsers.
- Limit the file size to 30KB (20KB for mobile phones) or less for quick loading.
- Avoid using background images. They’re not recognized by many email browsers; including Outlook 2007, Microsoft’s newest version of its widely used email application.
- Make sure all tags are properly nested and closed <html></html>, <tr></td> <td></tr> etc.
- No javascript please. Many email browsers can’t read it.
- Avoid flash or streaming video in HTML emails. Animated .GIFs are usually OK. (but V12 doesn’t suggest it)
- Never use CSS layers to position elements; use HTML tables instead. Many email clients do not support CSS layers, and will destroy the format of your message.
- All dimensions for tables, rows, cells should be in pixels, not in percentages.
- It’s usually OK to use the COLSPAN attribute (how many across?) but ROWSPAN (how many down?) is not recognized by many browsers.
- Special ASCII characters like ®, ©, or ™ should be converted to HTML (® © ™ ).
- Foreign characters should also be coded to remove accents, tildes and other characters that do not always reproduce correctly.
- All images should have their height and width spelled out. Otherwise, if images are blocked they may display as white boxes with infinite height and widths, pushing all the HTML text off the screen.
Here are three top tips for composing HTML that works in email
- Provide a 1 n absolute path to graphics on your server, rather than including the graphics as an attachment or a relative path to a local server that won’t be available when the email is opened.
- Insert the style sheet elements in the body of the email. Not in an external stylesheet (which will not work if the link is not working) and not in the header either (because many web email readers will strip out those headers).
- Prepare your email in multipart mime which means there is both a text version and an HTML version, along with the code that allows the email program to deliver the right version for each recipient. This translation procedure will generally be done by your mail transmission service. If they don’t offer it demand it.
HTML and Cross-browser Compatibility
As if it isn’t enough to have basic coding challenges, different readers and browsers handle emails slightly differently:
- Gmail and other web mail programs strip out the headers. In fact, to avoid potential problems, many third party email services will remove the headers before the email is transmitted.
- Outlook 2007 completely changed its code base, and is now based on Word compatibility instead of Internet Explorer. As a result, HTML forms no longer work in email, and background images are no longer displayed.
HTML code no-nos that can get you filtered
- Text in different colors or font sizes (without using embedded style elements)
- Using ‘dotted decimal’ IP addresses to reference graphics and links
- Unbalanced body, table and other tags
- Leaving the html editor information in the header
- Having spammy words in alt tags or as file names
- Missing or untitled between <title></title> tags
The Special Problem of Mobile Delivery
Depending on your audience, a few to most of your users are seeing emails not on their computers, but on their mobile screens. Mobile devices display differently but all have the problem of narrow screen width.
Here are some best practices when delivering to mobile:
- DON’T use long URLS that fill the entire mobile screen.
- Design narrower pages if you know you are going to mobile users: 300-400 pixels vs. 550-700 for a desktop monitor; 40 text characters maximum vs. 72 for standard email.
- Mobile readers display HTML in a variety of ways, so always include a text version in multi-part mime so the client will deliver your message in a readable format. (Blackberry for example, displays actual HTML code rather than interpreting it as a result that’s useless for readability)
- Someday, mobile companies may agree on a common graphic standard, but today there are significant display variations from one mobile screen to the next.
Source: Beasley Direct Marketing, Inc.