Grab the deck

187 slides and links to any resources mentioned (click green blocks). There’s a few slides that aren’t in the video - though the video shows responsive emails working in the browser - so its worth checking out both.

Starbucks reminded me that users aren’t always checking email under ideal “office testing” conditions, and to look into new ways to reduce the file size of desktop images. To that end I went back to basics, running this 508K Gap hero image through a bunch of image optimization tools.

Tools

Original 508K image  view                                                  Optimized via RIOT 84K  view

Click “View” to see the full-sized image that each tool produced.

RIOT

RIOT was my favorite, it cut the 508K image down to just 84K at 70% compression. I liked the interface and control it gives you. Though unlike Kraken and jpegmini you have to install it on your system. For Mac users imageoptim also did a great job, again it’s something you install.

RIOT interface

Back to basics

Image optimization is an easy win for improving mobile load times, and can be done without visibly reducing the image quality. I usually save images out of Photoshop via “save for web” at 70%, but with these tools I’ll be able to save an extra 30% or more. Here’s a few more comparisons using RIOT:

Neiman Marcus original 60K  view                                       RIOT at 85% 37K  view

Horchow original 162K  view                                              RIOT at 70% 80K  view

Hugo Boss original 260K  view                                            Hugo Boss at 70% 59K  view

media query support
iPhone native	Yes
iPhone Mailbox app	Yes
iPhone Gmail app (not native Gmail)	No
iPad full-sized native	Yes
iPad mini native	Yes
iPod Touch native	Yes
Android 2.1 Eclair native client	No
Android 2.2 Froyo native client	Yes
Android 2.3 Gingerbread native client	Yes
Android 4.0 Ice Creme Sandwich native client	Yes
Android 4.1 Jelly bean native client	Yes
Android Outlook Exchange via native client	No
Android Outlook.com app	Yes
Android Gmail app	No
Android Yahoo Mail app 1.4.6 & 2.0	No
Microsoft Surface tablet (outlook.com/hotmail)	Yes
Windows Mobile 6.1	No
Windows Phone 7	No
Windows Phone 7.5 (Mango)	Yes
Windows Phone 8	?
BlackBerry OS 5	No
BlackBerry OS 7	Yes
BlackBerry Z10	Yes
Palm webOS 4.5	Yes
Original Kindle Fire + HD (New vr. of Silk) native client	Yes

Platform versions

You need to know how many users are on each platform version to get the full picture. For instance ~96% of Android users are on version 2.2 and up. Which means they’ll get the mobile layout if using the native client. 28% of BlackBerry users are using OS 7 according to this chart.

I can’t find recent Windows Phone stats, though Microsoft has been aggressively pushing 7.5 upgrades. Since May 2012, they’ve been preventing version 7 users from downloading apps from the Marketplace. The post also states, “Most phones are already running Windows Phone 7.5″.

While there are grey areas - like how many Gmail app users we have - iOS, BB and Android all support responsive email design in their latest platform versions.

Update: we’ve had mixed reports on WP8 support, while we own a WP7 and WP7.5 we don’t have a WP8 phone so haven’t been able to confirm this ourselves. Anyone running WP8 let me know…cheers!

{ Here’s how it looks on the Galaxy Note - 1st email uses CSS bg images 2nd is the workaround }

We tried it on three of our Gingerbread devices - S2, Galaxy Note and Ace - and the same thing happened. So we did more testing and confirmed that CSS background images are not supported on Android Mail 2.3. Though background images are supported if defined in the HTML.

Unfortunately GB accounts for 60% of Android’ marketshare, so it’s not something you can write off. Though CSS bg images are supported in later versions like Ice Creme Sandwich.

Swapping content

This is important as you often use background images to swap content in responsive email designs. It’s how we first came across the problem ourselves, trying to adjust the header on this template a few months back.

I’d forgotten about it until I received this responsive email from Pinterest (not one of mine, though slick design).

They’ve run into the same issue we were having, their hero image displays for a second then disappears. It’s an easy one to miss as the images are drawn briefly, so when you run it through a static preview tool they’re visible.

Workaround

