Gmail: Introducing Actions in the Inbox
googleappsdeveloper.blogspot.co.uk
googleappsdeveloper.blogspot.co.uk
Making a universal email message have bespoke instructions for a specific mail provider. Call me old fashioned but I don't like that. Infact I still like to read my e-mails in plain text.
Also, I dare say, not so useful for the many of us accessing gmail via Mac devices' mail clients.
Its all using open standard formats, and the specific schemas are open standards or proposed for standardization (and Google has said that its schema support may change if the schemas change in the standardization process.) Other providers could use it as well. This is how progress happens in open systems. The alternative is either abandoning the open system for new functionality, or just never getting new functionality at all. And its not the provider that is key here, but the client (the fact that for many gmail users the supplier of both the mail service and the mail client is the same makes it easy to confuse the issue.)
> Also, I dare say, not so useful for the many of us accessing gmail via Mac devices' mail clients.
Yes, features in the Gmail client that aren't included in other clients aren't useful to people using the other clients. I'm not sure why this is noteworthy.
https://developers.google.com/gmail/schemas/registering-with...
You can still read email in any client, so why would you choose any specific client? I think the onus remains on the content creators, just as it is on the web and elsewhere on the net, that they only use the extended functionality to enhance the content (and not replace it). An example here would be HTML emails -- which, since you said you prefer plain text, I'm sure you hate? But they are common and those that use them know that they need to include a "view on the web" link for clients who don't understand HTML.
I do like plain text the best though, as I think that's where email excels, though SMS has some overlap. Ultrafunk Popcorn[1] was my preferred email client for 5+ years, and was an awesome client. Required only a conf file and something silly like 200k of RAM to run. Sadly, development stopped on it awhile back I think, though it probably still works just fine. It's the equivalent of the foobar2000 music player, dead simple and efficient.
1. http://web.archive.org/web/20130116201517/http://ultrafunk.c...
I'm surprised by the reaction in here- yes, it's an addition to the standard e-mail system. Do we really want that system to stand absolutely still? If that's the case, why are we cheering so much web browser development? Surely a browser from 1997 should be good enough for anyone?
That'll be a first. Historically, Google has deeply neglected Apps users. My Apps account didn't get G+ until almost a year after it became generally available.
That's a funny way of looking at it. I pay Google money for my account so that I have, above all, a reliable system to use for my business.
No beta bullshit. And with Google Apps, that's what I get.
Regular users are the guinea pigs and once a feature has proven itself year(s) later, it's added to Apps. As someone who runs a business, I'm quite happy with that approach.
I get all the latest and greatest on my personal GMail account, I don't need it on my business account.
I think everyone would be happier if Apps users could signal to Google they would like to be a 'new features beta tester'.
Also I can see uses for this on business systems. Notifications are send via email, could be useful to make it possible for users to also take action in their inbox without proceeding to web.
I want my email to be a consistent experience - not to get some different behavior if I access through a certain device. Email and its simplicity was universal - I saw the same text on my phone, tablet, laptop and desktop. Will every mail sender who makes use of this, include the JSON and an alternative link to achieve the same result. I think this could get very inconsistent very quickly. Fragmenting email is not something I like the idea of.
For Google Apps customers' internal mails I think this is useful. For the wider Internet I don't like it.
What's nice about what they've done here is that they've required an additional (but now standard) level of authentication for the senders who want to include this richer, more actionable content. And they haven't hardwired this into Google Plus or some other walled garden. That's welcome, IMO.
CSS is a complicating factor as well: some CSS is unsafe and must be stripped, which requires a real (error-tolerant) CSS parser to go along with your real HTML parser.
And identifying remote images: you'd think that was easy right? But do you know how many ways there are to reference a .png image in HTML and CSS?
At one point Facebook emails were even hiding web bugs in BGSOUND tags -- sneaky!
I agree a standard set of HTML and CSS for email would be a huge benefit.
It was only afterwards that I started noticing most beautiful emails are just sliced images displayed within tables. Thats right, tables.
Google Reader drama isn't ever going away on HN, is it? The loud minority keep bringing it up regardless of what innovative products Google develops.
> I want my email to be a consistent experience - not to get some different behavior if I access through a certain device.
One decade ago most clients poorly supported HTML email, if at all. It was an inconsistent experience. Understandably it was new technology, so most of us patiently waited until the standard was adopted by email clients.
Same thing here.
Actually, its to make machine-parsing of meaning easier so that information can be extracted from email and presented through other UIs (particularly, Google Search and Google Now.) Surfacing and facilitating responses to calls-to-action in the Gmail UI is important, but the big motivation is, I think, found in the two pages in the "Cross Google Experience" section of the documentation for the Schemas in Gmail feature [1][2].
[1] Answers in Google Search: https://developers.google.com/gmail/schemas/google-search [2] Google Now: https://developers.google.com/gmail/schemas/google-now
Good marketing bit there ;)
The fact that it is open does not imply it needs either to be supported (does gmail support S/MIME, by the way?) or that it is convenient.
Links? Phishing would be much different if people read links instead of the <a> label.
Images? Really? Just attach them and do not add clutter to the message.
Edit: did I say something wrong?
Really?
Additionally, as always, people take it as an attack against themselves when you threaten an action they do often and like doing.
For my (probably our?) part, I prefer text email to a large degree. I do enjoy the ability to view in HTML a few select correspondences I get, but they could just as easily be links to a webpage. In a similar vein, I prefer bottom posting or inline replies for anything beyond a simple response, and trimming unused portions from large quoted sections.
People that reply with color coded text to denote who's speaking cause me a unique type of pain, and I reserve a unique type of hatred for them.
That said, there are probably others that I annoy with my style of correspondence.
Not all of us do it on purpose, sometimes it's Outlook helpfully changing our text color to blue after we've copy/pasted from some text from a correspondent. I usually notice this right after I send. Sometimes if someone has a name that's unusual to me, you can tell I had to copy/paste it because it's blue and the rest is black. Always love that one.
[1] https://developers.google.com/gmail/schemas/registering-with...
> To hinder: to add difficulty. I'd say it certainly does hinder use of the protocol.
How does Google requiring registration before actions are displayed in Google properties hinder use of the schemas in email outside of Google services?
This rapidly becomes unwieldy - how are you going to convince people to register with tons of providers? So this format is pretty much google only.
That's probably a bad assumption, once you have more than a few parties using this system. I'd be surprised if even Google used the current, apparently manually-reviewed, registration system for long rather than as a short-term measure before moving to a less cumbersome accountability mechanism (and this is more "accountability" than "security".) But even if multiple parties were using that kind of method, there's a clear incentive -- especially for the players that aren't Google, but even Google has some incentive -- to build a facility where a shared registration application can be automatically distributed to multiple parties.
And some "designed for gmail" badges may actually be a good thing — maybe that would force Microsoft to do something with grotesque HTML rendering in the latest Outlook.
http://en.wikipedia.org/wiki/Microsoft_Outlook#HTML_renderin...
Emacs is the polar opposite of the Unix philosophy; it's more in line with the Lisp Machine tradition. Programs like sort, uniq, and grep don't embed interpreters for dynamic languages and provide thousands of different extensions for anything from reading mail to connecting to IRC.
Are you implying that there ever was a time when all programs did only one thing and did it well? Which era was that?
Its still a valid and important way of constructing software systems. But users mostly don't want a separate UI for each of those components, they want them strung together in a way which provides a simple experience that allows them to get the things they want to do done.
How is automatically recognizing meaning and surfacing action requests from email a "barely related" feature to an existing email client?
https://developers.google.com/gmail/schemas/actions/end-to-e... (The html with my own link) https://developers.google.com/gmail/schemas/embedding-schema...
From my account to the same account but it did not render any actions in my gmail inbox. Did any of you guys succeed in making the buttons appear?
https://developers.google.com/gmail/schemas/registering-with...
[1] We are excited to see how you plan to use schemas in email. You can start testing your own integration today. All schemas you send to yourself (from x@gmail.com to x@gmail.com) will be displayed in Google products. So go ahead and try it out now!
https://developers.google.com/gmail/schemas/actions/securing...
This is right out of Microsoft's embrace/extend playbook.
1. I book a flight, and get a flight confirmation email from the airline. It includes a machine-readable version of my flight info in the metadata.
2. I press a button, and the flight gets added to Google Calendar, or a flight-status tracking app, or a shared travel calendar service for people who fly a lot. Note that this stuff doesn't need to be written by Google; it's an open format.
Sound potentially useful?
Btw how would one suggest something like this officially? There seems to be no issue tracker or anything for gmail.
And he's right, it does make phishing easier.
Because its machine parseable, it makes a lot of presentation options available that aren't available when you rely on a standard hyperlink without a data format with a standardized identification of the requested action.
> And he's right, it does make phishing easier.
Well, that depends on what the requirements are to have the client present the actions from the schemas: the current Google requirements, I would say, do not make phishing easier. You must register with Google for the schemas in the email you send to be recognized in Google products (e.g., Gmail) [1], and the registration is per-set-of-emails, and fairly specific as to the content, and appears to be manually reviewed [2].
[1] https://developers.google.com/gmail/schemas/registering-with... [2] https://docs.google.com/forms/d/1PA-vjjk3yJF7MLPOVKbIz3MBfhy...
You're right: this addition turns email into a data or event queue of sorts with standardized actions that can be performed on it. I like it. Given that email is one of the few non vendor-locked communication technologies we have and we already have a lot of infrastructure to deliver it reliably, this seems a promising evolution path.
I'd like to see something similar for IM: currently SMS is the only open standard for instant messaging, and any other option locks you into either a platform or a specific client, which the other person will probably not use.
XMPP is an open standard (through IETF RFCs and related standards) for messaging and presence whose motivating use case was instant messaging: http://en.wikipedia.org/wiki/XMPP
The whole history of modern operating systems and the Web is the example of that. Think of all the amazing and useful things that could be (and have been) done had there was no Data Execution Prevention or Same-Origin Policy or any other limit introduced because of security.
Also, please don't try to insinuate that I'm against the feature. I'm not. I can stop using GMail if I ever want to. I just think everyone should consider their own security and decide how valuable it is to them based on reasonable possibilities.
https://developers.google.com/gmail/schemas/actions/securing...
so it actually could help to SOLVE the phishing issue. especially if other mail providers sign on.
Probably would be a security nightmare.
No, it wouldn't identify the meaning of the requested action to the email client in a way which allows the mail client to categorize/present the email specially based on the requested action, and in a manner which is consistent with other emails with the same kind of action request.
Would Google encode a vcf file in JSON and embed it in the message? How is handling VCF different than handling other optionally-actionable data?
No, if I was saying that, you would have seen those words in my message rather than yours. If you want to say that, go ahead, but don't misattribute it to me.
But if you were to make that argument, I'd probably point out that its not "non-message-related" (actually, the biggest problem I have with it -- at least with the examples -- is that rather than adding semantic markup to the main content its all done by adding largely-redundant markup to the <head> element of the main content; I'm not sure if this is required, though, and I would hope it isn't since schema.org microdata doesn't normally require this mechanism, and this style is an uncomfortable hybrid between separate attachments than embedded semantic context.)
And the file type is HTML. I don't see why an additional filetype is needed for this.
> Would Google encode a vcf file in JSON and embed it in the message?
I would be very much unsurprised if Google expanded its schemas-in-email support to include the schema.org Person type [1] and related types needed to support it, which provide the functionality provided by vCard (and a lot more). Since, after all, Google already supports that schema type for rich snippets in search.
[1] http://www.schema.org/Person
> How is handling VCF different than handling other optionally-actionable data?
vCard was a solution that was well adapted to the state of internet communications in 1995, but not necessarily the best model for new functionality in 2013.
No-one was 'misattributing' anything to anyone. It was a figure of speech. Welcome to the sarchasm my friend.
> "its not "non-message-related""
A bad word choice on my part. it is indeed message related; I was just (poorly) trying to draw a line between the message itself and the potentionally-actionable addenda. This whole project seems like an unnecessary marriage of the two.
> "I don't see why an additional filetype is needed for this."
For the same reason we have vcf even though it just happens to be particularly-formatted text. The filetype is more than the encoding. It's a hint to the client and the operating system as to how something should be handled. And should a given client not be aware of these 'actions', using a file-type enables the host system to present an application or extension that is. Again, not unlike VCF.
"Aware" clients could process and present these 'actions' alongside the email, with little difference to how they want to do things currently and not unlike the way they process and present image attachments or PDF previews or what-have-you.
Embedding it within the email not only disadvantages those not using the big email clients (as we've all seen embrace/extend in action, right?) but it places ones email provider in the middle of a non-email exchange between the user and another service.
If anything, the way functionality has been created in 2013 is exactly why we should take care to not see things like this become a carrot for data silos.
HTML isn't an encoding, and HTML is the filetype in which the structured data used for schemas-in-email is embedded, using open standards for embedding various kinds of data in HTML.
> And should a given client not be aware of these 'actions', using a file-type enables the host system to present an application or extension that is.
It is now quite common for systems that handle HTML to provide mechanisms for extension to provide additional functionality that don't rely on segregation of related data into separate files with separate types.
> Embedding it within the email not only disadvantages those not using the big email clients
Parsing microdata and JSON-LD isn't exactly difficult; obviously Google specifically as the first mover has some advantage, but I don't see how this disadvantages any other client any more than any new feature a client implements.
> but it places ones email provider in the middle of a non-email exchange between the user and another service.
How is it a "non-email exchange"? Its an exchange conduct through email. That's an "email exchange".
> If anything, the way functionality has been created in 2013 is exactly why we should take care to not see things like this become a carrot for data silos.
How is the completely-open framework involved a "carrot for data silos"? You keep asserting conclusions without explaining your rationale.
Yes, that's the point. Embrace/Extend is part of the risk. The pitfalls have been shown before. We're supposed to learn from these things.
> "I don't see how this disadvantages any other client any more than any new feature a client implements"
There's a line between client features and proposed extensions of standards. e.g. everything Mailbox has done is fundamentally different from Google's 'Actions'. If you can't see that difference, it might explain why you don't see any problems.
> "How is it a "non-email exchange"?"
When I write a review for a Netflix movie I just returned, it has nothing to do with email or my email provider. Period.
Today, Netflix sends me an email letting me know they got their disc and including a helpful link in the email should I want to write a review. I can click that link and exchange data with Netflix.
Under this proposal, the mail provider brokers the exchange of data from myself to Netflix. It allows (in this case) Google to index not only that I got an email from Netflix, but without my doing anything, they're provided (in an easily machine-readable form) data that indicates the very precise meaning of that message.
And should I click to review, they're provided with all the data I use to respond to those very-machine-readable questions.
Reviewing a movie I've just watched is a follow-on interaction, that may have been raised by the email, but has little to do with it. It ought be no different from my reading and interaction with an attached PDF or image, or adding a calendar invitation, or anything else.
For those of us who are on board with the modern "let's give large data silos all our data so they know everything about us" approach - this might sound like something between a non-issue and a desirable result.
But not everyone is on-board with such an approach. And making that the default interaction that non-technical users are presented, and adding additional overhead for anyone who would rather not fork ever more data over to the data silos, it is not a 'feature'.
> "How is the completely-open framework involved a "carrot for data silos"?"
Under the guise of adding 'features' (carrot), providers are going to be able to much-more-easily harvest much-more personal data from users, even without those users doing anything, over the current state of things. And, again, there's no reason a properly Unix-y/Internet-y architectural solution to this same problem couldn't have been chosen. Such an architecture would present zero difference in functionality or interaction for those who are fine with the silos. But massive differences in usability and interaction for those who are not, those who don't know the difference and those who use mail clients that aren't tirelessly maintained.
e.g. Presenting this data as an attachment that can be opened by programs other than the email client, in a context separated from the email provider. So those that want to use a better/safe/more-accessible tool to display/process these forms can choose to do so, regardless of what they choose to read their email with and regardless of whether that client is/can be updated as fast as the user desires.
That this proposal is "open" only means that any particular silo is encouraged to support it, no different from, e.g., any other proprietary extension to css or html.
I for one think it would be pretty sweet if I could just tap a notification to (for example) verify my email address & archive the message, rather than involving a browser!
Still really great that Google signed up partners for the rollout. It's a bit of a chicken vs. the egg problem for technologies like this and it seems they have some cool email providers on board to help with the adoption.
Regardless of the outcome, this is great for consumption of emails and for users who have trouble dealing with their high volume of email.
so how many other clients will support this? Gmail is pretty big, but if functionality is limited to Gmail it won't take off
[1] https://developers.google.com/gmail/schemas/google-now [2] https://developers.google.com/gmail/schemas/google-search
Definitely agree with most of the commenter's. Sounds like a huge helper for google apps and the SaaS apps built on there.