I could find this useful with some types of transactional emails. I'm currently working on an app where a user submits their timesheet and an email is sent to a manager to approve the time. Right now the manager has to click "Review Time" in the email where they will then be kicked out to a portal I setup that lets them review the entries. With something like AMP I could embed all that logic in the actual email, letting the manager submit a review without having to leave that email.
The problem with all of this is none of it will work because of platform support. Like you said support for AMP Emails is limited to Gmail and maybe a handful of other clients. Part of me wishes that AMP Emails were an actual standard rather than a "standard" that google created to help itself. And with only Gmail really having support, you know this will only ever get used in marketing shenanigans and to more deeply track you.
Now you have an email that's useless when offline :(
The ancient way would be, just embedding the spreadsheet in the email, which can be done because html is supported, and then accepting some replies, like "LGTM" to approve right away, or "you need to adjust X" as the review comments.
Although there's problems beyond just being able to handle the email response.
Today is that email is insecure. There's a big push for e2e encryption on instant messaging, but not on email, even while it faces the same problem of privacy not being a default.
And a bigger problem in my mind is that people working on wealthier countries probably have had almost permanent internet access while working for the last 10yr. This might make offline a non-goal for most products/services.
The biggest win from using email today might be how well it works asynchronously.
Yeah but the same argument could be made for the web. Why build a react app that complicates everything instead of just a plain HTML site. The simple answer is use cases, if you're delivering a simple email with a notification then no you do not need something like this, but some will have a case where they do need to reach for something like this. It's no different than web or mobile development. If we shunned every piece of tech that had potentially nefarious uses cases then we would still be stuck in the stone age.
> Yeah but the same argument could be made for the web. Why build a react app that complicates everything instead of just a plain HTML site.
Yes. Yes!! Exactly the same argument can be made about the web. Why is the answer to this "let's do the same in email" and not "why don't we work to reduce overengineering and complexity"?
Humans prefer to have barriers to completing a task removed. No clicks is much better than one click and privacy is almost completely dead. Privacy will slowly die unless there are major changes legally and culturally. It’s worthy to fight against the loss of privacy. I think it will be a losing fight though.
An extra couple clicks does not really seem like a major stretch, especially for anything that should be secure.
Worst case do what many things I have seen do, the act of clicking the button opens a web page that simply states "thank you for doing X". That way regardless of what platform they click it form, it works.
I am assuming you are already building the functionality into a portal that managers can go to and see a list of everyone, so why replicate that functionality in email?
Wanting to have this functionality in email feels like a severe case off over engineering for things we have been doing for a very long time.
There are very few benefits to users but all the benefits for google. This keeps people in Google for longer. That is not something we should accept. Giving google more control.
> On the one hand we have some companies trying to block things like tracker pixels and other static images for tracking purposes.
Speaking of which, when you access Gmail via IMAP, Google replaces every URL in HTML email with a tracking link, having you go through their servers first before being redirected to where you actually want to go.
I've noticed that almost all links in emails I receive in Gmail for Android, redirect through a Google link first.
I just checked and though click-and-hold shows the real link, if I tap to open, it actually opens "https://www.google.com/url?q=<original link>" in my browser.
EDIT: This happens for both Workspace and normal "free" accounts.
This definitely sometimes happens and sometimes not, but I'm not sure when. I remember this happening recently on my private email (that I can't access atm), but I can't find any examples in my work email.
To be fair a lot of emails aren't very strong evidence anyways. A lot of vendors still don't DKIM-sign their mail, S/MIME is basically nonexistent, so it's not too difficult to forge a letter.
Beyond a reasonable doubt does not mean beyond any hypothetical, fanciful, or possible doubt. I think you'd have a hard time providing a jury with a reason to believe a particular e-mail was forged, particularly if there is other corroborating evidence. And that only applies in criminal proceedings - under a preponderance standard you'd have even more of an uphill battle.
It's a lot easier for a single entity (ME) rather than a Corporation to get all this set right, I suppose. My personal domain email has DKIM,SPF,DMARC, and I send all my emails S/MIME signed at the least. Where I run into issues with this is for automatic/service account emails, like for monitoring alerts and the like. Either have to save the PW with the S/MIME cert command somehow, or just not S/MIME sign at all for service accounts.
I think that the entire concept of dynamic emails is misguided and eliminates a few of the strengths of email.
I already make sure to never allow my mailreader to render HTML or resolve links anyway, though, for security reasons. So I guess this won't affect me any.
True. But I can't imagine what the would be, honestly. I get along fine without using my smartphone for anything of importance -- especially banking -- even though I'm constantly told that's not possible.
I don't know. Companies can get annoyingly creative with this kind of stuff.
About banks and smartphones, it's a tangent but by chance my bank haven't managed to force us to have a smartphone to deal with it so far. They are trying hard though.
For months they have been displaying on web transactions that paying on the web would require the app in a few weeks. Now they just say passive-agressively that it would have been easier with the app because I would not have to type the second code we have to enter without it (except I actually saw how it works with the app and it's not even much more convenient).
I guess we are enough users to have not installed the app.
And indeed, at this point nothing in my life requires a smartphone. It's merely convenient for directions and for showing QR Codes to whatever machine which wants to see some in transport networks.
I've said it before, Google Chrome is the modern IE in terms of pushing proprietary web solutions that block out the competition, I can't remember which services it was but a few times I've seen here on HN people complaining that new Google Products work only in Chrome, but if you fake the browser agent in Firefox, it works just the same, they are just blocking out other browsers, which is really bad, I wonder where that lands a company in ADA compliance if you cannot even access something in your browser due to some developer somewhere not thinking about other browsers.
There are differences though. Anyone can take the Chromium web engine and build their own browser on top, with tremendous amounts of control. Heck, this is such an attractive proposition that even Microsoft has done this.
While the mono culture of a Chromium driven web is a huge problem, it's not the same as the IE problem.
The biggest mistake IMO was the Firefox open source project focusing on building a browser as opposed to a web engine.
Even nodejs was created on Chromium (and the difficulty of building node on Gecko was the primary reason why MS chose Chromium over Gecko).
I suspect if we want to avoid a Chromium monoculture, we will need a similar split like the Netscape > Firefox one, where someone pulls out the Gecko rendering engine and builds an open source product/business on top of it.
> Anyone can take the Chromium web engine and build their own browser on top, with tremendous amounts of control.
No. There's no "tremendous amount of control". You're still ~100% reliant on Chrome to produce all the features.
> where someone pulls out the Gecko rendering engine and builds an open source product/business on top of it.
What would be that business? Browsers are free.
On top of that: you've ripped out the rendering engine. Now what? You still have to update it, and develop it, and keep up with the rest of the industry.
Any email with linked images was already "somewhat dynamic" - I've used (abused) this in the past to fix incorrect logos on emails that had already been sent, etc.
Funny enough, this is the basis for one of David Copperfield's magic tricks. He sends the audience an email before the show starts, implores them to not open it (and I'm sure if they open it, it'll be blank or whatever). Then during the show, the audience comes up with a word that Copperfield could not have know. At the end of the show, he asks you to check that email that was sent long before the word was picked. Of course the word is "magically" there. In reality, the email was sent ahead of time with a linked image. The image contents at that URL are hot-swapped during the show to include that word... "magically".
It's too bad that mail clients encourage people to write HTML email by default. The default should be plain text, or perhaps better yet, text/markdown but without links as image sources.
Dynamic or not I've found most emails these days don't include anything useful in the email anyway, you have to click through to get any information out of it.
This could change that of course but the emails don't have information in them because of Gmail.
Senders are already going out of their way to ruin the user experience just to stop Gmail slurping up all the information.
It's actually not entirely that. Google appears to have some kind of unpublished "quality score" that is applied to emails received in a Gmail account, and it uses this score to determine if the message will appear on the inbox tab or in the promotions tab (or worse, the spam box).
One big part of raising this mysterious and possibly just a myth "quality score" is to increase your emails open rates and especially your click-to-open rate. Basically, the more people you get to open your email and then to click through to your website, the better that Google will think your emails are performing and the more likely they are to appear in the inbox in the future.
Plus, clicking through an email provides tracking information not only to Google, but also to the site you clicked through to, which helps them with their marketing campaigns or whatever else they are doing with their tracking info.
There is an entire pseudo-science that email marketing people use in attempts to increase deliverability and "inboxing" in Gmail and a lot of it just comes down to "get more people to click through to your website", and it does appear to help, at least anecdotally.
My knowledge originates from this post if you'd like to evaluate the source. The reason as to why is a theory in the post too so it's not exactly a real source, it's my source.
E: I should have acknowledged the rest of your post, sorry! I did read it, I've just got nothing to add as it's new information to me, thank you for the info! Didn't mean to come across as dismissive there! :)
For what it's worth, I'm a google workspace administrator and we've had issues with legitimate business emails going to our spam folders. We used various tools in the workspace admin console to whitelist the sender, but their mails kept going to our spam. We contacted google support, they verified our settings were correct, then kind of shrugged and said they can't explain why gmail flags things as spam. They clarified that it wasn't just that they weren't allowed to tell me, but that it was literally impossible for them to know.
So I'm not sure if there is such a thing as a "quality score", but there certainly is a machine learning black box.
Amazon's order confirmations were the one I was thinking of. Got damn they're useless these days.
Also remember when you could respond to social network messages via email? It was so useful! You don't even see the content anymore haha (that one's almost definitely to draw you back to the site tho)
You get a flight booking email confirmation. It contains the day and time of your departure. Two weeks later, the flight takeoff time is moved up by an hour. It's nice to see that information reflected in the initial confirmation email when you go to look it up and find your confirmation number or whatever.
I could see this being useful for emails that send out coupon codes. If a coupon code is updated for some reason, that update can be pushed to the user without having to send them another email.
The problem is cases of where you would want to update an email after it is sent is few and far between.
Send another email with the same thread-id with the updated info and when you navigate in Gmail’s UI to the thread the most recent message is shown and the rest is collapsed. This is already possible. You could add some metadata to make this intentional, e.g. message-type: notification and message-obsoletes-id: <prev msg id>... something like that.
The AMP’s schtick is to make emails into widgets. It’s not so much that it’s bad (potentially evil, though), but it makes email into a completely different thing.
In my mind first it’s AMP, then Android Instant Apps or something, and before you know it you have DRM in your emails.
I think it’s for X400 mapping https://www.rfc-editor.org/rfc/rfc2156. Anyway I have never seen it used in an email. A by seen I mean I just grepped a whole bunch of messages looking for it ;)
I feel the fact that the flight changed time on you is also useful information. Say if they feel that because they can dynamically update the original email it absolves them of the need to specifically make you aware of this change. Then you miss a plane, with no proof they have even pulled the rug on you.
I personally would prefer the current system. Initial email or no email changes ever. Initial email lists the original times. If changes, airline sends another new email.
This is one of those things everyone told the allegedly "open" AMP project was a very, very bad idea, and the AMP project lead basically told everyone Gmail was doing it whether people liked it or not, and then insinuated anyone who had an issue with it was violating the Code of Conduct.
It’s quite astonishing to think how divorced from reality you must be to see how badly the whole AMP thing has gone and think “Yup AMP for gmail. That’s what we need.”
Don't forget all questions about this were ignored, issues on GutHub were closed, and then the project lead wrote a self-congratulatory blog post on how the whole AMP process is open and transparent.
I can't get past the feeling that this is what Wave could have been, and now I'm torn between the infinite possibilities it opens up and the horror that Google will have even more power over their kind of emails no one should support.
I think the idea is good but the semantics aren't aligned: if a "thing" is to be modified, it can't be an email. There is too much history ingrained about emails being static and updates appearing in another email. But maybe this can open up a new form of collaboration that never mentions the word "email" but uses SMTP/IMAP as a transport. I'm thinking about what Deltachat is doing and it's using the protocols to transport "metadata" information that is not to be read directly by users. They even created embedded apps to further the capabilities and give users a way to do much more than just exchanging messages: https://webxdc.org/
All in all there is a place for self-modifiable documents with updates transported via SMTP, but the semantics need to be very clear. And it's hard to believe Google and follow it to be a good steward for an open, beneficial protocol and idea.
Those of us that are software developers need to reject this if possible. I regret not doing enough to inform my organization on why AMP should be considered harmful back when it was becoming a thing. Even though they likely would have still gone ahead with it, there was still a decent chance they could have been persuaded.
> Modern DKIM deployments are problematic because they incentivize a specific kind of crime: theft of private emails for use in public blackmail and extortion campaigns.
was I the only one that read this like... oh, this is how we plan on getting past your carefully curated spam filter, by changing the email after it slides in?
I do think that we need some other markup language that is more consistent across platforms, but AMP doesn't sound like it. Neither should emails have dynamic content (though some vendors bypass that already with .gifs).
I would already be satisfied with email clients supporting Markdown, but then it couldn't fully replace HTML in terms of flexibility. It'd just be a nicer middle ground between plain text and HTML.
Don't post this like it's something new. It has been around since 2019. With all the usual pushback and everyone being annoyed it even exists. But has adoption picked up? Probably no. It's not new.
Interesting to see the responses here are mainly negative.
I think email (and by extension, mail) is traditionally static because the medium never allowed for dynamic updates. I don't see the harm in trying to improve upon that. If a solution is found that allows for full transparency of those updates with sufficient privacy, why not?
Should email stay the same as it has been for another 50 years? I don't think it will.
An Email is supposed to be a document which reflects the state of a topic at the time it was sent.
The fact that there is a need in the industry for distribution of dynamic content which provides different (more recent) information whenever it is read is clear.
But maybe that's not an evolution of email but in direct contradiction to it. Maybe it's something entirely different that is needed ... an industry standard for notifications.
Unfortunately the current landscape of the market is not favorable to create proper industry standards anymore like it used to, as all the big players feel that they have no need to co-work anymore to solve a cross-industry problem.
The fact the content is static makes the content usable offline and suitable for archive purposes. I don't want this feature to be tarnished. In fact, it already has (and is already dynamic and online) thanks to HTML.
I would agree but at least part of the issue is that Google has a poor track record within the email design community for having weird / wonky support of the standards that already exist.
If they had worked on addressing some of those shortcomings alongside the launch of Amp for email, it would have gone a long way to promoting adoption.
The article is regarding something from Google so you are always going to have the anti-Google crowd come out and blast it no matter what it is. You also have the people that are still upset that anything except text is allowed in email.
I have received dynamic email a couple of times over the last couple of years and each time it has been a pleasant experience. For example my local mechanic sent a reminder that it was time for my vehicle inspection and my oil change. I was able to schedule my appointment for these directly from the email without having my email reading interrupted by having to switch windows or tabs.
Yes. I assume he uses a SaaS product for customer contact and for scheduling. One of the great things about SaaS is it gives local small businesses access to the latest technologies.
Emails that can be changed after delivery eliminates one of the huge benefits of using email, though. It's a bad thing even if there are no privacy concerns.
And how could there be no privacy concerns? At a minimum, a server somewhere is going to be notified every time you open the email, so it can check for updates.
As someone who's been working in email marketing for 5 years, I couldn't agree more. I'm quite surprised with the amount of negative comments.
But it is what it is. The main problem with amp for emails is that email marketers don't have the time to make them. We're always excited when somebody get something out that's awesome, but it stays at that.
We're back at our day to day operations. Unfortunately amp is staying in the "Important, but not urgent" category for a few years now.
> who's been working in email marketing ... I'm quite surprised with the amount of negative comments.
If take email marketing to be a legit line of business, you might like this feature. But your assumption would be invalid. Email marketing is detrimental to society. It's the not-illegal spam. Don't market to us.
> working in email marketing for 5 years, I couldn't agree more. I'm quite surprised with the amount of negative comments.
Because you're working in marketing, and you literally don't care about people. People to you are just money making machines that you need to squeeze to get that sweet ROI, OKRs, hockey stick graphs on "user aquisitions", increased ARPU and other crap.
I've yet to remember a single marketing crap in my inbox I didn't delete immediately upon receiving.
Thanks for the question. From where I'm standing this is a great emai and a opportunity for brands to convey their message more effectively and to make users experience more enjoyable.
From where this community is standing, this is a big opportunity to work on fun projects. Email development is specific a little bit, but it's greatly enjoyable for many.
Whether it's worth the risks, hmm, maybe, maybe not, I've seen a few great arguments in this thread.
Actually, from this thread, I feel this type of email I mentioned MIGHT be acceptable in a sense. The ones where you can do a functional thing from email, like accept a calendar event are a different story.
But we're a long way from having amp as a standard practice.
Interesting. That email is exactly the sort of email that annoys me to no end as a user.
It has a large graphic and extremely low information density, and doesn't actually provide much value. It's just an ad. And an ad that obviously comes with tracking.
I'm certainly not the target demo for that email, but if the marketing emails I get that are intended for my demo were like that, I'd consider them to be spam.
All this screams to me is that google has way too much power in email to be able to implement something like this.
On the one hand we have some companies trying to block things like tracker pixels and other static images for tracking purposes.
Then we have google saying "lets make emails dynamic" and just making it easier to track.
I hope no other email provider adds support for this. Email needs to remain static and platform agnostic.