There are other ways to hide mobile content from desktop users. One of the workarounds we’ve been using is “cell collapse”. You can view a demo here and view source. It will look blank until you resize your browser down, then an image will appear (not in early IE).

There is an empty table cell with a   (Non Breaking Space) in it which allows the cell to draw at whichever dimensions we specify. You may wish to use a transparent Gif set to display:block and set line-height etc. for code conformity and maximum support The cell contains a background image, which is defined as a cell property not via CSS. So if via CSS we define its width and height as zero and it’s display property as none, it will not be drawn. However if we set the width and height to match the background image at a certain breakpoint, the image becomes visible.

Possible fix

Ideally you just want to use CSS bg images rather than a hack. Graeme thinks there could be a fix - it is weird how it draws it at all - we just haven’t had time to chase it down. If you figure it out let us know, but for now if you’re deploying responsive emails I just wanted to give you a heads up.

Since 09, the progression of tools I use to test mobile email looks like this: free online tool like iBBDemo > DeviceAnywhere > iPod touch > one device from each major platform > device lab.

DeviceAnywhere quickly became a lifesaver, but paying by the minute and clunky interactions drove me to buy an iPod touch. It was a relief to finally test the speed and ease with which users interact, ergonomics, reading postures, usage patterns and performance.

Then as so much of our work became mobile, adding more devices seemed like a legitimate investment. Not just in QA, but in our design skills as it allowed us to study each platform. Today we’ve 31 testing devices - mostly purchased new and unlocked from Amazon - ranging in price from $55 - $600. There’s more affordable ways, like buying from eBay or places like Gamestop which sell used devices.

I’ve had some emails asking about our mobile testing set up. So here’s what we currently test on, how I’ve rigged it up, why we chose these devices, and which I think are essential or an indulgence:

iOS

Most of our clients stats show high iOS numbers, so these were the first devices we purchased. An iPod touch is a great buy, it runs the same email client as the iPhone and costs $199 without the data plan hassles. If the iPhone 5 has a larger screen and there is an iPad mini we’ll have to add both (yep added these).

1.  iPod touch 640 x 960  OS 4.3.5

2.  iPod touch 640 x 960  OS 5.1.1

3.  iPod touch 5 640 x 1136

4.  iPad 2 1024 x 768 OS 4.3.5

5. iPad 3 (2x resolution) 2048 x 1536 OS 5.1.1

6. iPad mini 1024×768

Android

We’ve seen some quirks across different Android versions relating to responsive email design. CSS background images not supported, some issues around URLs coupled with progressive disclosure and other weird happenings.

If you buy one Android, run Gingerbread as it accounts for ~60% marketshare. You can pick up an older model like our Galaxy Ace new for $199, which came with GB installed rather than the advertised Froyo. Though ideally you want to own a few running different platform versions and screen sizes ect.

7. LG GT540 - 2.1 Eclair, 320 x 480

8. Motorola Defy - 2.2.2 Froyo, 480 x 854

9. Samsung Galaxy Ace GT S5830M - 2.3.6 Gingerbread, 320 x 480

10. Samsung Galaxy S2 - 2.3.6 Gingerbread, 480 x 800

11. Samsung Galaxy Nexus - 4.0.4 Ice Cream Sandwich,  720 x 1280

12. Galaxy Note - 2.3.6 Gingerbread, 800 x 1280 “Smablet”

13. Nexus 7 - 4.1 Jellybean, 800 x 1280 7″ tablet

14. Android mini PC - runs 4.0. Hooks up to any screen like your TV, comes with Gmail app…nuts for $55.

Windows Phone

Originally I wanted the Lumia just to play around with metro. Then we realized that in order to take screenshots you have to become a developer (don’t ask total nightmare). So as we had it set up, Graeme started tinkering with Windows dev and bought a couple more phones. Hopefully their numbers will pick up with WP8 and Surface as its a lovely UI. Though not essential to the US market just yet.

15. Nokia Lumia 800 running WP7.5 “Mango” screen is 480 x 800px

16. LG-E900 WP7 screen is 480 x 800px

