A web action is the interface and user experience of taking a specific discrete action, across the web, from one site to another site or application.
The concept of "web actions" was introduced to both capture the emergence of this new type of web interaction (e.g. the spread of "Blog this, Digg, Read later, Follow, Like, Share, Tweet, +1" buttons across pages), and as a user-centric reframing of the previous developer-centric notion of "web intents".
At IndieWebCamp 2011, both discussions and a UX effort demonstrated that the term "web intents" was too confusing and too abstract to effectively do user centered research and design in the area. The term "web action" is based on the fact that from the user's perspective, they think they are taking an action when they click these buttons. When the term was tried out with others creating designs/UX in the space, it seemed to work much better to convey understanding.
Most recently, web actions were presented and discussed at OSBridge 2012:
There are two use cases that are worthy of exploring for webactions:
1. Provide the familiar buttons UI of Twitter, so that notes on your own site feel "at least as useful" as syndicated tweet copies. This is for the scenario where a reader of your tweets clicks a permalink on the tweet copy, navigates back to the original on your own site (perhaps to read more or view better embedded images / video), the reader can still favorite/reply/retweet/tweet etc. your note (all verbs/buttons which will act on the tweet copy of that note).
There's been some demand for this in response to POSSEing out to Twitter:
2. Provide a UI for indieweb users to comment / link-blog your notes/articles on their own site
By designing, developing for these two particular use cases, it may provide us a with a constrained enough design-space that we can come up with simple uses/guidelines for webactions that produce a good user experience on indieweb posts.
3. Additionally, some news articles include "Tweet this" links inside an article, inline with the content, or quotes. Such "Tweet this" links appear to be contextually handcrafted, including an elided version of the text they're adjacent to, along with a permalink to the article, and a "via @-name" where @-name is the article author or publisher's Twitter account. E.g.:
The 2012-06-28 OSBridge "Web Actions" presentation proposed the
<action do="post" with="permalink"> <a href=twitter>..</a> <a href=pinterest>...</a> ... </action>
action do verbs
See also: webactions-verbs-brainstorming
There are many possible web actions to place on / above / in a post. Here are some suggestions.
In general, successful interfaces have very few web actions on a piece of content, e.g.:
A note is most similar to a Twitter tweet, thus the following actions are recommended as buttons to be placed in the footer of a note, after info about the note such as date published, location:
If you POSSE to Twitter, providing familiar verbs (even wording and icons) provides a more comfortable and lower cognitive load actions interface to your readers.
An article is worthy of posting as a headline (article name) and permalink to anyone doing indie-bookmark posts, and as a short post on any number of services, and thus at a minimum it makes sense to include
how many actions
To minimize the cognitive load of an interface, minimize the options for the user to consider. E.g.
Thus consider having at most 4 actions on a post. Perhaps only 3 at most since the (...) button is not a web action (but rather a method of hiding the far more uncommon actions).
By analyzing silo designs we see some patterns for what order actions are displayed. These patterns of convergence are slowly educating users and making them familiar with a certain order. There are likely reasons behind such convergence as well such as
It's also typically placed away from the other buttons, often right-aligned with the content that it applies to (and thus out of the way).
You should add provider-specific / silo-specific buttons only for the silos that your site POSSEs to.
A lot of the design/UX we do on the indieweb is driven by doing the right thing for our friends to read and use our content.
For example: one of your friends who reads your posts from a silo happens to click through on the permashortlink to your post, then reads the full post on your site, then wants to reply/favorite/like/repost, and should be able to click those buttons right there on your site, rather than clicking back to go to the silo, and looking for and clicking a button there. (e.g. this real-world complaint from @zeldman re: having to click back to Twitter to reply.)
Such buttons also help your site and your permalinks become a better (more complete) replacement for the silo-UIs your friends are used to interacting with.
We should encourage our friends to interact more with our own sites than with silos.
Provide hardcoded markup for silo-specific web actions only when the HTTP referer [sic] shows that the user came from that silo.
No need to direct any traffic to silos that didn't come from them.
No need to pollute your user interface (a la NASCAR problem) with silo buttons unless your user came from that silo and would appreciate even expect those silo buttons.
The whole point to start with is to support (provide a better user experience for) readers who are coming from the silos you've POSSE'd to. Make them feel at home (even more comfortable) on your own site, than they do on the silo they came from.
E.g. on the serverside, always provide a rel-syndication ("View on ..silo-name..") link to POSSE copies of posts, because they are useful for original-post-discovery and POSSE threading (e.g. threading POSSE tweets) and other syndication-link-use-cases.
Then in JS on the clientside, replace the ("View on ..silo-name..") link with web action buttons (using
Perhaps consider keeping (instead of replacing) the ("View on ..silo-name..") visible link (in addition to the web actions) if you think the silo POSSE copy of your post provides sufficient additional value to offset the cost of UI clutter and directing your readers to a silo.
More advantages of dynamically adding silo buttons in clientside JS:
To be clear, this is not advocating for adding any more silo-specific buttons than you already have for whatever reasons you decided. Help figure out what are minimum sensible sets of silo-buttons for each silo and contribute to the above lists.
It's expected that indieweb sites will likely all end up with slightly different sets of action tags and silo buttons inside, based on:
We need a registry of common verbs to use with web actions. This should be built based on research into real world usage and brainstorming on top of that:
Action tag examples in the wild
Examples of real world web sites using the
Barnaby Walters notes, e.g.
Laurent (all posts?), e.g.
Indienews comments pages, e.g.
Some of Barry Frost's post have webactions as of 2013-10-01, e.g.:
Glenn Jones notes, e.g.
Web Action Browser Support
If you install a browser (or browser extension) that implements the action tag, you can click on action buttons on other sites (e.g. like those listed in the examples in the wild above), and then have the actions direct to your own site.
Web Action Hero Toolbelt
Website Action URL Support
Main article: Web Action URL APIs
IndieWeb Support in particular:
Drop Social Buttons
The always insightful @IA wrote up a post explaining why we should consider dropping social buttons (perhaps currently the largest / most popular set of web actions)
The social buttons used by a variety of silos often come with tracking cookies, meaning that the social networking services are alerted to the fact that logged-in readers have been reading content even if they do not actually take any actions (sharing, retweeting, +1ing/faveing). Depending on the nature of the content on your site, this may be a breach of your ethical standards and the reasonable standards of privacy. For instance, visits to sexuality, health and political sites may then lead tracking cookie organisations to draw unwanted or undesirable inferences that breach a users privacy.
In 2010, the British developer Mischa Tuffield noted that Facebook and Google tracking cookies were used on the NHS Choices website, which is used by people to look up health conditions. See here.
Wikipedia has rejected the introduction of social share buttons partly on the grounds of privacy (Wikipedia:Perennial proposals).
Drop Delegated Logins
While delegated logins aren't necessarily seen as a web action, they are at least superficially similar, in that they typically consist of a button with a particular social site brand. MailChimp decided to drop theirs, read why:
Real-World Candidates for Web Actions
Add links to/screenshots of existing website UIs which a web actions UI could replace
See Also: Web_Action_URL_APIs
Web action delegate URLs are URLs which present a configurable UI for performing an action, which can be customized via query parameters in the URL. They're kind of like a callback URL but presenting a UI to help perform an action instead of performing it automatically with no user intervention.
The web action delegate URL pattern is the practice of software allowing a user to set these custom URLs as delegates for certain actions within an application, probably with URL template placeholders which are auto-filled depending on the context of the delegation.
Apps which submit to to delegate URLs
Session notes from events where web actions have been discussed: