Introduction to designing for email

This article aims to address the challenges faced in the design and development of HTML email and outlines the industry standards and company best practices that must be adhered to in order to ensure all email correspondance to our customers and prospective customers is optimised for accessibility, consistency in rendering and successful delivery.

Email design principals are significantly different from those of web or print design. It helps to pretend that you’re coding like it’s 1999 – a lot of what you need to do to make an html email render consistently across all email delivery platforms is very basic and nothing like coding for a normal website. Although email and site design have similar goals, email designers must take into account other factors such as email client and browser limitations, optimizing for the preview pane and call-to-action placement – just to name a few. Below are details on the the do’s and don’t’s that must be adhered to in developing an HTML email for Experian Interactive, followed by a quick checklist summarising the main points that, if applied, should ensure bulletproof email delivery.

Challenges

• Most email programs now block all images in your HTML email by default. You’ve probably noticed how you have to right-click on an email, or click a button, to make images display in the emails you receive. How should you design around that?
• In recent years, desktop email programs (like Outlook, Lotus, Eudora, and Apple Mail) have made great progress in standardizing the way they display HTML email. But now webmail services (like Yahoo, Gmail, and Hotmail) are getting more popular, and they have their own unique challenges. Two steps forward, one step back. What works and what doesn’t in webmail clients?
• There’s so much spam out there, spam filters need their own spam filters – firewalls, and they block email before they even get to your recipients’ spam filters, based on reputation. What can we do in terms of design and build to make sure we’re not put on the spam list?
• Spam laws require that every email marketer follow some very important rules. What you need to include in every single email you send to your customers to make sure you’re meeting legal requirements?

Dimensions

The width of your email (the containing table) should not exceed 600px. While the height (length) of the container does not need to be defined, it is important to include a call to action in the top 300px of the design to ensure it is visible in most viewing panes.

Preview Pane Area

Outlook’s preview pane window is a commonly overlooked element in email design. The designer only has, at the most, 300 pixels of height to present the email’s main content and navigation to an Outlook user. In this case, since the user doesn’t have to open the email to preview its content, this section should communicate the main message of the email quickly and efficiently.

Above-the-Fold Area

The area that appears above the browser’s bottom window bar is called the “Above-the-Fold” area. This is especially important for browser-based email clients such as Hotmail and Yahoo!. The “Above-the-Fold” section on a 17” monitor with a resolution of 1024×768 is on average 550px in height (depending on which email application and browser combination you’re using – for 800 x 600 resolution, it averages 420 pixels). In most cases, these extra 120 to 250 pixels of space are used for content that supports the preview pane area design. It is important to note that this area should be visually engaging as well, since this is the first thing Hotmail and Yahoo! users will see when they open the email. When laying emails out using Photoshop and Illustrator, it’s always useful to set guides at 300, 420 and 550 pixels to designate where the preview pane and above-the-fold sections appear.

Structure

Mail clients are light years behind in terms of CSS support, which means that we must resort to using tables for layout if we really want our newsletters to display consistently for every reader.

Layout using tables

In order to ensure rendering is consistent across all email platforms, stacked and nested tables should be used to lay out content in a robust, stable layout. Each table cell should have a width. It is recommended that a closed </td> tag be brought up to the preceding line – not left on it’s own, where it can add extra unwanted space. Tables should not have padding or cell spacing.

When using multiple nested tables, avoid using borders. If you need a border around a td cell, keep in mind that Gmail displays a border around a td cell when it’s defined in a div, but not when it’s defined as a border style in a td tag. To ensure your borders are always rendered, it is best to use an image stretched to the height/width of the outer rows/columns of the containing table OR for simple line borders, set 1px wide columns and rows on the edge of the table with a background colour that will fill to create a border effect.

Troubleshooting: Are you using styled borders on any tables? Some email clients render the border as an extension to the defined width of the table. So, for example, if you have a table that is 400px wide and it has a 1px border applied to it, some clients will display this table as 402px wide and this could affect your layout. It is advisable to calculate the width minus borders where appropriate or use images in separate table cells to emulate a border effect (this option is less likely to break your layout).

