Web Intents: the future of web apps

This article first appeared in issue 229 of .net magazine – the world's best-selling magazine for web designers and developers.

Like. Read Later. +1. Tweet. Tumblr. StumbleUpon. For the last few years, little chiclet buttons have been spreading like measles across the web, appearing and vanishing as new tools and services rise and fall in popularity. The popular ShareThis button, which offers site owners the chance to at least corral all these social services into one pop-up box, currently offers over 120 potential destinations – and while nobody ever actually lists them all outright, it’s often hard to tell exactly who all the options are helping.

It’s a problem in need of fixing, and one that both Google and Mozilla have solutions in the works to handle – Web Intents and Web Actions/Activities respectively. Their executions vary, but the basic goal is the same: to move away from the site/app creator having to link to specific services to get things done, in favour of simply enabling them to provide verbs that the browser can handle on a user-by-user basis.

What would this mean in practice? Well, for example: at the moment, there are many different bookmarking tools, with two of the most popular being Delicious and Pinboard. To integrate a bookmark button on the end of an article, the site owner has to add two different chunks of code. In a Web Intents/Actions world this would simply become one ‘Bookmark This’ button. When the user clicks it, their browser sees the verb, consults its list of registered services, and hands over the data.

That’s only the simplest possible scenario, though. What stops Web Intents/Actions being a glorified ‘mailto: link’ is that they’re capable of far more, including two-way interaction that make them suitable for full web applications as well as simply chiclet replacements. Current Web Intents specifications handle the verbs Discover, Share, Edit, View, Pick, Subscribe and Save. With very little coding, for example, you can both send an image to an editor and receive the touched-up version back, just as easily as pulling information like contact details out of an external address book and into a specific form – all without a single custom API call or even knowing what the second party actually is.

There is, of course, more subtlety to it than this. Just as Mac and Windows deal with image files based on their type rather than simply files and images, so too can apps specify formats and datatypes. A web based image editor, for example, can get involved when dealing with a JPEG, while politely staying out of the way of PNGs or MP3. In the event of multiple registered clients and services being able to handle a request, the browser simply displays a menu for the user to choose which one they want to use. Assuming proper implementation, the same scrap of code will work for all of them.

Differing visions

The catch is that while Google and Mozilla share roughly the same vision, their implementations and ultimate goals are slightly different.

“Although browser feature development is now done out in the open under the umbrella of standards bodies it still feels like a meeting between different Masonic orders,” explains Glenn Jones, one of the organisers of the Web Intents Design Push event in February. “So as long as I have not misunderstood the handshakes, any differences here are about the scope of what everyone is trying to achieve.

“The Chrome team is focused heavily on web applications and are interested in the feature working offline, for example. Mozilla is more interested in the wider use case of social media, and want to keep the solution a little more simplistic.”

‘Simplistic’, unsurprisingly, isn’t quite the word used by Tantek elik, web standards lead at Mozilla. “We think that Mozilla’s Web Activities is a more focused approach [than Web Intents] that relies on the open web apps system for discovery,” he explains. “The goal of basing discovery on web apps is an assumption that requiring user-installed apps is a user-centric mechanism which is more secure, privacy enhancing and understandable.”

One specific technological complaint from the Mozilla side is that Web Intents rely heavily on JavaScript, with a shim currently available for anyone who wants to experiment with them. “This is a non-starter for many websites and applications, as they need to function on devices with limited capabilities, or when users turn off JavaScript, or otherwise are unable to access external scripts,” continues elik. “We know from Twitter’s example and best practices of using simple hyperlink tags that it is possible to make web actions work without JavaScript, therefore web actions should also work without JavaScript.”

What both sides agree on is that the user interface side of the technology still needs work. What happens, for example, when the user clicks on a verb for which they haven’t registered a service, or if the service fails? How quickly will sites who currently use Facebook Like buttons to drive traffic choose to adapt to a world where “Share” could bounce traffic around anything from Google Plus to MySpace? More to the point, how will those services take this hit to their information maps?

“In the last few months it’s the loss of hidden value that Facebook/Twitter/Google and so on can exact by tracking people’s browser history across the web with all this injected JavaScript that worries me,” says Jones. “This data has great monetary value to the companies involved and not having JavaScript in pages that quietly tracks users’ browser history could discourage them from providing interfaces. This is a big reason for users to like Web Intents/Actions, but it could slow down uptake by the likes of Facebook.”

Working together

These and more issues still need to be resolved before either Web Intents or Web Activities can become widespread enough to be a standard building block.

“I don’t believe it’s in anyone’s interest to develop different standards within this space,” says Jones, “Hopefully the question about one winning out against another is moot. I take heart in the fact that Ian Hickson (a member of the Google Standards Development team, and the author/maintainer of the Acid browser compatibility tests) is now considering merging the registerProtocolHandler(), registerContentHandler() functions with Web Intents.”

To compare the two technologies, the best starting point is the Google site, which offers plenty of live demos, a JavaScript shim to experiment with, and plenty of Q&As that explain both why this kind of technology is important and why it requires new technology. The Mozilla version is more developer-focused and assumes more background knowledge, but you’ll find the main hub here.