How To Make Email Template Responsive

31 minute read fourth dimension

Creating Responsive Electronic mail Design: Email Coding and Optimization Techniques

Introduction

Increased screen sizes and resolutions mean more than opportunities for improving your responsive email design. This guide has been updated to aid you design and code for today's (and tomorrow's) devices.

If you read your email regularly using a phone, yous probably know that it's an experience ranging from crawly to awful. While an electronic mail newsletter can look superb in a PC inbox, it can become absolutely unusable when squeezed onto a pocket-sized screen with small-scale fonts, narrow columns, and cleaved layouts being common issues.

This guide will look at why designing for mobile has go a necessary skill for email designers. It'll cover the fundamentals of designing and building a mobile-friendly email, backed up with upwards-to-engagement tips and techniques.

Chapter 1

Why optimize your email for mobile?

If you ship e-mail newsletters, it'south likely that a growing percent of your subscribers are reading your messages on an iPhone, tablet, or other mobile device.  According to a recent survey released by Litmus, mobile has get the most popular, with 42% of all emails existence read on a mobile device, followed closely past webmail at 40%, and desktop with a respectable 18%. Apple's iPhone accounts for 28%, plus an additional 9% if y'all include iPads.

What this means for designers and electronic mail developers is that getting your electronic mail newsletter to display optimally on mobile devices is but every bit important as viewability on more traditional platforms similar Outlook and Gmail. In fact, when designing your emails, yous should start with a mobile pattern, considering if it looks good in a mobile view, it's going to expect great on desktop. Failing to think mobile-first could diminish response rates, or equally Render Path summarized:

…those that aren't tracking which device their subscribers are reading their emails on, or optimizing their emails or websites for mobile devices stand to lose out. A poor user experience could mean no response, no action, or obviously put, no ROI.
'Email in Motion: How Mobile is Leading the Email Revolution' – Return Path

At that place are not only ways you can ameliorate the mobile electronic mail feel—like the utilize of media queries when coding upwardly responsive layouts, to more than advanced techniques like targeting specific devices. Merely at that place are too design considerations when planning your newsletter and subscribe forms for smartphone users.

Commencement: Which mobile devices should exist considered?

Which mobile devices can you design for?

A quick caveat: The techniques listed here aren't universally supported by all mobile email clients. As yous may know, not all electronic mail clients were made equal—even on the same device, how an HTML electronic mail displays tin can vary radically from inbox to inbox.

Thankfully, the iPhone and other Apple tree iOS devices can non only boast of near trouble-free email rendering, but too account for a large percentage of mobile email opens, too. However, with the latest release of iOS thirteen, Apple'due south night manner will pose new design and coding challenges to overcome and then e'er think to test your emails.

With this in mind, we nowadays to you a non-exhaustive listing of mobile email clients and their support for media queries. For context, media query back up enables you to employ many of the responsive techniques that we'll be covering in this guide.

Default device email clients

Client	Media query support
Amazon Kindle Fire	Yes
Amazon Kindle Fire Hd	Yes
Android 2.one Eclair	No
Android 4.x native client	Yes
Apple tree iOS	Yes
Gmail App for Android	Yes
Gmail App for iOS	Yes
Yahoo Android and iOS	Yes
Outlook Android and iOS	Yeah
Gmail Android IMAP	No
Microsoft Windows Phone 7.5	Yes
Microsoft Windows Phone eight	No
Microsoft Surface	No
Windows Mail	Yes
Samsung Email 6x	No

tertiary-political party email clients

Client	Media Query Support
Microsoft Outlook Exchange third-party app (Android)	No
Gmail mobile app (all platforms) There are limitations: see supported CSS backdrop	Aye
Yahoo! Mail mobile app (all platforms)	No

Chapter 2

Design techniques for mobile optimization

Let's embrace the visual side of creating a mobile-optimized email newsletter and swoop deep into coding. This will not merely help you lot make informed design decisions when designing your email newsletter, but information technology volition make it that much easier to anticipate the techniques nosotros'll be discussing later on.

We've already started talking about responsive electronic mail design. If you're familiar with the employ of this term in the context of web design, then you'll be pleased to know that we'll be using the same concepts and techniques here for email. If things similar adaptive layouts are new to you lot, I highly recommend reading this primer by A List Apart.

For this guide, we'll exist designing two CSS layouts of the aforementioned newsletter: one layout that looks great in webmail and desktop clients, and another layout that can exist easily read on the smaller mobile device screens.

For example, here's an HTML email in Outlook:

Beneath is the same email, only this time viewed in Apple tree'southward iPhone Mail service. Equally yous tin run across, at that place are meaning differences between the two layouts. The mobile version is skinnier, lacks visual ataxia, and is just every bit readable as the desktop version. This tin exist attributed to the employ of mobile-specific CSS:

As a signal of comparison, the correct image is the same email, without this stylesheet. See how tiny and unreadable the text is? This is the trouble that faces millions of email newsletters received on mobile devices every twenty-four hour period.

Mobile-friendly layouts and pattern elements

Designing for mobile isn't but a matter of taking a crack at writing mobile-specific CSS. Here are another considerations:

• Single-column layouts that are no wider than 600 to 640 pixels work best on mobile devices. They're easier to read, and if they fall autonomously, they'll do so more gracefully.
• Links and buttons should have a minimum target area of 44 × 44 pixels, as per Apple tree guidelines. Null is more than unusable than clouds of tiny links on touchscreen devices.
• The minimum font size displayed on iPhones is 13 pixels. Keep this in mind when styling text, because anything smaller will be upscaled and could interruption your layout. Alternately, you tin can override this behavior in your style sheet—practise then with intendance.
• Remember to proceed your bulletin concise, and place all important blueprint elements in the upper portion of the email if possible. Nonetheless, since screen sizes have go larger and at that place's more real estate than ever before, it'due south recommended that y'all explore and test various formats (east.one thousand. long-form content vs. short-course content). Always continue your brand in mind. What might work for one brand may not work for yours.
• When appropriate, y'all tin use mobilehide{ brandish: none !of import;} to hibernate content in your mobile layout. Utilize caution when hiding content in mobile. Ask yourself, if your content is non worth showing in mobile, should it be included in your desktop version? If y'all discover your blueprint uses this class on several elements, y'all may want to reconsider your design and content.

When mocking up an HTML email or template, our advice is to create three sketches or wireframes: one of the desktop and webmail layout, i for the tablet layout, and one for a mobile layout. Building these three layouts will allow you to see how your content volition intermission on diverse devices, and information technology volition help decide what media queries yous'll demand.

Chapter 3

Coding mobile emails

When web designers or developers talk about stylesheets or CSS (Cascading Way Sheets), they're unremarkably referring to an external stylesheet. And while that works for websites it's not the best for email.

Several major email clients block external stylesheets we included our CSS in 2 ways:

• Embedded styles located in the <head> of an electronic mail contained in a manner tag
• Inline styles included in the torso of your electronic mail

When coding a mobile-responsive e-mail, you'll demand both, as some clients will remove the embedded CSS in the <head> of your HTML document, so the inline style ensures your emails expect perfect no matter what device your subscriber is using.