Avoid colspans: (table cells that “span” across multiple columns) in your HTML tables. There are lots of email applications that can deal only with basic table layouts and don’t properly render tables with colspans in them. The only way to combat this problem is to keep your layouts very, very simple, if you want your email to work across all the major email apps. If you’re working on an email layout and find the tables are getting complex, and you’re having to code using colspans you might think about chopping it up into separate tables. For instance, you should always use separate tables for the header, body, then footer of your emails. It is always better to go with more “simple” tables, than one big “complex” table.

If your design requires ‘floated’ blocks of information or images, do not use div’s (with a float style at- tribute) to achieve this effect. Some mail clients ignore “float” altogether (namely Gmail), and therefore it is better to code a more complex table layout than to rely on the float declaration.

Padding/Margins

Avoid using any padding or margin styles to layout content. Where white space is needed, add another row/column to your table and set it to the width of the padding/margin you require. While a 1×1-pixel image can be used to force spacing in order to create a precise email layout, spammers often use 1×1-pixel images to determine if their email has been opened. As such, using this practice will increase the likelihood that your email is classified as spam.

Use <br /> instead of <p>

The <p> tag in Internet Explorer uses more space (margin-top and margin-bottom) than in other browsers/email clients. This could lead to layout problems where, for example, if you’re using a table with a fixed width and height and your design is based upon these dimensions. If you have content in the table within <p> tags, than the height of the table could increase in Internet Explorer which could lead to gaps in your design. To prevent layout problems use the <br /> tag instead of the <p> tag as it renders the same in all browsers. Another problem with <p> tags is in Windows Live Hotmail. <p> tags are removed. So the safest way is to use the <br /> tag.

Forms

The use of forms within an HTML email is not recommended. If, however, a form is required they may be used as long as they don’t include JavaScript functionality and aren’t mailed to AOL or Hotmail users since these email apps don’t support form functionality.
Some email clients do not support forms that use <form method=”post” action=”http://…. >. Because of this, you’ll need to use the <form method=”GET” action=”http://.. > approach. This will write all forms content to the query string of the page they are posted to.

Other elements to consider – Flash, JavaScript, ActiveX, external stylesheets, movies, image maps and other stuff that won’t work in HTML…

• Flash does not work in most popular email clients and should not be used in any email creative. You can deliver HTML emails with Flash in them, but most recipients won’t be able to view them. Not unless they’re using an email program that uses a browser to render their HTML email. Microsoft Outlook was a program that used Internet Explorer to render HTML email, so Flash would sometimes work there. But Microsoft Outlook 2007 (and reportedly Outlook 2010)is no longer going to use IE to render email. They’re using Microsoft Word instead, so Flash will not work in Outlook anymore. Also, most anti-virus applications block the code used to embed Flash movies, and they block JavaScript, ActiveX, and even background music files. All of these have been used in the past to spread viruses, so it’s commonly blocked now. Remember, keep it simple.
• Javascript does not work and should not be used within an HTML email.
• External stylesheets should not be referenced. Stylesheets used in the header area of the HTML document will not work in most email clients and should not be used. All styles should be inline and on each instance of the element being styled.
• Try to keep the total file size under 30k. Emails should never exceed 100k as this is the threshold for some clients classifying them as spam.
• Do not use image maps, sound files or video in HTML email.

Provide a link for an online version

Although you test your HTML email with different browsers and email clients, you never can be 100% sure how it will display in your subscribers email program. In case it doesn’t display correctly you must provide a link at the top of every HTML email to view an online version, for example:
If this email doesn’t display correctly, click here to view the online version.

Special Considerations for web-based email clients

A lot of your recipients will be checking their email in a web browser such as with Yahoo!Mail, Hotmail, or Gmail. Since they’re viewing email in browsers, there are some important factors to consider when designing/coding your HTML emails:

