Web Intents - the future of web apps | Hacker News Reader

Web Intents - the future of web apps

paul.kinlan.me

200 pointskinlan39 comments

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 vs http://google.com/plusone vs 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.

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>

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?

> In this case, the intent degrades to a link to the action URI for browsers that don't support intents.

Or when no support library is added on the client to provide some kind of in-page UI enhancement. Yes, that's the whole point: building on existing and well-functioning technologies to avoid that things break down completely and that a segment of the population is entirely left out for no good reason.

> What would be at the action URI? An error message or something that tries to fulfill the intent?

Second case, some sort of intents picker if multiple web services can fulfill it, or a redirection to the intent handler if there is only one. An error message if there is no registered service able to handle the intent.

And it keeps the distribution of intents registrar from your proposal, which I think is a good idea.

We are thinking about how an anchor may look in this context, the problem at the moment is that only really allows very flat data structures to be sent. What if you want to share an activity-stream object.... saying that, I do like the proposed syntax.

Intent choosing will be left in most likelhood up to the UA to define, they could favourite items. The main reasons for the intent tag is 1) it is a new platform feature and shouldn't be hacked in; a tag gives us the benefit of future enhancements, and 2) we and others could index this data and provide it as an option for the user to pick applications to use.

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.

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.

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.

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.

Try thinking of it in terms of Android intents/activities. The vast majority of the time, it's handled automatically for you (where "it" is whatever you were trying to do), but when you want the option to choose, it's there.

In some cases (e.g., sharing) it's clear that there's never a single good option -- the choice should probably always exist. There are plenty of others (e.g., image editing) where a site might want to have a specific default, but allow for choice where appropriate.

The alternative, I'm afraid, is what we have now -- you only get the options (usually just one) that an app's developer happened to find time to integrate by hand, usually poorly.

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.

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.

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

I think it's an entirely different idea, with the same name.

The first implementation was also before twitters (see webintents.com)

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

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.

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?

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.

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/ or 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/

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.

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

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.

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.

This is really a great idea.

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?

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

it belongs in meta rather than as its own tag

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?

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)

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/)

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.

Aren't APIs kinda sorta built for this?

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.

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.

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.

What's future is past.

http://en.wikipedia.org/wiki/Cyberdog http://en.wikipedia.org/wiki/OpenDoc http://en.wikipedia.org/wiki/Object_Linking_and_Embedding

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.

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.

Reply on news.ycombinator.com