Email Procedures
- Approach
- Getting started
- Helpful pointers
- Some Important Pointers
- Testing
- Before launching campaign
- Troubleshooting
- Designs from third parties
Approach
There are almost always issues with Outlook. Design creatively to avoid tricky implementation but always put the content first.
For responsive emails the design should try to keep the total number of columns to one. Multiple columns rarely work in the Gmail mobile app and are troublesome to make backwards compatible in Outlook. The process of making an email responsive should be achieved by making it more legible through increasing font sizes etc on smaller devices.
For greatest compatibility, email builds should use a tables approach.
Use tags including table
, td
, tr
etc to construct an email build.
Styling an email build should be done with inline style=""
attributes to
ensure that email clients inherit exactly the rules we want.
Do NOT use the class=""
properties unless for responsive design.
As mentioned, we have a library of historic email builds within our repository. This contains email builds created within the last few years or so, in almost all templates you will find:
1. Body attributes
<body leftmargin="0" topmargin="0" marginwidth="0" marginheight="0">
These attributes in the body tag are technically not valid according to W3C but has proved an important addition to all builds within our testing. This essentially sets the margins to zero.
2. Reset styles for the body tag
body {
width:100% !important;
-webkit-text-size-adjust: none;
-ms-text-size-adjust: none;
mso-margin-top-alt: 0px;
mso-margin-bottom-alt: 0px;
mso-padding-alt: 0px 0px 0px 0px;
}
This piece of CSS overrides many issues with Outlook around text size, margin and padding.
3. Set an appropriate viewport tag
<meta name="viewport" content="width=device-width; initial-scale=1.0;" />
Add the viewport tag for greater mobile compatibility. This has been proven to help force the exact width necessary for mobile devices. Appears to be especially important with responsive email templates.
4. 120dpi screens
<!--[if gte mso 9]><xml>
<o:OfficeDocumentSettings>
<o:AllowPNG/>
<o:PixelsPerInch>96</o:PixelsPerInch>
</o:OfficeDocumentSettings>
</xml><![endif]-->
Having this piece of code before the closing head tag will help with common issues in Outlook when screen resolution is 120dpi.
Getting started:
The following questions should be asked before starting the email template:
- Does this email template need to be editable? For example, will the client need to edit it within Mailchimp or other similar platforms?
- Similarly, will this email template be used in a platform (such as Mailchimp or Campaign Monitor) or delivered via a website?
- If built for a specific platform, are special tags such as
<unsubscribe>Unsubscribe here</unsubscribe>
required? - Should the email be responsive i.e. should font sizes increase on devices? Should columns fall underneath?
- Make sure you have links ahead of the email build
- Ensure you have a PDF and JPG/PNG from the client (if design being supplied) or colleague. We do this because clients often use software such as InDesign to design their email templates and we need to ensure the colour and dimensions are correct. In addition, we may want to crop out images from the JPG/PNG if the quality is better there
During the build:
To compare an email build against the design, you can use the Pixel Perfect Chrome extension to overlay the design. This allows us to get everything as close as possible. This is typically only useful for the desktop view.
From a code point of view, the following is not a comprehensive list but should all be considered when constructing an email build:
Content pointers
- Google web fonts can be used using this technique, a web safe font should be used as a fallback
- Copy and paste text from the supplied document whether PDF or Affinity - do not write text out manually unless completely necessary. For example, if Affinity is copying over uppercase text, this should be mixedcase and we should use CSS to make uppercase if that is what the design required. Lots of uppercase text in email can be a marker for a spammy email
Code pointers
- Always use
display:block;border:none;
on images, there might be scenarios where you have to usedisplay:inline-block
but this is rare - Capitalise hex references - some older email clients display colours inconsistently if not capitalised
Structural specific pointers
- Keep code clean and regularly comment - tables get messy very quickly and comments will help with any amendments needed by you or other members of the team
- Avoid
colspan
androwspan
- use nested tables instead - Do not use padding and margin style attributes - use spacer images instead
- Recommended width should be approximately 600px wide, very max 650px. Have noticed the extra width on Yahoo mail requires horizontal scrolling
Image pointers
- Use CSS on images tags so if an email client doesn’t immediately show images there is a visual alternative
- Compress all images using compression tools such as Tiny PNG and Tiny JPG
- If image file sizes are small in size, consider exporting them out at double resolution thus to appear sharp on retina devices
- Background images can be used and also used in Outlook with this fallback
- Avoid transparent PNGs whenever possible, causes some odd rendering issues in iOS and Gmail apps
Some Important Pointers
Height - TOP or BOTTOM
Height spacer should use the below syntax and not spacer.gif - some Outlook versions will double the height of a spacer gif so this works as a good alternative...
<tr>
<td style="mso-line-height-rule:exactly;line-height:25px;font-size:25px;"> </td>
</tr>
Width - LEFT or RIGHT
Width spacing should follow using the img tag images/spacer.gif
, always make
sure to specify the width on the column and the image and always just give a
height of 1.
<td width="36">
<img src="images/spacer.gif" style="border:0;display:block;" alt="" width="36" height="1">
</td>
Custom Fonts
If a custom font is used that is not a system font, do make sure to import the font through the import link within the template i.e.
<style>
@import url("https://use.typekit.net/{hased_string_here}.css");
</style>
However, if you find there are issues with Outlook on iOS then you may want to implement using <link>
:
<link href="https://fonts.googleapis.com/css?family=Libre+Baskerville:400&display=swap" rel="stylesheet" type="text/css">
As a side note, do make sure that the client is happy with the default font if for some reason typekit is done and cannot load in the custom font i.e.
body {
/* ... */
font-family: brandon-grotesque, Calibri, sans-serif;
/* ... */
}
Pre-Headers
Having a hidden span at the start of the email will display some teaser text in email previews in Gmail etc https://www.campaignmonitor.com/blog/email-marketing/2011/12/a-practical-guide-to-email-preheaders/ - this is NOT relevant for all projects...
<body bgcolor="#FFFFFF" leftmargin="0" topmargin="0" marginwidth="0" marginheight="0">
<!-- HIDDEN PRE-HEADER TEXT -->
<div style="display: none; font-size: 1px; color: #FFFFFF; line-height: 1px; max-height: 0px; max-width: 0px; opacity: 0; overflow: hidden;">
<!-- Content goes here... -->
</div>
<!-- EO HIDDEN PRE-HEADER TEXT -->
<!-- Rest of email template here... -->
Testing
It is vital that email builds are thoroughly tested. Once they are sent, there is no going back! We use our Email on Acid account which typically gives us 90+ email clients to test with. You may use this account to test as you go. If this is a bespoke email build, it is recommended to test the email build in chunks (perhaps blocks at a time) as a bug might might appear mid-build and finding it earlier will cause fewer headaches.
Code tests to run
- Regularly check HTML to ensure code is W3C valid using W3C validator
- We temporarily rename the images folder to check for two areas:
- To always make sure all alt tags are complete (except for spacer.gif) and that they are relevant to the current image
- Use CSS on images (as mentioned above) so that there's a visual clue that an image needs to load
- Are platform specific tags in the template such as
<unsubscribe>Unsubscribe here</subscribe>
(this may appear differently depending on the email platform being used) - Ensure the final product is pushed to the repository for future reference
Using Email on Acid, please check for the following
Regardless of whether or not this is a code build, drag and drop or a simple template, please do test with Email on Acid. Other than anything that appears to be broken, also look out for:
- Check for invisible characters - in 2019 we spotted these characters appearing. They often come from Affinity or straight from a PDF. If you can't see them, you'll likely see them in Gmail in Email on Acid or on a PC when viewing the email build in Chrome or other browsers. These need removing by using arrow keys and when the cursor doesn't move, you can delete the character.
When you are almost finished, run the following spam tests
Content checks to make
- Are all illustration images .pngs
- Does the email have preheader text?
- Have all assets been compressed?
- Have all links been tested and go to the appropriate place?
- Do the (where necessary) unsubscribe, preferences and view email online links work?
- Have all alt attributes been populated with the appropriate text? Spacer images shouldn’t have any alt text
- Check
mailto:
links within the email and ensure that the email and subject lines are correct use URL encoding for spaces and special characters - Check
tel:
links so that phone numbers have no spaces or brackets - Proof or have the emailer proofed by someone else
- Do we have licenses for stock photos?
- Do all merge tags work?
When sending campaign
- Have credits been purchased?
- If using a segment, are we seeing the correct number of subscribers?
Troubleshooting
- If you are seeing an image rendering as a different colour in iOS, the chances are this is down to compression on the PNG or a scenario where a PNG has been compressed more than once
Designs from third parties
- Please think about mobile experience
- At a minimum, font sizes can increase for headings and body text for mobile users
- A mobile-first approach might be to keep everything in one column - it is possible to have two columns for desktop which would collapse a single column but that comes with added complication and possible incompatibilities with older email clients
- More than two columns would be unmanageable and unpredictable
- Container should be a maximum of 600px wide
- Font sizes should be a minimum of 12px
- When providing a design handover, please try and include (where possible)
- Links
- Alt text
- Google or Adobe font (if applicable)
- Preferred fallback font family for those email clients that don't support
- You may use CSS Font Stack to best determine an appropriate alternative
- Appropriate merge tags
- Supply pre-header text - see explanation within this section
- Assets to be supplied at double the resolution of that in the design
- Note: SVG is not support in email
- For other formats, feel free to refer to this guide