Hostile environment

Images are blocked by default, in place of alt text you see “download pictures”. The file weight is displayed below the creative as a further deterrent. Knowing many users pay for data, WP, BB and Android allow the user to manage downloads. Though widespread image blocking makes it hard to get accurate mobile usage stats.

{ Screenshots from Nokia Lumia 800 running WP7.5 “Mango” / screen is 480 x 800px }

From name dominates

The from name - sliced off after ~15 characters - dominates the creative below, which by default is more zoomed out than iOS. You can pinch to zoom in, or use the lesser known double tap gesture but it’s extra work.

Auto scaled HTML text

WP scales some HTML text up depending on it’s container. This results in odd sections of copy being emphasized and occasional formatting issues. Though on the plus side, some pre-header and footer text becomes legible. BTW I’m sure it’s a coincidence that Google’s emails are broken.

Gmail quirks

Media queries are supported in the browser (IE9), Hotmail and Yahoo! Mail but not Gmail. Defining the viewport also works in Hotmail and Yahoo! Mail, but again no Gmail support. Below, the viewport is set to equal the device width. Gmail ignores it and the 600px wide image is zoomed right out. This might be because it’s left aligned, see also Neiman Marcus.

Flat UI vs. 3D

Do users have a harder time distinguishing flat buttons, or is color and size enough of a visual cue? A flat UI like Metro is more email friendly as gradients, drop shadows, glow ect have little support on the desktop. You also have to write more code for iOS-y buttons and it takes longer to draw.

Different UI elements from Android, iOS and Windows Phone 7 -  from Android guidelines.

While I prefer a minimal look, I’m nervous about ditching depth cues altogether. With no hover state a drop shadow can serve a useful function. I also wonder if we’ll outgrow skeuomorphism as touch interfaces become more familiar?

Mobile testing

I’d been using DeviceAnywhere for a while before I got a real iOS device. Within seconds of playing with my email on an iPod, I wanted to tweak the design. You can’t beat seeing where your grip rests, the speed with which you scroll, positions you read in, download times, accidentally triggering links and other newbie errors.

Besides the Lumia, I just added a Samsung Nexus to our testing suite and a Galaxy Note is on the way. I felt it was important to expand the range of Android devices we test on. Though it’s impossible to have every device, so I still supplement with tools like DeviceAnywhere (more preview tools).

Though if you’re a designer it’s worth getting a Windows Phone just to study the design patterns. Also the Lumia has the most beautiful matte screen, it’s like the monolith from Space Odyssey…makes me want to design dark emails all day long.

See a difference?

Here’s screenshots of a 710px wide email (816KB images) on the iPad 2 and 3. The difference in resolution (1024×768 v 2048×1536) makes it hard to do a side-by-side comparison. So I took some photos you can eyeball. Can you tell which is which? I couldn’t at first.

On closer inspection HTML text is sharper on the iPad3, and small image-based text slightly more pixelated. I doubt the average user would notice though. Especially as email read times are in the seconds.

{ HTML text  - purple section is an image - iPad 2 top and iPad 3 below }

I’m not saying your images wouldn’t look sharper if you used hi-res. Of course they would. But that 710px image looks no worse than it ever did on the iPad 2.

Media queries

If you did want image quality on par with native apps there are a few options. Using @media you can switch between different res images based on viewport size or pixel density. Though setting an image to display:none doesn’t prevent all the assets from being downloaded. You could end up forcing a 1.3MB download on mobile users (1MB iPad 3 + 250k desktop + 50K mobile).

Fluid

Instead of sending all viewports the smallest res image e.g. 320px, with fluid you’d do the reverse. Prepare the image at the highest res, set the width to 100% and let the browser resize it. Problem is, you’d still be forcing a hi-res image on mobile users.

{ Play with fluid email }

Server-side

Server-side solutions like DIS detect the device via the UA string then serve up an appropriate sized image. Working from a low-res default you don’t have to maintain a list of every device/client, just a representative selection. Though it’s too fundamental a feature for a proprietary solution.

{ iPod User agent readout via DIS. Frowning at laptop webcam, with Graeme taking screenshot }

Connection speed

