Design, Email marketing, Subject Lines, Trends

The Complete Preheaders and Snippets Tutorial

Tricks for using preheaders

Every email client shows you the sender (usually the “Friendly From”) and the subject line. Some go a step further and display additional text below the subject line. Desktop programs such as Outlook and Thunderbird, browser clients such as Gmail and Yahoo, and devices such as the iPhone and some Android phones, all display this “snippet” of text. The snippet is a potential opportunity to increase the likelihood that your email will be opened, but it is often overlooked. We have already discussed the importance of a good “From” address in Best Practices Enhanced Vol. 1, and good Subject Lines on this blog, but the snippet, while not used everywhere, is used in enough email clients and on enough devices to warrant consideration when you are putting together your mailings.

Here is an example of how snippets display on an iPhone 5:

Email on an iPhone

You can see that the snippets for PBS and Wall Street Journal are not very inspired, while the snippet for Travelocity, at least, includes the most important bit of information from the email (“EXTRA 12% off today”). iPhone users can turn off the snippets or change the number of lines that are displayed, but four is the iPhone’s default setting, and people rarely bother to change default settings.

Here is another example taken from the desktop version of Gmail:

Gmail on computer

In this case, ThinkGeek, an online store that specializes in science fiction-themed knickknacks, has made sure that the next line of text after the subject line has some useful information, while the other vendors shown are counting on their subject line to do all the work. The worst offender here is Touch of Modernwhich is slightly ironic considering that this particular website says in its description that it is dedicated to “extraordinary design.” The subject line (“Something incredibly artful”) is so nondescript it almost seems like a placeholder, and the snippet that follows it only makes matters worse by begging to be added to your contact list. Fab’s first email subject line is long enough to push most of the snippet text out of the line. That works fine in Gmail on the desktop, but the iPhone only displays the first 35 – 40 characters in the subject line and devotes the next lines to snippet text. On the iPhone, most of the visible information, then, would be devoted to the click-to-view message, followed by the first alt tags on the images at the top of the page.

It’s a shame to waste this valuable real estate on things like “Click here to view as Web page,” “Unsubscribe,” and random alt tags when you could be using it to further promote your message. There are some easy ways to do this, and they don’t require major redesigns to your email. In this article we’ll look at some of these ways, including some advanced techniques that will help ensure your email gets noticed.

First Element Solution

The simplest, and most popular solution to the problem is to make sure that the first text in the email is meaningful information. Here’s a typical example:

Preheader sample

Old Navy has started their email with the line “Give something special and treat yourself too.” In email browsers that display snippets, the Subject line (“Amazing Gifts for Them…And You!”) is immediately followed by this line. By putting this sentence before the usual “View in Browser” and “Unsubscribe” links, Old Navy ensures that the snippet expands on their sales message. It is probably no coincidence that it rhymes as well.

Here’s a slightly more sophisticated approach from gdgt.com:

Second preheader sample

In this case, they’ve organized everything so that the first bit of text on the page is their image’s alt tag (“gdgt”), followed by two text-based links (“Reviews” and “Best Gadgets”). The alt tag and the two links all assemble into a meaningful phrase (“gdgt Reviews Best gadgets”) followed by the two lines of text on the left:

from and snippet

Cleverly, they’ve used “text-transform: uppercase” to make the links text appear in uppercase in the email, but still appear upper and lower case in the snippet. Unfortunately, they did all this at the expense of the “View in browser” link, which appears nowhere in this particular email. Knowing that alt tag text is also incorporated into snippets, some marketers takes this technique one step further by making sure that the image is the first element on the page, and that the image’s alt text contains the preheader message. With the technique, the alt text is also the first text on the page if image display is turned off.

The downside to using preheader text as a first element is that it runs the risk of drawing attention away from the primary message. This is especially true if, as with the Old Navy example shown above, the preheader text is also a link. For this reason, email marketers often assign a mid-tone color to the text and use “text-display: none” in its style information if the text also contains a link.

Preheader Div Solution

