5 ms·

Web Intents - the future of web apps

200 points by kinlan 15y ago

jinushaun 15y ago
Interesting idea, but the examples seem very awkward. I was expecting an in-page UI instead of an HTML popup. I was expecting a cookie to save my favoured intent for later use so I didn't have to choose a service provider every time I wanted to shorten a link. I was expecting to be returned to my originating page once I was done with the intented service.
- kinlan 15y ago
  This is actually something that we can work on over the project, cookies are something I am pushing for, but it would be entirely up to the User Agent. If you check out the cloud picker for example, it does return you to the original page. On the subject of in-page UI, at the moment there are too many risks embedded an in-page UI... IMO, also for a non-built in solution we have to deal with popup blockers so it limits what can be done.... However this should be a core part of the web platform soon so the current shim won't be needed.
radagaisus 15y ago
This is really a great idea.
nikcub 15y ago
it belongs in meta rather than as its own tag
- kinlan 15y ago
  We tried this pretty early on. I feel like it is bastardisation of the meta tag to add information that is needed by the system to register an intent, we can't add new attributes just for intents. Then if you have to have it span across multiple tags it is a nightmare to manage for developers. If you don't span across multiple tags you have to have a special encoding inside the meta tag to describe the intent, which again is massively frustrating for developers. How would you specify an intent through the meta tag?
  - nikcub 15y ago
    it might be a bastardization of meta, but there must be a way to stuff this metadata into the existing structures, possibly even HTTP headers (I remember RSS auto-discovery going through a similar development process.). my initial thought was: <meta property="app:type" content="image/jpg,img/gif" > <meta property="app:handler" content="open" > and use canonical as the href. you can have multiple handler types, which are standard types, and then handers are actions the concern that I have is that with the types this is just file extensions being moved to the web and all the problems that caused in desktop computing. ie. associating applications with file types. but you are saying that there is no default handler, that you get something more akin to an 'open with' which lists the applications that can handle that type can you email me (email in profile) to discuss further, or is there a mailing list? I am interested in this area and have seen a number of 'web app/widget discovery' initiatives over the years but none really took off (edit: code didn't show up)
    - gbhn 15y ago
      I've talked with Paul a bit about this. We've also mocked up using link tags, which carry a bit more metadata. Probably the most promising approach, though, is using other webapp manifest ideas to bundle intent provider installation with that. (a la http://lwn.net/Articles/419151/ http://lwn.net/Articles/419151/)
      - groby_b 15y ago
        Not a huge fan of the link tag. It's mutated by now into the "this is somewhat related to this page, somehow" tag. (I mean, seriously, rel="sidebar"?) I'd think in terms of semantics, the <embed> tag is more appropriate. If you want to re-use existing tags at all, that is.
twidlit 15y ago
Aren't APIs kinda sorta built for this?
- adelevie 15y ago
  Be more specific. The Intents are a kind of API. If you mean REST APIs, one advantage that comes to mind is that Intents should require less integration on the server. Just write a callback that handles the expected data, and don't worry about integrating plugins.
- extension 15y ago
  The key difference is that intents are generic and resolved by the client based on the user's choice. So, instead of a "Share on Facebook" button, you would just put a "Share" button on your site. When clicked, the browser can fulfill the action using any site it knows about that implements sharing. It somehow asks the user which site to use.
pauldino 15y ago
I have been working on something like this but a bit different for a while; you can see an example at http://cloudactions.herokuapp.com/paint/ http://cloudactions.herokuapp.com/paint/ or http://xdpaint.herokuapp.com http://xdpaint.herokuapp.com - I'd be curious what you think. (If you choose the Flickr open option or Imgur save option you don't need to log in with anything) You can turn the iframes into popup windows if you eval 'cloud.noIframes=true' from a javascript prompt or enter 'javascript:cloud.noIframes=true' in the URL bar. EDIT: There's also an older iteration of this idea at http://xdproject.org/filterizer/ http://xdproject.org/filterizer/
drusenko 15y ago
Have you thought about defining an (optional) Integrator ID that would be dispensed by the central authority? There are a couple use cases here: 1- Some services that are prone to abuse may require the Integrator ID to rate limit or prevent spam. The central authority could rely on a system that makes it difficult to obtain multiple IDs. 2- Some services may wish to provide a revenue share to integrators as an incentive -- we can imagine that Picnik is the service, and it collects revenue from usage through ads and premium upgrades, and opts to share that revenue with integrators.
- nikcub 15y ago
  this goes completely against the spirit of the web and the main reason why it was a success. I hate API keys. you have more then enough information about clients in each layer of the network stack to be able to block or throttle bad behaviour, we do not need to setup gatekeepers or control proxies throughout the web and butcher it
  - drusenko 15y ago
    I respectfully disagree. As someone who deals a lot with spam and abuse issues, there's basically nothing left to identify unique clients on the web. IP addresses definitely don't work and CAPTCHAs don't work either (they're broken by hordes of humans in low-income countries solving them in near-realtime). How would you prevent automated abuse? It's become a very difficult problem.
- gbhn 15y ago
  A really key part of intents is that they're locally resolved. For centrally-resolved links, urls already work really well with the DNS system. Of course, features that prevent abuse will be a key support element for browsers. That's part of the rationale behind the choice of a pop-up window in Paul's demo for instance -- in-page elements have some vulnerabilities that pop-ups don't.
skybrian 15y ago
Nice idea, but surely you can't introduce a new cross-site communications protocol without discussing the security implications?
- kinlan 15y ago
  We will be setting up discussions soon. This is just the shim (and will evolve) for browsers that don't support the final full implementation.
cppsnob 15y ago
What's future is past. http://en.wikipedia.org/wiki/Cyberdog http://en.wikipedia.org/wiki/Cyberdog http://en.wikipedia.org/wiki/OpenDoc http://en.wikipedia.org/wiki/OpenDoc http://en.wikipedia.org/wiki/Object_Linking_and_Embedding http://en.wikipedia.org/wiki/Object_Linking_and_Embedding
- extension 15y ago
  OLE and OpenDoc are for embedding documents within each other. I don't see anything in Web Intents related to embedding. It's simply the web equivalent of file type/action handlers, an everyday feature of most operating systems.
  - groby_b 15y ago
    To be fair, it seems similar in that it allows you to perform an action within your current page, including modifying embedded content. It's different in that I don't see how you can add new content to an existing page.
rkalla 15y ago
I like this idea, my gut tells me there is something in that arena to be solved with some simple like this (maybe even a universal JSONP callback method definition for an endpoint or something for services that you can call out to for things like this?) I wonder if the actual usability of this is what stymies it... for example, say SmugMug exposes their image filtering API that they use to sharpen and enhance uploaded images and Flickr exposes their geocoding API to allow you to pass in GPS coords and they write them into the JPG meta for you... what is the motivation for these services to expose these services to 3rd party (potentially competing) web applications to make use of them? I am assuming you have access to these services because you are already customers of those companies, wouldn't they want to keep you in their garden? If you put this in a pot and boil the water off of it, wouldn't this idea more or less come down to the problem web services are meant to solve and in that way end up with a similar looking ecosystem? Not critical of the intents idea, just trying to think of where this goes once it exists to get a better idea of how it should be designed/pitched/used/thought of. Thoughts?
- kinlan 15y ago
  You expose the service to get users to use your service and for client application developers - it is impossible for you today to build an application that integrates all the services that your users want to use for very specific actions. It is also about getting data into your application; for users today the process of attaching an image/file that is in the cloud to an email is as follows. Edit email, open up file store (say flickr) download file, go back to email,find downloaded file, upload file and attach. With a cloud file picker solution this becomes a whole lot more integrated and as service provider it is in your interest to offer the ability for users to pick your files.
ollysb 15y ago
This feels like an engineers vision of the web. The two benefits of this over apis are: 1) The user gets to choose how to perform a particular activity. 2) Services can be found either automatically or by the user searching for services and saving them for later. Don't the majority of users want this taken care of for them? Imagine going to facebook and having to find a service to perform a friend request. That's just an irritation for a benefit that most people don't want(wow I can send an invite using SMS with this service). It's also notable that there's no styling on the examples. How is the UI going to be integrated, are all of the web intents supposed to follow a standard CSS format? How about the amount of space that service takes up on the page? I suspect apis are popular because they're the best fit for sharing functionality on the web. Users want curated, integrated websites, not a set of mix 'n' match components.
- extension 15y ago
  I'm pretty sure this can be implemented without forcing the user to make any choices they wouldn't have to make anyway. For actions like share and pick, the user will want to choose which service to use. For view and edit, they may not care, so there should be a default choice, either by the user or the originating site.
