The Email Factory

Email Marketing

Convert to conversion tracking

3 minute read

Mel Jewell

In the old school days it used to be you’d measure an email campaign’s worth by the number of opens it produced, and the number of clicks to drive traffic to your website. But in these more challenging days, with the open metric being horribly skewed by Apple’s MPP among others, are just clicks enough anymore? Most email service providers should be able to provide conversion tracking, and this by far could be the most important metric – if the purpose of your email is to sell things, then just how much have you sold via your email?

A conversion of course doesn’t just have to be for retail success – you may want to track people that showed an interest in an event or your services, or clicked through on to a specific call-to-action – whatever it may be, it’s all trackable. Depending on the ESP, it could require a little bit of extra code on your website but here’s an idea of how easy it would be with us were we your ESP:

Step 1: Capture your user

We generate a unique conversion ID for the user and campaign which will get included in any URL back to your website from your email. You just need to make sure you can capture the value of the parameter, e.g. cid (this is the default, but you can change it to something else if it unluckily clashes with another parameter of the same name), from the URL and store it in a cookie or session variable to be used later on the conversion page. So, when your email gets sent out, your URL will end up looking like this and you can just snaffle up the cid:

https://www.yourdomain.co.uk?cid=jyUY76YFft5Du88trSlkJ763JGL-iyu78t6DFT5

Step 2: Add a conversion beacon

All you need to do is stick a beacon, or an invisible 1×1 pixel sized image, onto the page after a conversion has been made, e.g. the “Thanks your order has been completed” page if you were tracking sales. Then you can drop the captured ID into the src link for this image back into the platform that will record it for your specific campaign.

<img width="1" height="1" src="http://clicks.yourdomain.co.uk/convert/jyUY76YFft5Du88trSlkJ763JGL-iyu78t6DFT5"/>

You can also juice it up a bit by adding the amount they spent, and even labels to help you break the conversions into categories to see if one area is doing better than another e.g. if you sell white good appliances you could stick in what type of sale you made, a WashingMachine or DishWasher or MultipleProducts:

<img width="1" height="1" src="http://clicks.yourdomain.co.uk/convert/jyUY76YFft5Du88trSlkJ763JGL-iyu78t6DFT5&total=399.99&label=WashingMachine"/>

Step 3: A gremlin in the machine

We all know that despite our best efforts, things can go wrong, normally in the form of a page refresh. In some cases it may not matter, but if you are tracking physical sales you definitely don’t want those being inflated. To prevent that happening you can add something unique to your link, for example an order number, and this means your conversion can never be counted twice.

<img width="1" height="1" src="http://clicks.yourdomain.co.uk/convert/jyUY76YFft5Du88trSlkJ763JGL-iyu78t6DFT5&total=399.99&label=WashingMachine&uid=ORD12345"/>

Step 4: Let the conversion begin

Within the platform, all you have to do is toggle it on:

The links from your template will now include the cid, or whatever you want to call it, and you should see your conversions begin flooding in. As you can see here, you can also add an extra follow up to a conversion if you wanted to, e.g. trigger an email to them with extra information automatically which opens up a whole new world of possibilities.

Instant analysis at your fingertips

A lot of this could be tracked in things like Google Analytics to be analysed later, but the advantage of doing it within the campaign itself is you then have visibility of your most active customers, so not only do you instantly see how well your campaign performed, you can then build up a better profile on your users to target them further.

Why not get in touch to see if we can help enhance your campaign analysis?

Email best practice

It’s a feature, not a bug: email edition

2 minute read

Adrian Young

Are those pesky email applications messing with your design? You didn’t want that address to be automatically linked to Maps, and you certainly never asked for telephone numbers to be underlined! It’s time to squash the bugs.

The battle begins

Overriding a piece of email software’s functionality often isn’t a simple task. The only tools at our disposal are HTML, CSS and a bit of imagination. Email development forums are awash with questions and suggestions on this topic, plus a graveyard of now-defunct solutions. There’s much trial & error, and the successful method usually amounts to some kind of hacky trick.

Here’s an example. Some versions of the Outlook mobile app will recognise and auto-link dates and times to the user’s calendar. This also turns the associated copy blue. One effective solution is to secretly break up the text with an invisible special character called a zero-width non-joiner. Congratulations – you have successfully tricked an application into losing functionality!

Don’t fight functionality

But why would anyone want to do that? The fact that there’s often no easy ‘fix’ for these ‘problems’ says a lot. The problem does not lie within the application’s functionality. It lies within the sender’s design and objectives.

Suppressing a piece of functionality is not in the spirit of accessibility. And to be frank, it’s not the sender’s decision to make. Nobody likes it when a website blocks or forces the opening of links in new tabs. A similar etiquette applies to the world of email.

Design around it

