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.
> Making a universal email message have bespoke instructions for a specific mail provider. Call me old fashioned but I don't like that.
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.
They may be open formats, but you can't just throw Microdata and JSON-LD into an email and expect Gmail to display your actions. You have to register with Google:
Implementation-specific email headers aren't new, and many providers have been leveraging them in one way or another -- probably since email itself came to be. Outlook is a great example here. It's basically just value-add's for the client.
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.
The fact that this was posted on the Google Apps blog is telling- I imagine that Google wants to roll this out to Apps users before general Gmail users.
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?
> I imagine that Google wants to roll this out to Apps users before general Gmail users.
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.
Good point. I think in the days before Google starting charging for Apps, many of the users were the tech-head-early-adopter crowd. Which is why many were so disappointed that they got all the new innovations last.
I think everyone would be happier if Apps users could signal to Google they would like to be a 'new features beta tester'.
Yes, but I AM the administrator for the Google Apps account associated with my personal domain. It's not a matter of not having enabled it; G+ simply wasn't available.
Some weeks ago somebody proposed a way of indicating that he is just expecting a short reply to this email (for example yes/no). I think this is pretty close.
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.
Lots of strangely negative reactions here. We (http://inky.com) think this is a positive development and plan to support it as well. We're happy Google has promoted open standards in doing this.
I don't think the reactions are strange at all. Google have a bad track record in implementing things and then abandoning them for one.
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.
I see your point, but consistency of email display went out the window with HTML email. We (and Google, and hopefully everybody else providing mail readers) put a ton of work into sanitizing HTML before rendering it in the preview pane. This makes mail display a delicate balance between safety and preserving the sender's intent. It's already a far from trivial problem, and is one of the hundred or so non-obvious reasons why making a mail client isn't easy.
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.
Not that I know of, and in fact real-live HTML emails often contain complete gibberish (made-up tags, etc.) that doesn't even validate; we have a bunch of fix-up rules for this stuff.
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!
Huh. I would think that the only ones benefiting from the current state of affairs are scammers and spammers, strange that the big players haven't gotten together and done something about it.
When I got dropped into crafting newsletters, I made the mistake of not looking into what different clients support only to find that my beautiful CSS buttons and the majority of the formatting was completely useless.
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 have a bad track record in implementing things and then abandoning them for one.
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.
It's all Fire and Motion. Google wants this to gain traction so that competing email clients spend cycles gaining feature parity. And for what? Make clicking a link easier?
> It's all Fire and Motion. Google wants this to gain traction so that competing email clients spend cycles gaining feature parity. And for what? Make clicking a link easier?
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].
I tried Inky after following your link. I signed up, added an account, let it sync up and played with it. I then went to settings and deleted my account and quit Inky. I noticed my computer running hot a few hours later and it turned out "inkycore" had been running with 100% in the background the entire time.
The feature appears to be independently implementable in other clients, so if it takes off and those badges start appearing, then other e-mail clients can follow.
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.
The format may be open, the ability to use it isn't - you need to register with Google[1] or they won't display actions on your e-mail. This appears to be necessary for security reasons. Imagine if every e-mail provider did the same thing!
And even if they implement the "open standard" in outlook, who says Google won't bait and switch (oh the irony) then, like they did with their youtube apps on windows mobile?
Give me a break. How is requesting they remove a non-compliant youtube app a "bait and switch". Is this going to be the new "cool" thing to post now every time a submission involves google?
So, suppose that (a) companies start sending useful metadata with their emails, (b) other clients like Outlook add support, and then (c) GMail capriciously removes support. As long as the metadata keeps getting sent, and there are clients which can do interesting things with it, I don't see the problem here.
That's bad, yes, and I wish they didn't require that, but it doesn't hinder the use of the protocol outside of their services, which is the most important thing. It just adds some extra work to the senders.
> > it doesn't hinder the use of the protocol outside of their services
> 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?
I assumed by "outside of their services" you meant non-google people who want to send email using this. On re-read, you mean it doesn't stop anyone else building a client that can understand these actions, right? That's true.
> Because just like google needs people to register for security, so do other providers.
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.
As a vendor, the registration would be extremely annoying. Since these widgets are meant to replace HTML links and buttons, I would then have to create and support 2 versions: the fancy widget version all the providers I registered with, and a fallback for providers that don't support it.
There is a large disconnect between people that use/default HTML on in their mail clients, and people that don't.
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.
> People that reply with color coded text to denote who's speaking cause me a unique type of pain
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.
I think he's referring to people who give no indications for who is being quoted/if the text is their response, /except/ different colors. Its pretty hard to do this without noticing - if you aren't seeing different colors, you should be adding (Tom) or whatever to mark who said what.
A solution to this seems to be to set the default composition to plain text, which may or may not have other negative consequences depending on your usage. At least that's a solution in Thunderbird, I have no idea if Outlook handles this well (or at all), and any caveats it may have. I imagine it does handle it, Outlook has historically been pretty feature heavy and I know people would have asked for this.
Sorry—I was reading into it as an analogy outside the context of e-mail: I initially interpreted it as a slight on the entire HTML technology. Making more sense now, sorry for the confusion!
Whatever happened to the Unix philosphy? 'Write programs that do one thing and do it well'. Last thing I want in my inbox. Call me a purist but email is for emailing people.
> Whatever happened to the Unix philosphy? 'Write programs that do one thing and do it well'.
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.
The question you should really be asking is why shouldn't they? The best applications out there do one thing and do it well. Awk, sed, vi(m), emacs, git. Need I go on?
This is simply nonsensical. Even the applications you listed don't just "do one thing". Vim and emacs have a trillion features each. Git has way more features than some other versioning systems. When does "one thing" turn into multiple things? Within the context of the thread - when did gmail stop doing one thing? When they added filters? When they added all of the labs features? With this current announcement? Do one thing and do it well is great but defining the scope of the one thing is not something to be taken trivially.
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.
I think you are missing the subtle tones, implications and context within the comment. It was not meant as a blanket statement hence it is a comment against a specific item.
The post you responded to addressed sending an email from one Gmail account to the same Gmail account. If you read the first paragraph [1] of the page you link, you will note that this does not require registration, so that does not appear to be the issue.
[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!
We were one of the companies to support this during the launch announcement today, and we've been playing with it for the past month or so. It's an awesome feature for transactional emails that require a quick action to be performed - we use it for task notification emails where you can check off a task as complete right within the email client. It's based on an open standard, and plain old HTTP POST so not specifically tied to Gmail.
Again, what is the difference between this and clicking a link? Instead of showing a link , they show a button is it? Adding a bunch of crap into email body is worth that?
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.
Because security really is never a good reason to be skeptical and skepticism, no matter how valid, is just a cloak for hating on Google. I love GMail and lots of Google's products. I even like that this feature will be limited to companies that register with Google. It doesn't change the fact that those partners could be broken into and used to send out malicious emails.
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.
> So many possibilities? There is nothing here that couldn't be achieved by having the user click on a link.
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].
>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.
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.
> currently SMS is the only open standard for instant messaging
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
Just like short sellers, we need these naysayers to keep us grounded. :) Yes, I choose to see the positive possibilities and the opportunities that show up thanks to our beloved naysayers.
No. It's more that there are so many positive possibilities yet a large group of people still choose to exploit them to make themselves money by harming others and end up breaking things for everyone else.
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.
Being an open format that can be implemented by any other mail client is, in my opinion, an important part of the feature, especially for those of us who don't use Gmail.
a company that inserts this type of response hook in their emails needs to register with google. the response interface looks clearly separated—its not in the body of the email—so there is no way that a phisher could fake it.
so it actually could help to SOLVE the phishing issue. especially if other mail providers sign on.
Some html elements (like forms, form elements, ...) won't work in emails/get stripped by (web-)mail clients. The same goes for JavaScript and a lot of CSS features.
> I don't get it, wouldn't an html email with a form element do the same thing?
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.
> So... you're saying it should have been conceived of as a particular file type and attached, like all other non-message-related elements?
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.
> 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, if I was saying that, you would have seen those words in my message rather than yours."
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.
> "It is now quite common for systems that handle HTML to provide mechanisms for extension to provide additional functionality"
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.
The buttons appear in the subject line in your inbox, so you can click them without opening the mail first. I think the use cases are fairly limited, but I can think of a few interesting ones (for example, bugzilla notifications could link directly to the bugzilla page, mailing lists could have a "manage subscription" button, etc)
Unlike an HTML form, this could show up in the notifications drawer on Android.
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!
Not really - it's all about contextual actions in the Inbox. That said, Gadgets have been available in GMail and I know of no reason why one couldn't pretty much implement the same action without Google's blessing. A data format spec is a natural next step for Gmail gadgets. Microsoft also has had support for mail apps in Outlook 2013 where you can specify activation rules for gadgets/apps to show up.
super cool. we are doing something similar with Birdseye Mail's Smart Actions http://www.birdseyemail.com/developers ... we opted to reuse open graph tags in favor of creating a new JSON / JavaScript syntax
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.
How long till gmail us turned into a hybrid private messaging/gmail system tightly integrated with G+ (more so than now)? Gmail as we know it seems to be on its last legs. Too bad, because it is a good product.
That's a remarkably dramatic response to Google announcing that (a) you can add structured event metadata to emails in a straightforward open format, and (b) G+ will use this metadata.
Just need to make sure I am getting this. Actions will make things happen once you open the email right? I am rather confused by this whole concept. Furthermore when will Google give me more control over my inbox like a builtin ifttt system? I mean filters does alot but I want more and not just for gmail but for all Google services. Example certain days I go to the gym but I only go if it is not raining. I wish I could tell calendar schedule gym if not raining. Is that what actions is?
You can accomplish both of those with keyboard shortcuts. "e" archives it, "#" trashes it. They also work in the list view if you select the messages you're concerned with ("x" to select).
Can the response include who is clicking the action? For example, if you want to take a quick poll from within an email that is sent to multiple people, can you identify who is voting for what?
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.