

Web Intents - the future of web apps - kinlan
http://paul.kinlan.me/web-intents-a-fresh-look

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

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

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

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

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

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

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

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

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

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

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

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

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

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

------
radagaisus
This is really a great idea.

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

------
nikcub
it belongs in meta rather than as its own tag

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

~~~
groby_b
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
Aren't APIs kinda sorta built for this?

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

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

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

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