Addresses are another type of content that could be auto-linked and coloured blue. If they’re sitting on a coloured background, that could result in an ugly clash and illegible text. The solution: place them on a white background instead. Cosmetics do not trump usability.

Example of address in an email being auto-linked to maps — Outlook has helpfully linked that address to the maps application. Should we break that… or change our background colour instead?

Reallocate the effort

I mentioned trial & error earlier. That means editing code, uploading it to an email platform, sending tests, and checking them on real devices and/or previewing services. All of this all takes time. But this is not a task that deserves it.

Imagine what could be created in that time rather than destroyed. Optimum email designs. Improved accessibility. Better content. Don’t squash the ‘bugs’ – give them a better habitat instead.

Email best practice

Simple email design for a fragile medium

4 minute read

Adrian Young

Google recently caused a ruckus in the world of email marketing. As part of an update to Gmail, support for background images was (accidentally) knocked out. Oops. The result was an industry of marketers in panic.

Email developers scrambled to find a fix. Workarounds were found, and Google ultimately resolved the fault at their end. Crisis over. This incident will soon be forgotten – which is a pity, as there lessons to be learned.

Things change

This isn’t the first time such an event has occurred. Changes to email platforms are fairly regular. Sometimes for the better, sometimes for the worse. I recall at least two times when a major email platform made a change that immediately broke responsive stacking content on mobile devices.

Or how about some ancient history? In 2007, Microsoft made the infamous decision to switch its ubiquitous Outlook application from a web browser-style rendering engine… to one based on Microsoft Word.

These sort of sudden, unexpected developments vary from subtle to industry-changing. But they have a couple of things in common:

They are beyond our control as email marketers.
The more complex the email, the greater the chance of it being affected.

Ours is a diverse but fragile digital environment

One customer is viewing your email in Apple Mail on an iPhone 14 Pro Max in dark mode. Another is looking at it in the Gmail web app in Firefox on Windows 10. Someone else is using a little-known third party Android app on a flip phone. The point – there are countless devices, platforms, versions and personal settings to cater for.

Now add Outlook and its archaic code support to the equation. With all this in mind, it’s clear why HTML emails can only work thanks to an array of coding tricks and extensive ongoing testing. The more complex the design, the more liable it is to break now or in the future.

Overloading the medium

Like all email developers, I’ve been faced with many moments of hair-pulling frustration. Inexplicable gaps in emails, font problems, wrestling with truncation… the list goes on and on. This raises a question – why are we going to all this trouble?

Thinking specifically about the Gmail background troubles, I cannot imagine any email content in which a background image is essential. Nice, sure. Fancy, sure. But essential, no. As a means of conveying useful information to a customer, a regular image and some text will do just fine.

All of this boils down to the fact that email is far more fragile than a website. And that is not a bad thing. The trouble only starts when we try to force email beyond its capabilities.

Simplicity is key

Most email development struggles are of our own creation. Why battle for hours to achieve a particular design when the easier option is to simplify? This isn’t admitting defeat. It’s making the smart choice to design for the medium, rather than trying to shoehorn a pseudo-website into an email.

Neither does it mean making an ugly email. Simple is not a synonym of dull. A simple email can include static images, and a static image can be as eye-catching and complex as you desire. The email that houses them doesn’t need to be convoluted, and will only benefit from simplification.

Complex email design is less accessible

The hidden beauty of accessibility is that it benefits everyone. The design and coding techniques that it involves will often directly improve your overall email, or serve as a reminder to clean it up.

Complex email design is the enemy of that. It increases the chance of colour clashes, screen reader navigation difficulties and inconsistent use of text and images to communicate information. Simplicity in design means that we don’t have to strive to find clunky solutions to these problems – we circumvent them entirely.

Email code is absurd

It’s easy to forget just how ridiculous email code is. HTML data tables are used for structure. Multiple nested elements are used to achieve something that could be done with a single HTML tag on a website. Spacer objects are often required to force items into place. An assortment of tricks and hacks loosely pins everything together.

And yet we repeatedly choose to attempt complex designs in this environment. Surely the logical choice would be to have less of this clunky code, not more?

Email designers are their own worst enemy (or at least the email developer’s)

Mobile phones have some fairly decent photo editing apps. But they’re no replacement for Photoshop on a desktop computer with a mouse or tablet. The mobile apps are suited to quick, simple edits only. Trying to do anything more in-depth is convoluted if not outright tortuous.

Designing emails that look like websites is like trying to perform complex photo editing on a mobile. It’s simply not the right tool for the job.

Breaking from convention takes courage

Almost every brand sends fancy HTML emails. Companies need to adhere to brand guidelines. No-one wants to challenge the status quo.

That could be good news for you. The one who breaks convention reaps the rewards while others struggle on. Be that one!

Data

Fill the gap

3 minute read

Mel Jewell