An alternative to the first element approach is to use a non-displaying div preheader that contains the information you want to appear in the snippet. This method affords greater flexibility because the text that appears in a div preheader does not have to appear anywhere else in the message. With this method you can either expand on the meaning of the subject line, give people the most important piece of information from the email, or paraphrase the text on the page as needed. Here is an example from Direct Marketing News (DMN):

div preheader sample

Ignoring, for the moment, the fact that DMN has mixed up their own initials in the From name, the div tag gets the piece of information that will appeal to the most people across immediately (“Register now for a chance to win an AMEX giftcard!”). A look at the actual email shows that this information does not appear in the top part of the message:

Top of email with preheader div

By using a preheader div, DMN was able to keep the top of the message on topic while allowing the snippet to act as an enticement to encourage registration. Had DMN not used the preheader div on this email, the text below the subject line would read: “View web version Leads, Channels, and the Ongoing Pursuit of ROI,” which may have worked with some segments of the market, but nothing beats a free gift (as long as it’s genuine).

But preheader divs come with one drawback. As we discussed in the series on Responsive Email Design, not all email clients handle invisible divs well. Some will go ahead and place the text on the page. For this reason, preheader div tags are usually configured something like this:

Preheader snippet text goes here.

The color attribute shown in the example is based on an email with a white background. Some marketers prefer to omit this color information since text on a background of the same color is seen by some spam filters as a negative quality and can effect the email’s deliverability. Some marketers set the font size to zero, but that comes with the same caveat as color on color.

Which is better?

So is it better to use a div or a preheader that appears as the first text on the page? Most email marketers use the first text approach. It is simpler to implement and is in less danger of being flagged as spam. It also eliminates the problem of compatibility. A preheader that appears as text on a page will work anywhere, whereas non-displaying divs might not.

On the other hand, if your email design is not conducive to the first text approach, and there is some message further down in the content that makes a better teaser line than the first text on the page, then the div approach is the better choice.

Preheader Best Practices

Whichever method you use, it is a good idea to make sure that the snippet is not misleading. If the snippet reads “Learn how to receive your personalized coffee mug,” there better be a way to do so in the email or you are only going to alienate your audience and come across as dishonest.

You also need to be careful about the wording in your preheader. A preheader sentence such as “All clothing is now 50% off for all platinum club members,” could shorten to “All clothing is now 50% off…,” which might make non-platinum club members angry when they finally see the full sentence. Rewording the sentence (e.g., “Platinum club members now get 50% off on all clothing”) so that the modifying information comes first will help avoid this problem. Also be careful with statements where the second half of the sentence contradicts the first half (e.g., “The Ford Fiesta is a great car, if you like visiting the repair shop”). Unless you are intentionally intending for the message to be cut off for a humorous effect, it’s a good idea to reword the line so that this won’t happen.

Another thing to watch out for is the Title tag, which the iPhone will include as the first text in the snippet, but other email clients, such as Gmail and Yahoo, will not. There may be times when you can take advantage of this idiosyncrasy, but in most cases you’ll want to remove the title tags from your email’s HTML to ensure that your preheader appears the same across all platforms.

Whether you choose to use a first text preheader, or the div version is up to you, but you should be doing one or the other. The various email clients give you a certain amount of text to get your message across, and if you’re not taking advantage of it, you are missing out on a simple and easy method to add to the potential selling power of your email.


VISIT THE WEBSITE
Design, Email marketing, responsive design, Trends

Responsive Design in Email, Part 4: Tales From the Front

Fighting for better email

[Note: Unlike most of our blog posts, this one comes from our Marketing Communications Specialist Jim Morton personally, recounting his adventures in the exploration of responsive design. Like many of you, much of Jim’s HTML work these days is confined to email design, which, as you know, plays by different rules from web design. We think that what Jim experienced in studying the subject is good information for anyone interested in trying their hand at responsive email design for the first time.]

In the previous three articles, I examined the proposition of using responsive design in email. At the beginning of the project, I knew about responsive design and how it worked, but I had never bothered with it. I designed my emails so they could be read on something as small as an iPhone viewed in landscape, but would still look good on a 27″ monitor; that seemed good enough.

