Choosing the Right Words - Web Intents

I ran a small session at UXCampBrighton last weekend about Web Intents. At the end of the session I was hoping for a discussion about the use of verbs in Web Intents, but the questions where a lot more wide ranging.

As people grasped the concept they rightfully asked some questions of it. I thought it would be useful to document an aggregation of these conservations and my answers.

The slides

Will social media companies let go of branded buttons?

We discussed the value to companies of having buttons that both advertise and endorse a brand through the use of logos and trademarked phrases. I was asked the question; would social media companies provide services through Web Intents if it meant letting go of this visual branding?

The network effect of sharing social media outweighs any value gained from the promotion of visual identity on buttons.

That’s to say Twitter, Facebook etc. have expanded by linking people as they share social media objects (text, images etc.). Traditional visual branding is not as important as engaging users in the experience of using a service, in this case sharing social media objects.

In a small way we can already see this effect in action as the social media/networking sites allow publishers to re-work their visual identities by removing the terminology and phrases they’ve carefully crafted and promoted. In the BBC example below, the designers did not use the buttons provided by the services, instead they have greyed out the logos and removed the terms ‘tweet’ and ‘recommend/like’.


Most large companies have strict visual guidelines for the legal use of their logo’s and trademarks. Take a look at the Twitter and LinkedIn guidelines as an example. I would suggest in this context that these companies don’t care about small infringements of their visual identity as long as people are encouraged to share using their networks.

The caveat here is that the speed of visual recognition and trust engendered by some of these buttons/logos may help increase traffic to these services. Web Intents would need to create the same or greater levels of traffic to these services while using generic iconography and terminology. If it did not, I am sure the social media companies will not be as happy to embrace Web Intents.

Users will never get the concept

At one level Web Intents can be seen not as a new idea but the standardisation of a pre-existing design pattern into the UI of the browser

Earlier this year the StumbleUpon “Stumble” button passed 25 billion clicks. On AddThis network StumbleUpon has 1.69% marketshare (2 Oct 2011) across all the services it offers. This gives you some idea of the level of interaction which can be mapped to the type of design pattern Web Intents is trying to capture. As long as the user experience developed for Web Intents does not add a lot more complexity, it should be widely understood by the current users of services such as StumbleUpon.

Why don’t we just let Facebook/Twitter dominate – do users really want choice?

Yes, the AddThis statistics make stark reading with 67% of market share in the hands of Facebook and Twitter. Even in light of this, there is a long tail of hundreds of other services that fit the design pattern of Web Intents. Maybe it is the inability to provide choice that defines the current usage patterns not the other way around.

The current status quo has publishers coalescing around a handful of the biggest services, because they have no means of knowing which services are the ones an individual user would prefer. If a site could deliver individualised button/links based on a user’s choice, there should be a substantial gain in utility to the user and traffic for the publisher and the service. This change may not inevitability reduce traffic to large service providers, but instead, increase traffic to smaller ones.

You need also to consider that different communities around the world embrace different services and that sharing a web link is only one type of many services.

The level of choice. /> Hick’s Law or Hick–Hyman Law, roughly states that the time it takes to make a decision increases with the number and complexity of choices. As the decision time increases, the user experience suffers.

Satisfaction curve


I am interested in finding out how publishers define the optimum number of services to display to the user. What factors are foremost; is it purely about screen space; the market share of services or is it Hick’s Law playing a part in these design decisions? More importantly, what results would I get if I could test user choice vs decision complexity in this context?

In page UI vs chrome UI

I believe that keeping the complexity of interactions to an absolute minimum will be a deciding factor in the success of Web Intents

A browser is split into two heavily defined surfaces. There is the web content/page and the chrome. Building interactions that span these two areas is not easy. Building any type of browser UI that overlay’s the HTML content brings up some security concerns.

Taking into account all the above, I still think keeping all the UI contextual to the original area of interaction in the web content is very important. Popping windows away from the original click event or navigating between full pages will cause more mental load for the user. There are already working models we should look to such as current proprietary buttons for sharing and the OAuth UI flow. These have been heavily researched and tested in the real world and should form a starting point for any UI design. In the end it will be the browser development teams that frame the main UI flow.

Common iconography and verbs

I think it is obvious to most people that a common iconography and language is needed for Web Intents. The calls to action need to be both understandable and recognisable as their proprietary counterparts i.e. Twitter ‘tweet’ and Facebook ‘like’

It is unlikely that all the elements of language/ iconography will be fully developed in the API specification process being undertaken by the Chrome and Mozilla teams as they will be surfaced in the HTML of the publishers of sites.

I would like to see a two phased approach. Engage the UX community in an open process to quickly define the visual language for calls to action i.e. the buttons. Then create a simple wizard on to generate the code for people to use. Guidelines and wizards for site publishers are fundamental to generating up-take.

In conclusion

Although I was asked many questions the overall response to Web Intents was positive. I was even approached by some UX designers about getting together a workshop/design meet-up to look at the whole UX flow.

The answers above are written from a personal view point. If you’re new to the topic, I would recommend reading the discussion forum to gain a broader insight.

  • Data Portability
  • User Experience Design
  • webintents

This is an awesome summary, lets plan the next event together so I can attend (damn travel). /> How about set something up in Google London? I might be able to get the dev’s in on a hang-out.

Here are my thoughts.

Q: Will social media companies let go of branded buttons?

Honestly, I don’t expect them to. But that is not a problem, I expect they will become a sink for the intent by providing an tag in their page and parsing it. And that is enough to get the process started.

Q: Users will never get the concept

If implemented correctly users will never see “intents” or “activities”, they will just see a “share”, or an “edit” or “pick” button and a list of their services that they can use.

Q: Why don’t we just let Facebook/Twitter dominate – do users really want choice?

It is more than user choice, it is about the developer not having to explicitly support new networks, or removing old dead networks from their code.

It is more than just “share”, which undoubtedly is the biggest first use-case.

Q: In page UI vs chrome UI

You are correct, it is up to the UA to decide, however I am pretty confident and I know in Chrome’s case (you can check the commits) that it will be outside of the Page UI and away from the context of the click. We need to make sure that all of this is un-spoofable; the second that it is only in-page then it becomes open for attack via spoofed code.

Q: Common iconography and verbs

I believe this is important, but can be managed outside the spec. I would like to contain the de facto set of common verbs and have activity-streams to maintain their set (and objects), but also let the wide community define their own verbs.

We have a basic mapping to “widgets” ( that help define the common look and feel, but I am very very open to this being contributed to via 3rd parties as it is outside my skill-set… In fact is waiting for pull requests />

Really like the idea of a wizard and is part of what I intended to be.