Hybrid is the answer. Is it the right question?

Nicole Merlin started it. She posted an in-depth tutorial on how to optimise emails without media queries. This prompted email community member Ted Goas to ask the question: why we do all this just because gmail has an embarrassing problem?

This is a valid question and one we also ask ourselves regularly. However, it boils down to this:

It is the “email way” to find workarounds and hacks for rendering problems.

This is for a number of reasons:
1) No coding standards in email.
2) Fractured, buggy and ever-expanding rendering environment in constant flux.

Compounded by:
1) It is in our nature to solve problems.
2) If a workaround exists then it is a possibility. If there is a possibility, that soon becomes actuality.

Compounded further by industry factors:
1) The customer/client relationship. Customer says “it doesn’t look right” Customer is entitled. Customer is always right. We are the producer and supplier. We feel we must do all we can.
2) As a supplier, more products and options (more tools in the box) means problems can be fixed, means happier customers.

At Action Rocket we have a process doc illustrating how we can find the right type of email design and coding techniques before we start work.

Here is a generic version of our internal document for reference:

code-methods-doc-2

 

If you enjoy such charts, you may also like this one.

We recognise that Hybrid is not always the most suitable method of email production in the real world, it depends upon a number of factors like:

  • Complexity
  • Updating/maintaining code
  • Meshing with ESP quirks
  • Audience

Every case is different and we tailor to requirements. But when we have a connected hive of problem solvers combined with this email attitude to code (if it works it flies) the future is hacky.

Perhaps the real question is: can we change the “email way”? Web guys have the luxury of saying IF old terrible browser THEN upgrade your browser. They can draw lines in the sand. We can’t do that in email, short of an elaborate “I am Spartacus” movement against gmail, whereby we all just refuse to cater for it. So the cycle continues.

Of course if code standards existed in email that would cause a paradigm shift…and if gmail supported media queries that would be a huge step in the right direction…and if this, if that. We aren’t holding our breath, we’re getting on with it. It’s what we do.

