Some designers and clients may think HTML e-mails (as opposed to text-only e-mails) are like designing and coding a web page, since both are based on HTML. But not every good website developer is a good e-mail coder. Here’s why.
Today’s websites can take advantage of updated technology by using style sheets (read: less code on the page and faster page load time), and tableless layouts (read: more flexible or responsive layouts). On the other hand, HTML e-mail designs must be coded for the lowest common denominator to be readable across different:
- platforms (Mac, PC, etc.),
- devices (smartphones, tablets, etc.),
- browsers (Firefox, IE, Chrome, etc.) and
- e-mail programs (Outlook, Mail, etc.).
Therefore, they must be coded as tables (an antiquated method of coding, used in the first generation of websites) and contain redundant code so that everything appears correctly after taking into consideration the “damage” that might be done by an e-mail program or mail server.
Just because the e-mail looks good in your inbox doesn’t mean it does in everyone else’s.
An e-mail coder should take into consideration many variables:
- E-mail service providers (ESPs) and programs. Every ESP (MailChimp, Constant Contact, etc.) and e-mail program interprets an HTML e-mail slightly differently, some removing chunks of the code. Usually, though, the visual difference is spacing before and after a paragraph of text, or the space between text and an image. So don’t expect the design to be accurate down to the pixel.
- Mail servers. Every mail server treats an HTML e-mail slightly differently: some remove background images, while others retain them or prompt you to show them. Sometimes the removal of background images is due to your workplace server spam settings.
- Font sizes. E-mail users don’t have their fonts set at the same exact size as each other. Font sizes are specified in the code, but if the recipient has his or her font size set smaller than yours, then they will see it smaller than that set size. In other words, font sizes are not absolute.
- Smartphones and mobile devices. The text should be legible when viewed on smartphones and small mobile devices without having to pan in. A responsive e-mail would be the way to achieve this.
- Images. If an image (such as an image used for a headline) were to not appear, no content should be lost. You would not want your recipient to open you e-mail and not see the headline if the text for it was part of an image and that image was removed by a server. Your coder should plan for this.
- Responsive view. The content falls into place in the proper order when being viewed responsively. Note that Gmail doesn’t play nice with responsive layouts.
- Testing. Testing in various e-mail programs, browsers and ESPs, and on multiple devices is a must.
An HTML e-mail design will not look exactly the same to every recipient due to so many uncontrollable factors—but it should be pretty darn close! Therefore, the goal should be to have the e-mail appear as close to the intended result as possible with everything being readable, with the e-mail coder putting in fail-safes for worst-case scenarios.