Automation, CAN-SPAM, Design, Dynamic Content, Email marketing, HTML Issue, Personalization, responsive design, Subject Lines

The Past Year in Email

Happy New Yer!
Another year has come and gone, and although after the events of last year it seemed like the earth was about to spin off its axis, we’re still here and email is as strong as ever. It’s time once again for our annual look back at the best and worst examples of email of the past year. There are a few old favorites and a few surprises. We’ll start with that old chestnut that never seems to go away: The Bad Mail Merge.

Dear your name here,

bad mail merge

A few years ago, faulty mail merges, like those in the example above above, were the most common mistakes we saw. Attempts to sound personal suddenly have the opposite effect, pulling back the curtain and showing that the email for what it is: a pre-written script with information inserted as needed. This particular template called for both a first name and a company name, neither of which was available. The use of dynamic content instead of a merge could have avoided this problem by given the mailing other options when information was missing. It’s never good when a company that is trying to sell you on their technological prowess can’t assemble an email correctly.

The example below is even more egregious since it purports to be aimed at a specific person. This, coupled with the formatting errors in the apparently meaningless text below the main message (see UTF-8 discussion below), sent this one on a quick trip to the Spam Folder.

bad mail merge #2

While not as bad as either of the errors, another problem that cropped up in a new mailings was the repeat of my first name. Since I’m sure I never put my name in a field twice, I have to assume that the problem is somewhere in the email’s dynamic content structure.

merge error

Aw Gee-Mail

Weather error

Personalization can be a great way to start an email, but it has its limitations. The example above has my name, and a shout out the weather. The only problem, here’s the weather in Moraga for the day this email was sent:

actual weather

Not exactly sunny. I’m not sure if the “sunshine” comment was a dynamic insert based on some erroneous weather predictor, or simply an educated guess on the part of the sender. Either way, receiving this message on the coldest, most overcast day of the summer made us chuckle.

Time’s a-Wastin’!

jumping the gun

It seems like stores push closer and closer to Halloween when it comes to holiday sales. Kohl’s takes it one step further by announcing that you just have a few hours left for your Black Friday deals three weeks before Black Friday! From the content, it looks like this mailing was intended to be sent out on the 1st, but Black Friday threats simply won’t work in that case.

Musicians Who are Pushing

snippet cutoff

Gmail and other email clients like to give you a peek at what to expect before you open the mailing. You can use this your advantage with a preheader. Just make sure that when that preheader is abbreviated, you don’t end up with a different message. Musicbed made use of a preheader, but didn’t take into consideration what happened to the preheader when the window wasn’t big enough to fit the whole thing. They ended up with “musicians who are pushing,” instead of “musicians who are pushing the genre to new place.” Perhaps out of paranoia, Patrick James avoids the problem altogether by using a short preheader message followed by a long series of periods.

Amusingly, this particular problem isn’t limited to email. In 1998, a campaign in New York state to provide schools with pencils that featured an anti-drug message had to be pulled when kids started noticing that the more you sharpened the pencils, the more pro-drug the message became.

too cool to do drugs
Source: http://www.nytimes.com/1998/12/12/nyregion/slogan-causes-pencil-recall.html

It’s All Ελληνικά To Me

How you code your email can make the difference between a readable message and gibberish. An email written using 8-bit Unicode characters and then coded for 7-bit ASCII is going to have some problems. Some times you see this immediately in the subject lines:

utf errors

And sometimes it appears in the body copy. Normally, these snippets of code standout, and do little more than interfere with the design, but if you’ve created an email that relies directly on UTF-8 Unicode to get its idea across, you’re going to be in trouble. That’s what happened with ThinkGeek’s otherwise clever mailing:

thinkgeek

The text below the image was supposed to be a humorous paragraph printed upside-down and backwards, as an in-joke to the Stranger Things TV show. If you look at the source code, you’ll find the original message was:

