The email community was abuzz yesterday with Google’s announcement of Amp for Email at Google’s AMP event in Amsterdam. The development was met with excitement because AMP for Email allowed for fully interactive emails in Gmail.
This article will go into some of the key information behind AMP for Email.
What is AMP?
AMP or the AMP Project which is short for Accelerated Mobile Pages began as an open source project by Google to speed up the load of mobile web pages on bandwidth and processor restricted devices.
What is Amp for Email or AMPHTML Email?
Google says that AMP is Open Source and would like to see AMP for Email to be widely supported by other non-Google modern email clients.
However as of now, AMP for Email is only available as a Developer Preview for select developers on Gmail webmail. Gmail hopes to roll out AMP for Email publicly later this year to both Webmail as well their mobile apps.
How Do I Get Access?
AMP for Email is only available for developers at the moment and requires an NDA. End users will have to wait.
This is Not Google’s First Interactive Email Attempt
Google beta tested “Enhanced Email” featuring interactive carousels in 2010. Google has also been adding interactive features around email using Schema.org. AMP for Email does seem like Google’s most ambitious attempt at interactive email.
Use Cases for AMP for Email
Check out this presentation for demos of AMP in Email by Doodle, Booking.com and Pinterest.
Refreshing offers in an email.
Viewing and saving a Pinterest pin in an email.
The was also a Doodle example showing the ability to respond and view real time responses to a survey within an email.
You can test out AMP for Email markup by going to this link:
This CodePen example demonstrates how you can incorporate “classic” and AMP interactive email within the same email.
Benefits of AMP for Email
Submitting and fetching data from a website without leaving the email
The distinctive feature of AMP for Email is the ability for recipients of an email to take an action within an email and have the data sent to a remote website and update the the email with new content without the recipient leaving the email itself. For example, you could tap on a like button under a picture and have it refresh with a list of all the people who have liked the picture so far.
AMP’s interactive update capability is achieved using AMP’s “dynamic content” features like amp-bind and amp-list.
Interactive content in email made “easy”
AMP offers a few built in modules such as carousel and light-boxes so implementing these features in the email only requires a few lines of markup.
However, AMP is by no way the only way to achieve interactivity in email. You can create some pretty amazing interactive email content just by using HTML and CSS. In fact companies like REBEL were founded around this.
Live content without the hacks
AMP for Email allows for content that is refreshed when the email is opened. This means an email content is never stale and supports use cases such as dynamically updated sports scores and poll results.
Although regular HTML email content is static, prior to AMP, regular HTML email has always supported dynamic content through the realtime generation and loading of images (as well as external stylesheets). Companies like MovableInk and Liveclicker offer APIs to make it easy to embed live information within images. AMP for Email just makes this a lot less hackish.
Drawbacks of Amp for Email
A new MIME part
The requirement that the content be packaged in a new “text-x-amphtml” MIME part is the biggest drawback of AMP for Email.
Adding support for this MIME part is going to be a tall order for the majority of Email Service Providers out there such as MailChimp and Salesforce Marketing Cloud. Judging from how long it took the ESP’s just to support responsive email in their solution it can take years before a majority of ESPs get around to support this format.
I can see the API based ESPs getting around to it quicker though (providers like SparkPost, SendGrid and MailGun), but limiting this capability to technological savvy senders seem self defeating.
A brand new language
AMP goes against existing email development practices
This one is perplexing to me. AMP for Email does not support the img tag, the !important selector, background attributes and inline styles – the bread and butter of HTML email development.
Instead developers are forced to use the amp-img tag that comes with its set of tight restrictions (height and width attributes are required).
Surprisingly although table background attributes are not supported, the CSS background-image property works in AMP for Email.
Speaking about CSS, AMP limits CSS to 50kb!
AMP is super strict on validation
Email developers are used to putting all sorts of hacks into HTML email to appease the various email clients. In order to preserve performance and stability, AMP will break if the content isn’t clean. That means any unsupported tags and attributes will cause AMP not to render.
What We Don’t Yet Know
There are a few things that have not been disclosed about AMP for Email:
If a recipient is able to interact with their account on a website through an email, what methods will be available to securely authenticate the recipient.
Whether senders need to apply to be whitelisted in order to use AMP for Email and what the requirements entail.
Whether users be given an option to disable this feature.
I’m still formulating my thoughts, but I feel AMP for Email is a bit of an overkill. Certain things may make sense for AMP as it relates to its original goal – to speed up mobile web-pages – don’t make sense to email, such as the elimination of the img tag and inline CSS styling.
Requiring a new MIME part frees developers new to email from learning the quirks of HTML email and its baggages, but seeing that most email clients won’t support AMP HTML that doesn’t seem likely that a developer would be able to avoid “learning” how to code email to satisfy Outlook. Also this MIME part requires every single email service provider to retool their software – which seeing how long it took some ESP’s to support responsive code – can take years.
I’d rather Google just sprinkle AMP support within regular HTML and use progressive enhancement capabilities already adopted in interactive email to enable interactive AMP features within Gmail. This way out of the gate, AMP for Email would be accessible to everyone.
Still I’m very excited that Google is investing interactive email and I look forward to further AMP developments in email.
I just hope AMP for Email doesn’t suffer the fate of Google Wave and Gmail Grid View – which were shut down by Google before being widely available.