Some users are on 3G or 4G, others WiFi. How do you differentiate?  Historically most iPad sales are WiFi. But WiFi reception at a busy conference isn’t the same as at home over broadband, which isn’t always optimal anyway. If you increase file size, load times increase by the same factor, and who wants to download a 2.0MB file at 64k a second…

{ Slow download times impact sales }

With our dynamic video, we calculated the available bandwidth based on the previous group of frames. So we were always monitoring and adjusting the compression/fps/res. You can’t use this technique with a single image though, and there’s no JavaScript support in email.

So even using @media or DIS, we’d be making broad assumptions about bandwidth. Looking at 50 retail emails, 258k was the average image weight (17k-973k range). Worse case, you’d be taking a 2MB gamble by targeting the iPad 3’s resolution.

Alternatives to images

We’ve been saying use more HTML text for years, and more recently CSS3 for buttons ect. Though less time and budget spent coding, and increased creative freedom with images, make this a difficult sell. Especially on a daily send.

Do what you can. Make any reusable components HTML, like navigation and footers. In the Crate&Barrel example, body text within a simple rect was HTML, the more complex areas image-based. One old UK trend, used HTML text at the top of the email, then it would drop off to images. You could also just make your logo hi-res, as it’s usually only a small file. It doesn’t have to be all or nothing.

{ View Next email }

One big image

We use the term “One big image”, though it’s rarely the case. Going back to those 50 retail emails, half of the hero images were sliced up. It’s the only reliable way to add multiple URLs. This means a mosaic of images to prepare and swap, rather than just one. It’s not a show stopper, but it does add to the complexity.

As does asking a designer to create a 1400px layout. Sure we can do it, but it’s an adjustment. One that would also require access to hi-res assets.

ROI of crisper images?

With popular viewports now ranging from 320px-1536px a one-size-image fits all approach is sloppy. With the adoption of Smart TV’s and even cars with on-board email, the problem is just going to get more acute. If we’re not going to wean ourselves off print mag layouts, the least we can do is optimize image downloads.

But until there’s a reliable way of conditionally serving images - that doesn’t make a truckload of assumptions - I’m reluctant to gamble on hi-res.

Twitter API

The latest tweets with e.g. #eslots in them, are grabbed from Twitter’s API and rendered into an email on open. So every time it’s opened, the tweets automatically update. We can also use animation to refresh the stream, without re-opening. We are not limited to hashtags, you can use operators etc. to curate tweets as well.

