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 /> etc. /> /> /> On web sites we are often presented with a collection of buttons for services we do not use and more importantly not presented with the ones we do. Erin Jo Richey called these types of sites “button sluts”. There are some unsatisfactory user interface fixes for this issue such as “AddThis” which extend the user’s choice by extending a broken pattern. I don’t think these really solve the underlying problem.

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"] /> /> action="http://webintents.org/share" /> type="text/uri-list" /> href=" http://examples.webintents.org/intents/share/sharelink.html" /> title="Kinlan’s Link Share" /> /> [/sourcecode]

/> /> 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