Tag Archives: head tags

Responsive Design in Email, Part 3: Handling Media Queries

Responsive design
In our last article on Responsive Design we examined Adobe’s new Edge Reflow program, which is designed to help facilitate the process of responsive website design. Unfortunately, we found that, like Dreamweaver, Edge Reflow is designed almost exclusively for website production, with no tools for creating responsive email files.* There is, of course, an alternative, and that is to code it yourself. Before you tune out completely, keep in mind that as long as you don’t try to get too fancy, creating media queries is not that daunting. This article is designed to help you get past the main stumbling blocks inherent in using responsive design in emails. As always, the K.I.S.S. rule applies. Keep things simple and you shouldn’t have any trouble building an effective responsive design. Once you’ve created your basic template, building new templates becomes a lot easier.

Email is Not a Web Page

The first thing to remember is that email design has certain characteristics that are substantially different from those of a web page. It is this fact that make both Dreamweaver and Reflow frustrating to work with at times. The main points of difference are:

  • Email cannot use JavaScript
  • Email cannot use separate CSS files
  • Tables are still the best way to control positioning
  • Some email clients can use head tag styles, but some cannot
  • Inline styles are always more compatible than styles in the head tag.

With a responsive web page, it is not unusual to have several CSS and JavaScript files connected to a page. Email design has no such luxury. Images are separate files, but everything else better be contained within the email if you want it to work.

The second thing to remember is that every email client plays by its own rules. Some ignore any expressions that appear in the head tags, which means your responsive design won’t work with that email client. As we discussed in the first article in this series, Gmail will use the head tag information if you view the mail on your iPhone with Apple’s Mail app, but not if you view it with Google’s Gmail app. Even with two email clients that both accept head tag styles, there may be display differences, so thorough testing is necessary every step of the way.

Tables Not Divs

Before you begin coding your responsive design media queries, you need to make sure you are starting on the right foot, and that means using tables. If you hang around web designers, or, at least, hang around the forums that web designers hang around, you’ve probably heard the mantra that you should be using divs not tables. “[Y]ou MUST use tables for tabular data!” A web designer on Stack Overflow posted. “Tables exist for that purpose, you MUST avoid tables only for layout purposes by using divs instead.” True enough if you’re designing a web site, but as every email designer knows, divs don’t always work in email. Outlook.com, for instance, ignores floats and margins, two of the primary components necessary for positioning elements on a page. This is especially ironic considering that Outlook.com is just about the only email client that actually uses most of the new HTML5 tags.

As with any other element on a page, tables can be assigned different attributes in the media queries. The main difference with responsive design is that elements with different media query attributes will need to be in separate tables to behave predictably. But before we get to that, let’s look at the basics of a media query.

Start Simple

For your first responsive design, it’s a good idea to start simple. It’s possible to have instructions for a dozen different sizes of screens, but it is not really necessary unless you’ve designed your email with multiple columns, which is generally not recommended. Depending on your design, you will want to switch to a mobile version of the email when the screen size falls somewhere between 500 and 600 pixels. Let’s say you’ve decided to switch to the mobile display at 525 pixels. Your media query would begin like this:

@media screen and (max-width: 525px)

You may want to use a smaller or a larger number, that is up to you. Smaller smart phones and the early iPhones had screen resolutions of 320×480 pixels. This number has increased substantially over the past few years. Newer iPhones have screen resolutions of 640×1,136 pixels, and the Sony Xperia Z Ultra and Samsung Galaxy S4 come in at a whopping 1,080×1,920 pixels, which rivals some desktop monitors.

These numbers may suggest that, at 640 pixels, the iPhone should display the full sized version of the email, but it will not. The number of pixels listed in the media query and the screen resolution are not equivalent. Newer iPhones, for instance, have a resolution of 640 across, but a device width of 320. This is because the width information in CSS does not take into account the iPhone’s retina display which doubles the number of pixels available. Likewise, the Samsung Galaxy Note II’s 720 pixel resolution comes in at 480 pixels in screen width. Of course, you can take pixel densities into account when you define your media queries, but this will only add an unnecessary layer of work to your email design. You may also want to create an intermediate set of rules for tablets and the very large phones (“phablets”), but keep in mind that this will add another media query and another set of instructions to your head tags. Also keep in mind that, if properly designed, your email should be readable on these devices without requiring any responsive adjustments. An email with a max-width of 650 pixels wide with 12 point type should be perfectly readable on any tablet (some people prefer to use the more cautious 600px).

