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

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, are great for branding or ad impressions 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. You can also adjust image compression, depending on the device/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.

1. No user reconnaissance

Ignoring user context

65% of US adults sleep with their phones on or near their bed. So its no surprise that peak mobile email usage takes place at 7am, probably right after the alarm on their phone wakes them up.

We are designing for users with blurry vision, poor co-ordination until after their first cup of coffee and little time to spare. Goals? shower, what to wear, breakfast and maybe a hangover cure (yeah people also read mobile emails drunk).

2. Dismantle cluster bombs

Clusters of links stacked closely together, mistaps unavoidable.

Most pre-header links including the, “mobile version” are not designed for touch. Fonts are tiny and the lack of vertical spacing makes it impossible to avoid a mistap without zooming in.

Zooming or pinching is a multitouch gesture which requires two hands, further inconveniencing one-handed users.

It’s not just pre-headers that need to be re-evaluated. Check out the stack of impenetrable links in Esquire’s email and the table of contents in Smashing Magazine’s.

The Apple Human Interface Guidelines (HIG), recommend a minimum target area of 44 x 44 points.

3. Search & rescue the CTA

Tiny call to action buttons, impossible to see at a glance let alone tap.

When it comes to buttons app designers have realized you can never be too obvious. Mobile users are often distracted, for instance 62% of people use their mobile while watching TV.

Compare a typical in-app call to action with the email on the left.

In-app buttons are at least 44px high, positioned were the thumb naturally rests and expand across the width of the page.

That way it doesn’t matter if your holding the phone in your left or right hand. Even if a user is right-handed, they’ll switch hands when multitasking -  e.g. eating lunch - then switch back after they’re done.

4. Ergonomics MIA

Some parts of the screen are easier to reach than others.

Touch screen input is via fingers and thumbs, often one-handed. Pay attention to how users grip a device, it can improve the usability of your email.

Place popular controls such as, “Web View” within easy reach of your thumb. Less popular or sensitive content such as, “Unsubscribe” place bottom right, as it’s awkward to bend your thumb back.

5. Friendly fire mistaps

Touch targets in close proximity to the toolbar.

The Windows Phone 7 UI guidelines recommend that you increase the size of your touch targets, if they are close to the edge of the screen. Ideally leave some padding above the toolbar, as its an area susceptible to mistaps.

6. Camouflaged creative

Creative that blends into the background making it illegible.

Poor contrast is heightened on tiny screens, making small elements hard to read. Add in partial attention, who knows what lighting conditions and white text on a gray background is not advisable.

It’s always worth doing a grayscale check for mobile emails.

7. Navi Fubar

Messed up navigation or pre-header due to auto-scaling text.

If your HTML text is under 12px, the iPhone will automatically scale it up potentially breaking your layout.

To turn off auto-scaling add the following code (or make your fonts bigger):

style=”-webkit-text-size-adjust:none”

8. No design element left behind

Half measures and inconsistent design.

This email is great if I’m shopping for shoes, not so great if I want to shop, “NM Kids” via the navigation.

While small steps help, it’s frustrating for mobile users to be barred from parts of your creative. One study found poor mobile usability on par with visiting the DMV or being stuck in traffic.

9. Lack of in-field testing

Preview tools rock but for nuanced design supplement with real devices.

Get to know the platform you are designing for, or risk annoying users.

It’s only because I own an iPod that I know how easy it is to scroll, how long it takes to load, that my thumb dislikes the bottom right corner, how cartoonishly responsive the interface is and that it has an annoying habit of flipping orientation when I’m lying in bed.

Designing for touch is a lot easier when you have a real device to interact with.

10. Tadpole training

Many users are new to touch gestures and carry desktop baggage.

When I first started using touch screens I’d avoid swiping over linked areas. I was worried I’d accidentally trigger a URL, so I’d look for, “safe” paths to navigate around the page.

Keep in mind that some users have only spent months using touch screens, compared to decades with a mouse.

Mobile designers are also tadpoles, conventions are murky e.g. with no hover state how do you indicate an element is linked without resorting to buttons everywhere?

Users don’t know where they can click. With iPad UIs, we’re back to square one. We haven’t seen this since  mid-1990’s -  Nielsen 2010

This ambiguity, means there’s an increased risk not all users will interpret your design as intended.

I’ve committed every misfire on this list and many I’m not yet aware off. The only way to refine your skills is to give it a try.

Web users spend 80% of their time looking at information above the page fold. Although users do scroll, they allocate only 20% of their attention below the fold -  Nielsen March 2010

Luckily there are design tricks to encourage scrolling, here’s 12:

1. Diagonal lines {View}

A continuation of the title text, the diagonal line cleaves through the creative drawing the eye downward.

2. Scavenger hunt {View}

If you map out a clear path through your creative, users can’t help but follow.  Also see the mother of all scavenger hunt emails, by Localsknow.ca. Both examples incorporate game play to engage the user.

3. Hijack the Navi {View}

A partial view of the creative captures users curiosity in the preview pane. They’re compelled to figure out what lies below.

This example courtesy of Chad White, was one of the 2009 Hall of Fame inductees. A riff on this is this Easter Bunny email and Clinique email.

4. Animation {View}

Similar to the bunny email above, the animation in this J. Crew email compels users to explore down the page. Also see Saks and Bed, Bath and Beyond.

5. Legs in the air {View}

Can legs in the air really be a category? I’m not sure but here’s two more. The promise of nudity and unusual composition acts as a teaser.