Through our extensive travels around multiple email platforms we have noticed that whilst they all do the basics really well, sometimes there is just that missing bit of key functionality that you long for, or it just doesn’t quite work how you want. So, you find yourself doing things the hard way and dreaming of a day where all you need to do is push a button and it all magically happens. But how can you fill the gap?

Well, we thought “why not do something about it?” and came up with our own solutions that anybody can take advantage of. Fortunately, most email platforms provide their own API integrations so these solutions, where required, should be adjustable to suit each platform.

Fill the gap scenario 1: list splitting

You may have a list held in your platform and for whatever reason you need to split it into 2 or more chunks. In theory this is possible with A/B testing but not if you need it for some other purpose.

The hard way: download the data, stick it into a database, run some SQL on it to output however many chunks you want, reimport.

The easy way: use a tool which lets you enter a list identifier, what you want to call the new lists and how many splits you want and it will run the downloading, SQL and reimporting for you whilst you eat that biscuit.

Demo

Here’s a demo of how a tool to split files could work (since it’s a demo we’re restricting to a 1 column file, txt or csv only, and we’ll only split out 100 records):

Fill the gap scenario 2: list limiting

It could be possible that you have a list held in your platform, but for now you only need to send a small amount from it.

The hard way: you download your list, recreate it to the size you want and reimport.

The easy way: use a tool which lets you enter a list identifier, what you want to call it and how many rows and it will run the downloading, limiting and reimporting whilst you sit back with that cup of tea.

Fill the gap scenario 3: campaign send going slow?

It could be that something seems to be going slightly awry with a campaign send and it’s being very slow or stopped delivering entirely.

The hard way: you download all that should be sent and check the send status, then run some group counts on the domains of the unsent emails using Excel or SQL.

The easy way: use a tool that lets you identify a campaign send by its ID that will download all the unsent emails and run the count for you before displaying the results to you so you can see where the roadblock is whilst you get some darts practice in.

Fill the gap scenario 4: campaign send delivered poorly?

If your campaign didn’t perform as well as you hoped and you suffered a lot of soft bounces, and you want to try a resend down different IPs for example then you will want to pull them into a new list.

The hard way: you may have to go into the campaign send, download all the soft bounces and reimport into a new list. Not so bad…assuming it’s just the one campaign…

The easy way: use a tool that can let you input one or more, campaign ID that will identify just the soft bounced records and reimport that into a new list for you whilst you put your feet up and think about your next holiday.

I’m sure there are countless other niggling little things that a simple solution using API can be found for that will save you time and frustration – we’re always looking to innovate where we can, so why not ask us if you have a problem, and let’s see if we can come up with a solution. You can always check out some more information on ways we’ve tried to solve other development problems here.

Artificial intelligence

Is ChatGPT your next email developer?

7 minute read

Adrian Young

There are two ways to build a marketing email:

Hand-coding
WYSIWYG editors

We swear by the former, not only for quality but also for speed. But what if there’s an even better, quicker way?

Enter ChatGPT. Much hype has surrounded the AI platform’s ability to code. It can conjure up HTML and CSS in seconds. So too can it generate Javascript functions or back-end PHP or even truly hardcore programming such as C++. Whether or not it does it correctly is a different matter.

Let’s not worry about that just now. We’re here to put AI email development to the test, so let’s find out if ChatGPT can put together a responsive mailing.

The quirky world of email development

If you work in email marketing in any capacity, you likely already know that it requires some unusual coding techniques. There are lots of devices and email services out there, and they have widely different ideas about how HTML and CSS should be interpeted. In order to construct a mailing that looks presentable on all of them, the developer needs to be aware of these limitations and inconsistencies and the arsenal of tricks to work around them.

Has this niche set of knowledge made its way to ChatGPT? We’ll start with a bare bones request.

Prompt:

Code a responsive email template

Result:

Unusable!

ChatGPT has produced a very basic HTML document with some styling, but I wouldn’t call it an email template. It doesn’t include any means of stacking content on mobile, and the structure is based on HTML div elements rather than tables. While divs are the building blocks of a web page, tables remain the most reliable method for email.

On the plus side, it has picked an inbox-friendly width of 600 pixels. And it’s nice to see that accessibility has been implemented via an image description and a proper heading tag.

My request was extremely minimalistic. I need to do my part here too, and that means being more specific about what is needed.

A little lot more instruction

Take two. We don’t want divs, so let’s tell ChatGPT to use tables. There are some basic universal requirements in responsive email, so we’ll nudge it in the right direction regarding those.

Prompt:

Code a responsive email template, using HTML tables for structure. Set the width to 600 pixels on desktop, with a fluid width on mobile. Include CSS classes to enable stacking of content on mobile devices. Include all known email client fixes that are still relevant. Set the page background to a light grey colour, and the email content area to white.

Result:

Better… but still broken beyond repair.

