Commercexchange



The basics of developing a HTML email design

Mel Jensen

This article is being written due to the large number of enquiries that we have directed at ourselves, as well as having HTML email formatting problems reported to us. As an email service provider, often the software is thought to be at fault, rather than a design fault.

99.9% of poor-formatting cases are caused by the HTML not being robust enough for delivery to multiple email clients. HTML that renders perfectly when viewing in a browser can be an unrecognisable mess when delivered to Microsoft Outlook 2007 or Lotus Notes 8. To further complicate matters, different versions of the same client can have as many rendering issues as there are between totally different clients.

And don’t forget webmail! Not only does each webmail client have its own formatting, which in itself can wreak havoc with your carefully put together email design, but each email has the potential to look different depending on which browser you are using to view your webmail.

As if this huge variety of clients were not enough, we now also have the smart phone and the tablet to contend with, and the cacophony of different operating systems, screen sizes and compatibility levels that this comes with.

Unfortunately, designing HTML emails isn’t always an exact science, and there will always be some element of trial and error. Different designers will have different opinions as to how to best achieve similar results, and we’re not saying that other methods don’t have merit. However, this documentation compiles over 16 years of collective experience in designing HTML emails.

Overview

The below list is a bullet pointed overview of the items covered in more detail within the balance of this document.

• Keep the design to a maximum of 600 pixels wide

• Do not use background images

• Include a ‘view as webpage’ option

• Keep to standard fonts

• Write the HTML in code rather than in using an editor

• Keep the mail below 100 KB in size

• Always make sure you validate your HTML before transmitting -

• Do not use Scripts and Dynamic HTML

• Do not use Flash or videos

• Always include the pixel height and width when adding images

• Always add ‘border=”0” to any image tags

• Avoid long lines of HTML code over 512

• Test thoroughly using a multiple client tester, such as ,

Designing

The design stage can be defined as when the initial look and feel takes shape, whether that is in the designers head, on paper or in a design programme such as Photoshop. It is important to build in certain criteria at this stage to prevent HTML rendering issues at a later stage.

Width

Almost every mail client has a different preferred width, but you should find that a width of 600 pixels wide will suit most clients reading panes.

Images

Many email clients, especially certain versions of MS Outlook, will strip out any background images, and that includes any background applied to the body, so it’s best to design using no background images at all (although you can get around this by applying a background colour* as well as a background image at the development stage, so if the image gets stripped out, the colour will remain).

To this day, some email clients will also strip out images altogether, so it’s a good idea to avoid putting too much information on the mail in an image based format. It is also good practice to include a link on your mail to view the mail as a webpage, just in case the mail renders incorrectly.

Font and Font Size

Ideally, only universally-supported fonts such as Arial and Times New Roman should be used in email messages.

Arial is a font that was specifically designed for onscreen readability and studies have indicated that Web users prefer Arial, Verdana and Tahoma to others when viewing Web pages and email.

Including fonts that are not installed on your recipients’ machines will mean that the fonts will be substituted, which can affect your design. When using a special font (such as the unique font for a company logo) place it within an image.

Fonts can be specified in pixels, points or HTML font size value. Use a point size no smaller than 10 pixels, 10 point, or size “2”.

* a background colour must use the html coding style=”background-color:#xxxxxx”, as bgcolour=”#xxxxxx” will no longer work in some browsers.

Developing

It sounds incredible, but to write HTML for emails you need to forget all of the advances made within the last 10 years, such as DIVs, HTML5, etc, and write the code as if it were the year 2000. This means writing the file using TABLEs and TABLEs alone. DIVs will get moved around and stripped out by email clients so it’s best to avoid them at all costs.

Writing in code rather than using an editor

Using a HTML editor such as Dreamweaver or MS FrontPage is a great way to easily create great looking web pages, but using them for HTML emails can cause as many problems as they can solve.

Typically, an editor will add in non-essential code which can mess up your email rendering on delivery to some email clients, but in addition some of this code will flag up as SPAM on SPAM Filters: An example of this is the tag!

File Size