6. Big Arrows {View}

Hard, horizontal lines deter scrolling. The arrow shaped dividers invite further exploration.

Though keep paragraphs of text short if you want people to keep reading.

7. Super tall element {View}

Big bags, stockings, tall ladies and piles of presents…all super tall design elements that indicate further content.

8. Scannable organic layouts  {View}

Organic or editorial style layouts, are easy to scan with no hard horizontal lines to break up the flow.

9. Chain link {View}

Similar to organic layouts, chain link layouts connect each product via a design element. Dotted lines, diagonal lines or scrolls…anything that maps out the route the eye should take.

10. Vertical lines {View}

Vertical lines encourage scrolling, whether it’s a big arrow or vertical stripes. 

11. Teaser content {View}

Mobile users check email during quick breaks, so important content should be viewable on the first screen. If your content overflows then allow some teaser content to peek through.

Unlike on the desktop, we know where the fold occurs. Stay ignorant, and you end up cutting off your CTA.

12. Numbered lists {View}

Everyone loves a list, here’s another example from Sephora.

Morsel:

Eye tracking reports by Nielsen, found the very bottom of a page often attracts additional attention.

They recommend, “While placing the most important stuff on top, don’t forget to put a nice morsel at the very bottom”.

So here’s mine…last October Clicktale found that 20% more visitors continue to scroll when using larger screens vs. tablets. Attention time also more than doubled over that of small screen users.

Also check out David Hoang’s post, “1996 Called - It Wants “The Fold” Back“. David argues users don’t mind scrolling if given a good incentive and the title made me laugh.

Worried users won’t scroll horizontally? Here’s the link activity per screen: 44% 30% 14% 12% nicely spaced out. Around 20% opened on a mobile, 28% in the evening.

At 978px wide, it was a redesign of my first horizontal mobile email from 14mths ago. Here’s before and after screenshots.

Unpacked deck

The idea was simple. Build it like an unpacked mobile app, laying each screen side by side. Each page would be roughly 320px wide, with elements in the right position and size for touch.

This one I built for Mobile Spinach last Sep, it’s 1280px wide. One benefit for desktop users is all the content sits above the fold.

Panorama

So I was excited to learn Windows Phone 7 - released in the US last November - supports horizontal scrolling.

“Panorama applications are a part of the core Windows Phone OS 7.0 visual experience…these applications offer a unique way to view controls, data, and services by using a long horizontal canvas that extends beyond the confines of the screen.” - UI Design and Interaction Guide for Windows Phone 7

A background image is optional, “meant to give the panorama its rich magazine-like feel”. The guidelines advise using either a single color background or an image that spans the entire panorama.

For email I’d mix the two (or stick with solid), bleed from an image into a solid color after the first screen. Background images have poor support in email,  it would also reduce file size.

The resolution on Windows Phone 7 is 480×800px and the Panorama approx 2100px. The maximum horizontal scroll in Outlook 2007 is also 2110 pixels.

Windows 7 also supports two way scrolling, “Vertical scrolling through a list or grid in panorama sections is acceptable as long as it is within the confines of the section and is not in parallel with a horizontal scroll”.

I’ve seen a couple of desktop horizontal layouts that support two way scrolling.

The layout above appears to be looped, once you reach the end of the panorama you don’t hit a wall. Not something we can mimic in email, spotty anchor tag support is the best we have.  As Ros mentioned over on Campaign Monitor for the iPhone” Two taps on the anchor link are required to jump to the linked element”.

In April, Gartner predicted that in 2015 Microsoft’s Windows platform will secure second place in marketshare behind android, at 19.5 percent, due to its alliance with Nokia.

Teaser content

You’ll notice the panorama and my template up top, use teaser content to indicate there’s more to the right. The iPhone 3G is 320px wide, rather than make each screen 320px, reduce to 300px so the next screen peeks out.

I took screengrabs from the Victoria’s Secret mobile bridal site and laid them side by side. If the max scroll in Outlook 07 is 2100px wide, we can fit 6-7 screens.

A horizontal look book works well for fashion retailers, though layouts can contain different text to image ratios. I also liked how VS linked to a short video which played on iOS.

Page indicators

As well as teaser content, try adding page indicators to the bottom of your layout. A familiar visual cue, which tells users how many screens there are and which they’re on. You could even add anchor tags for the clients they work under.

Scroll indicator

When you load an email on the iPhone, a semi-transparent gray bar pops up for a few seconds, it’s a scroll indicator. Not only does it tell you which way to scroll, it provides a guide as to how much more content there is.

If the Adidas email below was wider, the scroll indicator would be narrower.  As it is, we know there’s only a bit of content to the right.

Try to reduce the lines of footer text in horizontal layouts (and the pre-header). The more height you add, the more zoomed out your creative will be, making it hard to read on the iPhone.

No footer text 580px viewable vs. 770px zoomed out.

View full-sized screenshots

Arrows

Many of the examples in the horizontal email gallery (just updated) use arrows, some animated. Whether teaser content is enough, or a heavier hand is needed is something to test.

If Windows Phone 7 lives up to its predictions, mobile users will become much more familiar with horizontal scrolling.

Though it’s one choice amongst many. In the last 18mths I’ve tried 320px and 400px skinny layouts, two column skinny, fluid, responsive, dynamic, horizontal and even some imageless pixel art. There’s not one mobile email layout that fits all, your content will determine which you pick.