This time it has used tables for structure, so that’s a major improvement. It has also set a breakpoint. That’s the backbone of responsive email code and the point at which mobile-specific styling is triggered. There’s some kind of attempt at stacking code, but I can see at a glance that it isn’t going to work. We’re also missing the usual pile of fixes that make an HTML email possible.

A rethink is needed.

A different approach

Here’s what we’re going to do: hand code a simple email, and then provide ChatGPT with detailed directions in order to recreate it. This is a reverse way to approach our project, but perhaps if ChatGPT has a more defined goal it will be able to produce a usable template.

Our email will have a main image, intro paragraph and a button. Under those will be a couple of secondary features laid out side-by-side on desktop, and stacking on mobile. For the sake of this test, let’s forget about any header and footer.

Now for our prompt. It’s going to be a long one. Let’s give ChatGPT a fighting chance and focus primarily on structure rather than styling.

Prompt:

Code a responsive email template, with the following requirements: • 600 pixels wide on desktop • Fluid width on mobile • A page background colour of #f1f1f1 • Email content area background colour #ffffff • A hero section with an image, heading, paragraph of text, and a button • The hero image should be 600 pixels wide, to match the email content area • Button should be pill-shaped, with a background colour of #a56e53 and white text • Under the hero section should be two secondary features • Each of these must also have an image, heading, paragraph and button • Secondary feature images will be 290px wide on desktop, to match their containing column, and expanding to full width on mobile • Hero text and button should be a bit larger than those of the secondary features • These secondary features should take the form of adjacent columns on desktop, each at 290 pixels wide • Place a 20 pixel gap between them • The secondary features must stack into a single column on mobile • All parts of the email should have 20 pixels of padding on each side on mobile, except for the hero image which can be full width and touching the edges of the viewport • All body text should follow this font stack: HelveticaNeue-Light, Helvetica, Arial, sans-serif • All body text should be colour #61524b • All heading text should be colour #a56e53 • Use lorem ipsum placeholders for text • Enter all hrefs as # placeholders • Apply links only to buttons. Do not apply links to images • Include all known, currently-relevant email client fixes • Include CSS or HTML comments around each section to explain what it is or does • Set a mobile breakpoint based on a max width of 639 pixels • To ensure compatibility with Outlook and other email clients, use HTML tables for structure

Result:

Nice try… sort of.

In order to test this properly, I’ve saved a local copy and manually added my image references. Here’s how it looks in a browser:

At first glance, that isn’t too bad. The general layout, colouring and sizing are all correct. So too are the button shapes, and the secondary features switch to a single column on mobile as requested.

But there’s some strange overlapping going on. Our images are offset to the right, and sit partially over the grey background. This in turn causes some unwanted horizontal scrolling on mobile.

Behind the scenes, the true extent of the errors comes to light. It has reverted to a div-based structure, and uses some CSS code that won’t work universally in email.

Nonetheless, for the sake of completeness I’d like to test this as an actual email. It works, more or less, on iPhones and the Gmail app. Webmail is a mixed bag. Outlook however is where it all falls apart:

Outlook is the primary reason that email development requires such unorthodox coding methods. A lot of code that works just fine on a website, simply isn’t recognised by Outlook. Here we can see that the adjacent columns have failed and the pill-shaped buttons are reduced to tiny rectangles. To fix that would entail a complete recode.

No need to re-invent the wheel

So far, ChatGPT has failed to code a responsive email from scratch. To add some faux drama, let’s say our make-believe client is becoming impatient waiting for our make-believe email.

It’s time for a last ditch effort. At The Email Factory we already have a tried & tested template. We don’t need a new one. How about we give our base template to ChatGPT and then ask it to complete some content within that framework?

Result:

Now we’re getting somewhere.

But that doesn’t mean success. This time the template works reasonably well in a browser and even in Outlook, although the dodgy buttons are still present. The secondary features however don’t expand to full width on mobile:

That can however be easily fixed manually. In fact, it may be feasible to fix everything in this code rather than to start again. But I don’t want to do it myself, as that defeats the purpose of this experiment. Instead I’ll tell ChatGPT what needs to be corrected.

A few pointers

Final try. I’ve fed back some information to ChatGPT for it to make the necessary changes.

Result:

A huge step backwards.

Well, that was a big let-down. Instead of applying some finishing touches to the template, the layout has exploded. It no longer stacks on mobile. The code is now full of Microsoft conditional statements – a technique that should only be used sparingly and under specific circumstances. And the buttons? Still ugly in Outlook:

Maybe with painstakingly detailed prompting and a lot of patience we could finally achieve a working email. But we’re already far beyond the point of convenience.

The current state of play

In my experience so far, ChatGPT has only done one thing consistently: fail. And I don’t only mean within the limited scope of this one project. I’ve had similar results when trying to generate marketing copy or website code. The output is usually along the right lines but ultimately too broken to actually use.