{ Our Feb 2012 newsletter, pulled in tweets containing #EEC12 }

One hashtag. Infinite layouts.

What you get back from Twitter is just raw data. We then format it into email creative using, “server-side Photoshop”. You can choose to leave out bits of data, like the time-stamp or avatars. Tweets can be composited over any background image, as it’s carried out server-side. On open, it’s drawn as a single foreground image.

{ Twitter chat layout is drawn server-side, so few creative restrictions }

Mobile / tablet / desktop

DIS can apply a different script for each email client or device. So you might narrow the width, change the color palette and decrease the no. of tweets for iPhone vs. iPad. Though by combining dynamic elements with media queries, you get additional control over the static layout.

Augment the Twitter stream

Graeme had the idea of adding players game scores to their tweets. You could even do Twitter mashups, such as combining Twitter with Flickr or Klout. There’s any number of APIs - Facebook, Skype and Goggle Maps are some we’ve played with - but they’d have to add to the gameplay to make the cut.

{ Game scores with tweets }

Email bleeps

Opt to skip tweets that contain naughty words, or replace them with XXX. The naughty words file is customizable, so if you don’t want a competitor’s name in your email just add it in. I’ve mixed feelings about email bleeps, but it’s an understandable concern.

Skype chat

Anyone with Skype can start a conversation with the DIS server (it has its own Skype account). Skype messages via the chat, are then automatically embedded in the email content. So whoever is running the game, can send private Skype texts. Optionally, players can send their own messages to DIS.

It doesn’t have to be text. Below is Graeme and me making a Skype video call to DIS on an iPad, then streaming it into an email on my iPod.

{ Hijacking our Avatar demo in the conference hall at the WhatCounts summit last Oct }

Get out of the way

Graeme wants to see a couple of gamers taunting each other. I want email that’s more intimate and human. Users will have their own ideas. All this tech does is provide a means to communicate, then get out of the way. However it gets used, I believe social integration in email should go both ways. It should be…social.

      ___           ___           ___                       ___
     /\  \         /\__\         /\  \          ___        /\__\
    /::\  \       /::|  |       /::\  \        /\  \      /:/  /
   /:/\:\  \     /:|:|  |      /:/\:\  \       \:\  \    /:/  /
  /::\~\:\  \   /:/|:|__|__   /::\~\:\  \      /::\__\  /:/  /
 /:/\:\ \:\__\ /:/ |::::\__\ /:/\:\ \:\__\  __/:/\/__/ /:/__/
 \:\~\:\ \/__/ \/__/~~/:/  / \/__\:\/:/  / /\/:/  /    \:\  \
  \:\ \:\__\         /:/  /       \::/  /  \::/__/      \:\  \
   \:\ \/__/        /:/  /        /:/  /    \:\__\       \:\  \
    \:\__\         /:/  /        /:/  /      \/__/        \:\__\
     \/__/         \/__/         \/__/                     \/__/

Support

It looked fine almost everywhere I tested, under a range of browsers. The only clients it looked skewed in, were MobileMe and Symbian S60.

Support for ASCII art with pre tag
Email clients
Outlook 2000 & 2003	Yes
Gmail	Yes
Hotmail	Yes
AOL	Yes
Outlook 2007, 2010 & XP	Yes
Thunderbird	Yes
YahooMail!	Yes
MobileMe	Kinda
Apple mail	Yes
Lotus 6.5- 8	Yes
Facebook Messages	Yes
Mobile
iPhone	Yes
iPad	Yes
Kindle Fire	Yes
Android 2.2	Yes
BB	Yes
Windows	Yes

ASCII into clean HTML

If you copy from Notepad into HTML, it collapses, as it doesn’t retain the spacing. If you save HTML from Word, it retains the spacing but adds excess code and styling in the header. Eventually I copied from Notepad into HTML, but wrapped the ASCII in a <pre> tag, which maintains preformatted text.

iPhone

Using the spacing character nbsp instead of the pre-tag, wide layouts wrap and become jumbled on the iPhone (below left). Once I narrowed the width, it rendered fine. Though the pre tag is more reliable.

ASCII with marquee tag?

I couldn’t resist…not only does it render with images off but the file size is only 1.3K. I’ve only seen two emails, using the marquee tag.

                                     ,-~ |
        ________________          o==]___|
       |                |            \ \
       |________________|            /\ \
  __  /  _,-----._      )           |  \ \.
 |_||/_-~         `.   /()          |  /|]_|_____
   |//              \ |              \/ /_-~     ~-_
   //________________||              / //___________\
  //__|______________| \____________/ //___/-\ \~-_
 ((_________________/_-o___________/_//___/  /\,\  \
  |__/(  ((====)o===--~~                 (  ( (o/)  )
       \  ``==' /                         \  `--'  /
        `-.__,-'       Vespa P-200 E       `-.__,-'

Fonts

Use a mono-spaced font like Courier New, which uses uniform spacing between each character. One problem with generating ASCII from a photo - besides being naff and your HTML possibly exceeding 100K -  is you can’t control the output. The resulting, “image” can looked warped in different clients. I also used charset=UTF-8.

{ I look wide under iOS and elongated in Outlook 07 with img converter }

,—,/// Snippet text

You may want to place some copy before the ASCII, otherwise it will show up in the snippet text.

{ Gmail snippet text }

Old school