- dfabulich 15y ago
  I completely agree. There is only one good use case for the Web Intents API: sharing. But sharing should have a simple non-generic HTML tag and JS API just for that. There's no other purpose for this unnecessarily generic API.
  - kinlan 15y ago
    hmmm - whilst sharing is defiantly one of the first and easiest use-cases to envisage, there are a whole host of other API's that will be built on this including registration for authentication (via OpenID - only present the services the user uses), cloud-based file pickers, print, send, bookmark, and in the future a lot of system generated events. The point isn't that this is an unnecessarily generic API - it is not, it is like saying postMessage is a unnecessarily generic API, rather it is firstly a service discovery mechanism and simple communication channel.
extension 15y ago
It seems like there should be an even simpler way to create an intent link than with a form. Something like <a action="http://webintents.org/share" type="text/uri-list" data="http://kittens.com">Share Me!</a> Presumably browsers would also be at leisure to provide access to intents in their native interface, like a share button right on the toolbar. The intent choosing UI is a thorny issue. I dislike forcing the user to respond to install dialogs or limiting them to intents they have previously installed. I think my ideal browser would silently remember all the intents it has seen. When it needs me to choose one, it shows me a list of candidates I have used before (as intents), padded to some pleasant length by candidates most often visited (directly). If not all candidates fit, a "More..." option expands the list to completion. Some sites will want to be certain that intents they invoke can be handled by all users. So, maybe they should be able to suggest some services to be appended to the user's (possibly empty) list. Making the action field a URI could create some interesting politics. I can imagine the action space being fragmented along company lines e.g. http://facebook.com/like http://facebook.com/like vs http://google.com/plusone http://google.com/plusone vs http://twitter.com/tweet http://twitter.com/tweet etc. A flat namespace might encourage more reuse of actions and less creation of new ones. But maybe I'm just being paranoid.
- masklinn 15y ago
  You don't even need to add attributes for the core behavior: <a href="http://webintents.org/share?type=text%2Furi-list&data=http%3A%2F%2Fkittens.com">Share Me!</a> Add a microformat/microdata attribute to provide a browser hint if desired (for native browser supports or browser extension) and you're done: <a intent href="http://webintents.org/share?type=text%2Furi-list&data=http%3A%2F%2Fkittens.com">Share Me!</a>
  - extension 15y ago
    In this case, the intent degrades to a link to the action URI for browsers that don't support intents. What would be at the action URI? An error message or something that tries to fulfill the intent?
    - 15y ago