In the early days of email marketing it was always a struggle to keep the mail below a certain size, so that recipients using dial up could download the mail easily, but these days Broadband has removed this issue, and mails have grown in size exponentially.

But, did you know that if your mail is over a certain size, some mail clients will ‘trim’ them? For example, if a mail is over 102KB in size, Gmail will clip off the rest. Keeping the mail below 100KB is the best solution, and by server basing your images you should easily achieve this.

Stylesheets

Some email clients add in their own stylesheet, and some will strip out yours, so it’s best to avoid using a stylesheet altogether, and use style tags on page and within the body.

E.G.

HTML Validation

Always make sure you validate your HTML before transmitting. Webmail in particular cannot handle invalid HTML – for more information please see

Scripts and Dynamic HTML

Most email clients will be unable to handle dynamic HTML or scripts, and some ISP's will also actively seek out and prevent any mails containing this code from being delivered. Technologies which should be avoided for use within eBulletins include:

• JavaScript

• VBScript

• Java

• ActiveX

• Audio

• External Style Sheets

• Flash / Videos

• Frames and IFrames

• DIVs

• Forms (Avoid embedding forms, such as surveys, into emails. Some email clients such as Hotmail might not pass the data through to the collection point. Instead, link to a Web form through which the recipient can complete the survey.)

Images

Always include the pixel height and width when adding images, the reason being that if the receiving mail client strips out the image, the space allocated for it should remain fixe, therefore not messing up the rest of your design.

You must also include the border width, even if this is 0:

Long lines of HTML code

There is a potential problem which can occur within Outlook, where the HTML message contains a long line of code of over 512 characters without a line break. Typical errors that occur are exclamation marks appearing in the HTML at 512 characters on the line.

To avoid this simply break up the HTML code onto separate lines so that all systems can parse it.

Validation

Validation of HTML is an important, and often omitted, step. A large percentage of HTML emails do not comply with World Wide Web Consortium (W3C) HTML standards, which can cause rendering and delivery issues, particularly at AOL, MSN and Hotmail.

For example, AOL has a filter that is an HTML validator, which scans incoming messages for HTML syntax and formatting errors. If it detects invalid HTML, it will reject the message.

You can read more about HTML Validation, and use the online validator here:

Testing

Testing is the most important step. If you have followed the advice given within the design and development stage you will hopefully experience few issues at the testing stage. However, it is inevitable that at some point there will be some.

Ensuring a thorough testing procedure is in place can be critical to your campaigns success, and ideally, after HTML validation, an email should be test-transmitted to a wide variety of email clients and webmail clients.

In my opinion, the bare minimum for this should include:

• MS Outlook 2003

• MS Outlook 2007

• MS Outlook 2010

• Lotus Notes 8

• Gmail (testing in Chrome, Internet Explorer, Safari and Firefox)

• Yahoo (testing in Chrome, Internet Explorer, Safari and Firefox)

• At least one iPhone email client version

• At least one Android Smartphone email client version

Of course, it is not practical or cost effective to have a number of different email clients installed across several machines within your business, but there are a number of great companies out there, such as , which allow you to upload your HTML, run a test across a number of different clients and let you see the results.

This kind of testing should not be underrated, but be warned that fixing an issue for one email client may cause a problem for another. Please don’t be disheartened by this, as it is worth the perseverance, and you will learn lessons that can be incorporated into your next email. Thankfully, EmailOnAcid have really great resources available in its forum () and blog (), both of which have no end of useful tips and shared experiences.

Although this type of test is invaluable, it does not replace an actual transmitted test email, so once you’re happy with the testing at this stage it’s important to ensure you send an actual test email or two, just to ensure there is no conflict between your code and the sending system. At this stage I would recommend sending to:

• At least one version of MS Outlook

• Gmail (testing in Chrome, Internet Explorer, Safari and Firefox)

• Yahoo (testing in Chrome, Internet Explorer, Safari and Firefox)

• At least one iPhone email client version

Useful References

These are third party sites, and we take no responsibility for any discrepancies or errors within these pages.

Email testing clients:





Guide to CSS Support in email clients:



Mobile email compatibility:



HTML Validators:





Examples of email design:





................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download