Web Intents - Gluing web functionality together
There is a new concept forming at the moment called Web Intents. The name is a reference to the Android feature which allows applications to register their “intent” to handle certain types of actions.
The screenshot above shows all the options for sharing an image on my Android phone. The underlying application does not have the ability to share images itself, so it asks the OS to list the applications that can. The user is then presented with the choices above and the two applications exchange the data required for the feature to work.
Intents work in a similar way to how applications on a desktop register their ability to open and modify a particular file type. An Intent takes things one stage further registering not just a content type, but also a verb to describe an action i.e.
- Post a Status
- Edit an Image
- Share a Bookmark
- Reply to Post
- etc
We already have perfect examples of this pattern in use today in the shape of the many social media buttons which are proliferating across the web. At the moment they are not built using the concept of Intents, but they could be.
/>
Tweet
Web Intents could provide a whole new generation of interactions on the web which would complement how it already works. They could give more user choice and de-clutter the web of the visual and mental load created by all these buttons. If widely implemented it would allow large publishers and individuals to provide services on an equal footing.
Two driving forces for the adoption of Web Intents
Social buttons /> We already have multiple use cases for Web Intents in the shape of the many social media buttons. At the moment these buttons are a jumble of proprietary iframe code, which seems set to reinforce the NASCAR problem.
Currently, Twitter’s Web Intents is the most progressive implementation of social buttons. Twitter’s Web Intents API is not the same as the Web Intents API being developed by the Chrome and Mozilla teams, but it is an interesting architecture in its own right. I admire how they used a simple HTTP Get request to form a powerful API and then deployed JavaScript to hijack HTML links to create the buttons.
Web app/service discovery /> The second driving force comes from the search to create a simple discovery mechanism for web app/services. Michael Hanson of Mozilla Labs wrote a post at the beginning of this year about the growing need for a new way to glue web functionally together. The theoretical work around web app/service discovery and social buttons have the same architectural patterns. Mozilla have called their approach “Web Activities” and you can see a demo in a video they posted in July.
Building it into the browsers
Paul Kinlan from Google conceived the idea of Web Intents. He has started documenting their development at http://webintents.org/. Most importantly the Mozilla Lab and Chrome teams have started to work together on a common API to implement Web Intents into their browsers.
User interface and experience ideas
Having a design background I tend to think visually and built an early mental picture of what the user interface for Web Intents could look like. I visualised this before Paul Kinlan published the http://examples.webintents.org/ site and Mozilla Labs posted their video. In doing so I made some assumptions which I thought would be interesting to share; especially as they vary from Paul’s initial demo. It is also worth taking a look at Erin Jo Richey mock ups which provide a slightly different perspective to the user interface design.
Registration of Web Intents /> As a user I would like to be prompted about the registration of a service, if nothing else to make sure I only register with services from sites I trust. The closest model for prompting the user to allow data/service access is the Geo API. It would not take much to reuse the pattern to provide a Web Intents acceptance prompt.
The question of registering multiple services at once would need to be considered. I personally think site authors should be encouraged to create URLs where multiple Web Intents could be registered at once.
Managing Web Intents
Over time our preference for which services we use on the web will change, so browsers will need to provide an interface for us to manage this. In the wireframe above I used a 2-tier-tree navigation. The first tier represents the action verbs like” share” and the other tier content types such as “link”. Technical names such as “mime-types” should not be used and exchanged for more friendly language.
I would also expect some fine grained controls such as the ability to enable and disable services and to change their order of display. With all of these controls we end up with a user interface not too dissimilar to those used to manage our browser plug-in/extensions.
Using a Web Intent
Where a page subscribes to a Web Intent such as sharing a link, I believe the most functional interface would be button with a drop-down menu. This would allow the user to quickly choose from a set of options. Any service which requires further input from the user, like the assignment of tags, would be done through secondary windows.
At first sight the drop-down looks like we are recreating the NASCAR problem. What has to be remembered is that these options were chosen and curated by the user. It follows that they will be limited in number and always be meaningful options for that individual.
Silent registration – the most complex UX problem /> The interface could either silently register the Intents or prompt the user. The designers of Andriod’s OS took the decision to silently register so my wish for more control may not be what the majority of users want.
The Web Intents architecture
The user interface for Web Intents really needs to be built into the browser, but for the time being Paul Kinlan has built a temporary JavaScript library which allows us to experience Web Intents. The code examples below are based on using that library. There are three parts to the architecture.
/> />
Registering a web intent (Site A) />
Registering a new service is simple. Once you have included the webintents.js from the JavaScript library, you add an Intent tag into the header of a page. />
[sourcecode language="html"] />
/>
/> /> Subscribing to a web intent (Site B) /> Again you need to include the webintents.js file from the JavaScript library and also build an Intent object. This object describes the type of Intent and also passes the data. /> [sourcecode language="javascript"] />
var intent = new Intent(); /> intent.action = "http://webintents.org/share"; /> intent.type = "text/uri-list"; /> intent.data = [ url ];
window.navigator.startActivity(intent); /> [/sourcecode]
/> /> Collecting the data at the end point URL (Site A) /> At the service endpoint you need a small piece of JavaScript to collect the data. The magic bit is how Web Intents passes the data between the windows as they are opened. The sites at both ends of this interaction do not need to know anything about each other. The browser or in this case the JavaScript library negotiates this for the two parties. /> [sourcecode language="javascript"] />
/> [/sourcecode]
The API is still in flux as the Chrome and Mozilla teams align their work. The code examples above will change as this happens. You should visit the webintents.org site for the most up-to-date reference. If you wish to keep informed of how the development of the API is going I would suggest registering to the Google Group.
The Future
I think the future is bright for Web Intents, as it seems to have support from the Chrome and Mozilla teams. There are a number of technical issues outstanding, but none that should derail the project.
The role of brand equity /> I have not heard many people talk about the role of brand equity in the rise of social buttons. I have no idea how much it would cost to put my company’s logo on all the sites that host the Tweet or Follow button – it would be a lot.
Even considering social buttons as a form of advertising underplays their true value. In fact they are more like an endorsement from one brand to another. The Guardian newspaper carrying the tweet button on all its articles is the equivalent to it saying, “we believe that Twitter is the premium sharing service”. One has to ask how interested some service providers will be in a feature which hides this type of brand promotion, even if it is in the best interests of their users.
Although I am wary of the commercial issues and the user experience has yet to be proven in the real world, Web Intents has compelling properties. I think it is well worth promoting.
Useful Links
Reference Sites /> http://webintents.org/ /> http://examples.webintents.org/ /> http://usecases.webintents.org/ /> https://groups.google.com/group/web-intents
Blog Post /> Paul Kinlans – Web Intents a fresh look /> Tantek Çelik – Web Actions a new building block (Google+ comments) /> Erin Jo Richey – Button Sluts and Web Actions /> Tom Gibara – Reservations about the Web Intents system
Chrome – Connecting Web Apps with Web Intents /> Mozilla Labs – Web Apps Update – experiments in Web Activities, App Discovery
IndieWebCamp /> Chris Messina – Session: Standardizing Web Intents /> Ben Ward – Sessions: How the Indie Web Hooks into Hosted Communities
Reference Technologies /> Android Intents /> Web Introducer /> Activitystreams /> Twitter Web Intents API />OpenService Accelerators
Great summary, this is exciting stuff and thanks for helping to push it forward.
Re your AddThis mention… Web operators do look to folks like us increasingly for better insight into the effectiveness of these tools, via analytics and other services, and help optimizing these kinds of experiences by offering appropriate and effective choices for users. While not all sites use them in this way, our own tools for example can automatically personalize options for individual users, present the tools that make sense for them, and give the operator metrics on all aspects of that (and a lot more to boot). And they can do all of this via APIs, on top of which they can build whatever UI they might want, including those that only include 3rd party buttons. Even in the simplest case of the ubiquitous “drop-down menus”, the options that are presented to users are based on extensive data analysis (see a glimpse). So there’s more going on here than may meet the eye initially.
On top of that, though, I’m psyched about efforts like WebIntents and frankly have been wanting these things to go forward even more quickly for some time now (we’ve been advocates for as long as anyone). The open stack should clearly encompass the types of core sharing operations we’ve been observing for some time — and our advocacy on things like OExchange, XRD/-based service-discovery on hosts for sharing, and the like, I think shows the support. While the UX angle is the most obvious, there are other implications for operators that should be part of the conversation as well, and that’s where we’re excited to help all of this push forward.
In any event, keep up the great advocacy, see you on the lists!