Winning the Design Battle on Every Screen

Editor's Notes

1. I’m sure that basically everyone who has designed and built an email in their life…so most of the people in this room… have gone through the following situation: • You have a great email that needs to be deployed. The content is engaging. The design looks great.  • You even have a couple of decent breakpoints in there to make sure everything reflows well across devices. • You finish your build and get ready to throw it in Litmus.
2. • You look at iOS. Everything looks good so far.
3. • You test in Android and everything checks out.
4. • And even Outlook…through your ingenious use of hacks, workarounds, blood, sweat and tears…looks decent.
5. • All of this has started to make that fear…
6. that crippling fear that comes with hitting send on something that’s going out to thousands, if not millions of people, starts to subside…
7. and be replaced with a little bit of confidence. confidence that that email is going to reach people’s inbox’s looking great • So you hit send
8. • Only to later find out that something got missed along the way. Something in some client out there didn’t work correctly. • Now, you might not have the difficult job of sending to other email folks who are all expecting perfection…I don’t really envy Litmus or others in that regard. • But regardless…there is always a problem client…and a lot of the time you find it too late • whether that happens to be the Gmail App or Outlook Web Access there is always at least one
9. • And when you run into it after you’ve hit send...you go from that previous confident feeling…to one more like this
10. • Or you may even take it one step further, like elliot here, and just say screw it…let’s do this all as one big image. that’s easier, right?
11. So, what can we do to try and avoid situations like this? Is it even possible to make sure everything renders pixel perfect in every client?
12. • Hate to break it to you, but no, it’s not • There really is no magic trick. No silver bullet. Building emails that work well is difficult, challenging work.
13. So, why is this the case?  • Why is getting emails to render consistently such a challenge? Has it always been this hard? • Anyone that’s done this for more than a few years knows that yes, working with email clients has always been a challenge. ◦ For one…unlike the web…there are just simply no agreed upon standards… ◦ This causes clients to have drastically different implementations of basic features. It’s what forces us to use tables and what requires us to inline our styles. • But in the past it really wasn’t THIS hard
14. • Supporting Apple has of course pretty much always been easy. • Yahoo! and Hotmail had their quarks but honestly nothing that was too hard to work around • Gmail forced you to inline your CSS…creating a more challenging workflow…but not really much more of a rendering challenge…except for their hate for the color black • Outlook of course…well..nobody ever knows what the hell is going on with Outlook • But again…even with all of this...it really wasn’t that hard….you just had to know the quarks and constraints and you could do a pretty good job of making sure everyone got a decent experience…and to make it even easier…we were only designing for one screen size…mostly in images….and you could even be relatively sure most people were on a windows machine
15. • Then around 2008 things started to change • Apple released the iPhone and over the next few years the device storm hit
16. • Now the landscape looks a lot more like this
17. • A huge mix of operating systems, screen sizes, capabilities, and tons of new email clients • And of course the two major players that this added were iOS and Android
18. • iOS is relatively easy to support ◦ There’s very little device diversity ▪ Sure…there are iPad’s and a couple versions of iPhone’s but the user base typically stays within a couple versions of each other…there aren’t too many people still on an iPhone 3 ▪ The native iOS client is also built on webkit… ▪ for those of you that don’t know…webkit is a rendering engine…which is what tells a browser or email client how to render different components ▪ webkit is a great rendering engine on the web as well as in email…and features great support for things like media queries as well as css animations, html5 video, and other css3 things such as rounded corners ◦ So again…iOS, fairly easy to support ◦ The problem is…a lot of people don’t have it…and an increasing amount of people are opening your emails on their Android devices…and Android is a totally different story
19. • For one…there really is no such thing as “the android client”
20. There’s just way too much device diversity • Even if you narrow it down to just smartphones…Android is on everything from a 2.8 inch LG Optimus to a 6.3 inch Samsung Galaxy Mega • On top of that you have a very broad range of Android versions…with decent chunks on Gingerbread, Ice Cream Sandwich, and now KitKat • And this is all just talking native Android • When you get into other clients such as the Gmail App. Or if someone happens to be opening your email on an Exchange Account, even via the native mail app, you get varying levels of media query support.
21. • And then there is the hell that is Samsung. For whatever reason, Samsung decided they needed to “improve” the native email client by doing awesome thing like kill media query support. quite the improvement. In short…this new diverse landscape of devices, in addition to the need to design for every screen size has made things a lot more difficult
22. So, what can we do to deliver a consistently great experience in this new world?
23. • Are frameworks the answer? ◦ There’s been a whole slew of out-of-the-box frameworks and templates released as of late. And these can be great but they’re only a technical solution that solves the problem of a reasonably small set of devices and email clients They’re a technical solution that helps. They can do a lot of the heavy lifting. But we need more.
24. • the devices people are on are too inconsistent for a development solution alone to solve. and if we can’t count on technology to be consistent we have to come up with other ways of delivering what’s necessary. ◦ The first of those things is to Know our audience
25. • If you don’t have access to detailed analytics is there some other way you can start to infer information? ◦ Can you base your numbers around a similar company or vertical? Are they likely to be sitting in an office when they open it? Does your customer base skew younger or older? Is it less or more affluent? And if you tell me your customer base is “everyone” then you’re probably doing it wrong • Whatever way you do it you need to know your audience and then start making decision decisions based on them. No more designing for email. Design for your customers who happen to be receiving your message through email. Let’s take a look at two very different audiences ◦ Both of these sets of data are real by the way. From two clients that i’ve worked with.
26. • Here’s the first set.  ◦ Now this was a client that was mostly B2B ◦ Very high Outlook opens ◦ Only hitting around 13% mobile ◦ which means they’re about 87% desktop…most of that in Outlook
27. • second set ◦ Less consolidated ◦ Definitely more spread out across clients ◦ 68% mobile. Highest opens are on iOS. • Now this is obviously a very narrow look at two narrow sets of data. But just looking at this, should these two clients have emails designed in the same way? Based off of some industry benchmark that says everyone is using the iPhone? Probably not • Does the B2B client even need to be sending responsive emails? If your audience is 80% Outlook…maybe…maybe not…but mobile definitely shouldn’t be your main focus
28. • They should be taking an Outlook First Design approach…not a mobile first one. • And that’s exactly the approach we took with this client.  • Creating a strong Outlook baseline • We did decide that it was good to be thinking a little future forward and because the budget was there we attempted to optimize for those cases. If the budget wasn’t available it could have easily been justified to focus efforts elsewhere. • So after creating the normal 620 px width design we added on some mobile styles to make it friendly where possible. But because it wasn’t the main focus, it was considered OK that the gmail app didn’t get a 100% optimized experience.
29. • The client with 68% mobile on the other hand…we took a much more mobile first approach ◦ That is…not just designing responsively….but actually thinking small screen first ▪ with simplified designs ▪ asking questions like…. ▪ does a single column approach make more sense than trying to shift a bunch of stuff around the screen?….knowing that attempting the latter could possibly break the design on Android devices just so some small percentage of Outlook users will get a better experience? Or does that single column approach work across everything? ▪ is it better to simplify the interactions and content? The moral of the story here is. Just like you would your content and your send times. You need to be basing your design decisions on your audience. Not knowing your audience means you’re designing in the dark.
30. • Progressive Enhancement ◦ "There's a new email client every day, whether, desktop, mobile or tablet. You can do your best to make the experience hold up across devices, but you can't make it perfect across devices.” - Alex Williams • Your emails are never going to look the same in every client - but so what? • Your customers aren’t sitting looking at litmus tests the same way you might be • they neither know nor care that something’s displaying differently in their client • that doesn’t mean you can deliver bad experiences however • rather…develop a baseline experience and enhance it for people with more capable email clients
31. • Your emails are never going to look the same in every client - but so what? • Your customers aren’t sitting looking at litmus tests the same way you might be • they neither know nor care that something’s displaying differently in their client • that doesn’t mean you can deliver bad experiences however • rather…develop a baseline experience and enhance it for people with more capable email clients
32. • Your emails are never going to look the same in every client - but so what? • Your customers aren’t sitting looking at litmus tests the same way you might be • they neither know nor care that something’s displaying differently in their client • that doesn’t mean you can deliver bad experiences however • rather…develop a baseline experience and enhance it for people with more capable email clients
33. • Examples of Kevin’s video in email and how it used progressive enhancement to create a great experience
34. • Tested Clients ◦ 2.3 Native ◦ 4.2.2 Native ◦ 4.4.2 Native ◦ 4.4.2 Samsung Galaxy ◦ Android 4.0+ Gmail App ◦ Exchange via Native ◦ iOS Gmail App ◦ iOS Mail
35. • Go through basic stacking approaches ◦ display: block; ◦ aligned tables ▪ unstable ◦ table display types ▪ become non-table-cell and non-block level elements ▪ requires extra nesting to getting padding and table-cell or block behavior ◦ float: left; width: 100%; • Percentage that worked in each place - goes back to “know your audience”
36. • Know What Works Where ◦ fail hard? or less control but more support?
37. Soft fails
38. • Dealing w/ Gmail App ◦ Hybrid Approach
39. • Frameworks are great because they create consistency across your code
40. Frameworks are great because they create consistency across your code • Once you know your audience • & Once you know the common patterns you will need • & Once you know what works • You can set up your own • Lessens the chances for mistakes • Can also add in additional custom helpers and tools • You know which patterns work where and how they work