It’s clear that I set my expectations too high. The tales of ChatGPT’s near-miraculous capabilities were captivating, so perhaps the reality was always going to be disappointing. If there’s a perfect way to illustrate ChatGPT’s close-and-yet-so-far nature, it’s to ask it for an anagram.

Prompt:

Tell me an anagram of "The Email Factory"

Result:

The Fairy Comet Elf

I’ll save you the bother of checking that – it’s wrong. Trying to recreate that manually, letter by letter, results in this:

The Email Fctory e f

Re-evaluating our AI email development experiment

This project is arguably unfair from the outset. ChatGPT is a language model. Just because it can output code doesn’t mean it is a coder, or even knows what programming is.

Even so, it’s widely known that ChatGPT can generate code. So, despite all the mistakes and unusable templates, the fact that it can make a somewhat reasonable attempt is impressive.

Where do we go from here?

ChatGPT and AI in general are progressing at an incredible pace. It wouldn’t surprise me if everything I’ve written about AI email development above is laughably antiquated one year from now.

Perhaps when that time comes, I’ll prompt it to:

Write an article about how you surpass human email developers

Email coding

Was Outlook right about email all along?

5 minute read

Adrian Young

Ask any email marketer what their biggest bugbear is, and there’s a strong chance that they will answer Microsoft Outlook. The desktop Windows application is notoriously uncooperative with modern coding standards. It’s a place of archaic development techniques, myriad quirks and unpredictable rendering glitches. That sometimes leads to protracted development times and hair-pulling levels of frustration.

Here’s a comparison of clean web-style code versus Outlook-targeted bloat:

But I don’t think Outlook is entirely to blame. Here’s why.

Outlook is not alone

Modern web browsers, for the most part, agree on how HTML and CSS code should be interpreted. The same cannot be said for email services. The various pieces of desktop software, webmail sites and mobile applications all behave differently. Each email platform, from Gmail to Samsung to Yahoo, has its own strengths and weaknesses. The only significant exception is the ever-reliable Apple Mail. This uneven landscape is the reason for email-coding being a profession of tricks and workarounds.

While Outlook is inarguably the least code-friendly of all major email applications, it’s not alone in its patchy support for modern web-coding standards.

I’m here for the offer

I don’t open a marketing email to see brand fonts or fancy design or flashy GIFs. I open it because I think there’s something of value to me in there. That might be a special offer, or a new product that matches my interests.

And I want to absorb the information in the quickest time possible. A marketing email is rarely a thing to be perused. If I crave visual stimulation, I will look at art. If I’m in the mood for reading, I open a book.

When I open a marketing email, seeking that tempting discount, a plain-looking design or a graphical defect is not going to be a deal-breaker. It’s an irrelevance.

Email is email, the web is the web

I missed an if earlier: if I want to browse the internet, I’ll browse the internet. Email – electronic mail – used to be the digital equivalent of a posted letter. But at some point it became standard practice for marketing emails to resemble mini websites. Navigation bars, complex layouts, rich graphics, fully-blown footers. Even interactive components such as drop-down menus have become fairly commonplace.

To achieve such an email requires layers upon layers of non-standard coding techniques. To a front end web developer who is used to coding efficiently, it’s likely to look like an incomprehensible mess at first glance. I picture it as a ramshackle machine, bodged with duct tape and liable to break down at any moment. And what is all this effort for? To force a medium to do something that it was never intended to do!

Word games

Microsoft made an industry-changing decision when they released Outlook 2007. Emails would be displayed using the Word rendering engine. Yes, that’s Microsoft Word as in the word processor. And, at the time of writing, it has remained this way for all subsequent Windows editions of Outlook.

Not only does this explain the platform’s extremely limited support for modern web code, but it’s also the reason for sporadic rendering glitches. Marketing emails are often fractured by pixel-thin lines appearing as if at random. One common cause of this is content falling on Word’s unseen page breaks behind the scenes.

But is this truly a flaw in Outlook, or a problem created through misuse of the medium?

Things change: part I

From time to time, email vendors update their platforms and significantly change how they interpret HTML and CSS code. Sometimes that means improvements, sometimes it means email-breaking regressions.

Here’s a good example. More than once, I’ve seen the code used to stack content on mobile suddenly stop working. The solution: yet more unorthodox coding techniques.

This is part of the reason why companies (should) regularly check their mailings on as many email services and devices as possible. An email may display perfectly today, but tomorrow could be a different story. Even the most robust HTML email template is ultimately fragile. Keeping things simple is an effective future-proofing technique.

My needs are simple

From a consumer’s perspective, Outlook is perfectly capable of everything I need a marketing email to do. Formatted text allows me to scan over an email and pick out key points such as product name and price. High resolution images show me what a product looks like. Large, clear buttons give me a means to move onto the next step – in a web environment – should I choose to.