From CSS to Email

With media queries, you can move elements around or hide them to your heart’s content.

If you are using Dreamweaver or a similar program to create your email, you may want to do everything using a CSS file to ensure consistency throughout the email, and to make it easier to change individual elements at a later date. Just remember that you’ll eventually need to convert all that information to inline styles. You could take the CSS file and stick its contents between style tags in the head, but not all email clients use head tag information. For the most compatible results, after you’ve added the CSS information to the style tag, you should next run the whole thing through an inline styler. This will inline everything, but it may also throw out the media queries at the same time. If so, you’ll need to replace these.

When you are finished, the top of your email’s HTML will look something like this:

<style type=”text/css”>

.ReadMsgBody {width: 100%;}

.ExternalClass {width: 100%;}

blockquote .original-only, .WordSection1 .original-only {display: none !important;}

blockquote table.forwarded-only, .WordSection1 table.forwarded-only {display: block !important;}

@media screen and (max-width: 525px) {

td[class=”SecondKitten”]{

display:none !important;}

img[class=”SecondKitten”]{

width: 100px !important;

height: auto !important;

padding-bottom: 20px !important;}

img[class=”FirstKitten”]{

width: 300px !important;

height: auto !important;

padding-bottom: 20px !important;}…

…</style>

<body>…

The expressions at the top that appear before the media query are there to eliminate email formatting issues. The first two expressions are for Hotmail, and the others are there to reset HTML5 elements to display elements as block elements, which helps control formatting things such as tables and lists.

The three style classes shown after the media query affect different parts of the design. The first one (td[class=”SecondKitten”]) causes the table cell (td) to disappear when the email is viewed on any device that is less than 525 pixels across. The second one (img[class=”FirstKitten”]) forces the image (img) to shrink to the width of 100 pixels, regardless of its original width. Likewise, the third class (img[class=”FirstKitten”]) forced the image to expand to 300 pixels.

Down in the body of the email, you’ll see something along these lines:

<img src=”http://placekitten.com/200/200&#8243; alt=”Meow!” height=”200″ width=”200″ border=”0″ style=”display: block; font-family: Arial; color: #ffffff;” class=”FirstKitten”>

The “FirstKitten” class indicates that if the screen’s width is 525 pixels or less, the image’s dimensions shift from 200×200 to 300×300. Normally, you’d want to reduce your image for a smaller screen, but this example demonstrates that you are not limited to only reductions. Just keep in mind that enlarging above an image’s resolution may result in some pixelation of the image.

A little further down in the body of the HTML, you’ll find this table cell information:

<td width=”200″ align=”center” style=”padding: 0;” class=”Second Kitten”><img src=”http://placekitten.com/200/250&#8243; alt=”Meow! Meow!” height=”250″ width=”200″ border=”0″ style=”display: block; font-family: Arial; color: #ffffff; font-size: 18px;” class=”Second Kitten”></td>

Since the media query attribute assigned to the cell (td) has a display value of “none,” the entire cell disappears when viewed on a small screen, even though the img class is active and has its own values. Here’s our sample file as it appears on a monitor (Click here to view full-sized version of the image):

Responsive Design on a Monitor

Images used in this demo are courtesy of placekitten.com.

And here’s the same file when viewed on an iPhone:

Responsive Design on an iPhone

You can see that a few interesting things have happened. The kitten at the top of the page became larger, deteriorating the image slightly, while the kitten at the bottom of the page disappeared entirely. The call-to-action buttons lose their original size attributes and switch to the attributes in the media query, which specify 100%. This causes the buttons to stretch across the width of the display, which works well for small screens, but would look bad on a monitor.

Now, suppose we change the “SecondKitten” td class as follows:

td[class=”SecondKitten”]{

display:100% !important;}

Now the second box in the email appears like this on an iPhone (or similar small-screen device):

100 pixel kitty

You’ll notice that since the cell is allowed to display and given a value of 100%, the image appears, but now the attributes under the img class=”SecondKitten” take effect. The picture is visible, but reduced to 100 pixels across because that was the width indicated it should be when the screen size falls below 525 pixels. **

Design for the Least Compatible Client

As I’m sure you’ve noticed, not all email clients are created equal. Outlook.com, for instance, does a great job of rendering HTML5 code, but it ignores floats and margins in divs. Some email clients can handle head tags, and some can’t. While it is fun to try and create complex responsive designs that adapt to different devices, you’ll still need to design your email so that when all else fails, it is still readable under the widest variety of circumstances. It might be fun, for instance, to swap out entire sections using “display:none” as an inline attribute, but it won’t do you much good if any of your recipients are using Gmail because Gmail strips out the “display:none” attribute from the email. The old adage in email design is that you should “design your email like it’s 1999.” A better approach is to design for Least Compatible Client (LCC). Don’t put anything in your body tags—other than class selectors for the media queries—that won’t work in every situation. That way, you’ll always have an email that will look as good as it can under any circumstances.***

Responsive Writing

A quick survey we did recently indicated that most of the email designers who are actually creating responsive layouts are not using visual editors such as Dreamweaver, but coding by hand using HTML-oriented text editors such as TextWrangler, Sublime Text, or Ultra Edit. Although Dreamweaver does have tools for creating responsive templates, as mentioned in our other posts on the subject, it is aimed primarily at web designers and often adds unwanted code to your files. If this all sounds a bit daunting, it shouldn’t. Remember our initial advice: keep it simple. Besides, remember that others have gone before you and there is no reason to reinvent the wheel.

Learning From Others

A great way to learn more about how to use responsive design is to open the source code for the responsive emails you receive and see what they’re doing. In most cases, you’ll see a lot of expressions under each media query that aren’t used. This is because everyone is working from a template to which they may have added things they’ve needed over time. A particular email may only use four or five instructions, but the media query section may have a dozen or more extra expressions. Those extra expressions add slightly to the size of the email, but only slightly. Web pages can be a great source of ideas for responsive design, but they often rely on JavaScript to implement certain aspects, so approach with caution.

One excellent source of responsive design examples is Media Queries. This web site is a collection of the best responsive design pages on the Internet. It contains hundreds of dazzling examples of responsive web design. This is a great place to go if you are looking for ideas. Odds are there is an example here that matches your concept. All of the examples are web pages, so most include JavaScript. Formatting varies widely, from carefully formatted and commented, to one big, indecipherable, block of code.

Another source for bare bones responsive email design ideas is Code Pen, an online sandbox for testing HTML. While most of the examples given on this site are for web design, a search for “responsive email” will yield several useful examples of emails that were created to be responsive.

There are also some very good online tutorials available on YouTube. These range in quality from professionally-made, “I-can’t-believe-they’re-not-charging-for-this” instructions, to people with indecipherable accents talking into their laptops at the local Starbucks. Lynda.com also features a thorough tutorial on responsive email design by Chris Converse (includes sample files).

Test, Test Test…

However you choose to create your responsive email, you’ll need to test it across as many different platforms and devices as possible. Sometimes things may look perfectly acceptable across nine clients and devices and then the tenth one will send you back to the drawing board. As with all code, a misplaced percentage sign or missing bracket can ruin everything. Due to the nature of responsive design, it can be difficult to tell if your media query is working until you see it in action.

In the next installment of our series on Responsive Design in Email, I’ll discuss the process I went through to come up with a good responsive design, and what I learned along the way.

* The latest release of DreamweaverCC, now includes the option “Define in page” for media queries. By using this command, you can add the media queries to the top of the HTML document and still inline all the style information. With this change to Dreamweaver, it might be possible now to use it to create responsive email designs within the program. It’s nice to see Adobe finally paying attention to the needs of email designers.

** If you would like a copy of the original HTML file, you can download it as a zip file here, or as a text file here.

*** This advice does not include Styled Alt Tags, which may not work in certain clients, but these are less an aspect of design than a fallback when images are not displayed.

Responsive Design in Email, Part 2: Edge Reflow

Edge Reflow graphic

Update: On November 30, 2015, Adobe announced that they would be discontinuing the development of Edge Reflow, along with all the other Edge tools. Most of the features of Reflow have already been incorporated into Dreamweaver.

In last week’s article, we talked about the pros and cons of using responsive design in your emails. In response to the increased interest in responsive design, Adobe recently introduced Edge Reflow, a program designed to simplify the process of creating responsive designs. With Edge Reflow, you can create as many size-based variations on a web page as you want. Most of the formatting information goes into the separate CSS file, which you will then need to add to the head in your email. If you are using Adobe Creative Cloud, the program is available for download now. The program is still in beta, so it’s possible that some of the problems I discuss here will be addressed before the final release. It was originally scheduled to be released in July, but that deadline has come and gone, suggesting that Adobe recognizes that the program is still not ready for prime time.

In Edge Reflow, you draw boxes, place images, and create text boxes as separate elements on a default field. A resizing handle on the right lets you see what happens to your design when you reduce the size of the viewing platform. You can then reorganize the information in your design for different widths. For instance, you may want to set the default version of the file to a width of 900 pixels, and then create a version for viewing on a phone that is set to start displaying at 425 pixels. You can drag the various elements to different positions, change their float attributes, and hide them when necessary.

3 views of responsive design

With this file, the text and graphics were moved into a stacked position for the tablet view, and then the images were hidden for the phone view.

It sounds easy enough, but the sad truth is that, when it comes to email design, Edge Reflow offers few, if any, advantages over coding the email yourself. It has some nice features, but it’s worth mentioning the 800-pound gorilla in the room: Edge Reflow will not open HTML documents; only its own Reflow (.rflw) files. If you want to experiment with existing designs in Reflow, you have to recreate them from scratch. Nor does Reflow directly give you the option to save or export the files you create as HTML formatted files. To do so, you have to choose “Preview in Chrome” from the View menu and then it will either open in Chrome, or open the folder containing the HTML and CSS files. You can open these up in Dreamweaver and modify them, but there is no way to import those changes back into Reflow.

In an attempt to improve Reflow’s compatibility and usefulness, Adobe recently added a feature to Photoshop CC that lets you generate a Reflow file in Photoshop. This has some interesting aspects, such as the ability to keep any text layers you’ve added in Photoshop file as editable elements. This is a welcome addition, but it doesn’t address the real problem, which is that you are never working with your actual HTML document. During our tests, it became apparent that to use this feature you have to start from a predefined approach that may not be compatible with your previous designs. In our tests, we found very little advantage to using this feature. Your results may vary.

Edge Code

As part of the Edge gallery of programs, Reflow was primarily intended for use with Edge Code—a repackaged version of Adobe’s free HTML editor, Brackets. Edge Code has the features, such as color coding, that we’ve come to expect from HTML editors, but it is a bare bones affair. Notepad++ (on the PC) and TextWrangler (on the Mac) offer more features, and they are also free. As with Reflow, previewing files from Edge Code requires the Chrome browser to view the final results. Other programs in the Edge line include Edge Animate (just what it sounds like), and Edge Inspect, which is primarily intended to view web pages on various devices before publishing them (of little use for email marketing since you must still send the files to various email clients to see how they handle them).

What You See is NOT What You Get

For now, according to Adobe, only Chrome displays Edge Reflow’s responsive features to their full potential. Opening the same file in Firefox or IE can often lead to entirely different results. On one level, this is understandable. Some aspects of Reflow may not work as well in the other browsers, but this is the least of your worries when it comes to creating email. How well various browsers handle responsive design is less important than how well the various email clients and devices respond to the code. Like Dreamweaver, Edge Reflow was intended to help create responsive web pages, not email. Media queries and other style attributes are automatically saved to a separate CSS file. Before you can use these attributes in your mailing, you’ll need to transfer them to the head section of the email. Unfortunately, it is not possible to insert this information inline, so media queries are only usable with email clients that use the head information. [See last week’s article for information on which email clients are compatible with head tag information.]

When you are finished designing your email with Reflow, and have saved to preview in Chrome, you should end up with four files:

  • page1.html
  • Project_Previewer.html
  • page1.css
  • boilerplate.css

“Project_Previewer.html” is intended for use with multiple page constructions and can be ignored or deleted if you are working on an email design. “Page1.html” is the actual HTML you’ve created in Reflow, and “page1.css” is the style information for that page. “Boilerplate.css” contains several master style elements that may be important to your final results.

You can copy the CSS and place it between Style Tags in the email head, but this isn’t advisable. Not every email client uses the head tag information. You’re still going to have to convert all the CSS except the media queries to inline styles if you want your email to look good in as many email clients as possible. Once all of this information has been converted to inline styles and the media queries have been added to the head, you’ll need to send out test emails to various email clients and look at the results on various devices. Your design may look perfect in Edge Reflow and then fall apart completely when it’s transferred to your email marketing software. Similarly, it may look fine in your email marketing software and come out completely wrong in certain email clients, so testing across as many clients and devices as possible isn’t just a good idea—it’s absolutely necessary.

Gmail & Thunderbird comparison

Here is the same email in two different email viewers. On the left, Gmail strips out the header information so all the formatting is lost. On the right, the same email appears as it was intended in Thunderbird. Inlining the style information will solve this problem.

Form Follows Features

If you want to use responsive design, Edge Reflow might help you sketch out an idea, but it is not a complete solution. It is also very email-unfriendly. Although you can use tables in responsive design, Reflow provides no easy way to do so. Not to mention the fact that you still have a fair amount of work to do to prepare your final files for mailing. I do want to stress once more that Edge Reflow is still in beta testing, so everything I’ve said here may be negated by the time it is finally released. I certainly hope so, but I’m not holding my breath.

However you decide to tackle responsive design, it is important to make sure that your design is flexible enough to be easily read on as many devices as possible. Until all email clients—and especially Gmail and AOL—accept head tag information, email containing responsive design information must be readable and visually appealing under all circumstances. In our next post, we’ll look at how to do this, by combining media queries with inline information to create the most compatible email possible.

Next Time: Handling Media Queries in HTML.

Responsive Design in Email, Part 1: An Overview

How am I supposed to read that?!!

The hottest topic of discussion in the email marketing field right now is that of responsive design. Responsive design means that email changes its appearance if the viewing device falls within certain size ranges. For instance, suppose you have an email that features three columns of information in 12 pt type. It may look perfect on a desktop, but open the same email on a smart phone and suddenly that 12 pt type is reduced to three pt type and is virtually unreadable. Of course, the reader can always double-tap or pinch-out (zoom) to expand the text to a legible size, but asking your readers to do anything is always a dangerous proposition. It’s always best if the reader doesn’t have to do anything to receive your message and you make it as easy as possible for them to respond to the Calls to Action.

There’s no question that responsive design can help with this. It will automatically format your email according to the parameters you’ve set ahead of time and display the email in the optimal format. When used carefully, responsive design can help improve recipient response. So wouldn’t you always want to use it? Well, maybe not. As with most aspects of email marketing, there’s more to the story than meets the eye.

Talk is Cheap

A quick search of the keyphrase “responsive design email” turns up lots of posts that tell you the advantages of using responsive design in your email. Not one of these posts, however, gives us much useful information on how to do it. “Use @media queries” is the standard mantra, without a shred of information on how to do so. It’s probably not a coincidence that several of the emails I’ve received from the companies that are posting about the advantages of responsive are not using it in their own emails.

One recent blog post states that “adopting responsive design to your website and digital communications isn’t difficult.” It may not be difficult compared to building the space shuttle or performing brain surgery, but when it comes to creating email, responsive design adds considerable complexity to the process. For this reason, some ESPs now offer responsive templates. That’s fine as long as you don’t plan to exert much control over the appearance of your mailings. A few are beginning to offer tools for dealing with responsive design, but even here, much of your control over the design is lost to pre-coded sections of their choosing. If you want your email to have completely unique characteristics, you’ll still have to handle the coding yourself.

Media Queries

As I mentioned earlier, the secret behind responsive design is a feature of CSS called media queries. A media query looks something like this:

@media only screen and (max-width: 425px) {

#image2 {

display: none;

}

In the example above, the image designated as “image2” disappears when the width of the display is 425 pixels or less. Media queries let you control virtually every element on a page. You can change the fonts sizes, the positions of the images, whether or not an image will appear at all below a certain size, and much more. As one might imagine, this kind of power comes at a cost, and not without a few caveats.

Design and Design Again

Creating a responsive email means first designing a page, and then designing it again…and again. If you want to optimize your email display for several different platforms, you’ll have to adjust the design for each one accordingly. Sometimes, this means little more than adjusting the font size and moving some images around, but if you’re not careful, you can spend a lot of time trying to get the email to behave in all situations and the next thing you know, you have six different size settings in your styles. Responsive design can be very finicky about things such as position, sizing, and which units of measurement you choose to use. Like all code writing, it is also unforgiving when it comes to spellings and matching up brackets. Multiply this by how many different versions you decide to create and you can see where things can get complicated fast.

Once you’ve created your responsive design, you’ll need to test it across various devices. Here’s where things get tricky. Your design may look great when you view it as a stand-alone file in Chrome, but suddenly all its features fly out the window when you look at the same HTML with the same browser in Gmail. Congratulations! You’ve just discovered the main problem with using responsive design—the issue of head tag information.

What’s in Your Head

The biggest limitation to using media queries in email comes from the fact that media queries cannot be inserted inline. To take advantage of media queries, you need to include head tags in your HTML. All well and good, except that many email clients are going to ignore your head tags and replace them with their own information. Suddenly all those carefully constructed formats are gone, leaving your email looking more generic than ever. To complicate matters further, this will vary depending on the device you are using to view the email, and which app you are using to view it. A mailing sent to Gmail will show none of the style characteristics when viewed in a browser on a desktop. It will look fine when you view it using the Mail application on the iPhone, but it won’t if you view it on the same phone using the Gmail app. Here’s a chart showing which email clients accept head tag styles and which do not.

Head tag compatibility chart

The Scalable Alternative

The alternative to responsive design is scalable design, which has been around for a while. This simply means that you design your email so that it is readable on any device, regardless of its size. If the positioning of images and text is critical, those old email standards, tables, are still the safest way to go. Tables don’t scale down very well, so you’ll want to keep the maximum width low—around 650 pixels or less—to ensure that the type is still readable on a phone. Tables also don’t allow the elements to interact with other elements that are not in the same cell, so you won’t get the type reflowing around an image when the window is resized. On the plus side, they are still the most compatible way to control image positioning, and they can be used with responsive design as well.

Div tags may appear to be an attractive alternative, but they are not. They have the advantage of being more flexible, so you can have type flow around an image when the window gets to small for the type and the image to appear side-by-side. And because they don’t scale down like tables, the type stays readable on small devices. But div tags won’t work everywhere, and when they don’t work, it can be a disaster. There is still no consensus on div support, so some email clients support some aspects of divs while others do not. Outlook.com and Hotmail, do not currently support the float attribute, so everything ends up stacked on top of each other. Other email clients, such as Live Mail, ignore the overflow command, which can cause elements to overlap and ruin the layout.

Responsive design may be advantageous in creating email that is optimized across different platforms, but you can’t rely on it in all circumstances. You’ll still need to make sure that your email looks good when the media queries won’t work. The type must remain readable on smaller screens. In some cases, using divs instead of tables can go a long way toward making your email more compatible with devices such as smart phones and tablets, but, as mentioned above, this can lead to even bigger problems, particularly with older client software.

The Automated Approach

You can create responsive designs the old-fashioned way, by entering the HTML code a line at a time, but there are tools that are intended to help simply the process. Dreamweaver lets you use the media queries with the fluid design layouts. This gives you three choices of screen sizes with which to operate. Unfortunately, Dreamweaver automatically includes a Javascript file, which is a taboo in email design. Another program that has been getting a lot of attention lately is Edge Reflow, Part of Adobe’s new Edge series and available through the Creative Cloud. But is Edge Reflow the answer to the problem, or just another layer of complexity? Tune in next week for Part Two: Working with Edge Reflow.