Indiewebcamp and Web Intents

13 years ago

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.

Uses the query string parameters which are pre or dynamically populated
Extracts data from the referring URL. The service parses the HTML
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:

Look for url in the share link query string.
If not found, look for the data-url attribute of the Tweet Button anchor tag
If not found, look for the rel=”canonical” link tag in the head of the document
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.