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

In June 2011 I made the journey to IndieWebcamp in Portland where Web Intents became quite a big topic. For an introduction to Web Intents read my last blog post “Web Intents – Gluing web functionally together”

On the first day Chris Messina led a discussion that started with the architecture and focused in the possibilities of hijacking social buttons and turning them into Web Intents. Ben Ward carried on the discussion in another session.

The Web Intents could possibly fix the unwanted button issue and also allow large publishers and individuals to provide services on an equal footing. It’s this property which was so interesting to the people at IndieWebcamp.

Brainstorm user experience

At the end of IndieWebcamp Tantek Çelik and Erin Jo Richey brainstormed the current social sharing user experience and Web Intents. Erin posted a blog entry which has her thoughts on a possible user interface design. Tantek also posted a thoughtful piece that tries to give a historical context and future path for development through the studying of current use cases. There are some interesting comments on Goggle+ about Tantek’s post. Erin and Tantek have also put forward a talk for SXSWi on the subject.

Declarative mark-up for current social button patterns

Some of the discussion at IndieWebcamp was focused on whether we could use a browser extension to hijack current social buttons and overlay the Web Intents concept. The question asked was could we change a Facebook ‘Like’ button into a share button that used the registered Web Intents instead?

At the hacking session I started to build a prototype browser extension. It was primarily aimed at exploring the use of declarative mark-up as social button design pattern.

You need three elements to make Web Intents work the first is a browser based management interface. In this case I created a Firefox extension, a method to register the intent and a method to subscribe to the intent.

Web Intent registration

Ben Ward codified a hypothetical manifest structure for the Twitter Web Intents. It contains concepts for property name mapping and proprietary requirements. He based it on his experience of the Twitter Web Intents API. I have since added to the structure a little.

The registration of a service or group of services using JavaScript would typically look like this: />

function init(){
    window.intents.register({
        ‘vendor’: ‘Twitter’,
        ‘intents’: [
            {
                'name': "Tweet Link",
                'verb': 'share',
                'type': 'url',
                'required_params': ['url'],
                ‘url’: ‘http://twitter.com/share’},
            {
                ‘name’: "Retweet",
                ‘verb’: ‘share’,
                ‘type’: ‘status’,
                ‘required_params’: ['tweet_id'],
                ‘url’: ‘http://twitter.com/intent/retweet’,
                ‘param_map’: {‘object_id’: ‘tweet_id’}
            }
        ]
    });
}

window.addEventListener(‘load’, init, false);

Subscribing to a Web Intent

I built the subscription around the use of HTML5 ‘data-‘ attributes. This type of attribute can be used to provide all the additional information for a Web Intent. Its use would allow for progressive enhancement of a standard HTML link.

There are two distinct groups of attribute. The first group contains ‘data-verb’, ‘data-type’ and ‘data-url‘ which would be mandatory. Providing all the data needed to define a Web Intent.

Bookmark link

The ‘date-text’ attribute is an example of an optional data type. Supplying additional data would help the services to pre-fill forms that are presented to the user and improve the user experience.

Conceptually this design would use an agreed set of attributes for each verb/content-type combination, with a parameter mapping system so pre-existing URL end points would not have to be changed. We also added a proprietary naming scheme for extensions of optional data e.g. ‘data-v-twitter-via’

The Firefox extension

Although only half finished it is possible to try out some of the prototype functionality. /> You can register a Web Intent

• Allows for basic management through an interface
• Finds the declarative HTML mark-up for subscriptions

To try this out, download the extension. It should install directly into Firefox then view the registration page and select “Allow” in the dialog

/>

There should be a small blue “in” icon in the Add-on bar at the bottom of the browser. Clicking this will bring up the management interface.

/>

Finally, navigating to the subscription page will show you an alert for each of the Web Intent subscriptions it discovers in the HTML. That’s as far as I got (it was only a few hours of hacking !).

Why have I not finished the prototype?

If we map out the approaches taken to implement the current social buttons you find 3 distinct models. They all use a URL endpoint for each service, but vary in how they exchange data.

1. Uses the query string parameters which are pre or dynamically populated
2. Extracts data from the referring URL. The service parses the HTML
3. Exchanges data hidden behind a JavaScript interface

In practice you can see a combination of the above being used in a single implementation. Each model has different strengths and weaknesses. What is important is that all the current common use cases for social buttons are captured and that the Web Intent design has the widest coverage.

The design I envisaged passed data using the URL query string. This follows the design of Twitter’s Web Intents API and a lot of the other social button APIs. The Chrome and Mozilla teams are taking another approach still using a URL endpoint for each service but passing data as JSON objects through the context of the browser. This is arguably much more flexible.

Having read Tom Gibara’s post Reservations about the Web Intents system I do not agree with most of the points, but I can see the possible need to delegate URLs endpoints.

“…allows one web application to hijack an “intended” link to another. Example: an intent to view a Flickr photo by linking to its URL could be delegated to an application that displays Flickr photos in a way that is more to the users liking.”

Twitter has taken the approach of supporting just about every way of defining the data for a social button. They have also prioritised the order in which they discover it. The list below is taken from their button API documentation:

1. Look for url in the share link query string.
2. If not found, look for the data-url attribute of the Tweet Button anchor tag
3. If not found, look for the rel=”canonical” link tag in the head of the document
4. If not found use the URL of the webpage

If you added delegated URL endpoints to Twitter’s data entry this would be an extremely flexible solution. The question is whether this level of flexibility adds too much complexity. Only reviewing the use cases can give this answer.

I would like to spend some time considering this and as the Web Intent API is still in major flux while the Chrome and Mozilla teams align their work, I think this project is best left a while.

IMPORTANT /> The examples/code in this document are different to both Paul Kinlan webintents.org API and Mozilla Labs Web Activities API. In the past couple of months a lot has happened in this area and I now consider this work to be at a tangent to the main body of development taking place.