TL;DR Hybrid FTW, but it’s complicated.

  • http://time-wellspent.com Jaina

    Would really be interested in delving into Hybrid email building for where I work, but we simply don’t have enough stats and information on our customers to warrant the time spent on it. Real world situation getting in the way. I’d like to hope that the day when I do decide to jump into it, Gmail magically has and media-queries ;)

  • http://www.tedgoas.com/ Ted Goas

    I’m happy most people think it’s worth spending time on mobile Gmail. I’m happy this discussion happened; it’ll likely be the thing that makes me take the first step in making my templates ‘Uber Responsive’. I continue to stand on the shoulders of giants!

    But please don’t forget that priorities vary. I can’t spend 100% of my time on email and have yet to experience a client insist upon a shape-shifting email in Gmail. So it’s not “Mobile Gmail should be ignored,” but rather “Mobile Gmail is cost prohibitive to optimize for.”

    For me.

    Your mileage may vary.

  • http://emailwizardry.nightjar.com.au/ Nicole Merlin

    “It is the “email way” to find workarounds and hacks for rendering problems.”— Fully agree!

    For me, the fun of HTML email has always been the fact that it’s like someone saying to you: “Here’s a roll of sticky tape and a broken biro: please create a masterpiece.” To be honest, if all mail clients started supporting web standards tomorrow, it would be boring to me and I would probably stop doing it.

    I actually find the hybrid method to be quite simple and it actually makes a lovely kind of sense once you’ve been using it for a while. I’ve also found that it yields really consistent and robust results across all email clients.. plus I find that I end up with fewer layout bugs. Maybe it’s because it forces you to think quite hard at the beginning about the maths of the layout. I now usually use it as my baseline method and then if a client specifically requests high-resolution image support and are happy to sacrifice Gmail compatibility, then I just make a few tweaks (give the images pixel sizes & media queries adjustments and then add that awful Gmail non-shrinking hack) and it’s on its way.

    And at the end of the day, even though I think Gmail are jerks for the fact that they don’t support media queries, it’s not the only issue we face (for example, the Android TD stacking issue) that the method solves. And essentially, my clients want their emails to reach as many people as possible and to result in the maximum number of conversions and sales and all that jazz, and I want to feel happy that everyone’s going to be able to see the thing properly, especially since your average user has no idea about the fact that Gmail is actually a jerk in email rendering land.

    And as you say, Mike, “Web guys have the luxury of saying IF old terrible browser THEN upgrade your browser.” It’s so true. Also, even if we could tell them, it’s so much harder and more annoying for a user to switch to a different email program, let alone a different email provider.And the other thing is that web developers have always had way more of a relationship with browser creators because web developers create 100% of the content of the web. As email developers we really only create about 50% of people’s experience of email, with the rest being personal and business communication, which I’m sure Gmail would argue are its primary concern.

    Basically, everyone wants to make money. So if someone’s paying me to make their emails, their emails should make them the maximum amount of money, which means they need to be highly functional for the maximum amount of people. And obviously as a designer I also feel happier when they look prettiest :)

  • http://emailwizardry.nightjar.com.au/ Nicole Merlin

    TL;DR: “Because Capitalism”

  • http://emailwizardry.nightjar.com.au/ Nicole Merlin

    “It is the “email way” to find workarounds and hacks for rendering problems.” — I fully agree! For me, the fun of HTML email has always been the fact that it’s like someone saying to you: “Here’s a roll of sticky tape and a broken biro: please create a masterpiece.”

    I actually find the hybrid method to be quite simple and logical in many ways. I usually end up with fewer layout bugs than I used to. Maybe because it forces you to think quite hard at the beginning about the maths of the layout?

    Like you say, Mike, “Web guys have the luxury of saying IF old terrible browser THEN upgrade your browser.” I believe web developers have always held more sway with browser vendors because web developers create 100% of the content of the web. As email developers, we only create ~50% of people’s experience of email, with the rest being personal and business communication, which I’m sure Gmail would argue are its primary concern. That being said, even if we could tell users, it’s much harder and more annoying for a user to switch to a different email program, let alone a different email provider. And email providers surely know this. I don’t think there is that much pressure on them from a customer-satisfaction perspective because users are unlikely to know what’s going on and are even less likely to abandon their Gmail account over it.

    Basically I think everyone wants their business to succeed and their customers to be happy. So if someone’s contracting me to make their emails, their emails should yield the best possible results. For that to happen, the emails need to be highly functional and a pleasure to use for the maximum amount of their customers. And so far anytime I have used this method, clients have reported that they worked extremely well and that they were very happy with the results.

    But, like Ted said below, “Your mileage may vary.” :)

  • http://labs.actionrocket.co/ Mike Ragan

    Hey Jaina! Yeah right, I check every day just so I can update http://www.doesgmailsupportmediaqueriesyet.com/ I am quietly optimistic (thats the email way too I guess!) but we have to live in the now. I’m not sure what the political reasons are for not supporting but I hope it will all come out in the wash.

  • http://labs.actionrocket.co/ Mike Ragan

    Hey Ted, ha! That’s cool. “Uber responsive” is a fun term we use internally here, we spent a while working through names, I gave a talk about it at a Completely Email…. so many names!

    Priorities do indeed vary – hence the crib sheet – it’s a case by case still. For some it’s ideal and for others they are happy with different levels of optimisation. Most gmail app users (so I’m told) don’t even know what an optimised mailing is. But when they do, we must prepare ourselves, as gmail & mobile continues to grow rapidly.

  • http://labs.actionrocket.co/ Mike Ragan

    G’day mate – yeah – so very true. It’s the fun of it for me too…the challenge. That’s funny I was discussing the layout bugs only recently, I am getting “first time every time” (almost) for Hybrid builds, and I also think it’s the extra consideration required! Maybe also partly b/c the designs aren’t so complex? But either way I’ll take it!

    Good point about gmail’s primary concern – “users are unlikely to know what’s going on and are even less likely to abandon their Gmail account over it.” – yes, this. Nailed it. I’m reading and replying as I go, sorry!

    Totally agree, the customer feedback has been really great. There is one small caveat – that these cases are not looking after/reusing the code in house, it’s for more-or-less fully managed campaigns. This is something been working on recently to try to de-mystify the layout at code level e.g. removing possible hard to spot snags like fixed widths from divs – so that it’s a bit easier for 3rd party to pick up and follow. But I guess now I can just point to your super cool tutorial :)

  • Nicholas Rowan

    I like the breakdown into the various styles of coding used. I also like the thought process you have fleshed out as to why certain styles would suite certain campaigns. Personally I think too much is sacrificed when coding “uber responsive” purely to please Gmail app’s crappy support for …. well anything really :P

    If you can create a template with all the fun and wonder of webkit & media query supported code and make it so Gmail app simply shows the desktop version instead of scrambled eggs , then it’s a win. For now at least. I think we should always be pushing the boundries and innovating forwards while still making sure the email looks decent accross the majority of devices and browsers.

    Currently I don’t think Gmail apps user base is high enough to justify the loss of other features for generic Android and IOS mail. I do strongly agree that it is something that we should keep in our back pocket though. Who knows what the future holds or whats around the corner. It’s good to be prepared for any situation and I think you have that covered fantastically here in your post.
    :)

  • http://www.tedgoas.com/ Ted Goas

    Yea, it’s good to be prepared for any situation, no arguments there.

    See… I hang around and chat with you guys and you push me learn new things and this an absolute outrage

  • http://emailwizardry.nightjar.com.au/ Nicole Merlin

    Hehe, shucks and thank you ;)

    Yes! I get ‘first time every time’ as well! Like 95% of the time :) I think even though you have to do this entire bunch of stuff that is, as @tedgoas:disqus has said elsewhere, serving completely different code to completely different clients, aside from that, every single client renders the rest of it exactly the same, so it becomes wonderfully predictable.

    I haven’t had to work hybrid and hand work over to a third party to edit (beyond rearranging modules) so I admit I haven’t thought much about how that would work or have I thought about it from a code management/maintainability perspective, as you mentioned in the article. But I still rate it for sure. I shall deal with all that in the near future :)

  • Pingback: Will there ever be an email standard? | Email Design Review

  • Pingback: Kickdynamic | Mobile Email Strategies Beyond Design

  • Georgia Constable

    Hi all :)

    I am finding this debate so fascinating – thank you all! I am yet to attempt Nicole’s ‘hybrid’ method but am game for trying. My question to those of you who have used this technique is:

    Surely once you pick it up and it becomes second nature to structure your code for all emails this way, it doesn’t take more time – or not significantly at least? As we all do, every time I learn a new trick or work-around, I continue to use it from that point for every email I do after that. Is it really so complex that even when you’ve got the hang of it, it’s time consuming enough to need to think about whether it’s worth doing it that way for the client or not each time? Just curious to know what I am about to let myself in for here! :p

    Many thanks for your help :)

    Georgia

  • Elliot Grossbach

    Really helpful discussion and the chart is perfect. I abandoned column B soon after Android stopped supporting the stacking method. Was on a job and had to figure this out by digging deep into some forums, in 100% panic mode. Anyway, column C has worked great for me since, except of course on Gmail where I just force the desktop version. I typically get designs sent to me, so the hybrid method is probably not doable. From what I can see, it needs to be considered prior to the design phase, as there are quite a number of restrictions, even beyond a typical responsive email. And I also make a lot of templates that need to be re-used for ongoing campaigns. So having all those ghosted tables for Outlook would make the code a little too complex for that purpose, I think. I’m still anxious to dive into one of these, if a suitable project comes in. Even better, gmail at some point stops killing the styles on top.

    Unrelated question… Outlook365 and Outlook.com seems to ignore padding on table cells arbitrarily. Anyone have a fix for this? Padding on has always worked for me, and continues to work in every client except those 2. In those, it works sometimes, and not other times. And even within the same email, it can vary. This is killing me. I know there are other ways to implement spacing, but I don’t want to give in. And I won’t. Help!

  • Joseph Crane

    Would anyone be able to recommend me the best method to use in conjunction with Silverpop? I’ve recently been using a technique without media queries but it appears that Silverpop is stripping some of the important logic governing alignment and it’s having a negative impact on my designs!

    Thank you so much in advance!

    Joe