Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gmail: Introducing Actions in the Inbox

googleappsdeveloper.blogspot.co.uk

Post reply on HN
Print view View original

111–120 of 147 posts

Re: Gmail: Introducing Actions in the Inbox

#111

Post by infrec »

d43594 wrote: post #107
kyrias wrote: post #88

Earlier quoted context omitted.

Few things adhere to the Unix philosophies anymore, and really, why should they?

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.

Re: Gmail: Introducing Actions in the Inbox

#112

Post by dragonwriter »

imissmyjuno wrote: post #98
dragonwriter wrote: post #74

Earlier quoted context omitted.

> 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 requiremen…

>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 co…

> 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

Re: Gmail: Introducing Actions in the Inbox

#113

Post by dragonwriter »

notatoad wrote: post #103

can we expect this data to start feeding into Google Now?

You can expect it to feed Google Now [1] and Google Search [2]. That's a rather major part of the point.

[1] https://developers.google.com/gmail/schemas/google-now [2] https://developers.google.com/gmail/schemas/google-search

Re: Gmail: Introducing Actions in the Inbox

#114

Post by dragonwriter »

pornel wrote: post #34
cafeconleche wrote: post #13

I tried to email the following two examples with a simple SMTP python script: 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?

Maybe you need to register first? https://developers.google.com/gmail/schemas/registering-with...

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!

Re: Gmail: Introducing Actions in the Inbox

#115

Post by dragonwriter »

d43594 wrote: post #35

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.

Re: Gmail: Introducing Actions in the Inbox

#116

Post by icebraining »

jacalata wrote: post #92
icebraining wrote: post #63

Earlier quoted context omitted.

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.

To hinder: to add difficulty. I'd say it certainly does hinder use of the protocol.

"doesn't hinder the use of the protocol outside of their services"

Re: Gmail: Introducing Actions in the Inbox

#117

Post by dragonwriter »

jacalata wrote: post #92
icebraining wrote: post #63

Earlier quoted context omitted.

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.

To hinder: to add difficulty. I'd say it certainly does hinder use of the protocol.

> > 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?

Re: Gmail: Introducing Actions in the Inbox

#118

Post by imissmyjuno »

dragonwriter wrote: post #112
imissmyjuno wrote: post #98

Earlier quoted context omitted.

>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 co…

> 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

Right. My comment is more on the adoption rather than availability of open standards.

Re: Gmail: Introducing Actions in the Inbox

#119

Post by sixbrx »

kbenson wrote: post #80
pfortuny wrote: post #40

Earlier quoted context omitted.

Not that I know of. Why? Links? Phishing would be much different if people read links instead of the label. Images? Really? Just attach them and do not add clutter to the message. Edit: did I say something wrong? Really ?

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…

> 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.

Re: Gmail: Introducing Actions in the Inbox

#120

Post by roc »

dragonwriter wrote: post #109
roc wrote: post #78

Earlier quoted context omitted.

So... you're saying it should have been conceived of as a particular file type and attached, like all other non-message-related elements? 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?

> 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 p…

> "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.

Post reply on HN