tomstuart 15y ago
How does this relate/compare to Twitter's Web Intents? http://dev.twitter.com/pages/intents http://dev.twitter.com/pages/intents
- netghost 15y ago
  I think it's an entirely different idea, with the same name.
  - kinlan 15y ago
    The first implementation was also before twitters (see webintents.com)
flytail 15y ago
We have built and OCR service that includes pretty cool image pre-processing feature to ensure high performance OCR. The actual OCR is done using corporate level software from ABBYY. We did this for an android app we are working on but have built the service in such a way that it could be run by another piece of software easily. We will probably offer it out via a simple API but interested to know if we could also offer it via "Web Intents" - would it make sense? How could we do it?
- kinlan 15y ago
  Yes I think you could, the intent "action" is an arbitrary string there would be some sort of ocr/scan intent, then anyone who wanted to integrate with this service would simply startAction with the ocr/scan intent. We were thinking of providing a action verb for print, so it is essentially the opposite of this (well nearly..)
overgard 15y ago
This seems like one of those ideas that comes up every few years and sounds great to programmers, but never results in anything noteworthy, because it's a solution in search of a problem.

200 points by kinlan 15y ago

Interesting idea, but the examples seem very awkward. I was expecting an in-page UI instead of an HTML popup. I was expecting a cookie to save my favoured intent for later use so I didn't have to choose a service provider every time I wanted to shorten a link. I was expecting to be returned to my originating page once I was done with the intented service.

kinlan 15y ago
This is actually something that we can work on over the project, cookies are something I am pushing for, but it would be entirely up to the User Agent. If you check out the cloud picker for example, it does return you to the original page. On the subject of in-page UI, at the moment there are too many risks embedded an in-page UI... IMO, also for a non-built in solution we have to deal with popup blockers so it limits what can be done.... However this should be a core part of the web platform soon so the current shim won't be needed.

radagaisus 15y ago

This is really a great idea.

nikcub 15y ago

it belongs in meta rather than as its own tag

kinlan 15y ago
We tried this pretty early on. I feel like it is bastardisation of the meta tag to add information that is needed by the system to register an intent, we can't add new attributes just for intents. Then if you have to have it span across multiple tags it is a nightmare to manage for developers. If you don't span across multiple tags you have to have a special encoding inside the meta tag to describe the intent, which again is massively frustrating for developers. How would you specify an intent through the meta tag?
- nikcub 15y ago
  it might be a bastardization of meta, but there must be a way to stuff this metadata into the existing structures, possibly even HTTP headers (I remember RSS auto-discovery going through a similar development process.). my initial thought was: <meta property="app:type" content="image/jpg,img/gif" > <meta property="app:handler" content="open" > and use canonical as the href. you can have multiple handler types, which are standard types, and then handers are actions the concern that I have is that with the types this is just file extensions being moved to the web and all the problems that caused in desktop computing. ie. associating applications with file types. but you are saying that there is no default handler, that you get something more akin to an 'open with' which lists the applications that can handle that type can you email me (email in profile) to discuss further, or is there a mailing list? I am interested in this area and have seen a number of 'web app/widget discovery' initiatives over the years but none really took off (edit: code didn't show up)
  - gbhn 15y ago
    I've talked with Paul a bit about this. We've also mocked up using link tags, which carry a bit more metadata. Probably the most promising approach, though, is using other webapp manifest ideas to bundle intent provider installation with that. (a la http://lwn.net/Articles/419151/ http://lwn.net/Articles/419151/)
    - groby_b 15y ago
      Not a huge fan of the link tag. It's mutated by now into the "this is somewhat related to this page, somehow" tag. (I mean, seriously, rel="sidebar"?) I'd think in terms of semantics, the <embed> tag is more appropriate. If you want to re-use existing tags at all, that is.

twidlit 15y ago

Aren't APIs kinda sorta built for this?

adelevie 15y ago
Be more specific. The Intents are a kind of API. If you mean REST APIs, one advantage that comes to mind is that Intents should require less integration on the server. Just write a callback that handles the expected data, and don't worry about integrating plugins.
extension 15y ago
The key difference is that intents are generic and resolved by the client based on the user's choice. So, instead of a "Share on Facebook" button, you would just put a "Share" button on your site. When clicked, the browser can fulfill the action using any site it knows about that implements sharing. It somehow asks the user which site to use.

pauldino 15y ago

I have been working on something like this but a bit different for a while; you can see an example at http://cloudactions.herokuapp.com/paint/ http://cloudactions.herokuapp.com/paint/ or http://xdpaint.herokuapp.com http://xdpaint.herokuapp.com - I'd be curious what you think. (If you choose the Flickr open option or Imgur save option you don't need to log in with anything) You can turn the iframes into popup windows if you eval 'cloud.noIframes=true' from a javascript prompt or enter 'javascript:cloud.noIframes=true' in the URL bar. EDIT: There's also an older iteration of this idea at http://xdproject.org/filterizer/ http://xdproject.org/filterizer/

drusenko 15y ago

Have you thought about defining an (optional) Integrator ID that would be dispensed by the central authority? There are a couple use cases here: 1- Some services that are prone to abuse may require the Integrator ID to rate limit or prevent spam. The central authority could rely on a system that makes it difficult to obtain multiple IDs. 2- Some services may wish to provide a revenue share to integrators as an incentive -- we can imagine that Picnik is the service, and it collects revenue from usage through ads and premium upgrades, and opts to share that revenue with integrators.

nikcub 15y ago
this goes completely against the spirit of the web and the main reason why it was a success. I hate API keys. you have more then enough information about clients in each layer of the network stack to be able to block or throttle bad behaviour, we do not need to setup gatekeepers or control proxies throughout the web and butcher it
- drusenko 15y ago
  I respectfully disagree. As someone who deals a lot with spam and abuse issues, there's basically nothing left to identify unique clients on the web. IP addresses definitely don't work and CAPTCHAs don't work either (they're broken by hordes of humans in low-income countries solving them in near-realtime). How would you prevent automated abuse? It's become a very difficult problem.
gbhn 15y ago
A really key part of intents is that they're locally resolved. For centrally-resolved links, urls already work really well with the DNS system. Of course, features that prevent abuse will be a key support element for browsers. That's part of the rationale behind the choice of a pop-up window in Paul's demo for instance -- in-page elements have some vulnerabilities that pop-ups don't.

skybrian 15y ago

Nice idea, but surely you can't introduce a new cross-site communications protocol without discussing the security implications?

kinlan 15y ago
We will be setting up discussions soon. This is just the shim (and will evolve) for browsers that don't support the final full implementation.

cppsnob 15y ago

What's future is past. http://en.wikipedia.org/wiki/Cyberdog http://en.wikipedia.org/wiki/Cyberdog http://en.wikipedia.org/wiki/OpenDoc http://en.wikipedia.org/wiki/OpenDoc http://en.wikipedia.org/wiki/Object_Linking_and_Embedding http://en.wikipedia.org/wiki/Object_Linking_and_Embedding

extension 15y ago
OLE and OpenDoc are for embedding documents within each other. I don't see anything in Web Intents related to embedding. It's simply the web equivalent of file type/action handlers, an everyday feature of most operating systems.
- groby_b 15y ago
  To be fair, it seems similar in that it allows you to perform an action within your current page, including modifying embedded content. It's different in that I don't see how you can add new content to an existing page.

rkalla 15y ago

I like this idea, my gut tells me there is something in that arena to be solved with some simple like this (maybe even a universal JSONP callback method definition for an endpoint or something for services that you can call out to for things like this?) I wonder if the actual usability of this is what stymies it... for example, say SmugMug exposes their image filtering API that they use to sharpen and enhance uploaded images and Flickr exposes their geocoding API to allow you to pass in GPS coords and they write them into the JPG meta for you... what is the motivation for these services to expose these services to 3rd party (potentially competing) web applications to make use of them? I am assuming you have access to these services because you are already customers of those companies, wouldn't they want to keep you in their garden? If you put this in a pot and boil the water off of it, wouldn't this idea more or less come down to the problem web services are meant to solve and in that way end up with a similar looking ecosystem? Not critical of the intents idea, just trying to think of where this goes once it exists to get a better idea of how it should be designed/pitched/used/thought of. Thoughts?

kinlan 15y ago
You expose the service to get users to use your service and for client application developers - it is impossible for you today to build an application that integrates all the services that your users want to use for very specific actions. It is also about getting data into your application; for users today the process of attaching an image/file that is in the cloud to an email is as follows. Edit email, open up file store (say flickr) download file, go back to email,find downloaded file, upload file and attach. With a cloud file picker solution this becomes a whole lot more integrated and as service provider it is in your interest to offer the ability for users to pick your files.

ollysb 15y ago

This feels like an engineers vision of the web. The two benefits of this over apis are: 1) The user gets to choose how to perform a particular activity. 2) Services can be found either automatically or by the user searching for services and saving them for later. Don't the majority of users want this taken care of for them? Imagine going to facebook and having to find a service to perform a friend request. That's just an irritation for a benefit that most people don't want(wow I can send an invite using SMS with this service). It's also notable that there's no styling on the examples. How is the UI going to be integrated, are all of the web intents supposed to follow a standard CSS format? How about the amount of space that service takes up on the page? I suspect apis are popular because they're the best fit for sharing functionality on the web. Users want curated, integrated websites, not a set of mix 'n' match components.

