HTML email is a great way to engage your mailing list. From industry news to information updates, HTML emails are captivating, instant and track-able; providing you with opportunities to measure the return on investment precisely. But how does it all work? This document will help you understand the opportunities and limitations of the media, informing you about what’s possible and what’s sensible.
Who do you want to reach?
What email clients do you need to accommodate?
What email clients do your staff or clients use?
Is this a one off or recurring campaign?
How many emails do you intend to send per campaign?
What imagery do you need?
Do you already have a mailing system?
->If you do: What do you use?
->If you don’t: Do you require a mailing solution.
->Do you want to manage the content yourself?
HTML emails are very inflexible, they feature HTML coding standards ten years old – before style sheets became the norm. There are 4 or 5 major browsers who adhere to W3C web standards, but there are dozens of email clients that all render HTML emails in their own way, this requires extensive testing. It’s possible to get a unified look and feel if the design is straightforward and works within the limitations set out below. However clients like Lotus still have some problems, generally we won't support this unless it's a specific requirement. Campaign Monitor has a useful testing tool for a comparison of how email clients vary, here’s a list of email clients supported:
In general Microsoft Outlook is the most difficult to design for as it chose to use Microsoft Word’s limited HTML rendering engine instead of the browser equivalent at the time of development; this makes for some unexpected results. Sadly Outlook is not something you can avoid building for as its popularity generally outweighs its complications, as this table shows from a recent Make it Clear campaign.
It’s useful to know if there’s a specific email client you’re trying to reach as it can provide more flexibility when we consider the design or inform us of greater limitation if its for an older client.
As best coding practice we always build emails with HTML tables. This comes with some design limitations. It is therefore best to follow a simple grid layout for content and to embed all images directly. If more elaborate imagery is required this can be accomplished with slicing tools within Photoshop or Fireworks. However copy content can’t overlap images and needs to be positioned so that text and imagery remain separate. If text is required over an image it needs to be included as part of the image. However, as a rule of thumb and due to certain clients blocking images before a user has permitted download, it’s worth considering that emails should degrade so that content is still accessible. If no images are used does the email still communicate the message?
As a consideration it’s probably best to still use either GIFs of JPEGs as these formats are supported by a wider number of clients. Also the width of the email is best kept between 550px to 650px to provide sufficient space to view the documents in varying email client windows.
Background images are not encouraged unless used for tiling. Different clients have different limitations when it comes to creating background images. There are techniques for working around this but it takes a lot more time to test and correct issues across many email clients.
If a background image is used it should be supplied as a GIF 96 DPI to avoid outlook image resizing issues.
HTML emails can be complicated to create and test. We can construct an initial template and then repeat it for subsequent campaigns however an understanding of HTML is required if you'd like to edit the the template yourself.
With a simple enough approach to the design and coding it is possible to create a template that allows for like for like swap out of images and text. This would still require some degree of confidence with HTML.
Using some available tools such as Mail Chimp, the simplification of this process is possible, however you will need to let us know in advance of production if require us to implement this flexibility.
There are a number of considerations when sending out emails; the best solution will be dependent on what you are aiming to achieve. If you wish to send emails from your own client to a limited number of individuals that you already have contact with, then generally this will not pose a problem. If you've got a larger number of emails to send we would be happy to help, meaning you can avoid some of the following complications.
If you want to send bulk emails from your email client you’re likely to have a significant number of emails removed by spam filters. If you send emails from your web server you may experience delivery issues if your server is not configured specifically for mail sending or protected against blacklisting. Occasionally, if you have a large list, your server might grind to a halt under the load.
A mail service, like Campaign Monitor or Mail Chimp, which is relatively cost effective for medium to large campaigns and takes these issues out of the equation is an effective solution. As well as providing a number of useful tools this makes the process of generating emails and managing mail lists a lot simpler.
We use campaign monitor to test for spam issues, however content can be an issue.
There are spam filter implications when considering the design and content of the mail. Here’s a good resource. We make sure you're compliant with spam permission and regional laws when considering how you send out campaigns. Please read this for more information.
There are some designed template samples below, and also some stripped out templates. It is, of course, possible to create unique email designs. For the best results with email clients and design it’s good to use these simple templates as a starting point and work towards a unique design. These are tried and tested and should provide sufficient flexibility when approaching an email’s layout without risking breakages across email clients.
If simple templates aren’t adopted its not always possible to guarantee that the final email will always work as expected on different clients, which might result in more extensive testing and time to resolve design issues.
This document hopefully gives you an overview of the challenges when approaching HTML emails.
For further reading and resources head here.
For some stripped back layouts a great place to start is here.