Parentheticals & Excursions

This is a repost of a comment I originally made on Paul Kinlan’s blog. Since it appears that moves to adopt Web Intents in Chrome and other browsers are progressing quickly, I felt that I should reiterate my reservations here.

I’m excited about the prospect of an intent mechanism for the Web to parallel that provided by the Android framework. The Intent has demonstrated itself to be an extremely useful abstraction that broadens the range of applications that it is possible to write; it facilitates the creation of smaller applications that, as a consequence, have greater scope for reuse.

Bringing these benefits to the Web is something I’ve given some thought to (on and off) over an extended period of time, so when I read this post I had already formed a conception of how intents might work on the Web, which it turns out has many similarities and some key differences.

Firstly, I think there is some basic semantic confusion in the API as I understand it. Intents in the Android system can be formulated by one application but handled by another on the basis of its registered IntentFilters. In the web intents API, this distinction appears to have been elided; the <intent> element does not encapsulate an intent, but an intent filter, so is misnamed in my opinion. The <intent> element is also less expressive than the equivalent IntentFilter construct in Android which:

1. can match on URLs not just MIME types
2. can restrict matches based on categories
3. can match more than one action

Each of these have important use cases on the Web:

1. allows one web application to hijack an “intended” link to another. Example: an intent to view a Flickr photo by linking to its URL could be delegated to an application that displays Flickr photos in a way that is more to the users liking.
2. allows intents to be sensibly filtered for the user. Example: An intent might require that the UI for an activity be embedded within the current page (ie. in an iframe), an intent filter could use a category (corresponding roughly to the Android CATEGORY_GADGET) to indicate that it supports this.
3. avoids verbosity in intent definitions. Example: No consensus exists for the denotation of some specific action, and there are a large number of equivalent alternatives; a single intent filter could match them all.

Personally, I think it’s questionable to embed tags directly into the HTML to record this information. The cost of repeatedly downloading and parsing these tags (which could be numerous) seems out of proportion with the frequency with which the information would be acted upon by a user. In my opinion, a <link> tag to an XML document containing intent information is more in keeping with established patterns (eg. linking to stylesheets or RSS feeds) and provides for greater efficiency since the linked document can be cached by the browser.

And I think that assigning the responsibility of intent selection to the user-agent is a poor choice too (assuming I’ve understood this correctly - the post refers to intents being recorded by “the system” so it’s not clear). My reasoning is partly based on the history of browser plugins, which has been one of progressive deprecation and irrelevance, and originates (I suspect) in the inertia of users: who wants the near-immediate satisfaction of a web page interrupted by the demand to install a plugin? Web Intents could suffer a similar rejection if users are frequently called on to find/choose matching web applications to perform simple actions.

But I think there is another factor that accelerated the descent of plugins: users have gradually become conditioned to expect uniform behaviour of web applications across any browsers. Installing a plugin into one browser would probably have been tolerated better had users not begun to access the Web from such a multitude of devices. It simply isn’t satisfactory for users to go around configuring each system they use to browse the Web.

When I sign-in to Gmail —from any browser— absolutely everything I have customized about the functioning of that application is remembered and it simply works in the manner I’m accustomed to. Were Gmail to adopt Web Intents it would be jarring (and simply inferior) if, when accessing it from someone else’s browser, I was subjected to their intent handling preferences; I would expect my own. It would be better if the intents I had registered, and my preferences for them had been stored in ‘the cloud’.

This leads on to an important question. Android Intents work as well as they do because a privileged system process acts as a broker between applications. The Intent data transferred between applications is stored and transmitted to solely to the system process, resulting in a robust and secure basis on which complex application interactions can be built. The question is, what should that broker be on the Web? I can only see two main candidates: the browser and the cloud. The conception of web intents appears to lean heavily on the former. I can see limitations in both, but my gut (and it’s nothing more than that) tells me that the cloud (if its feasible) is a better fit.