extension 15y ago
I'm pretty sure this can be implemented without forcing the user to make any choices they wouldn't have to make anyway. For actions like share and pick, the user will want to choose which service to use. For view and edit, they may not care, so there should be a default choice, either by the user or the originating site.
dfabulich 15y ago
I completely agree. There is only one good use case for the Web Intents API: sharing. But sharing should have a simple non-generic HTML tag and JS API just for that. There's no other purpose for this unnecessarily generic API.
- kinlan 15y ago
  hmmm - whilst sharing is defiantly one of the first and easiest use-cases to envisage, there are a whole host of other API's that will be built on this including registration for authentication (via OpenID - only present the services the user uses), cloud-based file pickers, print, send, bookmark, and in the future a lot of system generated events. The point isn't that this is an unnecessarily generic API - it is not, it is like saying postMessage is a unnecessarily generic API, rather it is firstly a service discovery mechanism and simple communication channel.

extension 15y ago

It seems like there should be an even simpler way to create an intent link than with a form. Something like <a action="http://webintents.org/share" type="text/uri-list" data="http://kittens.com">Share Me!</a> Presumably browsers would also be at leisure to provide access to intents in their native interface, like a share button right on the toolbar. The intent choosing UI is a thorny issue. I dislike forcing the user to respond to install dialogs or limiting them to intents they have previously installed. I think my ideal browser would silently remember all the intents it has seen. When it needs me to choose one, it shows me a list of candidates I have used before (as intents), padded to some pleasant length by candidates most often visited (directly). If not all candidates fit, a "More..." option expands the list to completion. Some sites will want to be certain that intents they invoke can be handled by all users. So, maybe they should be able to suggest some services to be appended to the user's (possibly empty) list. Making the action field a URI could create some interesting politics. I can imagine the action space being fragmented along company lines e.g. http://facebook.com/like http://facebook.com/like vs http://google.com/plusone http://google.com/plusone vs http://twitter.com/tweet http://twitter.com/tweet etc. A flat namespace might encourage more reuse of actions and less creation of new ones. But maybe I'm just being paranoid.

masklinn 15y ago
You don't even need to add attributes for the core behavior: <a href="http://webintents.org/share?type=text%2Furi-list&data=http%3A%2F%2Fkittens.com">Share Me!</a> Add a microformat/microdata attribute to provide a browser hint if desired (for native browser supports or browser extension) and you're done: <a intent href="http://webintents.org/share?type=text%2Furi-list&data=http%3A%2F%2Fkittens.com">Share Me!</a>
- extension 15y ago
  In this case, the intent degrades to a link to the action URI for browsers that don't support intents. What would be at the action URI? An error message or something that tries to fulfill the intent?
  - 15y ago

tomstuart 15y ago

How does this relate/compare to Twitter's Web Intents? http://dev.twitter.com/pages/intents http://dev.twitter.com/pages/intents

netghost 15y ago
I think it's an entirely different idea, with the same name.
- kinlan 15y ago
  The first implementation was also before twitters (see webintents.com)

flytail 15y ago

We have built and OCR service that includes pretty cool image pre-processing feature to ensure high performance OCR. The actual OCR is done using corporate level software from ABBYY. We did this for an android app we are working on but have built the service in such a way that it could be run by another piece of software easily. We will probably offer it out via a simple API but interested to know if we could also offer it via "Web Intents" - would it make sense? How could we do it?

kinlan 15y ago
Yes I think you could, the intent "action" is an arbitrary string there would be some sort of ocr/scan intent, then anyone who wanted to integrate with this service would simply startAction with the ocr/scan intent. We were thinking of providing a action verb for print, so it is essentially the opposite of this (well nearly..)

overgard 15y ago

This seems like one of those ideas that comes up every few years and sounds great to programmers, but never results in anything noteworthy, because it's a solution in search of a problem.