Close this search box.

The thorny issue of Responsive Design in email: thank you Gmail for this unsolved headache

Email and adaptive design on mobile, a battle still not won in 2024.

Hello, hello! Today we're diving into the mysterious abyss of the responsive design for emails and newsletters. How? How? In 2024, are we still asking ourselves this kind of question?

Well, yes. It's a subject that, while complex, deserves our full attention, given that opening volumes on mobile. I promise, this time it won't even be a question of Microsoft Outlook. Gmail isn't the only one playing tricks on us. Google's good at that, too, so hold on to your seats as we navigate the intricacies of Gmail's different versions.

The crux of the problem: when Gmail gets involved

During a recent exchange with a customer, a problem was raised concerning inadequate rendering on mobile. The problem? Media queries not taken into account. Fortunately, we had a lead to start the investigation:

"We realized that the new template was not behaving correctly on Android Gmail in mobile. The font size is very small, and the display width corresponds to the desktop version, not the mobile one. We don't have this problem on iPhone. "

Customer concerned about Gmail mobile rendering

In today's adventure, our protagonist is Google (a.k.a. EvilCorp) and its mail service: Gmail. The valley giant, despite its stature as a leader at the cutting edge of digital technology, never fails to make us break out in a cold sweat. Support for certain CSS properties differs from context to context. But how do you identify the context?

The quest for environments: you can use the wrong Gmail a thousand times, but not...

"I have a bug in Gmail! "If you want to make an e-mail integrator cry, say these words without any further information.

It's a bit like sayingMy browser? It's Google"(source: an uncle somewhere during a Christmas meal). Here, there's no distinction between the tool and the service (or company).

In a nutshell.

Gmail is first and foremost an e-mail service provided by Google.. Free for private users and chargeable for professional use (Google Workspace). This service gives you an e-mail address with which to send and receive e-mails.

And because Google is cool (no, this is a joke, personally I don't think they're cool at all), it offers a tool for using your email address and "qué s'appelleio" an email client (or mail client).

Can you see me coming? No, not yet?

Well, depending on the context of use, we'll have a choice of email clients:

  • a Web version for use from a browser Firefox, Safari, Chrome... (do me a favor install AND use Firefox), we call it webmail.
  • cell phone applications a version for phones running Apple iOS and another for those using Google Android, all available in the ad-hoc store (like the Captain).

Great, we have a choice of weapons. Really sweet, thanks.

Except that each option is developed in its own way, and not all are created equal. Which adds another layer of complexity to our puzzle.

It's worth noting that the problem of responsive design doesn't apply to desktop versions, so our focus remains on mobile opening environments.

Gmail email addresses for Gmail? Well no, that would be too simple!

Unfortunately, we can't rely on a single element to define the context. the opening environment.

When we talk about opening an email via Gmail, the nature of the address used plays a crucial role too:

  • A personal Gmail address : or a Gmail pro account (Google Workspace) linked to a domain
  • An address from a mail service provider that offers the option Gmailify (Yahoo! Mail or
  • An address from another provider

It's when you combine these different cases with opening environments that the real challenge emerges. Some configurations still don't support media queries, and not only that!

diagram illustrating the different possible Gmail versions

Source: French interpretation of the illustration in the excellent multi-part article by Rémi Parmentier on the subject of Gmail. If you're looking for more detailed technical explanations, don't hesitate to contact us.

Unfortunate use cases: style is not taken into account and rendering is not good

I suppose you've already read the articles quoted as sources just above? What do you mean you haven't? So let's try to simplify things and get to the point. In which case(s) are you going to be annoyed?

The context ?
and media queries
Webmail computeryes
Webmail telephoneno
Gmail Android application (Gmail account)yes
Gmail Android application (Gmailified account)yes
Gmail Android application (POP/IMAP account)no
Gmail iOS applicationyes
Inbox by Gmail (Webmail)yes
Inbox by Gmail (iOS)yes
Inbox by Gmail (Android)yes
G Suite Basic (formerly Google Apps for Work)yes
Google Apps Free Edition (old version)no
Source: Litmus Live tracking of Gmail updates and there's plenty of other interesting info to be found

There are mainly two problematic scenarios, the third at the bottom of the list concerns "legacy" which we will not consider:

  1. A Gmail address opened via webmail in a browser on a smartphone
  2. A non-Gmail address opened via the Gmail application on an Android phone. What #EmailGeeks call GANGA

If you really find yourself in one of these two situations, is that you're looking for problems then chances are your email won't be displayed correctly. It should strongly resemble the desktop version, whereas you're actually on a smartphone. What's more, some styles (CSS properties) may not be applied at all.

The real impact on my campaigns: how bad is it, Doctor?

Spoiler alert: maybe not as much as you'd imagine.

To find out, we need to answer these two questions:

  • How many users/subscribers does this represent?
  • Does this really prevent consultation and action?

For the first question, there is unfortunately no reliable, consolidated authority data to my knowledge. As for the second, I don't think so.

OK, I can hear you grumbling from here and you're motivated to try and assess the impact on your user base. So let's try a little math problem:

How can I measure the impact on my base?

Let's take a hypothetical example:

We run an email campaign sent to a database of 1,000 addresses. Because we do things so well, our open rate is 100%, with an equal split between desktop and mobile (50/50, mind you).

Among mobile openings, let's imagine that 35% would be with Gmail addresses.

Questions :

  • How many gmail addresses are opened via gmail webmail?
  • How many non-gmail addresses are opened via the gmail app?

You have 5 minutes... no more...

Did you find the answer?

How do I do it? Can't find the breakdown in your state-of-the-art tip-top campaign management tool?

Honestly, is it that serious?

You could assume that the distribution is fair, and that would be a significant bias. Still, the result is an unrepresentative share. You'd better worry about the accessibility of your email or writing the message itself, rather than investing budget to solve this technical headache.

A headache that will generate code patches that will be doomed to disappear when Google makes an update. Really, read the Litmus article quoted above, hybrid spongy is far from being the future!

The answer remains vague and uncertain.

Understanding usage to minimize

What really concerns me is understanding usage. Why do I check my Gmail mail on my mobile from a browser? Why am I using Gmail as an app with an address other than Gmail?

We could come up with all kinds of hypotheses like:

  • I've been unable to configure my Gmail account via my phone's default email options.
  • I like the Gmail app so much that I use it with my other address.
  • I'm consulting a secondary e-mail address that I don't want to have in my main mailbox.
  • ...

The hypothesis I like (because I'm naughty and twisted) would be as follows:

Operational teams (marketers, designers, integrators...) test their campaigns and create this very specific context themselves. To test rendering on different opening environments, without going through a solution like Email On Acid or others, they go directly to their business or personal phone. A phone that already has a main address configured. So to get around this and avoid changing this configuration, the solution is to test via webmails or a secondary app.

A bit like an advertiser who does BtoC retail and tests everything internally on Windows desktop with Outlook (damn, I promised I wouldn't quote him, sorry, I can't help it).

Cuckoo for Plato's allegory of the cave. Believing in a reality that is merely a projection.

You're not your subscribers!

You don't have the same usage in the same context.

Let's stop wasting time and code overload or techno-solutionist debauches for a problem that only exists in very rare cases. I'm sure you have far more important and urgent problems.

The author

Laisser un commentaire

Your email address will not be published. Les champs obligatoires sont indiqués avec *