17. Dell WP7 screen is 480 x 800px (this one’s wacky has a slide out keyboard)

18. Surface tablet Windows 8, screen is 1366 x 768

BlackBerry

I admit I was late getting into BB, though I’m really interested to see where they’re heading with BlackBerry 10 (update: just added slick device!). OS 6 is webkit and supports media queries, so its not as bad as you might think. Going by this chart ~53% of BB users are on 6 and above. Go to any fancy lunch spot in LA and it’s all iPhone’ with a decent smattering of BlackBerry’ and hardly an Android in sight. If you’re targeting certain demographics or enterprise level b2b, then there’s still a lot of BB usage out there.

19. Blackberry Bold 9900 - 640 x 480 screen running OS 7.1

20. Blackberry Bold 9780 - 480 x 360 screen running OS 6

21. Blackberry Curve 8900 - 480 x 360 screen running OS 5

22. Blackberry Tour 9630 - 480 x 360 screen running OS 5

23. Blackberry Z10 - 768 x 1280 screen running OS 10

Kindle

I love my original Kindle, for $139 you got free 3G. I was surprised when the e-reader was first released to see a number of comments in the forums about accessing email. You can and many people do in a pinch via the experimental browser. It’s definitely worth getting a 7″ tablet like the Nexus 7 or Fire which has been a big seller and costs $159-$199. We’ve also pre-ordered the Paperwhite and Fire HD which has a new email client.

24. Original Kindle 3G - 600 x 800 screen - can browse webmail via the internet - greyscale

25. Kindle Touch 3G - touch screen webmail - greyscale (bit unresponsive rarely use it)

26. Kindle Paperwhite 3G - experimental WebKit-based browser

27. Kindle Fire 7″ tablet - Silk (based on Android vr2),  apps like Gmail 600 x 1024

28. Kindle Fire HD tablet 7″ - New version of Silk (Android). Default client, Gmail, Hotmail and Yahoo 1280 x 800

29. Kindle Fire HD tablet 8.9″ - New version of Silk (Android). Default client, Gmail, Hotmail and Yahoo 1280 x 1920px

Palm/WebOS

The Pixi is a great little device, it’s a shame about webOS as it’s a nice UI and renders email well. The Treo runs Windows Mobile 6 which is a precursor to WP7. It uses touchscreen and a little 5-way button to navigate. Actually between the BB qwerty keyboards, trackball navigation, slide out keyboard on the WP7 and the Galaxy Note stylus it’s a reminder that touchscreen isn’t the only input mode.

30. Palm Pixi Plus – 320 x400 screen - Palm web OS v1.4.5 (our cheapest at $85)

31. Palm Treo Pro – 320 x 320 screen – Windows mobile 6.1 (Precursor to WP7)

Set up & peripherals

Tired of devices taking over my desk and low batteries, I recently got organized. I’m calling it a “device lab” because it sounds good…but it’s just a table with a bunch of phones/tablets hooked up to USB hubs:

Sofa table, great find from Ikea. Long and narrow with 2 shelves, takes ~12 devices on each level. $59.

Tons of USB cables to keep the everything charged

Three 5-port USB hubs

16 of these stands

Blat, a command line email program we use to send tests

Extra flash memory for some older devices to store screenshots

For screenshots you’ll need to install apps, desktop software like visual studio and dev kits for some devices.

Acrobat - for organizing and sending those screenshots to clients as a PDF.

Install a range of clients on each device: native, webmail apps, Outlook exc. and popular apps like Sparrow.

Couple of data plans to test connection speeds. You can dodge for a while using wifi, except for BB.

Your call

Whether you go the real device route or stick with preview tools is your call. Some of our coders work remotely and use preview tools before sending tests to us, so a mixture works. Owning just 2-3 devices can make a difference; besides testing you accumulate everyday observations like how I don’t like to rest the iPad on my belly after dinner…little things.

I’ve definitely noticed we hammer the QA in a way we didn’t used to, sending multiple tests in quick succession without having to consider the cost or wait for previews. Debugging and mobile R&D is a lot easier and more important than ever with responsive design techniques to figure out.