But sometimes, “good enough” just isn’t good enough. One morning, while I was reading email on my way to work, I became aware of the fact that I read almost all of my personal email on my iPhone these days. A quick survey of people I know revealed this to be common trend among them as well. Then, on the Email Monday Blog, Jordie van Rijn cited a host of statistics indicating that mobile email can account for up to 65% of email opens depending on the audience. Should I be using responsive design to take advantage of this trend? I wondered.

Geniuses Only

The thing that kept me from taking the plunge into converting our email templates to responsive design was the same thing that has probably stopped a lot of you: namely, its reputation for being difficult. Responsive design, you’ll hear people say, is hard to implement and brings a whole new level of headaches to email design. The problem with this statement is it tends to be self-fulfilling. When I started this project, I carried that same baggage and found it difficult to get traction with my early efforts at it. Looking back at it, I see that a lot of my problems were the direct result of my preconceptions about responsive design’s supposed difficulty.

It was my trepidation over the process that led me to start with Dreamweaver, thinking that this might be an easier way to get responsive features up and running in my mailings. As many of you know, Dreamweaver has a nasty tendency to stick things you don’t need or want into your HTML, but I wasn’t too worried about this—Symphonie’s visual editor does a pretty good job of stripping such garbage out. However, I quickly discovered that Dreamweaver wasn’t going to help. In the first place, Dreamweaver insisted on creating separate CSS files for everything. Media queries weren’t handled directly, and when you chose fluid design, a CSS file and JavaScript file were automatically attached to the project—perfectly acceptable for a website, but not so good for email.

In early October, DreamweaverCC, added 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 the CSS information will automatically switch to inline for any formatting choices. This change to Dreamweaver makes it much easier to create responsive email designs within the program. It’s nice to see Adobe finally paying attention to the needs of email designers, but it came too late for my project.

On the Edge

It was with some interest that I read about Adobe’s latest product, Edge Reflow, which was specifically created to help make responsive design easier to facilitate. I’ve been using Adobe products for more years than I care to mention, and I am very comfortable with their programs. If anyone could make responsive design easier, it was going to be Adobe (full disclosure: I worked for Adobe as a technical writer and illustrator, but that was a long time ago). Since I was subscribed to Adobe Creative Suite, Edge Reflow was available in its beta test form. Could this be the solution to my problem?

Short answer: No. Perhaps if you are designing websites, Edge Reflow is a useful tool, but when it came to helping me design the email, it was of little value. If anything, it made the whole process more difficult by adding another layer of complexity (and files) to the process. To make matters worse, it required me to start from scratch and, worst of all, had no ability to contend with tables, nor did it offer any inline features. After spinning my wheels with this program for a few weeks, I concluded it wasn’t the answer I was looking for and continued my search (see Responsive Design in Email, Part 2: Edge Reflow for the full report).

BYOHTML

Eventually, I came to the conclusion that the only way I was going to get what I wanted was to go back to basics and write it all in HTML. I fired up my trusty Notepad++ and went to work. I started with the company newsletter. I had already designed it to be scalable, but I thought the images and buttons became too small to be useful in the scaled version. The layout was fairly simple—alternating image and text boxes divided into color coded section. How hard could it be?

Basic newsletter layout

At first, I tried to attach media queries to the previous version of the newsletter, but that proved to be impossible. In the original version the image and the associated text were part of the same table and the same row, so there was no way to get the image and the text to change their relationship to each other. Normally, this is one of the reasons email designers like tables—they keep things where they belong no matter what—but it’s not so good when you want things to move around more freely.

I thought about setting the positioning using divs, but I knew that Outlook.com doesn’t play nice with div floats or margins and I wanted to end up with an email that would look as good in as many email clients as possible. As with images and divs, you can control the appearance—or disappearance, as the case may be—of tables using media queries, but first I had to isolate the elements. For our newsletter, there were three primary elements: The image, its associated text, and the CTA button. By putting each of these in its own discreet table and nesting those three elements inside another table I was able to control the positions of all the elements with very little effort on my part.

The Compatibility Dilemma

