Dan Eastwell, Web Interface Designer and Developer

How are web intents implemented currently?

Web intents (the intent element) as they stand seem to be an analogue for a meta tag - they describe a single object this page represents and describe an action for it. In that case a meta tag could be better used. 

However, the type attribute seems to imply that ‘all images’ or ‘all jpegs’ can be shared (or have any other intent action applied to them). The immediate requirement that might follow from this is ‘I want users to only share main content image, not thumbs or ads’. How might this be achieved?

Most publishers will have several objects on a page (not least the page itself) that they will have at least one user intention, e.g. share, subscribe. In this case an element similar to the <a> element would be better used (or even an extension of the <a> element). 

In fact in several examples, including the this one I constructed, a simple <a> link to a service would do the trick, e.g. a link to the twitter intents service; a link to the reddit submit service.

Twitter asks (but does not require) you to include a script in order to create the intermediate pages from clicking share to the tweet being posted. This script is analogous to the shim that web intents requires currently until browsers support web intents natively to a (not yet defined) standard. In addition, the web intents twitter demo includes a bridge to the service.

If intents are supported as a web technology, no bridge page would be required - I would imagine there would be a standard service API (which still needs defining). There would also be no need for a javascript shim for web intents, as this functionality would be within the browser - using the terms on the web intents site, users would only need to register their intents, the browser would provide the invocation (in the same way you don’t need to ‘invoke’ an <a> link.

What service will the user use?

In the example users will be prompted to use the service stated in the intent’s href attribute, but will be given a choice to use other registered services (users may expect facebook?) in order to share the content.

The question is ‘what services’? Where will these be defined? Can the web publisher pass a list of defaults? There’s no current way of doing this, but a list at the site root might be a way of defining what services this website would prefer their users choosing for web intents actions.

For ‘share’ you’re passing along a url to be shared but unlike twitter, facebook has no intents services. Facebook has a script to embed (as per twitter), and HTML to embed a button. This code could be placed on a bridge page as for the twitter demo on the web intents site.. the same would apply to, say, a digg button.

So until services handle web intents as per a defined spec, bridges (in addition to a user agent shim) will be required. This seems no real big deal, though.

What action does the user want to perform?

This is a very key question. In my simple example, the <intent> element has no styling and is wrapped around the thing to be shared. I’ve provided a title, and if this is the browser’s handling of that attribute, it appears on hover - ‘Share this image on twitter’. I think that more accurately it should say ‘Share this image (default twitter)’. 

All well and good. What though if I want to allow users to perform additional actions, such as ‘like/endorse’? How can I indicate this to users? In fact - how can I specify this in the code?

What if I wanted to promote that users could share on more than one site? That their friends already had? 

This type of functionality might lie outside of the scope of finding a simple method of passing data from a page to a user’s chosen service, in the same way that a fly-out menu is beyond the scope of a list of links.

What problem are web intents trying to solve?

• Joining up a fragmented web identity - we have accounts on many services and have those we prefer - it makes sense to allow us to perform the same actions on other sites with our preferred service.
• Define objects on a page (or rather, show that “this page represents an object”) - there are existing technologies for this (open graph protocol, oembed) that could be utilised to define the page or key object on the page. The intent could use this to construct data to pass to the service. These protocols suffer from the assumption that each page contains only one definable item.

What issues will web intents face?

• Keychain identity across devices - web intents could provide a way of managing your identity on your browser. It goes without saying that you’d want to be able to manage your preferred services across devices and browsers.
• There are already several methods to do the same action (share, subscribe to feed, follow this user). Normally some code to embed a button, and script to apply an event handler then provide authentication and any additional steps (e.g. modify your tweet). These additional steps will need to be considered - without the embedded script from the service.
• Hiding services - this seemed to be the original justification for web intents - to hide a myriad of share badges on websites. Having one ‘share’ button and allowing users to choose their preferred service. However, hiding buttons that would otherwise have counts, friend images, could well cause many users to not click.
• Number of clicks (one for like, at least two with web intents) - for actions such as ‘like’ or ‘vote’, if you are logged into a service, you click once, the page state is updated with no further input from the user.

It’s web interface feels very clunky - blocky keylines against round-edged buttons, ‘developer designed’ dropdowns, icons that aren’t iconic and appear to come from more than one icon set…

The colour scheme is odd, too, with light and saturated blues along with evernote greens, other greens of different hues - the consistency is odd, too, the Chrome extension has a link in green, underlined, the web interface has links in that saturated blue, but not underlined. 

It feels like a piece of software that has gone through ‘Agile’ iterations, but with no overall design control, especially when compared with tumblr’s web dashboard interface, which has no unecessary cognitive load, and has recently updated the main page icons.