I remember when Graeme used to do mobile game dev for feature phones back in 2005. The company he worked for had ~60 real devices, plus a database with hundreds of device specs listed. Compared to that level of fragmentation I have it relatively easy. As for emulators, Graeme’s used them for 10+yrs and he’s never found one that accurately mimics the device.

Sure we’ll have to add new devices occasionally, say five a year at ~$2,500. Though considering mobile email is our core business, it’s a reasonable annual investment given the learning’s and benefits. Ultimately we just feel we can get a better handle on the craziness that’s mobile email with the actual devices in our hands.

It’s dimensions vary - see grid of grim - though I use 300×230px as a rough guide. It’s worth optimizing this area in your desktop layout, regardless if you’re using media queries as @media isn’t supported in the Gmail app.

1. Images blocked

Assume the worst when designing for Android. Compare The Bay (left) with Timberland’s cleverly placed HTML.

2. Color the pre-header

Black pre-header text against white blends with the UI chrome (left). Draw the eye with a colored bg or copy.

3. Encourage scrolling

Prompt users to explore beyond the default view. This Celeuma email has a 57px wide “Scroll me” column.

4. Style Alt text

Style your logos alt text. Crutchfield with images disabled (left) and enabled.

5. Vertical navi

Just make sure it’s designed for touch, with plenty of vertical spacing. MAC (left) Gilt (right).

6. Progressive Disclosure

Users can tap to reveal extra content from within the first screen. Thanks to Campaign Monitor for the image and write up. Although it only works in the native client, there are fall backs in place. Also see, Hint and reveal.

7. Color tables

It aids branding and recognition with images disabled.

8. Pixel art fallback

Taken a step further…place fallback pixel art just in the preview area. See Pizza Express and MAC. Thanks to @becskr for the MAC screenshot below right. Also see mobile pixel art and img-HTML app.

9. Left rail

Add a 300-320px wide left rail. Test the alignment of copy/images. MyHabit (left) Fab (right)

10. 14px and up

You can’t use @media to increase font sizes in the Gmail app, so make your desktop copy at least 14px.

11. Fluid grids and images

Using percentages your content adjusts to the width of the viewport, even in the Gmail app. More on fluid layouts here and here.

12. Design in chunks

This Crate&Barrel email looks beautiful on the iPhone and iPad, but it’s hard work on Android. Scalable layouts are often centered and spread across multiple screens, requiring lots of scrolling. You can fix this in the native Android client with media queries, but the conflict remains in the Gmail app.

{ iPhone far left / Android right, have to scroll across width of layout to read offer }

I bet the people who cited “too much scrolling“, as the reason mobile email is difficult to read were Android users! Get to your offer in the first 1-2 chunks, ideally you want it to fit on one screen like Timberland up top.

Best guess

If I had to guess I’d say most Android users are viewing email in the Gmail app. Firstly it’s easier to access than the native client. Secondly Gingerbread is currently running on ~60% of all Android’s. The native client on Gingerbread doesn’t block images by default, the Gmail app does.

If the majority of Android users were downloading images, I’d expect to see higher Android usage stats. Even if I’m wrong and it’s all due to poor user experience, I still plan to use more fluid layouts as a fail-safe for non @media enabled devices.

Android only displays the top left-hand corner by default and those dimensions vary. While there’s not one “fold”, you still want to try for some level of optimization. I created this grid showing the default view of eight Android devices and thought I’d share. Just align your creative top-left.

Download grid of grim (Zip 450k) 

(above image not actual size)

The grid dimensions are based on the eight Android devices we currently test on:

1. LG GT540 - 2.1 Eclair, 320 x 480

2. Motorola Defy - 2.2.2 Froyo, 480 x 854

3. Samsung Galaxy Ace GT S5830M - 2.3.6 Gingerbread, 320 x 480

4. Samsung Galaxy S2 - 2.3.6 Gingerbread, 480 x 800

5. Samsung Galaxy Nexus - 4.0.4 Ice Cream Sandwich,  720 x 1280

6. Galaxy Note - 2.3.6 Gingerbread, 800 x 1280

7. Kindle Fire -  Silk,  600 x 1024

