Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2

This article is aimed at people with some knowledge of working with HTML, CSS and email templates.

As more and more of us open our emails on mobile devices, a question we are increasingly asked is “How do I make my email look better on mobile?”.

The easy answer is to use one of our in-built templates. You can load these in and modify them to make them match your brand.

However, if you have developed your own or inherited one, then read on…

Why mobiles are difficult to work with

There are plenty of things that can go wrong in an email when viewing on mobile: squashed text, giant images or sometimes total template collapse.

Unfortunately, whereas you can often make an existing landing page more mobile-friendly, for broadcast emails we don’t have as many options open to us.

  1. Many mobile email clients ignore CSS rules. So we can’t just add a few rules to manipulate columns and rearrange content
  2. Javascript will most likely not run
  3. Email templates still need to be built around HTML tables (<table>, <tr>, <td> and so on). These are more rigid and difficult to work with than the div elements we prefer to use on web pages, but are required since some clients, such as desktop Outlook, do not display them properly
  4. Email clients vary far more greatly in the way they interpret HTML than their browser counterparts
  5. How mobile-friendly an email template is is rooted in the structure. Widths, column spans and other elements that are difficult to modify later without running the risk of breaking the whole thing are the main tools for mobile optimization.

A basic structure

To cater for desktop email clients, we usually suggest a basic width of around 600px. Although many screens are wider, if you stick to this then you can build the rest of the email template based on that width without having to worry about it expanding too much.

We don’t have that luxury in the other direction: we need to make sure the email can get squashed onto a mobile screen and still look OK. First we need to get a solid structure in place. For instance something like this:

 

The outer table will stretch to the maximum width allowed by the email client. The align=”center” attribute on the table cell will center the email, so if there is any extra space available then it will be even on either side. Then, within that table cell, is another table which contains our actual email content. The really important parts are:

 

“width” of 100% means that the table (and therefore the email) will scale with the available space. So on mobiles and tablets, the email will automatically shrink to the available space. This wouldn’t happen if we used a static width e.g. “width: 600px;”

“max-width” lets us limit that scaling so the email won’t get wider than 600px (so it will be consistent on desktop) – but does not stop it adapting to screens where there is less space than that.

Using percentage widths in this way, we fit our email to the device it is being viewed on without using CSS media queries such as this:

 

You could use those to change the email when a certain width is detected, and for a whole range of tasks they do make life easier. However, as mentioned, gmail for android at least doesn’t currently support CSS rules like this, so we tend to avoid them.

Columns

Using percentage widths in this way means that we can’t be sure of a particular email width to work from. So the rest of our HTML structure needs to account for that.

This isn’t much of an issue if you are using a single column layout. In fact, single column layouts are considerably more mobile friendly in general. Some studies suggest that simpler email designs actually perform better than their more complex counterparts. So since they are also generally easier to update, maintain and make consistent across the many email clients, this may be something to consider.

If you do want to stick with your multi-column layout, then the column widths need to scale proportionally too. Within a table setup as above, we could have a header row….

 

…and a main body, consisting of two columns of content:

 

The header row contains one cell which will automatically fill the full table (which is 600px or under as we saw). But the second row has three cells. A left column, a spacer column, and a right column. Rather than setting fixed widths, I’ve split my 100% out between them. 33% for the left, 2% for the space and 65% for the right.

So when the device width is lower than 600px, the width of the email adjusts. When the width of the email adjusts, the width of the columns adjust too while keeping their proportions.

This is an example with two “real” columns, i.e. columns that contain content as the space doesn’t count. There’s no reason you couldn’t do the same for three columns, but bear in mind that on a mobile space is at a premium. You don’t want to end up with
one
word
per
line.

Outlook

The email client that really has a problem with this method is Microsoft Outlook. Even 2010 and 2007 don’t support the “max-width” attribute, and that’s the basis of our entire structure. All we can do is resort to using “width” instead. However, we only want it to apply to Outlook. To do this, we can use this trick and add an extra table to our HTML. We start with our standard content table as above….

 

…and we put extra table HTML within it. However, we wrap the extra HTML in a conditional statement that means it will be ignored by all email clients except Outlook…..

 

Then all we have to do is put a style in the header of the email to set the width of our Outlook-only table (again wrapped in conditional statements).

 

Images

Images in email can also be difficult.  A banner image that is 600px wide is fine on desktop, but on mobile half of it could easily be hidden off-screen. Similarly, if you have some text beside an image, unless the image scales with the screen size you might find your text pushed off to the side. This looks messy and forces people to scroll.

My preferred option for dealing with this is to employ the same technique as above. Here’s a sample of a header row that could contain a banner image:

 

Again, let’s look at the styles applied to the image there:

 

The width will actually scale the image to the size of the table cell it is in. In this case, it would be 100% of the width of the email. If you put it in a column with a width of 50%, for example, then the image would only scale to that size. We have to put in the “height:auto;” to make sure the height stays proportional to the width.

Note The full image will still be downloaded. The scaling happens afterwards. So if you use a 1000px x 500px image and it gets scaled down to 100px x 50px in this way, the supporter’s email client will still have to download the massive image file first. Large files in emails are to be avoided anyway where possible, but when we take mobile into account this is even more important as mobile internet connections are (for now) slower and less stable.

This does mean that your images will all need to be in table cells, even if they are to be wrapped with text. This is good practice anyway. Some desktop email clients (e.g. Outlook again) ignore the standard ways of doing this, such as float.

Content

On a more general note, the upshot of having scaling column widths is that your text will be squeezed a little on mobiles. This is fine, but it does make the whole email longer. If the available width for a block of text is halved, the length will double. For text-heavy emails viewed on a small screen that could result in a lot of scrolling. You could either cut down the text or switch to fewer columns so you have more width.

So that’s it?

Probably not, but it is a start. The simpler your email template is the easier it’s going to be to mobile optimize, as well as edit and maintain. We’ll be adding to this document as and when we can. If you have any questions, corrections or suggestions you can get in touch at [email protected].

Example:

 
  • No labels