A few months ago, Mike Hanson and I started meeting with James, Paul, Greg, and others on the Google Chrome team. We had a common goal: how might web developers build applications that talk to each other in a way that the user, not the site, decides which application to use? For example, how might a major news site provide a “share” button that connects to the user’s preferred sharing mechanism? Not everyone uses the same top-three social networks, yet users are constantly forced to search for their preferred service within a set of publisher-chosen buttons. That leads to undue centralization and significantly undercuts innovation and user choice. How incredibly inelegant!
We figured that, with a bit more browser smarts, we could do better.
to the design studio!
Mike and I proposed Web Activities, and put together a screencast.
The Google team proposed Web Intents, and put together a far more complete proposal.
Techcrunch covered our collaboration.
While all this was happening, the always amazing Tyler Close, of Web Introducer fame and also from Google, was whispering in our ears “Guys, I think you’re doing it wrong. It’s over-engineered. We can do simpler.” We all ignored him. I think that was a mistake. Tyler was right. Web Activities was over-engineered. And, I fear, Web Intents is too.
the glaring inconsistency
Web applications already have a mechanism for communicating with other web applications loaded within the same browser: postMessage. It isn’t perfect, but it works, and it is flexible enough that much innovation has been built on it. Google, Microsoft, Facebook all use it, oftentimes for embedding widgets within other pages, each in a very different way. At Mozilla, we use postMessage extensively for BrowserID, and we’ve built nice abstractions on top of it, like winchan to consistently build a message channel to a new popup window (including all IE workarounds).
postMessage is a very simple, very Webby, and very generative: it’s easy to build new ideas on top of it. It doesn’t care about mime types, dialogs, callbacks, etc. It’s just a simple, authenticated message channel. The only reason postMessage isn’t enough to do what we need is that the sender and receiver are, for the most part, tightly coupled. The sender has to specify its receiver, which means the user can’t easily step in and substitute the endpoint of her choice. postMessage tightly couples the sender and receiver of the channel. We’d like a loose coupling, where the user gets to mix and match senders and receivers.
So wait, if that’s the only gap, then why are we proposing a completely different approach to cross-application messaging? Why should tight and loose coupling of messaging channels be implemented in completely different ways? Given that the postMessage abstraction has been so successful and useful, the “right” way to move forward is to tweak it, minimally, not to redesign a different stack.
a minimalist way forward
A minimalist way forward is to use postMessage as is, and to provide only the bits necessary to enable loose coupling.
Here, Tyler comes to the rescue again. He proposed, in one of the last chats we had with Google, using custom protocol handlers as the target of postMessage channels. So, when a major news site wants to share an article, rather than postMessage’ing (or linking) to http://twitter.com/, it can use the one-indirection-away URL share://.... The browser can then jump in and substitute the user’s preferred implementation of a sharing provider at that custom protocol handler. Everything else, linking or communicating via postMessage, is then the same.The only difference is, there’s one level of indirection to give the user a chance to step in and say “that service, please.”
another minimalist approach
so now what?
I propose that we stop for a second on the Web Intents discussion and ask ourselves: maybe we’ve been over-engineering this. Maybe we don’t need mime types and new HTML elements and new DOM properties, etc. Maybe there’s a much easier, good-enough solution, based on proven technology, with only minor tweaks to well-understood code paths. It won’t be perfect, we’ll probably need some JS libraries to make things more convenient for developers, but that’s okay. That’s better for the Web. Keep the platform simple, leave the real innovation to the edges.
I believe Web Intents, as currently proposed, are over-engineered. So are Web Activities. But it’s not too late to correct course. Let’s figure out the simplest way to involve the user in choosing an application, set up a message channel, and get out of the way.