“˙soƃƃƎ puᴉɟ ll,noʎ ‘ɹǝzǝǝɹɟ ǝɔᴉɟɟo ɹno uǝdo noʎ ɟI ˙pǝʇᴉɔxǝ ǝɹoɯ sn ƃuᴉʞɐɯ ʇsnɾ s,ʇɐɥʇ ǝsᴉpuɐɥɔɹǝɯ unɟ ɟo sʇɹos llɐ uᴉ ƃuᴉʇʇǝƃ ǝɹ,ǝʍ pu∀ (˙ɥʇuoɯ sᴉɥʇ sn pǝʇᴉsᴉʌ ǝʌ,noʎ ɟᴉ pǝɔᴉʇou ǝʌɐɥ ʎɐɯ no⅄) ˙sƃuᴉɥ┴ ɹǝƃuɐɹʇS ɟo uosɐǝs ʇxǝu ǝɥʇ ɹoɟ pǝʇᴉɔxǝ ʎʇʇǝɹd ǝɹ,ǝM”

Which, when view right-side up and reversed, reads:

“We’re pretty excited for the next season of Stranger Things. (You may have noticed if you’ve visited us this month.) And we’re getting in all sorts of fun merchandise that’s just making us more excited. If you open our office freezer, you’ll find Eggos.”

Unfortunately, the email was sent without the Unicode specification required to render the sentence, turning the message into gibberish.

Email Tourette Syndrome

unwanted code

Sometimes you can end up with gibberish inserting itself in an email for other reasons. In the example above, it looks like the URL was accidentally and replaced with the ALT tag, leaving only the query string. In the examples below, the problem was a matter of placement of conditional comments. Conditional comments are a way to assign special instructions that only Internet Explorer will read. To everything else, they will appear as comments and won’t display. The problem is that they can sometimes show up as text depending on where they are placed in an email.

While we understand the value of conditional comments, people are beginning to migrate away from IE, in favor of better alternatives. You might want to check your subscriber base and see if you even need them anymore.

A Bad Case of Mono

monograms or monographs?

This image came in an email from the normally exceptional email marketers at Email Monks. For the moment, I’m going to ignore the grammatical error in the ribbon banner at the top and concentrate on the type categories shown. I have no problem with Serif and Sans Serif, but there’s no such type style as “Monogram.” These are monograms:

monograms

What they meant was “monospaced.” Their description doesn’t make much (if any) sense either (and one more grammatical error to boot). A monospaced font is a font in which every characters takes the same amount of space, so a lower case “i” will take as much room as an uppercase “M,” even though the two characters clearly require different amounts of space. While the fourth category (Calligraphy) is a legitimate font category, in this case I would have used the more general category of “Decorative” as the final classification (of which Calligraphic fonts are a subset).

Give Me Some Room!

tanga on iphone

This email from Tanga looks fine on a desktop computer, and even a tablet, but reduce it to iPhone size and it suddenly turns into this scrunched up mess. Looking at the code, we see that whoever designed this is much more comfortable with HTML than CSS. The content is rife with deprecated attributes and the designer has used cells with non-breaking spaces to create margins. Either this was created many years ago, or someone needs to brush up on their CSS.

As bad as this is, at least all the content still appears on the page (albeit in a very squished format). Not so for Vibes’ webinar announcement. While it will appear just fine in most email clients. Something in its code just falls apart when opened in Live Mail. We’ve discussed the problems with Live Mail in previous year-end reviews, but now that Microsoft has abandoned it, maybe the folks at Vibes didn’t think it was worth the effort to fix.

Responsible Responsive

Responsive design was all the rage a few years ago. As we discussed in Part Four of our Responsive Email Design series, if you use a standardized template, then setting up a responsive template has advantages. It will mean a little extra work at the start but will yield dividends later on. Clearly, the folks at BangGoods didn’t read that article, because this is how their mailings appear on an iPhone:

This is a perfect layout for a responsive approach. The three columns across is fine for a desktop monitor, but it is rendered almost unreadable on most phones. Media queries that realigned the three columns and enlarged them according to screen size would do a world of good here.

The British Film Institute (BFI) takes a different approach. They do use responsive design, but they only use one column, so the main purpose of the media query is the adjust the size of the tables based on the screen size. This works well for the iPhone:

But not so well for the iPad:

They had the right idea, but set the size change at the wrong point, leading to an unnecessarily small display on the iPad mini.

Unsubscribe? Fuggedaboutit!

