Even for experienced designers or front-end developers, building email newsletters isn’t always easy. Let’s say you receive a lovely looking design, and you plug into your “matrix” (music) and get on with the development.
But, it just doesn’t work as it should in every email client. Styles don’t display, images aren’t visible, or they don’t align properly. What is going on?
This is where following best practice for HTML emails can save time and money. I’ve put together a few “guidelines (not necessarily rules) of thumb” that can help a designer that knows HTML (since these are the people most likely to build the HTML emails), on how they can create a HTML email that works.
Some of these are suggestions that I’ve personally used others are just some useful ones I’ve found in my journey and saved to my browsers Bookmark (I use XMarks personally).
Understanding the purpose
Before getting into the design aspects of the HTML email, what needs to be understood is your purpose for building a newsletter. Depending on the type of website you want to promote, the information contained in your newsletter may vary dramatically from others, but the core purpose of a newsletter is to deliver convenient updates right to your subscriber’s Inbox.
Consider some of the things you would need to offer in your design. For example, are you including links to sign-up for your service or buy your products; perhaps blog links, or most recently published articles on your site? The layout of your newsletter will reflect how you wish for your readers to respond, but ultimately you are looking to drum up interest and reach as many people as you can in one hit.
A simple design does work
HTML emails are not like website designs, which can become quite complex. They should be designed well, but not over complicated.
The cleaner the design, the easier it is to read by the end user, download via their client (smaller digital footprint). It also means that it’s easier to code, with less chance of visual issues occurring between different email clients and browsers.
Use Tables in your email
Remember Back to the Future, that’s famous Delorian and Michael J Fox? Well around this time HTML tables ruled the coding world. And they still do today. OK we are still ONLY talking about HTML emails OK?
That statement probably sounds contradictory towards today’s modern web standards, but e-mails are still archaic in their rendering engines, this is why you have to build towards older models.
And tables are the easiest way to get everything working properly among the various e-mail clients. Most e-mail clients are built to strip away any extraneous CSS content, this includes <style> blocks at the top of an email, . This means you won’t be able to use much of anything except for inline CSS. Clients such as Microsoft Outlook 2007 and Google’s Gmail have very poor support for floated elements and direct positioning.
So to solve any issues around that, you would need to nest multiple tables inside each other. Padding and margins are not set to a particular scale between many e-mail clients. This is a reason to stick to using
width="value" on all of your table cell elements. These will always display the same width no matter which e-mail client your readers are using, so it’s a lot safer and more consistent to set padding and margins using empty table cells.
Optimise the width of your email, be responsive
It’s been touted about that current best practices suggest that emails should be around 600px in width. MailChimp also found out that 800px is a workable upper limit, though I personally wouldn’t work to that, this is if you must code to a fixed with.
It’s always better to code responsive HTML emails rather than a fixed width
No one likes to write code that’s just come out of a surprise package Delorian driven by Michael J Fox himself, or should I say that is better suited for the web of 1998. This doesn’t mean that it’s all bad either. As archaic as using tables to build an email may be, new techniques like responsive web design are finding their way into HTML email.
Web versions – a must
Readers won’t always view your e-mail natively for whatever reason. Offering another version somewhere on the Web will give a sense of ease and compatibility. This process can’t be completely automated unless you have a text link at the top of your newsletter or are looking to include a plain text version.
However, most people who view your newsletter will use an up-to-date Web browser. How you set up your email in terms of content is up to you. Some duplicate the content of their web post into an email, other simply use snippets from a collection of posts and put them into the newsletter. Either way, a good method is not to include navigation in the web based version. In fact it is best that your web version is a replica of the HTML email newsletter you already sent out to that user. This way you don’t distract the user or tempt them to go elsewhere.
Using images in your content
Images are another reason why you should offer a web based version.
You’ll want to always set both width and height attributes on your
img tags. If you don’t do this, some clients will distort the image content. An
alt tag will also prove useful, in fact it is definitely required, so visitors can read what the image content contains before it’s loaded.
Positioning the images in your e-mail can become a bit tedious or difficult and times. Do not use floats. The image
align="left" attribute will work much better, or alternatively map out exact table cells to fit your images along the top, left, or right side of your newsletter. You won’t be able to get a perfect match-up with so many clients out there (especially mobile clients), but optimize your images and keep file sizes small for best results.
Test and test again
Part of your research – Understanding the purpose – I hope would have been finding out which clients your subscribers use to view your emails, or if this is a new venture looking at the most popular email clients.
Make sure you have as many web browsers as possible available to you. You can also enlist any friends or colleagues that you know or who may be willing to help on testing the HTML email newsletter. You’ll have to get proactive in order to clear out any bugs visually or otherwise.
Alternatively, there are some excellent resources out there, especially if you don’t have the resources to test all clients yourself. Campaign Monitor have a great support matrix detailing what’s supported and what isn’t among various mail clients.
Unless your signed up to every mail service out there, or your newsletter carrier doesn’t provide this kind of testing service, join Litmus to view how an email appears across several clients and whether they get caught by filters and more.
There are a a couple other points you may want to add to this list. But hopefully this list as it stands put you in the best position to create awesome HTML email newsletters.