But what about pixel-perfect design, drop shadows, cool GIFs, web fonts, animation, and other bells and whistles? I don’t need those. Such non-content is of immeasurably more concern to a marketing department than it is to a customer.

Things change: part II

And now it’s time to unravel everything I wrote above. Technology progresses, trends move on, and I don’t want to be a closed-minded Luddite.

When I claim that Outlook does all I need it to, I’m seeing things through a conventional lens. In actual fact there are several pieces of enhanced functionality that would benefit me as a customer. It would be handy to watch a movie trailer, or to listen to a snippet of an album, or check out a t-shirt in different colours… all without leaving the mailing. Just because email has traditionally been a gateway to a website doesn’t mean it must always be that way.

So, is outlook right?

I’ll pick a side – no. There are definitely lessons to be learned from Outlook’s approach to email, and it reinforces the importance of substance over style. But ultimately its resistance to modern web standards is resistance to progress in general, and holding the medium back. And if Microsoft was truly making a stand about what email should be, why equip Outlook with a diluted level of HTML and CSS capabilities rather than none at all?

Google’s AMP for Email is a determined move to transform email into a rich, fully interactive experience. The technology may not have taken off in dramatic fashion, but adoption rates are slowly growing. In any case, it would be absurd for the world of email to maintain its antiquated coding techniques forever.

There’s also a new version of Outlook on the horizon. Anticipated for late 2026, there are convincing rumours that it will at last support modern development techniques. That changes everything.

When that day comes, we’ll be given the gift of time. Instead of wrestling with rendering problems, let’s focus our efforts instead on customer-focused content and design.

Email Design

How to make light work of dark mode

5 minute read

Adrian Young

Black text, white background. That’s been the go‑to colour scheme on websites and emails for a long time. After all, it emulates the printed typography of a book or newspaper.

But a digital display isn’t a piece of paper. That’s why some bright spark came up with the idea of dark mode – an inversion of the default colour schemes of old. And there’s a point to it beyond ‘because we can’. Light text on a dark background is easier on the eye, especially in a dimly‑lit environment. It’s also easier on battery life. Whereas ink comes with a material cost in physical media, light comes with an energy cost on a screen.

The use of dark mode is entirely optional. You can generally switch from light to dark whenever you like, or set your device to react automatically based on light conditions. Most modern operating systems, lots of applications and some websites cater for dark mode.

We’re not here to talk about any of those. Email is our thing. Let’s take a closer look at how dark mode affects email, how to design for it, and how to code for it.

Don’t be afraid of the dark

There’s an important point to set down from the outset: the objective is to optimise your emails for dark mode, not to override your reader’s settings.

That means we all need to be flexible with our brand guidelines. Whether your customer has a visual requirement for dark colours or simply prefers them, user prerogative trumps everything else.

Google homepage in its light and dark versions — If Google isn’t afraid to invert its brand colours, none of us should be!

Discover the dark mode landscape

Rendering quirks and the tricks to get around them are at the heart of email development. The handling of dark mode maintains these traditions.

Some email services allow full control – you get to set the dark mode colouring. Others ignore your styling and force a dark colour scheme of their own. Some offer partial control, and a few don’t support dark mode at all. The challenge is to design and code an email that looks good on all of them.

It’s important to note that those services which apply their own dark mode colours are not a lost cause. You can and should still optimise your design so that they look as good as possible. Familiarity and consistency ward off unsightly surprises and the wasted time of trial & error.

Don’t be vexed by text

Warning: please excuse the rant‑like nature of this paragraph. It’s frustratingly common in email to see images used to display copy. There has never been a convincing reason to do so. Images‑of‑text instead of actual text is often a way to foist a brand font or elaborate design on users. And one that comes at the expense of accessibility, usability and best practice.

Dark mode is one more reason to use text. Image‑based text can lead to a messy, partially inverted email in dark mode. Real text puts the email developer in the driving seat. Some email services support web fonts, so it’s still possible to show brand fonts to a reasonable percentage of your audience. Other accounts will fall back to standard fonts of your choice.

Let’s be (partially) transparent

Email supports a handful of image formats. JPEGs are common, and best‑suited to photographic content such as product shots. GIFs are also popular, and handy for simple images such as icons, or for short animations.

Somewhat less widely used are PNG images. Which is a pity, because their built‑in transparency support is a dark mode designer’s best friend. Let’s take a logo as an example. Save your logo as a JPEG and it could end up sitting in an unsightly white box against a dark background. Utilise the PNG format instead and it’ll automatically let the background colour shine through. If your logo itself is dark, it could be lost against a darkened background. A white outline or glow effect – invisible on light mode – can counteract that.

Here’s how a logo might look in various light and dark mode setups

