How We Did It: Building the New Tuts+ Email Templates

The Tuts+ emails (newsletters, digests etc.) recently underwent a complete overhaul, including new designs and a new platform. This case study will explain how I built them in HTML and CSS, based on the designs from the first part in this series.

Kicking Off

When the time came to start building the shiny new Tuts+ email templates, I was lucky enough to be quite familiar with the designs. During the design phase, Ian had looped me in on major decisions and asked me plenty of questions to make sure we avoided any classic email gotchas. This process was an excellent foundation for me and I was ready to dive straight in when the designs were complete.

Ian sent me the designs, an overview of the layouts, a guide to the grid layout, and a style guide with all the necessary font sizes and colours. I was ready to get started.

Creating a Plan of Attack

My first step is always sketching. The aim of this is to identify all the distinct modules, ignoring minor cosmetic differences. This process gives me a final set of key modules to build that I can work through one by one to build up the primary structure.

Having identified these, in many cases I would build them all into a single page before separating them at a later stage, but layouts are quite awkward to review in that state. Instead, I developed each layout as per the designs so that they could be reviewed and approved more easily.

Referring to my sketched summary of the modules, I was able to bear in mind when a module needed to be reusable across multiple templates, and build it accordingly. Later on I would set up classes on the body of each variant, like var-admin and var-digest, allowing me to create styles specific to each particular layout.

Starting to Code

I began by setting up some LESS variables for elements I knew I would use over and over, like colours and measurements.

A guide to most of the typographic styles

Some of my variables (in LESS syntax) are shown below.

// Variables
@bg-body: #f2f2f2;
@palette-text: #58595a;
@palette-navy: #212a34;
@palette-design: #c94e4b;
@palette-code: #4cc1be;
@palette-web: #49b293;
@palette-photography: #8360a8;
@palette-game: #72BF40;
@palette-computer: #5d7dba;
@palette-business: #f38844;
@palette-3d: #f95858;
@palette-music: #56a4ca;
@palette-footer: #5a6e7a;
@palette-address: #999999;

@divider-color: #EAEAEA;
@link-color: #136fd2;
@alt-color: @palette-text;

@width: 640px;
@outer-gutter: 53px; 
@content-width: @width - (@outer-gutter * 2);
@grid-unit: 16px;

.rounded(@radius: 1px) {
  border-radius: @radius;
  -webkit-border-radius: @radius;
}

I always prepend my colours with palette to keep them together. This makes it easier for me to choose a colour from the suggestion dropdown that appears in Sublime Text:

Setting up the Webfonts

The next important step was setting up the webfonts used in the designs. The typeface is Roboto available from Google Fonts, so I added this tag to the <head> of the template:

1	<link href='https://fonts.googleapis.com/css?family=Roboto:300,300italic,400,400italic,500,500italic,700,700italic' rel='stylesheet' type='text/css' />

This is generated by Google Fonts and links to their CSS for the four different weights of Roboto that we are using.

I applied the font to the body tag and my main wrapper table for those clients that disregard the body tag or strip its formatting.

1	body,
2	.wrapper {
3	font-family: 'Roboto', sans-serif;
4	}

Then, to prevent Outlook 2007–2016 on Windows from displaying Times New Roman—as it tends to do when faced with an unknown font-face—I set up some conditional Outlook-only code in the <head> of the template:

<!--[if mso]>
<style type="text/css">
 table, div {font-family: sans-serif !important;}
</style>
<![endif]-->

This ensures every instance of the webfont is overriden in Outlook with a sans-serif. I apply it to tables and divs, the only two elements that are used to contain content in the template. It’s not necessary to go to a lower level than this, as all other tags will inherit this in Outlook.

Getting the Layouts Looking Fine

Next it was onto structural coding. I started with the first module that I had sketched out: the masthead. One challenge here was the logo, because for some of the templates it looks slightly different on mobile:

To achieve this, on mobile I hid the main logo and the text at the top. I hid the logo too, and added the tiny leaf as a background image to the masthead.

.logo img {
  display: none !important;
}
.logo {
  background-image: url(images/leaf@2x.png);
  height: 17px;
  background-position: center center;
  background-size: 15px 17px;
  background-repeat: no-repeat;
}

Shifting Elements

The next section I tackled was the “hero” article in the Digest emails; the first tricky part here being the labels. In the designs they appeared next to the heading text on desktop, but above the text on mobile. To achieve this in code we can use some display properties to make them shift around.

First, I created the heading tag with the content inside split into two spans, one for the text and one for the label.

1	<h2><span class="text">Using Curves in Adobe Photoshop</span> <span class="label">FEATURED COURSE</span></h2>

Styling-wise, the .text span inherits the h2 styling, and then the .label span is styled separately to make it smaller and give it a coloured background:

.label {
  display: inline-block;
  margin-left: 5px;
  padding: 3px 8px;
  vertical-align: 4px;
  border-radius: 3px;
  -webkit-border-radius: 3px;
  color: #ffffff;
  font-size: 8px;
  line-height: 10px;
  font-style: normal;
  letter-spacing: 0.1em;
}

Then, using media queries, we swap the elements around on smaller viewports:

@media screen and (max-width: 700px) {
  h2 {
    display: table !important;
  }
  h2 .text {
    display: table-footer-group !important;
  }
  h2 .label {
    margin-bottom: 12px !important;
  }
}

The h2 is our container, and we set it to display as a table so that we can tell the .text span to act like the footer group of that table and move to the very bottom of the layout. The .label span then displays at the top, and we add a margin underneath it to give it some breathing room.

Unsurprisingly, Outlook on Windows (2007–2016) didn’t want to display the labels properly, since it doesn’t respect border-radius, nor does it like adding padding to inline elements. The results really weren’t good, so I set up some alternate styling for Outlook that I placed in conditional code in the of the template:

<!--[if mso]>
<style type="text/css">
 /* Outlook fix for featured course labels */
 .label {background-color: #ffffff !important; vertical-align: 2px !important; color: #c94e4b !important;}
</style>
<![endif]-->

This meant that in Outlook they would appear as simple coloured text:

Background Images

The Promotional template has a very distinctive feature: an edge-to-edge hero with a background image.

Credit to Marco Goran Romano for the brilliant image used as a placeholder

Background images in email aren’t supported everywhere. The main two email clients posing issues are Outlook 2007–2016 (Windows) and Gmail.

Outlook doesn’t display regular backgrounds at all, requiring some special Vector Markup Language to get them to work. (Stig at Campaign Monitor’s backgrounds.cm is a great tool for generating this code). The problem with it, however, is that you end up with two code blocks: one in HTML and one in VML. This is risky when you know that others need to be able to easily update the background image: if someone tries to do this without reading through the instructions properly, they would likely get it wrong.

Gmail does display background images, however it doesn’t respect the background-size or background-position properties, which can make styling them quite difficult.

We looked at the subscriber numbers and were able to make the call on Outlook: it would be fine if Outlook users saw a solid fallback colour instead of the image.

For Gmail users, we would need to set up some guidelines around acceptable images when the templates are used. The background should either be a seamless repeating background, or set up so that it would always look fine at 100%, pinned to the top-left corner.

Interestingly, Gmail does support vertical background-position properties on the left hand side: top left , bottom left and center left . Unfortunately you can’t position horizontally, which is usually what you want to do by making it display center center .

On some of the ad blocks, we were able to have background images in Gmail, because they are pinned to the bottom left. These blocks also reverted to a solid background colour in Outlook.

Navigating Negative Margins

I toyed around with two ways of getting the negative top-margin on the masthead to work, where the white box of content appears overlaid on the masthead itself.

In web development, you would add a negative margin-top to the content box, dust your hands and get on with your day.

In email development, however, this is not possible. Negative margins are only supported by a handful of email clients, leaving a lot of common ones in the dirt (like Gmail, Yahoo and Outlook.com).

That remained our first option however: use a negative top-margin as a progressive enhancement, which would display with a margin of 0 in all non-supported clients (seen below left). The downside is that quite a lot of clients would see this marginless version and the layout certainly lost something without it.

The other alternative was to fake the negative margin by creating a blank white table at the correct height and width. The downside to this approach is that the Gmail app often shows tiny hairlines when scaling down content on mobile where there is lighter content over a dark background or vice versa. These aren’t actually real lines or borders, just minuscule glitches that cannot be fixed with code. We decided to go with this scenario, because it benefited the greatest number of readers, and the hairlines were generally imperceptible. We also decided to keep an eye on the issue and revisit it if we weren’t happy with the results. (Unfortunately these templates could not be built using the fluid-hybrid method because both MailChimp and Campaign Monitor pose big problems with doing so.)

Overlap, with Gmail’s tiny line between sections

Preparing for Different Platforms

I knew I would be handing the templates over to Ian for integration with multiple Email Sending Platforms: MailChimp and Campaign Monitor. Since my code had to work well with both template languages, I followed a few tips to make this process as smooth as possible.

Editor’s Note: since the design and development phase we’ve actually moved on from MailChimp, instead using only Campaign Monitor. That said, the following tips are very useful!

Style at the Highest Level Possible

For example with text styling, I applied it all to the <table> , not any of its children, so that if cells or paragraphs were converted to editable areas there was no risk of losing any styling anywhere. Table contents inherit their text styling from the parent across all email clients. The only exception is AOL mail, which often fails to inherit the color property unless you place that on the individual cell.

Use Paragraphs For Text

Campaign Monitor templates require a multiline element to be defined when you want an editable block of text that allows for line-breaking, bold/italic/underline, linked selected text, and so on. It also automatically wraps all the text inside the multiline with a p tag, which can really break your layout if you haven’t allowed for paragraphs. When you use a line break in Campaign Monitor, it will end the current paragraph and start a new one. MailChimp doesn’t do this, and when you create a line break it simply adds a <br/> tag. But it has no problem with paragraphs and will respect any paragraph styling that you have set up, so it’s safe to use them for Campaign Monitor’s sake, with no nasty side-effects in MailChimp.

Make Variants User-Selectable

One of the templates needed to have a set of the different coloured headings for each topic that could be chosen when creating a newsletter in MailChimp. I set up a batch of heading styles that could be selected from a dropdown in MailChimp, using the correct syntax for defining their @style blocks:

/**
* @style topic-design
*/
.topic-design {
  color: #c94e4b;
}
.topic-design a {
  color: #c94e4b;
}
/**
* @style topic-code
*/
.topic-code {
  color: #4cc1be;
}
.topic-code a {
  color: #4cc1be;
}
/**
* @style topic-web
*/
.topic-web {
  color: #49b293;
}
.topic-web a {
  color: #49b293;
}
/**
* @style topic-photography
*/
.topic-photography {
  color: #8360a8;
}
.topic-photography a {
  color: #8360a8;
}
/**
* @style topic-game
*/
.topic-game {
  color: #72BF40;
}
.topic-game a {
  color: #72BF40;
}
/**
* @style topic-computer
*/
.topic-computer {
  color: #5d7dba;
}
.topic-computer a {
  color: #5d7dba;
}
/**
* @style topic-business
*/
.topic-business {
  color: #f38844;
}
.topic-business a {
  color: #f38844;
}
/**
* @style topic-3d
*/
.topic-3d {
  color: #f95858;
}
.topic-3d a {
  color: #f95858;
}
/**
* @style topic-music
*/
.topic-music {
  color: #56a4ca;
}
.topic-music a {
  color: #56a4ca;
}

But… I supplied this to Ian who discovered that it didn’t work at all; none of these heading styles were showing up in the dropdown when he edited the text. He tinkered with it and discovered that MailChimp doesn’t actually show these options as selectable heading styles unless they have some kind of font-related property like font-family or font-weight .

It also didn’t work because I supplied it separately, and any special MailChimp template code for editable areas or custom styles must appear in the <head> of your template; it cannot be an external file. So, we added a font-weight: bold declaration to our heading styles, popped the CSS in the head, and got it all working.

Final Testing and Wrapping Up

Now that all our layouts had been viewed and approved, problems sorted and compromises decided on, it was time to finish testing and prepare all the files for deployment.

I set about doing plenty of gruelling final tests in Litmus and Email on Acid. I use Trello to keep track of requirements, tasks and bugs for each project I’m working on. I worked through my lists of bugs and tasks until there was nothing left and the files were ready to deploy.

Setting up a Kit of Templates

The Envato team wanted to be able to dive into the code to mix and match different layouts, so I needed to provide clear HTML and CSS comments, as well as ensure that transferring modules between templates wouldn’t cause major catastrophe.

I set up each template with its own body class:

1	<body class="var-admin">
2	<body class="var-digest">
3	<body class="var-newsletter">
4	<body class="var-promotional">

And then set up a class that could be added to easily switch between a white and grey background:

1	<body class="var-admin grey-background">

I also separated out layout-specific styles (both mobile and desktop) into individual stylesheets to save on file size:

1	<link rel="stylesheet" type="text/css" href="css/var-admin.css" />
2	<link rel="stylesheet" type="text/css" href="css/var-digest.css" />
3	<link rel="stylesheet" type="text/css" href="css/var-newsletter.css" />
4	<link rel="stylesheet" type="text/css" href="css/var-promotional.css" />

I gave instructions to add a link to each stylesheet where elements from that layout were being used. For example, if a Digest module is being ported to the Newsletter template, the Digest CSS link should be added to the head of the Newsletter template before copying over the module HTML.

For common elements, like the ad bar and ad blocks, I made sure the styling was completely independent of layout, so that they could be moved around freely.

I included all these instructions in a README file, and zipped it up with all the HTML and images to be sent.

Shipping

And then we were done! I shipped everything across to Ian who undertook the remainder of the integration himself. It’s somewhat nail-biting to hand over template files without the ability to obsessively test and re-test during integration, but I had the utmost faith in Ian, of course!

Once his work was finished and it was time to start sending, Ian sent test copies to my Litmus and Email on Acid accounts so that I could go through the rendering previews and flag any issues. A couple of background images dropped off here and there, which we fixed up before the templates were finally ready to be sent.

In the next and final part of this series, we’ll take our static templates to the next level, showing how we integrated them into Campaign Monitor!