8. Nexus 7 - 4.1 Jellybean, 800 x 1280

Each device is on a separate layer in the PSD, so you can look at them individually. Android groups screens into four sizes: small, normal, large, and extra large. We tried to cover that range, along with different platform versions when buying devices. Though Gingerbread currently dominates at ~60%, followed by ICS then Froyo as of August 1st.

Native vs. Gmail

To complicate matters the native client and Gmail app display differently. I’ve recorded both in my grid. We don’t have a ballpark of how many Android users uses prefer the Gmail app over the native client. Image blocking makes it difficult to collect stats and I’ve heard differentiating the UA string might be an issue.

{ Native client on S2 and Gmail app on S2 with UI obstructing the bottom }

Optimize left-rail 2nd

I never scroll right on Android unless prompted. I’ll look at the preview pane, maybe enable images and if I’m interested scroll vertically. The left-hand content then needs to fit the screen, or I’ll delete it. I’ve seen similar behavior from other Android users click-thru data. Although not conclusive, I’m going with this theory for now.

These Next and Banana Republic emails are years old, but a left rail would work well for Gmail app users today.

CTA alley

Wherever you touch the screen, this Android tool draws a line like Etch-a-Sketch. It records the co-ordinates, speed and input size (e.g. tip of finger).

When holding the phone one-handed and using my thumb, my swipe path typically looks like the screen on the left. When holding the phone in my left hand and using my right-hand finger to scroll, it looks like screen right.

In most cases I prefer the lower middle, to bottom right-hand side of the screen (right-handed). I call these areas CTA alley on the grid. Users hand sizes will differ, though the areas we can comfortably reach remain the same. There’s more designing for touch tips here.

@media on Android

Android’s native email client supports media queries, the Gmail app doesn’t. When designing responsive layouts, I still try to optimize Android’s preview pane in the desktop layout as I know Android Gmail users will be viewing it.

{ View full template here }

I tried to get pertinent info onto the first screen. Gmail (left) and native client (right). Leaf logo the only image.

If using max-device-width: 480px, it doesn’t trigger the mobile build on a high res Android like the Nexus…max-width: 480px will. It’s screen width vs. viewport width. Also why you can’t resize your browser to test mobile layouts if using max-device-width: 480px, as your desktop monitor likely exceeds that res.

{ 480px breakpoint triggers mobile CSS in native client on 800 x 1280px Galaxy Note / “Gigantiphone” }

Zoom

The zoom/pinch gesture isn’t supported in the Gmail app, except the Kindle Fire which now has a “zoom mode”. The native client on the S2, Ace, Defy, Note and LG let you zoom in and out to view the whole email.

The native client on the Galaxy Nexus (ICS) and Nexus 7 (Jelly bean) only let you zoom in on the default view, not out. Like image blocking, zooming is a mixed bag and we’ve no way of knowing either way.

Orientation

I only mapped portrait mode in the grid. The default screen in landscape is filled with chrome on most Android’s, so here’s hoping it’s not popular. You sometimes have to reload images when switching orientation, so that’s another deterrent. The Nexus 7 comes with orientation turned off by default, it’s fixed in portrait. The native client on the Nexus 7, S2 and Note have a split screen in landscape.

{ Native client on the S2 }

Fonts

Users can alter the system font and size, but it doesn’t affect your styled HTML. It’s only applied to the surrounding UI. Worse case, your subject line might be shortened but your creative won’t be affected.

No 1st screen on Android

There’s so many different Android screen sizes, trying to map them all would be nuts. I just wanted to get a feel for how much that default view differs on popular devices. While having a fixed-width guide is somewhat delusional, I’ve found it useful when blocking out desktop and adaptive layouts. Especially considering the Gmail app. Obviously a fluid layout with media queries layered on top would be best, but most emails are still fixed-width, or at best px-% hybrids.

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 its 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), native email client, Hotmail and Yahoo! Mail but not Gmail. Defining the viewport also works in the native email client, Hotmail and Yahoo! Mail, but again no Gmail support as it strips out the header. 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 Galaxy 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 third party 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.