20 ms·

I don't get it, wouldn't an html email with a form element do the same thing?

by yread 14y ago

pfg 14y ago
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. Probably would be a security nightmare.
- diffsir 14y ago
  Yeah.. it's not like forms work in Gmail. oh wait they do. Get your facts straight.
codeka 14y ago
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)
dragonwriter 14y ago
> 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.
- roc 14y ago
  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?
  - dragonwriter 14y ago
    > 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. [1] http://www.schema.org/Person 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.
    - roc 14y ago
      > "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.
rkoz 14y ago
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.
Ironlink 14y ago
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!

I don't get it, wouldn't an html email with a form element do the same thing?

by yread 14y ago

I don't get it, wouldn't an html email with a form element do the same thing?

pfg 14y ago

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. Probably would be a security nightmare.

diffsir 14y ago
Yeah.. it's not like forms work in Gmail. oh wait they do. Get your facts straight.

codeka 14y ago

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)

dragonwriter 14y ago

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

roc 14y ago
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?
- dragonwriter 14y ago
  > 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. [1] http://www.schema.org/Person 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.
  - roc 14y ago
    > "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.

rkoz 14y ago

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.

Ironlink 14y ago

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!