Here'southward what a basic stylesheet using both embedded and inline styles looks similar:

                Embedded styles <head> <style blazon="text/css"> 	/* regular CSS styles go here */  @media merely screen and (max-device-width: 640px) { 		/* tablet-larger phone CSS styles get here */ 	}  @media only screen and (max-device-width: 479px) { 		/* smaller-mobile-specific CSS styles go here */ </style> </head>  Inline styles <table width="640" border="0" cellpadding="0" cellspacing="0">     <tr>     <td>     <tabular array width="320" border="0" cellspacing="0" cellpadding="20" align="left" >     <tr>     <td width="320" manner="font-family unit: Helvetica, Arial, 'sans-serif'; font-size: 33px; color:#1B1B1B; padding-left: 30px; padding-right: 30px; font-weight: 500; line-elevation: 40px; letter of the alphabet-spacing:.5px; width: 600px;">Content Example</td>     </tr>     </tabular array>              

Embedded styles are what help you create mobile-responsive layouts. In the example above, an @media declaration is made following mobile-specific CSS styles.

Let's examine what this declaration does: @media only screen specifies that the e-mail has to be displayed on a screen, and the second part, max-device-width states the device'south viewport requirements.

The examples in a higher place states that the viewport can have a maximum width of 640px and 479px, so the styles post-obit are implemented into your email, adjusting everything from prototype and text sizes to the overall layout of your email. Including two breakpoints can help yous tweak diverse elements in your e-mail to accommodate larger mobile displays, such as those on tablet devices.

Inline styles are the safety internet of CSS, as many email clients will strip away <style> tags from the <head> of your html email. With inline styles, yous can use various backdrop such as setting the width, font size and weight, or font family. In the above instance, nosotros identified the table widths and created a style= in the <td> that declares the font, padding, and color properties.

For a more exhaustive list of what will work in your mobile-friendly email templates, I recommend visiting caniemail.com or you can apply our CSS inliner tool that will take the hard work out of inlining all your styles.

At present, it's time to revisit our earlier example of an email layout that's been 'narrowed down' and stacked for a mobile display. Here's the design in iPhone Xs:

In this case, we've practical the tablescale class to HTML tables containing the text and images. Below is a snippet of code that contains ii @media queries, creating two breakpoints for mobile devices:

                <style blazon="text/css"> /* regular CSS styles go here */ @media only screen and (max-width: 640px) {  /* mobile-specific CSS styles go here */    .tablescale { width: 440px !important; margin: 0 !important; }  } @media just screen and (max-width: 479px) { /* mobile-specific CSS styles go hither */ .tablescale { width: 100% !important; margin: 0 !important; } </style>                              

The tablescale form does something actually interesting here. When the email is viewed on a device with a screen width of 640px or wider, it has no effect. However, when the screen width is 640px or less, it narrows down the table widths to 440px. This same action is taken at the second breakpoint at 479px, giving the table a width of 100%.

We've also added !important; to the mobile-specific styles to ensure they take precedence. But otherwise, it's run-of-the-mill CSS.

Y'all could as well feature other declarations, like:

                <way type="text/css">  @media only screen and (max-device-width: 640px) { /* mobile-specific CSS styles go here */ .tablescale { width: 440px !important; margin: } .imgscale { width: 100% !important;  } }  @media simply screen and (max-device-width: 479px) { /* mobile-specific CSS styles go here */ .tablescale { width: 325px !important; margin: 0 !important; } .imgscale { width: 100% !important; height: auto !of import; 	margin: auto !of import;   } } </style>              

Assuming that the examples in this guide have made sense so far, we're going to start looking at more advanced techniques for adapting your electronic mail for mobile devices.

Chapter 4

Building responsive layouts

While one-cavalcade HTML email layouts are generally the fashion to go when optimizing your newsletter for mobile devices, there'southward an elegant way to create responsive two-column layouts, without resorting to mile-long stylesheets in media queries.

While two-cavalcade layouts often allow more content to be featured above the fold on desktop email clients similar Outlook, they're a pain to read and navigate on mobile devices. Fortunately, this can exist fixed with a bit of coding.

One of the aureate rules of electronic mail pattern is 'where possible, use HTML attributes instead of CSS'. Whereas CSS back up can exist fairly flaky across the gamut of email clients, attributes tend to be rock solid. For example, attributes similar marshal="left" and cellpadding="x" are far more reliable than their approximate CSS equivalents, float: left; and padding: 10px;. Information technology'south exactly these attributes nosotros'll be using when edifice our 2-to-i column layout.

Let'southward await at such a layout in Outlook 2007:

In the instance to a higher place, nosotros have a 640px-wide container table, with two 300px-broad tables nested inside to grade columns, similar to our previous examples. These nested columns have cellpadding="10″ applied to end the content from pressing hard against the edges.

When coding for the web, we'd mostly apply float: left; to the left-hand column, to get them sitting side-by-side. Merely in email, instead we can employ align="left". As long as the container table width is more than or equal to the combined width of the ii columns, both volition fit nicely in this fashion.

Here's the simplified code for the two-column layout so far:

                <table width="640" border="0" cellpadding="0" cellspacing="0">     <tr>     <td>     <tabular array width="300" edge="0" cellspacing="0" cellpadding="x" align="left">     <tr>     <td>Column Left Content</td>     </tr>     </tabular array>     <table width="300" border="0" cellspacing="0" cellpadding="twenty" marshal="right">     <tr>     <td><img src="IMG_URL" width="280"></td>     </tr>     </tabular array>     </td>     </tr> </table>              

The rendered issue:

If the container table is 640px wide, you'll get a 2-cavalcade layout. But any skinnier than this and the right column will wrap nether the left column. Make information technology the same width as the cavalcade tables (320px) and yous've got a flush, one-column layout that fits an iPhone display exactly, with no zooming required.

Nosotros can attain this by adding a unproblematic, one-line media query to our HTML code:

                <mode type="text/css">     @media but screen and (max-device-width: 480px) {     .tablescale {     width:100% !important; Margin: 0 !important;     }     }     </style>      <table width="640" border="0" cellpadding="0" cellspacing="0" class="tablescale">              

The result is a responsive layout that displays 2 columns on desktop and web clients, then switches to ane column in iPhone Postal service and the default Android email client.

Adding Wikipedia-manner progressive disclosure

On the spider web, many responsive sites convert luxurious long-form content into items compressed for mobile devices. This is typically by using a technique referred to as progressive disclosure. This involves hiding content behind an interactive element like a button or link, then displaying it on click or tap.

Wikipedia uses progressive disclosure, as do a lot of mobile applications. We tin can besides apply it in mobile email.

Let's say we take an email newsletter with multiple manufactures. In desktop email clients, nosotros want a heading and text to display in each article, similar so:

Notwithstanding on mobile clients, we only want the heading to display, aslope a show/hide button (which toggles the text). This turns the email into an interactive table of contents, dramatically shortening the bulletin length:

To exercise this, we'll firstly need to turn to our HTML code and create an article with a heading, some text, and a show/hide push button. We'll too add a couple of classes to display the show/hide buttons exclusively on mobile devices. Hither'south a simplified version of the code used for each of the articles:

                <td>     <h4><a target="_blank" href="https://yourdomain.com" course="link">First heading</a></h4>     <a target="_blank" href="#" form="mobilehide">Hide</a> <a target="_blank" href="#" class="mobileshow">Show</a>     <div class="article">     <p form="bodytext">     <img src="https://yourdomain.com/kitten.jpg" style="float: left;" >Pellentesque habitant morbi...     </p>     <a target="_blank" href="https://yourdomain.com">Read more...</a>     </div>     </td>              

Take note the classes mobilehide, mobileshow and article—these will be treatment about of the action.

In our stylesheet, we'll hide the show/hide push when the email displays in desktop and web e-mail clients, by using brandish: none; in our stylesheet like so:

                .mobileshow a, .mobilehide a {     brandish: none !important;     }              

To ensure that the show/hide buttons are only displayed on mobile devices, we'll turn to our media query. Here's the code, including the earlier .mobileshow and .mobilehidesnippet and some webkit-friendly push button styling for good measure:

                @media only screen and (max-device-width: 480px) {     .mobileshow a, .mobilehide a {     brandish: block !of import;     color: #fff !of import;     background-color: #aaa;     border-radius: 20px;     padding: 0 8px;     text-ornament: none;     font-weight: bold;     font-family: "Helvetica Neue", Helvetica, sans-serif;     font-size: 11px;     position: absolute;     tiptop: 25px;     right: 10px;     text-align: center;     width: 40px;     }     .commodity {     brandish: none;     }     a.mobileshow:hover {     visibility: hidden;     }     .mobileshow:hover + .commodity, .article:hover {     display: inline !important;     }     }              

And, if things go well, the result is an electronic mail with testify/hide buttons that toggle content on the iPhone. If you lot would like to try applying this technique to your ain email campaigns, experience free to view the sample code on Github and adapt it for your own campaigns. Warm thank you to Eric Gideon for his contribution to this project.

Outlook and the 120 DPI issue

When talking near responsive design, information technology'due south instinctual to only think about mobile phones or tablets—but it's and so much more.

Outlook continues to exist widely used amidst many businesses, and thus should not exist ignored when thinking about your responsive e-mail design. So allow'southward breakdown the 120 DPI issue and how we can code around information technology.

DPI stands for dots per inch and is a unit of measurement for screen resolutions. Standard resolution is typically set to 96 DPI. However, with newer, higher-DPI displays, this resolution is scaled to 120 DPI.

When the DPI is scaled to 120, information technology will affect your text size and images, while your containers maintain their original widths, thus breaking your email. Here'due south an example without 120 DPI scaling:

And hither's that same example with 120 DPI scaling:

This trouble occurs when Microsoft Give-and-take is used to return an email, and is nearly common in Outlook 2007 through 2013 versions. This scaling consequence continues to be a thorn in the side of many email developers and designers equally this zoomed view frequently stretches your images, enlarges your text, and creates an overall poor user feel.

Using our previous code examples, let's create a truly responsive template that works both in mobile and desktop.

The get-go step is to enable VML or Vector Markup Language, and scaled images in the <head> of your email.

                @media only screen and (max-device-width: 480px) {  /* outlook-mso specific styles*/ <!--[if mso]>     <way type="text/css">     torso, table, td {font-family unit: Arial, Helvetica, sans-serif !of import;}     </style> <![endif]-->  /* outlook scaled image solution */  <!--[if gte mso ix]>     <xml>         <o:OfficeDocumentSettings>         <o:AllowPNG/>         <o:PixelsPerInch>96</o:PixelsPerInch>         </o:OfficeDocumentSettings>     </xml> <![endif]-->              

The second step to fix this issue is to add inline styles to your <tables> and other tags such every bit the image tag, past re-identifying the width. A general rule of thumb, if yous declare the width as anything other than 100% in a tag you should re-place inside a way=.

Here's the code we created for our two-cavalcade layout with the added inline-styles.

                <table width="640" border="0" cellpadding="0" cellspacing="0" style="width: 640px;">     <tr>     <td>     <table width="300" border="0" cellspacing="0" cellpadding="ten" align="left" style="width: 300px;">     <tr>     <td width="300" align="left" way="width: 300px;">Column Left Content</td>     </tr>     </table>     <table width="300" border="0" cellspacing="0" cellpadding="20" align="right" style="width: 300px;">     <tr>     <td width="300" align="left" style="width: 300px;"><img src="IMG_URL" width="280" style="brandish: inline-block; width: 280px;"></td>     </tr>     </tabular array>     </td>     </tr>     </table>                              

Now that nosotros take that new code, hither'due south the same rendering higher up with 120 DPI, at present totally responsive with the new code additions:

The text and images are larger, just everything is now in proper alignment.

If you desire to learn more about Outlook scaling issues, check out Courtney Fantinato's commodity "Correcting Outlook DPI Scaling Bug."

Affiliate v

Targeting devices with media queries

Yous may have noticed that we've been using ii standard media queries in this guide: @media only screen and (max-device-width: 640px) { … } and @media only screen and (max-device-width: 479px) { … }. This is bang-up for targeting Apple iPhones and other handheld devices that brand up the majority of mobile email client share.

Simply if you or your clients desire to target tablets, larger-screen Android devices, and some of the more exotic screen resolutions in the mobile ecosystem, so you'll need both unique media queries and unique styles to match.

As you lot may know, media queries are not supported past every mobile e-mail client. For more information on which email clients do and don't support the techniques in this guide, view our support chart.

Fine-tuning your media queries

Let's get dorsum to the max-device-width: 479px dominion in our earlier media query. What this tells mobile email clients (and browsers) is that beneath the 479px threshold, a mobile-friendly layout defined therein should be displayed. Above that, CSS styles outside of the media query should exist used.

Just the dimensions you tin can design for tin exist even more specific than that. For example, only targeting displays that are 320px or more than in width, but smaller than, or equal to 480px. Here's an example:

                @media only screen and (min-device-width: 320px) and (max-device-width: 480px) { ... }              

What a lot of folks don't know is that media queries can be quite focused. Apart from designing around a range of widths and heights, you lot tin also design for screen orientations (e.m. portrait and mural) and pixel ratios (how the width of each pixel in an image compares to the width they're displayed at).

This provides the ability to target devices with obsessive precision. Create an iPad-specific. Target devices with retina displays. While the endeavour that goes into adding targeted styles may often outweigh the benefits, sometimes information technology takes simply a couple of lines of code to get an email newsletter looking border-to-edge perfect on both your phone and favorite tablet.

Our friend Andy Clarke created a wonderful boilerplate for targeting popular devices. It's a not bad starting point for designing and building email designs that aren't express to 2 views each side of 480px.

Being paranoid about Android

Despite the words stated in the previous department, in that location are those who are critical of focusing on creating layouts around fixed widths similar 480px, commonly known in the industry as 'breakpoints'. Every bit Marc Drummond argues:

"If you are using responsive web design techniques (and you probably should be!), then this means that using default media query device-width breakpoints is generally pointless."
— Marc Drummond, "Responsive web design default breakpoints are dead"

Marc acknowledges that there are plenty of breakpoints that exist outside of something like Andy Clarke's earlier average—particularly amongst Android devices. Besides, new mobile devices come out all the fourth dimension, so the media query you're using to target the top-of-the-line Android handset today may be redundant tomorrow.

Edifice fluid layouts with media queries

The proposed alternative is to pattern fluid layouts that gracefully conform to the width of the viewport.

Past using a simple media query that applies a percentage width to elements—instead of stock-still widths, like 320px—it's possible for your newsletters to feature content that has a standard desktop view, merely stretches and contracts to fit below a certain viewport width. As a outcome, the newsletter can display optimally in a diversity of settings, from larger preview planes to smaller phones like iPhone 7.

We accept a detailed web log mail that goes into the mechanics of fleshing out fluid layouts for HTML email, and the adjacent affiliate volition impact how fluid-width images can exist used effectively in your newsletters.

Finally, a give-and-take of advice: While information technology's very like shooting fish in a barrel to get fanatical about tailoring your responsive email design for specific devices, don't lose track of the big movie.

If 85% of your mobile-toting subscribers are viewing your email in 320px x 480px viewports, don't feel like you have to create a @media query for every device. Creating a fluid design that can calibration using a combination of percentages and defined pixel widths yous will be able to cover a big percent of your subscribers.

Chapter 6

Optimizing images for mobile

While phone screen sizes have been steadily increasing over the years forth with screen resolution, information technology can exist tempting to include more and more than images in your emails. But a word of caution: While images tin bring an extra wow cistron to your emails, images should always be thoughtfully added with accessibility and mobile load times peak of mind.

In this chapter, we'll look at some techniques that take advantage of supported CSS properties like background-paradigm. These techniques volition non simply allow you lot to brandish mobile-optimized images throughout your designs, simply ensure they look crisp at whatsoever width.

Using groundwork images for improve headers

Back up and the use of groundwork images have been on the rising in the last couple of years thank you in part to increased CSS support utilizing all the benefits that media queries can bring.

One benefit of the increased support is the ability to put live text on images. Some other benefit is being able to substitute images when an email entrada is viewed on a mobile device by hiding the original and letting the beautiful, mobile-friendly paradigm shine through.

Background images and live text

In the past, if you wanted to include text on an epitome, it was created as a single graphic. And if that paradigm didn't load, you were at the mercy of your alt text. Now, with greater support for background images, y'all can accept live text and buttons along with the beautiful images.

Permit's see how this is done.

Background images in Outlook: setting upwards a DOCTYPE

At the acme of your HTML email yous'll need to declare the DOCTYPE. Doing so informs the browser that this volition be an HTML document.

                <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">              

Next, we'll ready our HTML tag, declaring the linguistic communication as en, which will tell screen readers that this email is written in English language. If you're writing emails in other languages, W3Schools.com has created a list of ISO language codes.

The second half of this code will be a VML or Vector Markup Language announcement, so Microsoft Outlook volition allow us to create background images.

                <html xmlns="https://www.w3.org/1999/xhtml" lang="en" xml:lang="en" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:role">              

Next, we'll insert our 120 DPI scaling to target Outlook 2007-2013 and ensure our email scales correctly. This code is placed in the <caput> tag and outside of the <style> tag.

                <!--[if gte mso ix]><xml> <o:OfficeDocumentSettings> <o:AllowPNG/> <o:PixelsPerInch>96</o:PixelsPerInch> </o:OfficeDocumentSettings> </xml><![endif]-->              

The top of your email should look something similar this:

                <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="https://www.w3.org/1999/xhtml" lang="en" xml:lang="en" xmlns:five="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office">  <head>  <meta http-equiv="Content-Type" content="text/html; charset=utf-viii"> <!--[if !mso]><!--> <meta http-equiv="10-UA-Uniform" content="IE=border"> <!--<![endif]--> <meta name="viewport" content="width=device-width, initial-scale=ane.0"> <title>Email Sample</title> <manner type="text/css"> html { width: 100%; }  @media merely screen and (max-width: 600px) { /* Table styles go hither */ }  @media only screen and (max-width: 479px) { /* mobile styles go hither */ } </manner>  <!--[if gte mso 9]><xml> <o:OfficeDocumentSettings> <o:AllowPNG/> <o:PixelsPerInch>96</o:PixelsPerInch> </o:OfficeDocumentSettings> </xml><![endif]—>  </head>              

Next we'll set up the tables and background image.

Within the <td> is where we'll add a style and input our groundwork image, declaring the background-position, background-size, and width.

This code will give your email a solid base that volition render correctly in Gmail and Apple Post, including iPhone. But we're non washed notwithstanding, nosotros demand to make this background bulletproof for Outlook.

Background images in Outlook: bulletproof backgrounds

Entrada Monitor's Stig Morten Myre developed a popular technique to create these bulletproof backgrounds, and even created a handy background image builder. The additional VML, Microsoft'south Vector Markup Language, volition let our groundwork paradigm to render correctly in Outlook, specifically 2007-2019.

If your image is a simple repeated blueprint or isn't required to line upwardly in a particular way, and so employ the same url link for both your <td> and VML.

Nevertheless, if yous don't have a repeated pattern background, it's recommended to have two versions of your paradigm. The showtime epitome that'due south linked in your <td> should exist double the size (i.eastward. If your email body is 600px broad, your epitome should be 1200px to render correctly on Retina displays similar the new iPhone). The 2nd image that's included in your VML should be the exact size (i.e. e-mail is 600px broad, then prototype is 600px wide).

Here's how this could look: In this first case, the same url is used for both, with prototype size at 1200px wide.

In this comparison, a dissimilar url is used in the <td>. The prototype size is 1200px, the VML image url is 600px.

While both examples allow for enough room around the live text, the second example is more visually hit and will more accurately mimic the intended layout and design.

Let'due south interruption down what's happening here. First, we'll create a conditional argument <!--[if gte mso 9]>. This lawmaking creates an if and then statement, showing that if Microsoft Office then replace with the following code.

Next we'll declare that this is VML, and set the manner with width and height that is advisable for your selected image. We'll use the v:fill up tag to place what paradigm URL will be used.

Finally, we'll utilize the v:shape tag to identify the position, and, as a best practice, restate the width and height and and then identify our end cap to identify what code will exist replaced.

Here'due south what it should look like:

                <!--[if gte mso 9]>          <five:rect xmlns:5="urn:schemas-microsoft-com:vml" fill="true" stroke="false" style="width: 600px; height: 320px;">            <five:fill type="tile" src="https://appoint.sailthru.com/rs/500-BIA-880/images/Hiking600sm.jpg" color="#ffffff" />  </5:rect>       <five:shape style="position:absolute;width:600px; height: 320px;">        <![endif]-->    <div>  <!-- code we are replacing --> </div> 	<!--[if gte mso 9]>   </five:shape>       <![endif]-->              

So let'south put information technology all together.

                <tabular array class="tablescale" width="600" align="center" bgcolor="#ffffff" cellpadding="0" cellspacing="0" edge="0"> 	<tr> 		<td width="600" style="border-collapse:collapse; mso-table-lspace:0pt; mso-tabular array-rspace:0pt; background-image: url('https://appoint.sailthru.com/rs/500-BIA-880/images/Hiking-Prototype.jpg'); background-repeat: no-repeat; background-position: top center; background-size: cover; width: 600px;"> 	 <!--[if gte mso 9]>          <v:rect xmlns:five="urn:schemas-microsoft-com:vml" fill="true" stroke="false" style="width: 600px; summit: 320px;">            <5:make full type="tile" src="https://appoint.sailthru.com/rs/500-BIA-880/images/Hiking600sm.jpg" colour="#ffffff" />                 </five:rect>        <five:shape id="NameHere" style="position:absolute;width:600px; top: 320px;">        <![endif]-->   			<div> 			<table class="total" align="center" width="600" cellpadding="0" cellspacing="0" edge="0" manner="width: 600px;"> 				<tr> 					<td class="left_header" marshal="centre" width="600" mode="font-family: Helvetica, Arial, 'sans-serif'; font-size: 35px; line-height: 40px; colour:#191919; padding-left: 35px; padding-correct: 35px; padding-superlative: 30px; padding-bottom: 200px; font-weight: 500; width: 600px; "> 	<stiff>Are you prepare for&nbsp;your next&nbsp;adventure?</strong> 						</td> 				</tr> 			</table> 			</div> 	<!--[if gte mso 9]>   </v:shape>       <![endif]--> 		</td> 	</tr> </table>              

Information technology'due south more often than not recommended that images be resized to fit within a viewport of mobile devices. Simply there are special occasions when your design doesn't allow this, resulting in a small prototype with illegible text.

Using unique images for mobile devices

If using a background image with live text (as seen in the example above) is non an option, you tin can create a unique image specifically for mobile devices. This tin can exist achieved by surrounding the epitome in a tabular array cell or <div>, and so creating a media query that hides the original and shows another header prototype every bit a background image instead:

                CSS @media only screen and (max-device-width: 479px) { .headerimg {     background-paradigm: url(https://yourdomain.com/images/header-325.png);     width: 100% !of import;     acme: 115px !important; } .imgheader {     display: none; } } HTML <table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td class="headercell">     <img class="imgheader" src="https://yourdomain.com/images/header.png" edge="0" width="600" /> </td> </tr> </table>                              

Here'southward how things look earlier and after the header images have been swapped out:

An advantage to using this technique is that you can shorten the length of emails by providing significantly shorter images. Or yous tin restyle your images and text to enhance the mobile experience. When it comes to mobile email, the shorter, the better.

Resizing images for fluid layouts

The result with the background image swap method above is that information technology's really only effective with static-width email designs.

These days, mobile devices can come in all sorts of shapes and sizes, therefore making fluid electronic mail layouts a popular selection. While the obvious solution seems to exist to ready background-size: 100% in the earlier media query, as Elliot Jay Stocks points out, the improve option is to use groundwork-size: encompass:

                @media only screen and (max-width: 600px) {  .imgheader {     width: 100% !of import; } }  @media only screen and (max-width: 479px) {  .headerimg {     background-image: url(https://engage.sailthru.com/rs/500-BIA-880/images/hero_img_mobile.jpg);     width: 100% !important; 	height: 300px !important; 	background-position: center !of import; 	background-repeat: no-echo !important; } .imgheader {     display: none; }  }              

Serving high-res images for Retina displays

Our final tip is in regards to getting images to display as sharply every bit possible on Apple tree'due south Retina displays. This is i that we've covered before, but given that these displays aren't going away anytime soon, it'southward worth a epitomize.

The trick is to create key images at twice the size you actually programme on displaying them, thus making the paradigm look super crisp on iPhone 11 and iPad displays. For example, using our earlier background prototype hack, we'd create a header prototype that was really 600px 10 300px (e.one thousand. https://[email protected]), but then shrink it down for mobile screens.

Here's how the media query would look:

                @media only screen and (max-width: 600px) {  .imgheader {     width: 100% !important; } }  @media only screen and (max-width: 479px) {  .headerimg {     background-image: url(https://[email protected]);     width: 100% !important; 	height: 150px !of import; 	background-position: center !important; 	groundwork-echo: no-echo !important; } .imgheader {     display: none; }  }              

If you lot specifically desire to target Retina displays with a special stylesheet, yous tin can utilise this CSS declaration instead:

                @media all and (min-device-pixel-ratio : 1.5) { ... }              

While doubling the size of your images volition produce sharp images for larger displays (i.e. iPads and tablets), they tin can also weigh your emails down, creating irksome load times and an overall poor experience for your subscribers.

You can aid prevent ho-hum load times with the Save for spider web options when you lot export your images from Photoshop or Sketch. You tin can also utilize an image compressor like TinyPng. For more information on using retina images, we recommend reading this mail past Litmus.

Chapter 7

Optimizing your subscribe forms

Optimizing your email campaigns for mobile isn't simply express to making sure your newsletter tin can be read on modest screens. Afterwards all, what's the point of sending mobile-optimized campaigns if mobile users tin can't subscribe to your lists in the commencement place?

The good news is that mobile devices similar iPhone and Android generally do a adept job of making forms at least remotely usable these days. Nevertheless, there are a couple of things designers and coders tin do to brand them as easy to utilize equally possible. The obvious benefit to optimizing your forms is that they require less time and effort to fill in on a mobile device. To you, this means college completion rates and more subscribers.

We'll cover a couple of pointers, and feature a simple case you lot can utilize as a starting betoken for your own subscribe forms.

• Tiptop-aligned labels—A mutual issue when using forms on a mobile device is having labels that reside out of sight when a grade field is selected in a browser. At the initial zoom level, a left-aligned label similar Enter your email address may be visible, only as presently as yous start inbound text, the viewport zooms in and the characterization is flung out of sight. The solution is to either use a tiptop-aligned label, or add the form characterization every bit a text-field value. The latter requires less vertical real estate, only tin can be a piffling annoying if the field you lot've simply started filling in was initially hidden by the phone's Grade Banana or keyboard.
• Use input type="email"—If you use input blazon="email" on the email address course field, a special keyboard volition display in iOS devices, featuring commonly used characters like @.
• Narrow down your forms—Use fluid layouts for mobile devices, as you can't predict the viewport'southward dimensions or orientation is a all-time practice. Simply making a text field's width fourscore% of the viewport width can massively meliorate the appearance and usability of your subscribe forms.
• Exist mindful of multi-choice fields—While on the subject area of narrow layouts, it'south prudent to force all content to flow in a unmarried column—particularly checkboxes. Often drop-down lists are a better option over radio buttons and reduce the amount of scrolling required to navigate the grade. After you've created a form, be sure to test it, then have your co-workers test it on their phones to ensure your course is thumb-friendly.
• Accept a stand on calibration—Finally, a lot of these tips here haven't been specific to forms, only more like web design in general. Included is the thought of setting the initial calibration or zoom on a mobile device using a viewport meta tag, specially when building standalone forms. When applied, they can foreclose the user accidentally zooming in unnecessarily and losing sight of near of the form. Here's what a typical viewport meta tag looks like in the head of an HTML page: <meta proper noun = "viewport" content = "width = device-width, user-scalable = no" />. For a couple of variants on this, check out Apple's viewport meta tag documentation.

Creating mobile-friendly plainly-text electronic mail

Not wanting to limit our advice to HTML email design, we wanted to add some pointers for optimizing plain-text campaigns.

When it comes to formatting plain-text emails, in that location are two camps: those who add together a line break every 60-65 characters to their message, and those who don't. Both have pros and cons, depending on which electronic mail customer your message is viewed in.

We have found the 60-65 character limit works best in desktop and webmail clients. This is considering there'south effectively no limit to how wide paragraphs of text tin can run in about reading windows or preview panes. Paragraphs of text tin can go very much unreadable after 60 characters or and then. Traversing from the cease of one long line to the beginning of another is simply as well much visual work for effective scanning.

Withal, on mobile devices, things are very dissimilar. In Apple Mail on iPhone, a 65-character line suspension combined with wrapping text results in a very jagged message. It'south arguably worse than reading an infinitely long line of text.

If you're sending HTML email with a plain-text version containing line breaks, most mobile electronic mail clients won't ever have to fall back to viewing it. So it isn't quite time to undo the app's handiwork when information technology automatically creates a nicely formatted text-version of your HTML campaign. However, if y'all're sending plain-text campaigns simply, information technology's worth having a await at your electronic mail client usage reports when deciding which style to become. If yous have plenty of subscribers reading their e-mail on a mobile device, it may not be an appealing thought to add your ain line breaks.

Affiliate 8

Example study: Twitter

Permit'due south put some of these techniques into do past applying them to a existent-world e-mail. Not but whatsoever e-mail, but one that's sent to millions of people every twenty-four hours.

In the non-and so-distant past, Twitter's electronic mail notifications were subpar on mobile devices. The problem was this: a combination of tiny text and wide layouts pushing out the zoom fabricated them nearly unreadable on minor screens.

Nosotros decided to practise something virtually it. In just five minutes, we practical a elementary fix that made a earth of deviation to the usability and readability of their notifications. And it may potentially help yous significantly meliorate how your email campaigns display on mobile devices, too.

In this case study, we'll show yous how we took a humble e-mail notification and turned it into something tweet-worthy when viewed in iPhone or Android Mail, or any mobile email client that supports media queries.

Taming the tiny text

Starting time of all, we wanted to approach the most credible issue with Twitter's notifications: tiny text. The reason why the text looks and then pocket-size is considering the 710px-wide layout forces the email customer on mobile devices to zoom out significantly to view the entire width of the message. Let's address this with a media query targeting small displays:

                @media only screen and (max-width: 479px) { ... }              

If you've read much on responsive email design, you may know that you lot add together these declarations to your <style> tags. The stylesheets within tin can merely be interpreted past HTML e-mail clients that come across the @media-but screen and (max-width: 479px) criteria. So let'due south put it to use on adapting the layout here. Commencement up, there are 2 tables surrounding the torso of the electronic mail bulletin:

                <table cellspacing="0" cellpadding="0" border="0" width="100%"> <tr>     <td mode="background-color:#e9eff2; padding: 30px 15px 0;"><table cellspacing="0" cellpadding="0" edge="0" marshal="middle" width="710" style="font-family unit: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 16px; colour: #333;">                              

We're going to bring them down to size by adding classes wrappertable, wrappercell and structure:

                <tabular array cellspacing="0" cellpadding="0" border="0" width="100%" form="wrappertable"> <tbody> <tr> <td style="groundwork-color:#e9eff2; padding:30px 15px 0" class="wrappercell"><table cellspacing="0" cellpadding="0" border="0" align="middle" width="710" style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:16px;colour:#333" class="construction">              

Now that we take something to target, permit's get to work with these classes in our media query:

                @media only screen and (max-device-width: 479px) { torso {     width: 320px !important; } .wrappertable {     width: 320px !important; } .structure {     width: 300px !important; }                              

The widths used above are significant, equally on the iPhone in particular, the display width is 320px in portrait orientation. Past narrowing the email layout to 320px, it volition be viewed at 100% zoom by default, which means that not simply will the whole design be visible, only text and images volition look crisp, too.

Putting a harness on the header image

The in a higher place technique would be all well and adept if it wasn't for that infernally wide 'Twitter' header image. And so we'll do something crafty and carve up the header image into three images. Sections which don't need to be displayed in our new, narrow layout can simply be hidden. Hither's the original code:

                <img alt="Twitter" height="52" src="https://a0.twimg.com/a/1335832060/images/email/email_header_710.png" way="edge: 0; display: block;" width="710" />              

And here it is, with the header image in three pieces:

                <img alt="Twitter" superlative="52" src="https://yourdomain.com/logo-left.png" style="border:0;" width="41" class="logo"><img alt="Twitter" superlative="52" src="https://yourdomain.com/logo.png" style="edge:0;" width="320"><img alt="Twitter" height="52" src="https://yourdomain.com/logo-right.png" style="border:0;" width="336" class="logo">              

Yous may accept noticed the class logo on https://yourdomain.com/logo-left.png and https://yourdomain.com/logo-right.png. Hiding these bits is pretty straightforward—simply add the post-obit to our existing media query:

                .logo { display: none !important; }              

At last, we've got a header image and layout that's trimmed down to size on mobile screens.

Another way to go the same result without slicing images is to create a tabular array row or <tr> with a groundwork color and then identify your logo in the <td>. Here'southward what that code would look like:

                <table marshal="heart" width="600" bgcolor="#3BC5F5" cellpadding="0" cellspacing="0" border="0" style="edge-collapse:plummet; mso-table-lspace:0pt; mso-table-rspace:0pt; width: 600px;">  <tr>  <td width="600" marshal="left" valign="bottom" class="logo" style="margin: 0; padding-bottom: 20px; padding-meridian: 20px; padding-left: 30px; font-size:18px; colour:#ffffff; font-family: Helvetica, Arial, sans-serif; width: 600px; "> <a href="url_twitter" target="_blank">  <img form="logo" src="twitter_img_logo.png" width="165" alt="Twitter" edge="0" style="brandish: inline-block; colour: #ffffff; width: 165px; colour: #ffffff; font-size: 20px; line-height: 26px;" />  	</a> 	</td>  </tr>  </table>                              

Now, on top of the above re-factors, we added some actress padding around elements and adjusted font sizes to gustation. Merely ultimately, almost of the major changes were accomplished with a couple of lines of code and merely a few minutes' work. The results speak for themselves (pictured).

Hundreds of people showed their support for these changes and joined us in lobbying Twitter to amend their notifications. The happy consequence was that Twitter heard united states of america and conducted a major redesign of their email notifications the post-obit week.

This guide was designed to give yous a strong code foundation every bit you lot embark on your own email marketing adventures to pattern and lawmaking mobile-beginning emails.

The mobile landscape is always changing, so while these techniques are a groovy starting point, you should always examination your code earlier you hit send. You can do this through testing services similar Litmus or through your own devices. And, of class, knowing where your subscribers are opening your emails will assistance y'all determine which devices you should be testing.

If you have questions about responsive email design or take a suggestion on how we tin improve this guide, be sure to go far touch with our team or achieve out on Twitter.

This mail was updated for accuracy and freshness in October 2019.

Press CMD+D to Bookmark this page

Better insights to build winning campaigns

Our analytics suite gives you smart, actionable insights to improve your campaigns.

Learn More

Case Study

With hyper-personalized emails, Bluetent experiences huge wins in the hospitality space.

Larn how

Info for your inbox

We get swell with inboxes. Sign upwardly for our newsletter for can't-miss marketing insights.

Subscribe

How To Make Email Template Responsive,

Source: https://www.campaignmonitor.com/dev-resources/guides/mobile/

Posted by: lewissithen.blogspot.com

Share this post