• Most web based email apps will strip out your <HTML> and <HEAD> tags, in order to keep your code from interfering with their web pages. This means…
• Any CSS that you place inside the <HEAD> tags will be lost. So don’t try to link to CSS files hosted on the server. Use embedded CSS instead, and make sure it’s below the <BODY> tag, inline where possible (using inline styles is the only way to ensure your styles are consistent across all email clients and browsers).
• Some webmail clients are starting to strip even the most basic CSS, even if it’s embedded below the BODY tag (as described above). This is because they don’t want any of your CSS interfering with their CSS, or maybe because they’re using so much JavaScript and AJAX technology, things just get buggy. Keep this in mind, and do lots of testing.
• Tip: you can use various web based Snapshot tools to get screenshots of your work in all the major email programs and webmail clients, to see if your code is breaking. This saves time and re-work.

Legal Requirements

Unsubscribe and Privacy Policy

Every email should provide a quick and reliable way for people to get off the mailing list. It will usually appear in the footer and the link must be prominent. A link to the businesses privacy policy should also be in the footer of every HTML email. Example: This email was sent to %%email%% because you have opted in to receive communications from xxx.co.uk. If you think you have received this e-mail in error, or if you wish to take yourself off the mailing list, follow this link. We invite you to learn more by reading our privacy statement.

Company information

The following company information should also feature in the footer of every email sent out from that business:
Trademark information, Copyright Details, Business registered numbers, Registered Address business, Trading Addresses, Rights Reserved statement, Links to any appropriate legal text.

Styling an HTML email

Use inline CSS-styling instead of referring to an external CSS-file in HTML emails. If you are styling text, the style must be applied to each and every table cell – it is not enough to simply put your font style on the containing table. In some email platforms (for example outlook 2007) the style does not filter down through nested tables. Avoid the use of any header tags (any tag above <body>) as web-based email systems, such as hotmail and yahoo! replace all header tags with their own html code. This includes using style sheets to define H tags also.

Example: <tr style=”font-family:verdana,arial,helvetica; font-color=#000066; font-size=12pt”>There is no support for replacing bullets with images in unordered <ul> lists in some email clients and therefore this technique should not be used. If using an image in place of a bullet is necessary for visual impact, the list should be displayed using a table where the bullets are displayed in one column and the list items in another, removing the need to use <ul> or <li> tags altogether.

Always design your CSS to “fail gracefully.” That means if someone took away your CSS, your design and content would still display decently. Before you send your HTML email, delete the CSS and see what it looks like. Did you have tiny text that is now gigantic, and blowing out your tables?

CSS is an especially touchy situation if you’re using a WYSIWYG editor to code an HTML email, because WYSIWYGs insert all kinds of crazy CSS and random DIVs by default. It’s one of the drawbacks of WYSI- WYGs for HTML email as you will likely have to go back and remove some of the code so things won’t break in email applications. This is especially true if you’re using the design view only in Dreamweaver for example. Always double check your code before finalising your email to ensure there are no hidden surprises or unnecessary/extra tags.

Using Microsoft Word to generate HTML is even worse than using WYSIWYGs. Word adds so much code behind the scenes that it is guaranteed not to render properly across most standard email apps and browsers. Do not use Word to generate code for HTML email.

Background images and background colours