It’s worth noting that GIFs also have a transparency capability… but it’s limited. It’s an all‑or‑nothing deal – a single colour can be set as fully transparent. While that can be useful in some situations, it doesn’t allow for the smoothly‑blended curves of a PNG.

Code for the mode

It’s time to get coding. First up, you need to explicity enable dark mode in email. That’s a two‑step process. Add the following HTML <meta> tags in the <head> of your document:

<meta name="color‑scheme" content="light dark"> <meta name="supported‑color‑schemes" content="light dark">

And then create a new <style> sheet, separate from your existing responsive styles. Now add a couple of root selectors to define light and dark mode:

:root { color‑scheme: light dark; supported‑color‑schemes: light dark; }

These colour modes can now be targeted via media queries. Not only does that mean you can set up specific custom colours for dark mode, you can even swap images.

@media (prefers‑color‑scheme: dark) { .email‑background { background‑color: #313336 !important; } .darkmode‑show { display: block !important; width: auto !important; overflow: visible !important; float: none !important; max‑height: inherit !important; max‑width: inherit !important; line‑height: auto !important; margin‑top: 0px !important; visibility: inherit !important; } .darkmode‑hide { display: none !important; } }

There’s an important reminder in that prefers‑color‑scheme syntax! We should always bear in mind that light or dark mode is a user preference.

Give it a go

We could go on about the technicalities of dark mode all day. But let’s now put it to the test.

Below is a simulated email. It’s interactive – try the controls to see how it looks in various states of light and dark mode.

Note: this demo approximately simulates light and dark conditions in email. Specific email services and devices will have their own rendering quirks. This simulation is set to automatically disable the use of swapped images on forced dark mode, so some switches will be tripped automatically.

Simplicity keeps things… simple

The more complex the design, the more work will be involved in making it dark mode‑friendly. That raises a question: is that design essential, or can it be stripped back? I like to find the answer in a second question: does the design help to relay information to the customer, or is it a box‑ticking exercise for the marketing department?

In light of that way of thinking, the best solution is often to simplify the design rather than piling on more and more CSS code.

Final thoughts

Dark mode is a good thing. It’s a piece of functionality in the spirit of accessibility and respects the user’s autonomy.

As with all things development, you don’t need to work from scratch every time. An email template and snippet‑based coding style mean consistent results.

Despite that, surprisingly few companies are actively supporting dark mode in email or even the web. By designing for dark mode, you are helping to lead the way.

Perhaps it isn’t light work, but it’s definitely the right work.

Email coding

Modules vs snippets in email development

3 minute read

Adrian Young

As an email marketer, you probably don’t go back to the drawing board every time you create a mailing. Email layouts are saved as templates, and recurring components are stored as content blocks. There’s more than one way to do that. Let’s compare the email development merits of modules versus code snippets.

Some email development definitions

Modules are recurring template components stored on an email platform.

Code snippets are shorthand phrases defined by a developer that trigger pre-built chunks of code.

Modules and snippets therefore serve the same purpose. But the means to get there is very different. That deserves a closer look.

Module methodology

A module is essentially a standalone HTML file that can be dropped into a larger template. It might be a banner, or a stacking product section, or an intro with a hero image and a button. Whatever you like, it can be moduled.

That module is hosted in a library on your email platform. You can copy, edit and select any module for use in individual mailings. The specifics vary but you’ll generally perform this task via a graphical user interface. There often needs to be some additional programming using your platform’s scripting language.

Next, there’s usually a master template which has modules slotted into preset positions. These can of course be moved around or removed or added to as required.

So, that’s modules. Now for snippets.

Snippet style

The phrase ‘hand-coding’ is sometimes misunderstood. A developer will not sit and type thousands of lines of syntax in their entirety. Modern development environments support all manner of production shortcuts.

Among these shortcuts are code snippets. There’s more to these than simple blocks of code. A developer can set a snippet’s variables and cursor locations, thus producing a piece of code that can be navigated and edited in seconds.

Thinking about email development specifically, one example of a snippet could be a call-to-action button. By typing a pre-determined phrase – let’s say ’embttn’ – the developer triggers the snippet. Within moments, the text, link, colour, size and border can be set.

And the winner is…

I’ve kept the tone neutral(-ish) so far, but now it’s time to pick a side. By just about any reasonable measure, there’s a clear winner: snippets.

Here’s why:

Understanding

A skilled developer will work primarily in a code editor like Sublime or VSCode. Raw code may look daunting compared to the friendly GUI of an email platform, but ultimately that interface only fragments and obscures what is going on behind the scenes. When a new user needs to familiarise themself with the setup, it becomes a puzzle to be pieced together.

Speed

Working with modules means navigating through multiple pages and menus in an email platform. It is never quick. Working with snippets on the other hand is lightning fast. I’ve seen build durations reduced from all-day to an hour as a result of switching to snippet-based coding. There is no comparison.

Cohesion

Snippets mean far fewer sources of content for an email, and a more consistent format. Often an entire template can exist in a single file. Dynamic content written in your email platform’s scripting language can go there too, peacefully co-existing alongside HTML and CSS.

Flexibility

We’ve already covered the flexibility of snippets themselves. But there’s a related benefit – it means the developer can work in their environment of choice, rather than the one presented to them by an email platform. The advantage of a familiar and custom-configured comfort zone cannot be understated.

Final thoughts

To pit modules against snippets is part of a larger battle – drag & drop email builders versus hand-coding.

We are biased, of course. But with good reason. As a company of email developers, we’ve seen the comparative disadvantages of module-based configurations. There are situations in which errors can go unseen months or years. But the fault is buried somewhere in a maze-like setup that potentially no one person understands fully.

Hand-coding, by contrast, is uncluttered and transparent. For me, snippet-based email development is not only the best way to build mailings – it’s the correct way.

Email Marketing

User experience in email design

4 minute read

Josh Green

Email is a fantastic graphical way of communicating with others. But so often in email design the primary function of an email is forgotten. It may be time for a fresh look at user experience in email.

Sure, some emails are just to pass on information, but nearly every single other email is about selling. It is currently impossible to complete a purchase with just an email but this is no bad thing, it streamlines the email’s function. The email exists solely to drive traffic to a web page.

The email exists solely to drive traffic to a web page.

Email is not website-lite

This key idea is so often lost in email design. Often it is closely tied to reproducing a similar or lesser version of a website instead. I think this is a terrible waste of space, and poor design that doesn’t challenge the ways email should look.

Instead of the ubiquitous ‘view in browser’ link, the logo, and a site navigation bar, why don’t designers just go straight into some products? The Subject line, Pre-subject line, From address and Friendly From address could all be used to establish the brand. The ‘view in browser’ link doesn’t have to be at the top. Lastly the navigation bar is just a poor version usually of what is on the site. Furthermore it nearly always links away from the main campaign … which is the primary purpose of the email!

Emails are ephemeral messages, they focus on what’s happening now. Including links in a navigation bar at the top of an email design just takes the user away from the sale that is happening now. This is a bad user experience. It’s equally bad for the sender because the click has been wasted. The purpose of the email was to get the user to go to the sale section and now they have clicked something else in the navigation bar.

Link with purpose

Emails also need to consider where they are driving traffic to. If it is easy for people to complete a purchase from nearly any page, that’s great. However if the email can misdirect users to contact pages or other areas of the site before the reader has even seen the primary content of the email, that’s not great. There would be an argument to say the content is incorrectly ordered.

Large full-width images are also a component that can affect the overall user experience of an email. First, it must be said stated that they are necessary and often provide some much needed beauty and spectacle to a design. However, they can be tiresome to scroll through and take up a lot of space for a single link. Consider their use carefully.

Text links form the backbone of the internet and were the first types of link on the internet. In email design, however, designers don’t always stick to the rules and sometimes only use bold links or just colour them differently. Always apply underlines to text links. Format them with sufficient font size and line height so that they can be clicked easily. Unfortunately, it is not uncommon to find many text links all squished into a paragraph of small text. This makes it very hard on some smaller screens to click the link you intended.

The primary message must be the focus in order to provide a good user experience in email design. Links that might scatter users all over the website should be kept to a minimum and collected at the bottom of the email. Analysis of email heat-maps always show the vast majority of clicks happen toward the top of an email. They gradually decrease as you move further down the email. With this in mind, email designers should focus on making the primary message content of the email as close to the top as possible. Migrate all other types of content towards the bottom.

The courage to break convention

This could mean a layout that reverses the content order completely would be a better email design. Start with the products you want to focus on, then any other content and finally add the branding and any footer content necessary. This would be designing in a manner that takes into account where the most clicks happen and relying on people to know who sent them the email. This is a step designers have so far been too scared to take.

To this date I have not encountered a brand that has been brave enough with their email design to use such a forward thinking approach. There are some examples, though, where brands do drop superfluous components such as navigation bars, however I have never seen one brand completely flip the email design.

Design for clarity, not confusion

Individual components in email design often provide terrible user experience. For example, an email might be trying to sell a high cost item. Instead of solely linking to that product, the email links to all sorts of other things relating to that product. For example, the product might be a new car. Rather than taking the clicker to the new car page it links to the car accessories page. It can be argued that at least the user is on the website, but the point of the email was to sell the car. The goal wasn’t to sell windscreen wipers for their existing car. Polluting the layout with complementary links to add-ons or related products only decreases the traffic to the main intended link.

To have the best user experience in email design, the email’s components need to be concise and link to a single location. Prioritise content order and remove superfluous components. Subject lines and From addresses should factor into the email design. Place recurring content at the bottom of the email.