Conceptually, the @media query is the heart of responsive design, and is pretty straightforward. You define styles to activate based on the @media query information, so you can move, resize, hide, and show different elements in your email. You may be tempted to try using the “display: none” attribute to control the appearance and disappearance of different sections based on the screen size, but I don’t recommend it. Not all email clients recognize this attribute, and when they don’t things break down terribly. Suddenly, you have a page with all versions of your content displayed stacked on top of each like a garage sale. Some clients, such as Gmail, force you to jump through so many hoops to get it to work that you might as well not bother. You’re still better off making sure that your email is readable under all circumstances than wrestling with multiple hidden versions. This particular issue gets right to the heart of the problem with responsive design.

However the biggest problem I faced in creating a cross-platform compatible design came from one company—Microsoft. While Google’s issues with the “display:none” tag forced me to rethink my design approach, it was Microsoft Outlook that generated the most problems for me. Getting my design to work across versions of Outlook was a study in frustration. My layout would work in Outlook 2003, 2007, and 2013, but not in 2010. Once I got it working in 2010, I’d go back to discover that it no longer looked right in 2007. The biggest problem was getting the tables to line up consistently. A quick search turned up a few articles on the subject of using Microsoft Outlook and responsive email design. Unfortunately, many of the solutions offered in these articles only shifted the problems to other versions of the software. I suspect that many of these people were working off the assumption that once they got the layout to work in their version of Outlook, it would work everywhere. In the end, the insertion of this tiny bit of code proved to be the only answer that actually worked:

style=”mso-table-lspace:0; mso-table-rspace:0;”

And even here I had to adjust the spacing in some of the tables to keep the images from interfering with the text.

Herein lies the biggest problem with responsive design in email. With so many different clients using so many different standards, finding out what works starts as an Easter egg hunt, and turns into a repetitious process of trial and error. While the technology of @media is conceptually simple and gives powerful options, individual vendors adoption of the required supporting elements has made it far more difficult and complicated than it should be. Perhaps when all—or almost all—the CSS commands are accepted across the board in email clients, then we will see some real strides forward in email design. Unfortunately, as we all know only too well, those wheels move very, very slowly.

Picking Your Battles

So was it worth it? I spent at least two weeks worth of studying and two more weeks of coding and layout, trying to get my initial design to work. I chased after a few concepts that led nowhere, and things that worked in some places fell apart in others. There was some satisfaction in seeing my final results in action, but I think I would have had less trouble with it had I not been searching for a shortcut to the coding part of the process. Ironically, the final design that actually worked came about after I threw out the file I had been working on and started over from scratch—that took me a day (of course, I had already done all the groundwork). Clearly, the web designer with a stronger background in responsive design will have a shorter learning curve than I did, but that can also bring with it erroneous assumptions about what will and won’t work. If you are new to responsive design, you’ll need to do some prep work before you can even start to code things. Of the resources I used, Chris Converse’s tutorial on Lynda.com was, by far, the most useful. As I mentioned in the previous post, looking at how others have tackled the problem is invaluable in coming up with good results.

The more complicated your email design is, the more of a hassle it will be to convert it. Goolara’s newsletter format is relatively simple, but it still took me a few weeks to get it where I wanted it. A complex design might prove resistant to a good responsive reworking solution. Whenever possible, designing your email with responsive in mind before you start is preferable, and will keep you from trying to fit a square peg in a round hole. As always, testing is crucial. While rendering services can be very helpful with catching errors, there were a few instances where what I received from the rendering service did not match the results I was getting with the actual email software, so use caution and test with actual mailings whenever possible.

The question you need to ask yourself is whether the effort you put into creating a responsive design is taking time away from segmentation and dynamic content efforts to make your mailings more personal. Larger companies, where the design is separate from the coding, won’t find this to be much of an issue, but if your designer is also the person who codes the file for email purposes, you’ll need to take into account the added time that they may require to get everything to work correctly. If it comes down to a choice between a nice responsive design and the good use of dynamic content, I would always choose the latter.  An email that addresses the specific interests and needs of a recipient is going to have more engagement than one that is merely easier to read on a phone. More and more people use their phones and “phablets” to read their email, but they’re still more likely to respond to an email that is relevant to them over one that merely looks good.

If you would like to see the results of my experiments, you can subscribe to the Goolara newsletter here, or you can write to me at jimm@goolara.com. You’ll also find me on Twitter: @JimAtGoolara. Happy emailing!