Let the User Decide What To Do

Once upon a time, most users would run one local application for each MIME type. Better still, for each platform, most users used either the same or functionally very similar applications: users would download 'an mp3 player', but every player did more or less the same thing (from the data's point of view, at least).

This isn't true anymore. In fact, the whole point of the idea behind Web 2.0 is that this ought not be true anymore: today's web wants less 'user interaction' and more 'user integration' -- which means not just tossing users data in a format they can handle, but giving users tremendous freedom to choose totally different things to do with that data. In other words: data and what users did with it were always related as many-to-many; but now both many's are being pulled more and more into the apps.

For example, I don't just play mp3s; I play, share, decode, encode, playlist, remix them, and probably a dozen other actions that don't even have names yet.

So if an app is sending data to a user, how does the app know what the user wants to do with it? (Notice that, as in the case of mp3s, this doesn't just mean 'what the user wants to do with the output'; it means 'what kind of output the user actually wants'.)

In natural-language conversations involving any kind of exchange, context will help show what the recipient wants to do with the item exchanged. Since rather deep context is generally available to both interlocutors, the giver can often transfer the item in a way that already addesses the recipient's desired use.

In exchanges over the web, deep context is often completely absent (without far more extensive user profiling than currently exists). Lacking context, the server can either try to guess what the user wants, or assume that the user is following a specified protocol exactly.

But while clients do follow protocols, people don't, and so the server needs to guess. Or force the user into a new protocol, like a plugin does, or at least specify an old one, like registerProtocolHandler and registerContentHandler do, or launch a datastream and hope the user is tech-savvy enough to figure out what to do with .zzf files.

But users do know what to do with .zzf files, much better than the webpage can, especially as new apps emerge that provide geometrically multiplying use-cases the web developer can't possibly keep up with.

The proposed Web Intents API is designed to take advantage of the user's superior knowledge. From the proposal website:

It is impossible for developers to anticipate every new service and to integrate with every existing external service that their users prefer, and thus they must choose to integrate with a few select APIs at great expense to the developer.

Web Intents solves this. Web Intents is a framework for client-side service discovery and inter-application communication. Services register their intention to be able to handle an action on the user's behalf. Applications request to start an Action of a certain verb (share, edit, view, pick etc.) and the system will find the appropriate Services for the user to use based on the user's preference.

The idea sounds deeply interesting.

The goal is of course desirable. The question is, do we really need another API for this?

The proposal site's FAQ says yes, in some concrete detail. That FAQ only partly responds to some of the objections raised on the W3C list. Rich Tibbett loves the idea of a Web Intents API, but also responds to the list objections. All three discussions are worth reading.

I don't know quite what to think on the implementation side, but the concept of Web Intents sounds brilliant to me. What do you think?