Email Templating - stuck in the 90s?
These days email newsletters and offers are still the best means of reaching your target audience. Conversion rates as compared to other marketing tools such as social media ads are still considerably better.
So it may come as something of a shock to learn that the email templates used to deliver your latest glossy offer or fantastic latest news still use very antiquated technologies to render your design.
Whereas conventional internet browsers mostly keep pace with the emergence and adoption of new standards in coding, email client applications sadly do not.
Obviously to some, an email client application is the application the user views their emails in. These roughly divide into three camps; web browser based clients, native clients such as Microsofts Outlook and mobile clients.
Where as the browser based clients will dutifully render all your modern css styling and fancy new techniques to make your design pop, the native clients do not. A case in point is Microsofts Outlook. Outlook used to utilize
Internet Explorer internally to render the html that made up the email but since 2003 it has been using Microsoft Word to render. You only have to try and look at a webpage loaded with Word to see this is far from ideal, page elements are stretched, skewed, in the wrong place, it's just a mess.
And this brings us to what is required to ensure your email templates at least look similar to how you envisaged them in as many clients as possible.
In order that your email looks vaguely similar across the myriad of clients out there, developers of templates have been forced to use very old techniques to author their code.
Back in the 90s, if you were to create a web page you would leverage code that rendered tables to achieve your layout. The table would have rows and columns and tables could have nested tables inside their cells.
Somewhere round the turn of the century it was decided that this was bad practice as semantically using a table for layout purposes was undesirable as the table element best describes data displayed in a tabular fashion, not a layout.
So mainstream web development stopped using tables and started using a more appropriate element - the div to define layout. But wait, there's a problem. Because email clients don't fully support the use of css (cascading style sheets), which is a separate layout language used to augment html in order to tell it how to render, this new technique was not going to work in emails.
Emails render differently in different client applications and so special coding techniques are employed to ensure consitancy
So to this day we are stuck with having to code our emails using tables. This doesn't sound like much of an issue unless you've ever ventured to look at the code in an averagely complex email - its complicated. With nested tables in tables in tables it becomes very difficult to keep track of very quickly.
In addition to this issue, modern browsers use css to enable responsive design, a practice which allows a web page to morph to fit any sized screen. This is an awful lot more difficult to do when you're using tables and so designing an email template to be responsive is a major undertaking employing lots of tricks and frankly hacks to get it working correctly.
To make things worse, some email clients have their own quirks and there is a special logical language to test which client the email is currently rendering in and take a different course of action based on the environment. For instance there may be a piece of code that displays a heading at a particular size but if that renders in Outlook it renders ginormouse. The developer will then need to utilize this special logic to tell the renderer - hey, if you are Outlook then run this alternative code.
There's also another fly in the ointment when it comes to emails - fonts. To the average onlooker, using a special font in an email which is destined to land in thousands of peoples inbox should be trivial, just specify the font to use right - wrong.
Fonts are only able to display in the manner you intended on a customers machine IF they happen to have that font installed on that particular machine they are viewing it on. That means that that lovely font you had specially designed is not going to look the same on any ones machine but yours. It is for this reason that web safe fonts are around. The long and the short of it is if you want to know what your email is going to look like when it lands in your customers inbox you will need to use a web safe font as these are fonts that all people are guaranteed to have.
If your still reading then congratulations, you now have a good understanding of the challenges that await the email template builder and it is my hope that you will have a new found appreciation of exactly what goes into the making of an email.