Background tags and images are stripped by some browsers and email clients. To ensure consistency in rendering, emails should be designed so that there is no need for background images. While most email clients have a white background as default, others use grey or even black. To ensure copy is visible (ie. Black on white), define the body background colour (and that of the containing table) to white (<body bgcolor=#ffffff>).

Image Use

Where possible, the main message should never be contained in an image. If the image fails to load, the Alt text should communicate the message, however the impact of this message will be lost. There are some basic principles that should always be applied when working with images in HTML emails:

• All images should be deep linked to their place on the server (or with Cheetahmail). When coding image tags in HTML email, do this:
• <img src=”http://www.yourserver.com/email/images/logo.gif”> Instead of this: <img src=”images/logo.gif”>
• When an image is sliced up for layout purposes, each image should be placed in its own table cell set to a height and width exactly the same as the image. These images should always have a style=”display:block;” attribute.
• If an image is wrapped in an <a href> tag give the image a style=”border-style:none;” attribute to ensure the image doesn’t render with a blue link border.
• Images should never be floated in a table cell. Not all email clients recognise this style. Where a float is necessary the content should be nested into another table.
• Where an image is placed in a table cell that is vertically longer than the image, the cell must have a vertical alignment of ‘top’ applied to it.
• Avoid spaces in your HTML code between an <img> tag and </td> tag. Some browsers will read this space as an actual space in the overall layout which can lead to “cracked” graphics.
• Be sure all your images use the alt, title, height, and width attributes. Setting values for these attributes improves results in Google Mail, as well as maintaining your layout when a reader has their images turned off. Note, however, that Outlook 2007 does not recognize the alt attribute and so we must also include title tags to all images – read more in the section on accessibility below.
• While some clients support animated gif’s, some do not (namely outlook 2007) and therefore should be used only when specifically requested. When used, it is important that the first frame of the animation contains the main message as this is what will show in clients without animated gif support.

Accessibility

Alt and Title Tags

Adding an Alt tag to your image tags will ensure that if any images are broken, or if images are turned off when a subscriber receives your email, your subscriber will have an idea of what is missing. Alt tags must be descriptive of the image – for example, it is not good enough to simply put ‘CreditExpert’ or ‘Free Credit Report’ on an image. It must relate to the surrounding copy so that it is clear what the message is. Alt tags also satisfy accessibility issues, conform to W3C HTML 4.01 specs, and allow the handicapped to read and receive their emails.

Alt Tag Example:

Incorrect: <img src=”http://imageserver/images/cta.gif” ALT=”CTA”=”0”>
Correct: <img src=”http://imageserver/images/cta.gif” ALT=”Click here for your FREE credit report now” border=”0” width=”10” height=”20” title=”Click here for your FREE credit report now”>

The title attribute can be used for almost any element (links, images, tables, etc.). Use the title attribute if you want to display a tooltip to describe the element. It is recommended to use the title attribute for links and images so that email clients that do not support Alt tags are still accessible.

Text and Richtext versions

Every HTML email must have a corresponding plain text and rich text version.

Rich Text Email: While you can generally be sure that if a user can view a rich text email, they will also be able to see your HTML email, some people choose not to receive HTML and so we must build a rich text version of every HTML email. A rich text version of your HTML email can be generated using the Cheetahmail system under the ‘Content’ tab. This code can then be copied in to Dreamweaver or text editor and altered if necessary. It is not advisable to use Microsoft Word to generate your rich text email.

Plain Text Email: It is imperative that we include a plain text version of HTML email for recipients who can’t view HTML. Sometimes, the plain-text version of your email is the one that gets displayed if your recipient checks their email on a mobile device. Here are a few tips on constructing a good Plain Text version of your HTML email:

• Use a plain text editor, like NotePad. Don’t use Microsoft Word because it won’t give you the kind of “raw” text files you need. You need an application that gives no formatting whatsoever.
• By default, some email applications start to wrap your plain-text messages at about 60 characters or so. That’s not really a big deal to most people. Just let your text wrap wherever their email programs choose. But if you have content that you absolutely do not want to wrap unexpectedly (like in the middle of a hyperlink), one trick is to type a letter 60 times across the top of your message, and use that as your visual “ruler.” As your content approaches the end of that ruler, hit your return key and “hard wrap” the line. Again, this is only if you want strict formatting.
• You can’t code a clickable link with plain-text email. You just have to type out the entire URL. Some email applications will make it clickable automatically. Some won’t.
• People don’t read email. They scan email. Especially plain-text email. So make it really easy to find important information with bullet points and visual markers.

Testing

Testing should take place throughout the build phase to ensure any errors are picked up straight away. All emails should be tested in browsers (IE6, IE7, Firefox, Safari, and Opera and IE8 where possible) as well as in email clients via the Cheetahmail system (Outlook 2005, Outlook 2007, gmail, hotmail and yahoo as a minimum). The Cheetahmail SnapShot tool should be used as a final test once the email is rendering properly in all of the above.

Common Mistakes to Avoid

Before an email is sent, it is important to double check that the following basic rules have been applied (also a useful checklist for troubleshooting if you’re having rendering issues):

DO:

• Give all table cells a width and ensure nested table cell widths add up to their containing tables width
• Apply a style (font, colour, size etc) tag to each table cell containing text. Always include both height and width tags to specify image sizes as well as table cell and dimensions.

DO NOT:

• Use Flash, Javascript or Image maps.
• Give tables cell padding or cell spacing
• Use <p> tags (use <br /> tags instead)
• Use background images
• Use padding or margin attributes (in styles)
• Use borders on nested tables (with exception – see section on tables/borders above)
• Use floating elements
• Link to external style sheets
• Include head tags in your code
• Get over ambitious with your email design. Designing HTML email isn’t the same as designing web pages. You can’t have all the CSS-positioning, DIVs, DHTML, and complex, embedded tables like you can in web pages. Keeping it as simple as possible will ensure its rendered correctly to all recipients

CHECK:

• All special characters in email copy are replaced with Html entities. e.g – ‘&’ for &amp; etc. •    All images are coded with “absolute paths”. Remember, attaching graphics and using “relative paths” won’t work. You need to host the images on the server, then deep link to them in your code.
• There should be no spaces in your HTML code between an <img> tag and </td> tag
• All Anchor <a> tags must feature a title
• All images that are linked or wrapped in an <a> tag must have border=”0” attribute and if contained in their own table cell, should also have style=”display:block;” attribute
• Links or <a> tags href’s should be deep linked to the correct location and contain the correct source and banner code tracking for that email. (Request from briefer)
• Are you using the most current header and footer code (copyright, unsubscribe etc.)? •    Be sure that your td cell widths are accurate. Unlike web browsers, which automatically set all cell to the widest-defined width, some email clients size each td cells based on the defined width.
• Have you included an unsubscribe link, a link to the privacy policy and our company details in the footer of your email?
• Ensure there are no unnecessary tags or divs in your code if you’re using a WYSIWYG editor – they are notorious for generating absolutely horrible HTML which can cause problems with email rendering
• Test thoroughly. Every email must be tested in as many email clients/browsers and operating systems as available. You can use server web based testing tools to screen shot for testing on any browsers etc that you don’t have access to.

Useful Resources

Here are some links to handy HTML email resources/inspiration:

•   http://spammeltdown.com/ – Elements, trends and patterns in email design.
•    http://www.emailsherpa.com - Great email marketing case studies and research.
•    http://www.clickz.com - Lots and lots of online marketing and email marketing news.
•    http://www.marketingprofs.com – Interesting case studies and articles.
•    http://www.btobonline.com – Email and direct mail news.
•    http://www.campaignmonitor.com – great resource for email design inspiration.
•    http://emailmarketing.typepad.com/ – Tamara Gielen’s blog on email marketing.
•    http://www.email-marketing-reports.com/ – Useful email marketing articles and links.
•    http://www.newsletterarchive.org/ – Online repository of email newsletters – ideas and inspiration.

Final Thought

Why Micro$oft, Why!!!! After living with the worst email browser in history, ‘Outlook 2007′ for 4 years now, we had all hoped Outlook 2010 would address some of these issues.
Unfortunately, it would seem Micro$oft have made this version even worse and more restrictive in it’s rendering abilities, so be prepared for some of the above to not apply when you start supporting this email client. And be prepared for the regression and devolution of email functionality and the specification of what we can do with layout in emails being even more constrained in the future. Boo Hoo M$.