AMP for email is a terrible idea

Google just announced a plan to “modernize” email, allowing “engaging, interactive, and actionable email experiences.” Does that sound like a terrible idea to anyone else? It sure sounds like a terrible idea to me, and not only that, but an idea borne out of competitive pressure and existing leverage rather than user needs. Not good, Google. Send to trash.

See, email belongs to a special class. Nobody really likes it, but it’s the way nobody really likes sidewalks, or electrical outlets, or forks. It not that there’s something wrong with them. It’s that they’re mature, useful items that do exactly what they need to do. They’ve transcended the world of likes and dislikes.

As evidence consider the extreme rarity of anything other than normal versions of those things. Moving sidewalks, weirdo outlets, sporks — they only exist in extreme niches like airports and lunchables. The originals have remained unchanged for as long as millennia for a good reason.

Email too is simple. It’s a known quantity in practically every company, household, and device. The implementation has changed over the decades, but the basic idea has remained the same since the very first email systems in the ’60s and ’70s, certainly since its widespread standardization in the ’90s and shift to web platforms in the ’00s. The parallels to snail mail are deliberate (it’s a payload with an address on it) and simplicity has always been part of its design (interoperability and privacy came later).

No company owns it. It works reliably and as intended on every platform, every operating system, every device. That’s a rarity today and a hell of a valuable one.

But the tech industry has never been one to let elegance, history, or interoperability stand in the way of profit (RIP Google Reader), so that’s not much of an argument. Still, I thought it worth saying.

More important are two things: the moat and the motive.

The moat is the one between communications and applications. Communications say things, and applications interact with things. There are crossover areas, but something like email is designed and overwhelmingly used to say things, while websites and apps are overwhelmingly designed and used to interact with things.

It’s fundamentally useful to have a divide here the way it’s useful to have a divide between a book about fire and a book of matches.

Emails are static because messages are meant to be static. The entire concept of communication via the internet is based around the telegraphic model of exchanging one-way packets with static payloads, the way the entire concept of a fork is based around piercing a piece of food and allowing friction to hold it in place during transit.

The moat between communication and action is important because it makes it very clear what certain tools are capable of, which in turn lets them be trusted and used properly.

We know that all an email can ever do is say something to you (tracking pixels and read receipts notwithstanding). It doesn’t download anything on its own, it doesn’t run any apps or scripts, attachments are discrete items, unless they’re images in the HTML, which is itself optional. Ultimately the whole package is always just going to be a big , static chunk of text sent to you, with the occasional file riding shotgun. Open it a year or ten from now and it’s the same email.

And that proscription goes both ways. No matter what you try to do with email, you can only ever say something with it — with another email.

If you want to do something, you leave the email behind and do it on the other side of the moat.

This is the great genius and curse of email, that all you can do is send messages back and forth. It’s not always the best option, but it’s rarely the worst. If it’s more complicated than that, you use something other than email: a chat app, a video call, a file host. These useful items are often located adjacent to email, sometimes closely integrated, but they’re never actually part of it. This is a good thing. The closest you get is little things like adding something automatically to your calendar or scraping flight info from an itinerary. Ultimately it’s still just reading something.

What Google wants to do is bridge that moat, essentially to allow applications to run inside emails, limited ones to be sure, but by definition the kind of thing that belongs on the other side of the moat.

Why do this? Are we running out of tabs? Were people complaining that clicking “yes” on an RSVP email took them to the invitation site? Were they asking to have a video chat window open inside the email with the link? No. No one cares. No one is being inconvenienced by this aspect of email (inbox overload is a different problem), and no one will gain anything by changing it.

Well, almost no one. Which brings us to the motive.

AMP is, to begin with, Google exerting its market power to extend its control over others’ content. Facebook is doing it, so Google has to. Using its privileged position as the means through which people find a great deal of content, Google is attempting to make it so that the content itself must also be part of a system it has defined.

“AMP started as an effort to help publishers, but as its capabilities have expanded over time, it’s now one of the best ways to build rich webpages,” it writes in the blog post announcing the AMP for Gmail test. No, it isn’t. AMP is a way to adapt and deliver, on Google’s terms, real webpages built with real tools.

The excuse that the mobile web isn’t fast enough is threadbare, and the solution of a special Google-designed sub-web transparently self-serving. It’s like someone who sells bottled water telling you your tap runs too slow.

AMP for email is just an extension of that principle. People leave Gmail all the time to go to airline webpages, online shops, social media, and other places. Places that have created their own user environments, with their own analytics, their own processes that may or may not be beneficial or even visible to Google. Can’t have that!

But if these everyday tasks take place inside Gmail, Google exerts control over the intimate details, defining what other companies can and can’t do inside the email system — rather than using the natural limitations of email, which I hasten to reiterate are a feature, not a bug.

And as if that play wasn’t enough, the other one is as baldly avaricious as anything the company has ever done. Dynamic content in emails. Where have I heard that one before? That’s right: it’s Google’s entire business model for offering a free email service. Ads.

What is the vast majority of “live” content on the web, stuff that needs to call home and update itself? Not articles like this one, or videos or songs — those are just resources you request. Not chats or emails. Cloud-based productivity tools like shared documents, sure, granted. But the rest — and we’re talking like 99.9 percent here — is ads.

Ads and trackers that adapt themselves to the content around them, the data they know about the viewer, and the latest pricing or promotions. That’s how Google wants to “modernize” your inbox.

Does “engaging, interactive, and actionable email experiences” ring a little different now?

Don’t use this. Don’t encourage it. AMP and other initiatives like it are already a blight on the web, and they will be equally bad for email.

Featured Image: HeiroGraphic/Shutterstock