My favorite ASCII art uses as few characters as possible, its minimal and lite. Though I’ve a hankering to mix ASCII and imagery. If you want to delve more, I’ve listed some resources below.

                            ,
                           //\
                          / | ;
                          | /_|
                        .-"`  `"-.
                      /`          `\
                     /              \
               .-.,_|      .-""""-. |
              |     `",_,-'  (((-. '(
               \ (`"=._.'/   (  (o>'-`"#
    ,           '.`"-'` /     `--`  '==;
   /\\            `'--'`\         _.'~~
  / | \                  `.,___,-}
  | |  |                   )  {  }
   \ \ (.--==---==-------=' o {  }
    ",/` (_) (_)  (_)    (_)   \ /
     / ()   o   ()    ()        ^|
     \   ()  (    () o        ;  /
      `\      \         ;    / } |
        )      \       /   /`  } /
     ,-'       |=,_   |   /,_ ,'/
     |    _,.-`/   `"=\   \\   \
     | ."` \  |        \   \`\  \
     | |    \ \         `\  \ `\ \
     | |     \ \          `\ \  \ \
     | |      \ \           \ \  \ \
     | |       \ \           \ \  \ \
     | |        \ \           \ \  \ \
     | |         ) \           \ \  ) \
 jgs `) \        ^ww            ) \ ^ww
      ^ww                       ^ww

Inspiration

www.heartnsoul.com/keyboard_art.htm#Gallery »

www.story.en.utf8art.com/ »

www.chris.com/ascii/ »

Converters

www.network-science.de/ascii/ (Created the text at the the top of this page) »

www.degraeve.com/img2txt.php (Photo to text converter) »

Tutorials

www.geocities.com/SoHo/7373/howto.htm »

www.ascii-art.de/info/tut_jro.txt »

Related

Using HTML symbols in email

img-html app and pixel art in email

14.5 average no. of opens

Total opens / unique opens = 14.5 (on the day it expired). We usually average 2.5 opens. Though it was spread out from 1 to 980. 20% of users opened 10-50 times, reaching 1000 points and 5% opened 100+ times.

The range of opens reflect users different goals. At 1am Xmas morning, Phil in the UK hammered the refresh 77 times until he’d reached 5,000 points. Chad White, just wanted to get a jackpot. While Tina of NJ, had her eye on the Xmas swag with hundreds of opens within just a few hours.

Players have different motivations which map to the no. of opens

Reward winners straight away

We fudged the way we gave out prizes. We should’ve generated a unique coupon code on reaching 1000 points, that could be redeemed online immediately. Instead we contacted winners via a second email once the game had expired, asking them to send us their addy. I know, I know…

Redeeming real-world prizes for in game achievements. What we did (left) vs. instant reward.

Holidays = mobile

We had ~ 55% mobile usage for the first 48-72hrs (Xmas Eve & Day). Surprisingly we saw heavy play on these days. As people trickled back to work, our Outlook no’s climbed to 21%. Mobile usage evened out at ~35%.

From our sessions data, we know that 10.5% of players opened on more than one client. Though 6% of that was desktop to desktop e.g IE to Firefox. Of the 4.5% that was desktop/mobile: 3% was mobile to desktop, 1% desktop to mobile and 0.5% mobile to tablet.

Client usage before players got back to work

Rethink it for digital

Originally I wanted to replicate the kitsch artwork of Vegas slots. Only it was tough to fit it within 285px. Graeme asked why I was trying to mimic a real slots machine, “Its digital, all you need are 3 icons and some animation”.

Creative that replicates real world objects, act as a shorthand. Users know what to expect off the bat. I still plan to build out a traditional slots demo, the trick is knowing what’s redundant, like page curl effects.

Early drafts including a Halloween skin vs. what we ended up with far right.

Much more to explore

We left a lot on the table for our first game. No reward screen on hitting 1000 or 5000 points. I’d wanted to have animated Xmas lights go off when you hit a jackpot. No highest score table. We discouraged sharing by omitting FTAF, SWYN or a webview link. No Twitter smackdowns or encouragement like, “OMG 100 opens, go Sara!”.

Turns out, you need very little gameplay to have fun. Sure it wasn’t without its flaws, but I’m encouraged. We’re already putting together our next game, with Twitter chat and a highest score table. Game on!

Sessions

The sessions database keeps track of where each subscriber/player is in the game. You can track a session across multiple devices, as its tied to an email address.

So you can award points, publicize a highest score table, have time-specific contests or show the no. of prizes left in a giveaway. We were chatting about inviting friends and playing in clans, so you could pool points.

Server-side Photoshop

Triggered by the sessions data - plus other variables like device, time of day and location - the creative is assembled on-the-fly. We have most of Photoshop’ image editing functionality, such as rotations, scale, blend modes ect. The slots game below is just one alpha mask, font file and script. Nothing is pre-rendered.

Script

Just like a web game, email games need a script (for the tech savvy its not actually a script but a dll). The server-side logic might say, if a player reaches 4000 points or has played two consecutive days then award - tips, discounts, new level, prizes, loyalty points, VIP content or recognition. You can even have a different script for each email client.

Reward screen / Eternity Warriors

Types of games?

Games of chance make the most sense. Slots, dice and spin the wheel games, like the Carl’s Junior app below. Though we’re also developing a virtual pet game and Graeme’s been looking into RPGs. So less Quake, more casual gaming due to the constraints.

Mobile awards program / Carl’s Junior

Real-time streaming in email

We’ve had real-time streaming for 2yrs. It’s how DIS started out, as a new way to do video in email that was superior to Gifs and dynamic. We even added live content. Though there are less demanding applications. We’re only using 4fps to add animation to our slot game for instance, rather than the 12+ we use for video.

Twitter # smackdowns

Part of the fun of playing any game, is taunting other players. We can approximate that, by pulling tweets into an email that contain a hashtag e.g. #emailslots. The real-time stream is an open forum for subscribers. As we’re accessing Twitter’s raw data, we can use server-side Photoshop to give it any creative treatment we like.

On the flip side, Graeme’s been experimenting with automatically broadcasting game updates to Twitter and Facebook. e.g. “I’ve just won the mince pie badge!”. While he can do this via the senders stream. We’d need to gain permission to access each players. Alternatively we could simply prompt users. Demos coming soon…

Prompted to share achievement / Trade Nations

Coach marks

While I’ve no problem using overlays for achievements. I’ve mixed feelings about coach marks. Instructions - often hand drawn - which show up when you first open an app. With only 285px on the iPhone first screen, it’s useful to have prompts that don’t permanently take up space. We added, “Refresh to play” on slots first open.

Coach marks / Snapseed

3d content

Below, the logo, text and 3D character (which is animated) are added on-the-fly frame by frame. Graeme hooked up his proprietary 3D engine to DIS. We can import a 3D scene or individual characters. We were going to do a 3D, “Fatten up Santa”  or “Santagotchi”  game for Xmas, but went with slots instead.

Win Win

In Aug 2010, online games overtook email to become the second most heavily used online activity behind social. They’re fun, drive up opens which can lead to more sales, improve deliverability, great for branding and huge on mobile.

While the business benefits are well proven, our aims are simple. We want to amuse ourselves and users - by at least attempting - to go beyond gamification to making games in email.

Check out Xmas Slots Results

Grab the deck

That was one of the finding’s in this (pdf) Babycenter report, with 78% of moms saying they use email on their smartphone. So when WhatCounts approached us to design a welcome series for SavvyMom, it was no surprise their mobile usage was over 20% (higher factoring in image blocking as BB & Android were only 2%).

With 90% of mobile users on iOS, Brittany Schneider (Director of Strategic Services), Aaron Grey (awesome coder) and I set out to re-design their welcome email. Here’s some of the challenges, with Aaron contributing.

Email 1

View email1 (resize your browser / @media not supported in IE8 or below FF3.5)

Fixed to fluid

16mths ago I wrote how some app sites favor 320px blocks of content, I had the same idea for SavvyMom. 640px wide fixed layouts on the desktop, that would reformat into one fluid column on the iPhone. With content blocks like the navi 320px wide or less.

Hide desktop content

In all three emails we hid the online version link, logo and recovery footer from mobile users. In email 1 we also hid the desktop image. One downside of display:none, is all the desktop code and images are still downloaded. The fluid layout as baseline would have been preferable, but there’s little support for @media on the desktop.

Branding vs. content

Putting, “SavvyMom” into the title text of each email allowed us to hide the logo. Freeing up first screen space, while retaining branding. Here’s a couple of my drafts, with and without the logo.

Font size vs. optimizing 1st screen

We had the choice of keeping the large desktop fonts (left). Or using @media to reduce the font size, moving CTA’s onto the first screen (285px). We went with the smaller title font (right).

Contrast

As we’d reduced the font size, I changed the font color from gray on the desktop to black on mobile devices to aid legibility. I also drafted up a mobile version with more contrast in the background. Though the lighter pastel pink was chosen, to keep things consistent.

Email 2

View email2 (resize your browser / @media not supported in IE8 or below FF3.5)

Swapping images to minimize scrolling

I drafted three options for email2: desktop images, mobile images and no images. We picked alternate mobile images, they were instructional so I didn’t want to hide them. Support for jump tags is flaky, it takes two taps on the iPhone, but it’s something to test. Though the best advice to minimize scrolling is use less copy.

S-curve?

In her audit, Britanny noted that SavvyMom’s s-curve layouts consistently out-performed vertical aligned layouts. Only I wasn’t sure you could go from an s-curve into a single column, and have all the content in the right order. So I prepared two options. Even Aaron had doubts, before finding a working solution:

“I was able to use @media CSS to remove the desktop image from each section and bring forward the mobile image. I accomplished this by defining the mobile images in the @media CSS as background images and then calling them into the HTML using a div tag. I also used @media CSS to center the call to action buttons for the mobile version.

In email 2, I built a two column table for each content block. Then, I was able to use @media CSS to make the table size to the window, decrease the table cell width that held the image to 0, and then hide the image. So the 2nd column cell of the middle content block appears to bump over to the left in the mobile version and all three remaining content blocks line up vertically”.

Here’s the code (or just view source in email 1, email 2, and email 3):

@media
#main .wrap { width:100% !important; }

#main .photo { display:none !important; width:0 !important; }

HTML:
<td align="left" valign="top" width="320" height="100" id="main" class="photo">


Email 3

View email3 (resize your browser / @media not supported in IE8 or below FF3.5)

Designing for touch

All targets were proportioned for touch. The navi is 320×44px and CTA buttons are CSS3 and finger-sized. The copy has only one link per paragraph. You have to be careful when fluid text wraps, that you don’t end up with one URL on top of another.

We also tested on real devices. Moving quickly from sketches, to Photoshop mock-ups, to testing and refining on iPod, iPad and Android. This enabled us to finesse the footer, which was initially prone to mistaps. As Aaron points out,

“To create the desired spacing in the footer and an easier link to tap, we added padding, increased the font size, and increased the line-height in the @media CSS”.

Segment by context

Designing this series, reinforced what a powerful tool media queries are. But it also highlighted limitations around image use, desktop support, placeholder content and sharing HTML across desktop and mobile.

To be fair @media never claimed to be a cure all, it simply changes your layout and does a fantastic job. But by itself, screen size is a vague indicator of context. We need more real-time data, like time of day and location.

Now that we’ve got a handle on mobile layouts, I’m left thinking about what Paul Gelb of Razorfish said recently,

“In two years or so we are planning for a shift where we will segment not by device anymore but by behavioral context. Is it at home, is it on the go…”

Update: when compared to the control, email 1 in this series saw a 3x lift in click-to-open rate. Comparing mobile vs. desktop views. 12% of those who opened the redesigned email on a mobile clicked, and 6% who opened on the desktop clicked (Remember that New Look study by Responsys, that found mobile users opened email more frequently which lead to an > mobile sales).

I found it interesting that 5% of all clicks came from BB users (which was the same as iPad also at 5%), when their usage stats indicated they had only 1% BB.

Fluid emails adapt their layout to different device widths. As the browser widens and narrows, the layout adjusts to fill the available horizontal space. That’s because container widths are set in percentages rather than pixels.

Max-width

On a wide screen monitor, long lines of text can become hard to read. Also fluid images can expand well beyond their actual size. To fix this we set a max-width, in this case 550px (default width of the image).

“IMG style=”width:90%; max-width:550px”

Unfortunately max-width is not supported in Outlook07 or IE 6.

Here’s the original test template (here’s how it looks in IE6).

Fixed to Fluid

Using @media we can switch from a fixed layout to a fluid layout, below a certain screen width.

So we’d say: make the width=550px, BUT if the screen width is below 660px make the container width=100%.

Instead of looking stretched in Outlook07 and IE6, the width is now capped at 550px on the desktop. Though when viewed on a small screen, the layout is fluid all the way down to a 176px wide Sony K750.

Here’s the test template with @media (here’s how it looks in IE6, Outlook 07 and iPod).

Flip it?

In the above example, mobile browsers that don’t support media queries would default to the desktop template. Alternatively we could set the fluid layout as our baseline, then switch to fixed on larger screens. Though lack of @media support would mean many users (Outlook07/ IE8 & below) would see the mobile layout.

Keep in mind…

When you send out high resolution fluid images, the mobile browser has to resize them e.g. 1024px down to 320px. Not only does this slow things down, but many users pay for bandwidth. Ideally you want to serve the right sized images to the right device.

Many brands can still benefit from this max-width workaround, Obama for one. His 2012 campaign consistently uses a fluid email template, placing accessibility above all else.

Different creative for Outlook users

Via the UA string in the HTTP request header, our dynamic image server (DIS) knows which client is being used to view an email. So were able to serve different images to different clients on open. This enabled us to fix the hacked off gradient, by generating a different foreground image just for Outlook users.

Context-aware

This capability has me thinking about the problems you could solve by serving alternate images to desktop and mobile users. Particularly retailers, who typically use one large hero image. The downside is extra prep. Though you’d still send the one HTML file, but with a dynamic image URL.
Legibility - Banana Republic’s desktop layout becomes unreadable when scaled down (left). The text is too small, CTA’s tiny and photo detail is lost in translation.

Desktop creative on the iPhone                           Alternate iPhone creative

Emphasis - Compare the email on the left with Gap’s mobile site on the right. It’s the same creative, given a different treatment. Not only are elements designed for touch, the store locator is given increased prominence. We can finesse our content to better serve mobile users; in this AE email you could emphasize the short code.

Gap email                                                                      Gap mobile site

Image resizing: In the Gap email above, the hero image is 109k compared to 38k on the mobile site. I looked at 50 retail emails, and found 258.4K to be the average weight of the images. Ideally you’d serve smaller resolution images to mobile users, increasing download speed and reducing data charges.

650px wide and 80K                                                320px and 25K

Why not just use Media Queries?

While writing this I’m working on a welcome series that uses media queries, I’m a fan. Nevertheless there are limitations with image replacement.

Performance: Using @media, your desktop images get downloaded along with the mobile images. So instead of a 50K download it’s a 300K download. Same if you hide a large desktop image, while not visible it’s still downloaded. With DIS, you only request the small mobile image. Resizing is done server-side, not on the users mobile browser. When streaming, you can also adjust image compression, depending on the bandwidth.

Support: Media queries are not supported in IE8 and below, older BlackBerrys, anything below Firefox 3.5, WP7 and most desktop clients like Outlook. EmailonAcid found support to be, “buggy to say the very least” on Android. Dynamic images have universal support.

Capabilities: Dynamic images are programmable and assembled on-the-fly. You can update time-sensitive offers after send or generate images based on time of day and location e.g. If its 7am on the East Coast and your on an iPhone - heck and the weather is cold - generate this image on open.

Media queries are a thing of beauty if you want to rework your CSS. I plan to use them in conjunction with DIS. They’re also free if you know how to use them. But there are solid reasons why mobile web devs have started to build responsive image solutions to manage their image assets.

Design for mobile & send to desktop?

This has worked for me with a skinny layout. But it becomes strained if you have a 600-850px wide template. Your buttons, text and images can become jumbo-sized on the desktop, in order to be legible once they’re scaled down. It just depends on the execution, I have seen some slick designs using this tactic.

Though you’re still sending large desktop assets - like 677K worth of images - to mobile users. When Google Maps was reduced from 100K to ~80K, traffic was up 10% the first week and 25% in the following three weeks.

Mobile email is more likely to be “in bed” than “on the go”. But I still think simplified layouts are a safer bet. Small screen sizes mean you can view fewer products at a time (though here’s an interesting idea).  Whereas the desktop can accommodate more detailed imagery and exposed product, without sacrificing clean design.

Goodbye editorial layouts                                      Hello glance-friendly layouts

Nothing’s perfect

Skinny layouts float in a sea of white space, fluid layouts rock but we’ve no max-width support in early IE or Outlook, media queries download desktop assets that mobile users don’t need, wide scalable layouts come with large file sizes and alternate images require extra resources.

Which tactic you use will depend on your audience, the devices you’re targeting, if you plan to serve identical creative to desktop and mobile, your resources, how image heavy your creative is and if you have a mobile commerce site.