On February 13, Google announced AMP for Email, an attempt to introduce some of the elements of its Accelerated Mobile Pages specification into email, putting the company’s high-performance web publishing system right inside the messages. Gmail will be the first email client to support these new features, which will give senders a way to deliver complex layouts and templates, interactive user actions, and dynamically updated content. That first implementation isn’t even ready yet, and yet already this is looking like a catastrophe. It should not be possible to design dramatic changes to our most widespread communication medium in secret and then deliver them in a surprise announcement! That completely misses the point of communicating.
AMP is a high-performance subset of established web technologies like JavaScript and HTML intended for mobile-first publishing. It was introduced by Google in 2015 as a somewhat more open competitor to Facebook’s embedded “Instant Articles” format; whereas Facebook renders third-party links right inside Facebook, Google created a zippy new quasi-standardized format for the rest of the web — and then took the additional aggressive step of serving them from google.com URLs and promoting AMP-formatted content in its search results. It has been met with suspicion, most famously by the the Register, which called it “bad in a potentially web-destroying way.” But it is certainly fast!
One optimistic view might be that AMP for Email is an attempt to open up functionality that already exists in Gmail — interpreting the links and other content of emails to present useful gadgets like package-delivery tracking — so it can be invoked more efficiently by senders without waiting until Google deems those functions worthy of special treatment. Skeptics will point out that Gmail has been the market leader in web mail for between 10 and 15 years, especially if you focus on personal use and ignore corporate and enterprise applications. If Gmail has become the dominant platform for email transactions, then AMP for Email could be considered a power play to create the new format, the unit of transaction being passed across an established open platform.
As used on the web, AMP restricts the broad scopes of web technologies until they are fast and efficient. The utility is less clear with email. Just consider the name of the product: “Accelerated Mobile Pages”… for email? AMP documents on the web are pages or even miniature interactive applications. Should we even be emailing pages and applications around at all? Dynamic content is a sort of bizarre concept for messages, the content of which could change after their receipt in ways that could undermine their utility or even their legal value. Richly formatted HTML email is widely loathed in comparison to plaintext messages, so this is a very strange horse to bet on. In contrast, the new Animoji feature on the iPhone X adds message interactivity in a trivial and superficial fashion, seemingly deliberately; upgrading the bones of email is a much bigger deal.
Most damning of all, AMP for the web is ostensibly solving a performance problem that simply doesn’t exist in the context of email. Bloated advertisements woven into the pages you want to see are a core part of the economy of the internet, and can kill your speed and battery life on mobile devices. In contrast, unexpected third-party ads in email messages aren’t a meaningful problem (outside of unsolicited spam, which is a substantially separate concern altogether). One of the fundamental miscalculations of AMP for Email is that it degrades the delivery speed of a medium in which nobody really likes rich-message content to begin with. AMP for the web was a faster subset of the standard web, but AMP for Email is a slower superset of standard email. The product name is a misnomer — it’s not accelerated at all!
There’s a steep cost: In order to add interactivity, AMP for Email executes JavaScript code in the messages for the first time, creating an enormous new target for malicious hackers. Google’s engineering and security are nearly always best in class, and you can be sure that the various scripts required for AMP features will be vigorously protected, but this is email’s biggest new attack vector since file attachments began carrying viruses.
All this to what end? AMP for Email may be an extension of email, but it is not a meaningful extension of email. There are some slick new display options, simple actions that could be accomplished with a link, a bit of that strange dynamic content, and not much else. And yet this will require carving out a schism between AMP and non-AMP email, between compatible and incompatible apps and clients. Just about one of the silliest things you can possibly do to a communication medium is artificially bifurcate it.
The reception has been largely negative, and at times even hostile. The comments posted by developers under the announcement are so far almost uniformly negative. “AMP for email is a terrible idea,” crowed TechCrunch, in what Google’s search product now presents as the top result. Maybe it’s actually a terrible implementation of an okay idea. Or, even more charitably, maybe it is just half-baked: The specification is presented only haphazardly in an “issue” post on GitHub — essentially a bug report — and a week or so after AMP for Email was unveiled, AMP tech lead Malte Ubl was posting comments like, “There should be a wider discussion as to whether it is a good idea in email,” and “The next thing is to discuss the topic in the AMP design review,” and “Totally agree that the forwarding behavior needs to be nailed down.” In a more reasonable version of this process, those steps would have been taken before an announcement.
To deal with email clients that don’t yet support the AMP for Email message format, the old plain-message format will be delivered alongside the newer version. Even beyond that inefficient redundancy, AMP for Email isn’t something that anybody will actually write directly because it uses specialized code. Generating the AMP messages will thus require new tooling and production systems, all of which will be completely divorced from the conversation flow of simple messaging, and will need to be replicated countless times over and built out on different platforms and devices. AMP implementation on the web has thus far proven to be a complete pain even for the biggest publishers in the world. AMP for Email now has an even longer road ahead with an arguably more stubborn audience. It is distinctly possible that we’ll never see authoring tools available in any mainstream email client for mobile devices.
Nonetheless, underneath its warts and the failure of process, AMP for Email still has the admirable goal of pushing our communication methods to evolve into something more sophisticated and powerful, possibly even more nuanced and expressive. The problem isn’t so much that AMP for Email is fundamentally a failure, exactly (although sure, maybe that, too), so much as that AMP for Email illustrates our failure to accomplish anything else in this space and the continued stagnancy of the most popular and widespread internet technology in history. AMP for Email is flawed and partisan and more than a little nonsensical, but it is also the deepest and best attempt to extend email in a very long time, because it is also the only attempt to extend email in a very long time.
And yet AMP for Email will probably fail, in part because it is not very good but also because most ideas fail in technology, in business, in the world. But the biggest flaw of AMP for Email is simply that it can’t reasonably be called version two of email. That isn’t Google’s fault — version two of email doesn’t exist anywhere else either. We aren’t even trying. That is such a profound moral failure that maybe technical failure was also inevitable. And so a lukewarm quasi-open standard pushed by a monopoly interest punts our indefensible collective apathy right into the next generation, deeply broken and silly and misguided but also, embarrassingly enough, still the best we say we can do. Watching something as important as AMP for Email land with a splat drives home the absurdity of the fact that in 2018 there’s still no equivalent to NASA for the internet — that is, some kind of well-funded public-interest research lab that could aggressively compete with the private tech sector in salaries and prestige. Instead, companies like Google get to decide how to build the future, and even how we will talk about the future before it gets here. One thing has already been made abundantly clear by the AMP for Email process: Even for Google, doing this properly is going to be a moon shot.
