Gmail, We Need To Talk

Dear Gmail: Two years ago, you launched an ambitious endeavor with Schema.org to bring a new level of richness to email. Schema.org allowed senders to embed rich meta data in email that allowed any modern email client, not just Gmail, to present actionable items within email.

From subject-line actions that allow the recipient to rate a product or service without opening the email to real-time updates of airline reservation information within an email, it felt like Gmail was taking the lead in email innovation.

However, based on queries in Gmail’s support forum, it’s clear that Schema.org has not caught on. And Grid View, Schema.org’s support of a much-anticipated graphical complement to the email subject line, was unceremoniously discontinued with nary a peep early this year.

Although the Gmail API seems to attract relatively more interest, it only appeals to those who want to integrate their apps with Gmail and not developers who build, design, automate and send email.

Are developers not interested in email innovation? Or are they simply not attracted to Gmail’s vision of email’s future?

Gmail Makes Developers Shun Email

Gmail and its plethora of rendering quirks is a big reason why developers avoid working on email. Developers like well-defined and documented environments, and email is anything but. Although many email clients suffer from rendering issues, getting an email to display nicely in the various Gmail desktop and mobile clients gives developers the most angst.

I don’t think you intentionally set out to make email “difficult,” but perhaps with the zeal to innovate, you inadvertently broke email itself. If you want more developers working on Gmail’s developer offerings like Schema.org and the Gmail API, you first need to address the basics — and that is to fix what you’ve broken.

How Gmail Breaks Email 

Gmail is the only email client that doesn’t support <style>. Many developers new to email are surprised that they can’t style their emails using rudimentary web development techniques (with classes and ids). Every CSS style has to be painstakingly inlined in an email . All this just for Gmail alone. Manually inlining CSS is time-consuming, and the alternative of running email through an inliner tool adds an unnecessary step in the development workflow.

Inlining CSS also significantly increases the size of an email; for a company that prizes efficiency like Google, this is an embarrassment.

The Gmail app is a step back from the native Android app. Android mobile phones used to come installed with an email client that was able to render mobile email nicely. Developers could use media queries to instruct the email client to display specially designed mobile responsive versions that made email readable within the smaller screen. However the Android email client was dropped for the Gmail app in the last version of Android (Lollipop), which does not support media queries.

Developers have complained about the lack of media query support at conferences, as well as during a Reddit Q&A session conducted by the Inbox by Gmail team. Yet none of the Gmail mobile clients support media queries.

Each Gmail client renders email differently. You may not be aware of this, but each Gmail client has its own set of frustrating quirks. Having to deal with each version of Gmail makes creating email a nail-biting chore:

• Gmail.com Webmail. Supports <style> but does not support ids and classes.
• Gmail Webmail for Business. Does not support <style>.
• Gmail App for iOS. Randomly increases font sizes by 50 percent (no <style>).
• Gmail App for Android. Randomly ignores container widths (no <style>).
• Gmail App for Android (for non Gmail.com addresses). Does not support background images in addition to ignoring container widths (no <style>).
• Inbox by Gmail for Android. Randomly ignores container widths but does so differently than Gmail App for Android (no <style>).
• Inbox by Gmail for iOS. Does not support <style> but seems to not suffer from as many quirks as other Gmail mobile apps.

To add insult to injury, rending Gmail frequently makes unannounced rendering changes — leaving developers to scramble to figure out workarounds.

Think about it. If developers spend hours testing their emails to ensure they render nicely in Gmail, how will they find the time to experiment with cool stuff like Gmail’s email enhancements?

Help Us Help You

Thankfully, many developers are still passionate about email. And we want innovations like Gmail’s Schema.org enhancements to succeed and be adopted by other email clients. But we need even more developers to be enthusiastic about email.

Here are some of the steps Gmail can take to make email a more developer-friendly environment:

First, Gmail, it’s time to support classes and ids in web mail and media queries in mobile apps. Not following standards used to be a Microsoft thing. Guess what? Even Microsoft is committed to fixing their Outlook email issues by reaching out to the email design and developer community.

 

Second, it’s time to be more transparent with developers in regards to email rendering. It’s great you have excellent documentation and a dedicated support channel for the Gmail API and Schema.org; now please share how Gmail renders email so developers new to email don’t have to search the web just to figure out how to code a basic email that isn’t broken in Gmail.

Third, if you need to have your own blend of rendering, at least make it consistent across your clients — and give the email community a channel to report bugs when we find them.

Lastly, like Schema.org, Google should take the lead in bringing the web mail stakeholders from Yahoo, Microsoft and AOL together toward the support of a common set of CSS and HTML. Full CSS support may not be realistic in a web mail environment, but there is no reason why a consensus cannot be reached on a common subset to make the lives of developers easier.

Moving Email Forward

Although the iOS mail client lacks a lot of the bells and whistles of the Gmail and Inbox apps, believe it or not, it is the preferred client among email designers and developers. That’s because we’ve found ways to leverage the powerful CSS capabilities to do some really cool stuff in email. Things that most people would swear could only be done in JavaScript, such as collapsible menus, image carousels and even shopping carts in email.

We’d all love to be bringing the same enthusiasm and creativity to Gmail.

If only you’d work with us.

Thanks to @pompeii79 for the Missy Elliott as Gmail inspiration.