Until this point, most of the mistakes we’ve listed have been embarrassing at worst, but these next two aren’t simply bad mistakes—they’re against the law. CAN-SPAM requires the ability to unsubscribe. That can be accomplished a number of ways, but the most common is with an unsubscribe link. If you put an unsubscribe link in your email, it better work. That’s not the case for Proline Tools and Longchamp. In the case of Proline Tools, clicking unsub takes you to the following page:

This suggests that the problem only was temporary, but a second attempt to click on the unsubscribe link a two weeks later yielded the same result.

Similarly, clicking on the unsub link from Wengtek.com takes you to this page:

On the plus side, clicking on any link in the Wengtek mailing took me to this page, so this might simply be an ESP issue. Since the email purported to be from Longchamp, I would classify this one as Spam and move on.

tl;dr

A related problem occurs when you have too much text in your mailings. Some email clients, such as Gmail, will choose to cut off the message with the following notice:

This particular email is from Kohl’s whose list of caveats and cautions could fill a book. When this happens, the unsubscribe link is not displayed. Does that mean the email is breaking the law? Probably not, but it does mean one more step to get to it. In case you’re interested, here is the entire block of legal notices at the bottom of that email (reduced for the sake of brevity):

At least, in this case, the only thing missing besides the footer is a lot of legalese that no one ever reads anyway. Not so for Touch of Modern, whose email gets clipped like this:

Touch of Modern specializes in expensive products for gadget lovers and technophiles, and their emails are often a solid wall of these products. So much so, that they often get clipped for being too long. So how much is missing? When you click “View entire image,” you not only get the footer, but an additional 132 products are displayed as well. They would have been better off reducing the size of their email, concentrating on a few items each time, and using the website to present additional items.

The Good

This year we also saw some nice use of animated gifs and clever subject lines. The leader this year was EmailMonks, who offered games for Easter and Thanksgiving, an interactive Halloween mailings, and some clever videos and gifs. Where the email clients could interpret the code, the games could be played right there in the message. When that wasn’t possible the viewer was linked to the online version. The also get points for their clever use of poster gifs that do a good job of leading the viewer to the linked video (see Using HTML5 in Email: Video).

Cinemagraphs

One technique we were hoping to see more of this year was the use of cinemagraphs. These are the animated gifs that use animation sparingly to create the effect of a live video image. One company that put the technique to good use is Bourbon and Boots, who used a smoking cigar to draw the eye to the image. Subtle but effective, and it captures the essence of the company’s brand.

One of the cleverest uses of an animated gif came from Netflix, but they didn’t stop there. The design concept started with the subject line:

The blacked out lines and the subject matter make us slightly uneasy, but still curious. Upon opening the email, you are presented with a startling animated gif:

[Note: The original gif only goes through its animation one time, I’ve set it up to repeat to make it easier to view.]

A very clever combination of subject line and content used to create an effect.

Until Next Time

That will do it for this year. As usual, most of the errors could have easily been avoided by a little testing before sending. We were happy to that certain errors that were once very common, now only happen occasionally. Marketers are getting more email savvy and template designs are improving. As an added note, I recently heard from Jordie van Rijn from eMailMonday, who has created this pre-launch checklist you can use to make sure everything in order before you hit the send button.

Happy New Year!

A-B Split Testing, Deliverability, Dynamic Content, Email marketing, Infographic, Personalization, responsive design

The Email Game

The Holiday Season is upon us, so we thought it might be fun to offer an infographic in the form a simple game of chance. Of course, your email marketing efforts should be anything but a game of chance. Careful planning, design, and testing will go a long ways toward improving your open rates. Keeping aware of your metrics and avoiding quick fixes, such as list purchasing, will keep your deliverability out of the red zone.

emailgame

You can find more on information on the topics listed in the Email Game in the following blog posts and in the guides and white papers in the Resources section of the main website:
The Complete Preheaders and Snippets Tutorial
Personalizing Your Email Marketing
Using Content Blocks and Dynamic Content
Deliverability Enhanced (downloadable white paper)
Oops! – Handling and resolving email marketing mistakes (downloadable white paper)
Using Text & Images (downloadable guide)
Best Practices Enhanced – Vol. 1: Content, List Management, and Testing (downloadable guide)
Best Practices Enhanced – Vol. 2: Design and Image Management (downloadable guide)
Responsive Email Design (downloadable guide)

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!