There’s a brand new way of making web apps interoperable … or there will be, if everyone can agree how it needs to be done. Richard Cobbett reports
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.
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.”
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?
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.”