IndieWebCamp is a 2-day creator camp focused on growing the independent web

webactions

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.[1]

Why

You should put web action buttons (or links) on your posts so that users can quickly interact with them and perform common actions such as:

You should also consider putting web action buttons on your posts even when inline in a stream (composite, home page, or archive pages), so that users can quickly interact with your posts while reading through a collection of them (without having to dive into and out of each post to interact with it).

How

Wrap tweet or share

Use the <indie-action> tag to wrap any third party / silo action buttons/links you might already have on your site, e.g. "Tweet" / share / +1 buttons. Here is an example of wrapping an existing Tweet button (from an actual blog post), whitespace/indenting added for readability.

<indie-action do="post" with="http://tantek.com/2014/179/b1/indiewebcamp-thoughts-before-gathering">
 <span class="tweet-button">
  <a href="http://twitter.com/share" class="twitter-share-button" data-url="http://tantek.com/2014/179/b1/indiewebcamp-thoughts-before-gathering" data-text="IndieWebCamp 2014 — Thoughts Before The Gathering:" data-count="horizontal" data-via="t" data-related="html5now:microformats">Tweet</a>
  <script type="text/javascript" src="http://platform.twitter.com/widgets.js"></script>
 </span>
</indie-action>

Note that everything inside the <span class="tweet-button"> is markup from Twitter, including the javascript. It's not required for web actions, just the markup that was there from before.

The <indie-action> element is an example of a custom element, part of the web components family of technologies. The element was initially <action>, but custom elements require a dash in the element name, hence <indie-action>.

Wrap favorite reply retweet

If you have Twitter "Favorite", "Reply", "Retweet" tweet action links, you can wrap those in <indie-action> tags so that those with <indie-action> tag support will be able to automatically interact using their own site rather than a silo. Here's some sample markup (again from an actual post), note that text verbs have been updated to use the general like, reply, repost terms rather than Twitter's terms. Again whitespace added for wrapping/readability (and non-essential attributes removed)

<indie-action do="like" 
 with="http://tantek.com/2014/175/t1/pdf14-why-need-indieweb-video-slides">
 <a target="" 
  href="https://twitter.com/intent/favorite?tweet_id=481682185359880192">
  <img src="http://si0.twimg.com/images/dev/cms/intents/icons/favorite_hover.png" alt=""/> 
  Like
 </a>
</indie-action>
<indie-action do="repost" 
 with="http://tantek.com/2014/175/t1/pdf14-why-need-indieweb-video-slides">
 <a target="" 
  href="https://twitter.com/intent/retweet?tweet_id=481682185359880192">
  <img src="http://si0.twimg.com/images/dev/cms/intents/icons/retweet_hover.png" alt=""/> 
  Repost
 </a>
</indie-action>
<indie-action do="reply" 
 with="http://tantek.com/2014/175/t1/pdf14-why-need-indieweb-video-slides">
 <a target="" 
  href="https://twitter.com/intent/tweet?in_reply_to=481682185359880192">
  <img src="http://si0.twimg.com/images/dev/cms/intents/icons/reply_hover.png" alt=""/> 
  Reply
 </a>
</indie-action>

IndieWeb Examples

Examples of real world web sites using the <indie-action> tag. When this gets too big (say, 10+ sites) we can move it to webactions-examples-in-wild

Barnaby Walters

Barnaby Walters on notes since at least 2013-03-15, e.g.

Laurent

Laurent (all posts?) since ????-??-??, e.g.

Tantek

Tantek's posts on tantek.com have the following web actions (using Falcon) since 2013-09-08:

  • articles, e.g.:
  • notes, e.g.:
    • have <indie-action> tags with verbs like, repost, reply with Tweet action fallback inside on each note post, and Twitter wording/icons (since the notes are primarily POSSEd to Twitter), e.g.: tantek-com-demo-note-2013-251.png
  • Since then updated (2014) to:
    • Like Repost Reply with the same icons as before.
  • 2014-09-07 updated from <action> (2013-09-08..2014-09.06) to <indie-action> tags per Jeremy Keith suggestion and web components convention.

Indienews

Indienews comments pages, e.g.

Barry Frost

Some of Barry Frost's post have webactions as of 2013-10-01[2], e.g.:

Glenn Jones

Glenn Jones notes, e.g.

Kyle Mahan

Kyle Mahan all posts on http://kylewm.com have "reply", "repost", and "favorite" webaction links as of 2014-05-15 [3]

  • Links fallback to Twitter Reply, Retweet, Favorite if a Twitter syndication URL exists

Scott Gilbertson

Scott Gilbertson posts notes with "Reply" "Retweet" and "Favourite" webaction links since ~2014-06-09. Links fallback to Twitter reply, retweet, favorite tweet actions. Example:

Michael Owens

Michael Owens's notes on mowens.com have the following web actions since 2014-08-14 (verified by Tantek Çelik, possibly earlier)

  • notes, e.g. https://mowens.com/notes/2014/07/01/2/
    • have <action> tags with verbs reply, favorite, bookmark, repost with mowens.com/interact fallback links which provide the following fallbacks as an inline progressive disclosure UI:
    • Reply: a webmention UI with form field to enter a URL of a reply
    • Favorite: placeholder text (presumably for links) to
      • "Favorite using * Twitter or * Facebook"
    • Bookmark: placeholder text (presumably for links) to
      • "Bookmark using * Instapaper or * Delicious"
    • Repost: citation UI text fields to copy/paste
      • "Short URL: [https://mowens.com/n/4Ws2]"
      • "Permalink: [https://mowens.com/2014/...]"

Pelle Wessman

Pelle Wessman on posts since 2014-09-07 (deployed at IndieWebCampUK hack day!) e.g.

Jeremy Keith

Jeremy Keith on post permalinks and in-stream on home page since 2014-09-07 (deployed at IndieWebCampUK hack day!) e.g.

Use Cases

There are at least two key use cases that are worthy of exploring for webactions:

Action Buttons

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:

Oops, the page I clicked thru to doesn't amplify the tweet, it simply repeats it. Bad UX. But there's more.[4]

If I want to reply to t's tweet, I can't do it from his site. I have to back-button back to Twitter. Lotta clicks.[5]

(and my (Tantek) followup: http://tantek.com/2011/009/t4/falcon-needs-reply-buttons-fave-rt-coming, referenced in the broader post: http://tantek.com/2011/010/b1/owning-your-data)

Inline Comment UI

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.

Quote This

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.:

Generically, "Quote this" is a better non-silo-specific phrase for this functionality.

Contents

Brainstorming

action markup

The 2012-06-28 OSBridge "Web Actions" presentation proposed the <action> tag as follows:

  <action do="post" with="permalink">
   <a href=twitter>..</a>
   <a href=pinterest>...</a>
   ...
  </action>

action do verbs

Where:

  • do takes a verb (could allow multiple verbs) - we can create a common verb registry like the rel registry. A few possible common verbs (from analysis in "Web Action Motivations and Clusters") - though these should be iterated based on user experience design iterations (names, how many in particular, what specific meanings).
    • post - more specific than "share", more general than "comment", or "tweet"/"reply", though those might show up in a UI where a reader expected a Twitter-like experience
    • reply - specifically to reply to the current URL. Twitter uses a different icon. IndieNews and Barnaby.co.uk both have reply actions.
    • repost - generalization or Twitter's "retweet", Tumblr's "reblog" ("retumbl?"), Pinterest "repin"
    • like - generalization of Twitter "favorite", Facebook "like", GooglePlus "+1". Alternatively, could split this up into separate verbs for "favorite" and "like", or further specialize: "heart" (Instagram "like"), "star" (Flickr "favorite" and Twitter "favorite"). It's not clear which approach (general or specific) is better. People do assign different meanings to favoriting vs. liking. (there's a photo on flic.kr/tantek with a conversation about this but can't find it now)
  • with takes a URL that represents a direct object for the verb to act on

See also: webactions-verbs-brainstorming

which actions

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.:

  • Twitter tweets: header: 1 action (follow), footer: 3 actions (reply, retweet, favorite) plus "(...) More" for embedding/emailing tweets.
  • Instagram photos: 2 actions (like, comment) plus (...) for various other lesser actions.
  • Facebook posts: 2 actions (like, comment)

note

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:

  • like/favorite/heart/props
  • repost/retweet
  • reply

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.

articles

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

  • post

how many actions

To minimize the cognitive load of an interface, minimize the options for the user to consider. E.g.

  • 2 options: Facebook: Like, Comment
  • 3 options: Instagram: Like, Comment, (...)
  • 4 options: Twitter: Reply, Retweet, Favorite, (...) More

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).

what order

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

  • ordered by increasing cognitive load
  • most commonly taken action(s) first
  • the last thing a user might want to do as last
  1. like/favorite/props. Facebook and Instagram put "Like" first, Flickr puts "Favorite" first, and Google+ puts +1 first. The reason for this is that it is likely both:
    • The most common action taken
    • The action that has the lowest impact, and thus lowest cognitive load of consideration.
  2. repost/retweet. Twitter puts retweet second. In addition, retweeting takes a bit more consideration than favorite (i.e. "Do I really want to send this to all my followers?"), and yet, requires less thinking than a comment (i.e. "What should I to say/add to this text?"), thus it makes sense to put (if at all) "repost" after "like" but before "reply".
  3. reply/comment. Facebook and Instagram both put "Comment" last (second, immediately after like). Twitter is an exception here and puts it first, likely to encourage the generation of more content on Twitter itself, since original tweets are the primary currency of Twitter (they don't do much to surface favorites in their UI). It makes sense to place "reply" at the end as commenting on a post requires the most cognitive load and thus is something a user would want to do after they've considered (and perhaps done) lower cognitive load options.

The "(...) More" button/link in Instagram and Twitter is not a web action itself, but rather a way of hiding "other" much less common actions from the UI (progressive disclosure).

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).

action fallbacks

Inside the <action> element the publisher can place hardcoded markup for the equivalent existing provider-specific web actions which would then work as they do today.

which silo buttons

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.

conditional fallbacks

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.

clientside conditionals

Conditional showing of silo buttons could even be done in clientside javascript, because non-JS useragents certainly do not care about silo buttons (<action> markup should be sufficient for any crawlers etc. to infer general UI semantics).

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 <action> tags), with respective silo-specific fallback inside (perhaps referrer conditionally as noted above).

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:

  • page size. omitting all that silo button markup in the HTML that is returned reduces initial retrieval page size which has numerous advantages, from performance to better search relevance (silo button markup only dilutes the relevance of semantic terms/headings/markup etc. in the page).
  • overall performance. check in JS whether the page appears to be rendered via a "slow" connection (however you want to define "slow", and using whatever technique you wish), and if so then don't load the 3rd party scripts at all (which would likely hurt page performance much more than any value they add).
  • potential privacy. Your clientside JS could also decide (e.g. based on a cookie) to not load 3rd party scripts for privacy/do-no-track reasons.

minimum silo buttons

Is there a minimal recommended silo button set for each silo that indieweb sites choose to POSSE to?

E.g.:

  • Twitter
    • favorite(?) - as evidenced by users actually favoriting POSSE tweets (Tantek)
    • retweet(?) - similarly by users actually retweeting POSSE tweet (Tantek)
    • reply[6]
  • Facebook
    • Like - as evidenced by users liking things far more often than doing anything else with them on FB.
  • ...

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.

silo button variance

It's expected that indieweb sites will likely all end up with slightly different sets of action tags and silo buttons inside, based on:

  • personal preferences for UI/UX
  • whatever silos we choose to POSSE to (already a personal preference)

Verbs

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:

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.

Current implementations:

Web Action Hero Toolbelt

  • The web action hero toolbelt cross-browser extension allows you to use web actions right now in Firefox, Safari, Chrome or Opera.

Greasemonkey Script

  • This is a bare-bones Greasemonkey script that will replace the content of action and indie-action tags with a link to the "intent" urls specified at the top of the script.

Website Action URL Support

Main article: Web Action URL APIs

IndieWeb Support in particular:

  • Aaron Parecki has a URL endpoint for posting new notes/replies which he forces twitter to use for him.
  • Barnaby Walters has a URL API for creating new notes, which accepts several query string params, inReplyTo, text and tags.
  • ...

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)

Follow-ups:

Some statics on sharing button use:

Privacy concerns

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).

Adblock Plus blocking

The browser extension "Adblock Plus" as of version 2.6.3 (possibly earlier) is known to block some social share buttons, even just Twitter tweet action hyperlinks!

The following Adblock Plus filters appear to be at least blocking follow, tweet, and retweet links:

##a[href^="https://twitter.com/intent/follow?"]
##a[href^="https://twitter.com/intent/retweet?tweet_id"]
##a[href^="https://twitter.com/intent/tweet?"]

If you're using Tweet Actions as silo-specific fallbacks for web actions, be aware that your fallbacks may not show up on users' machines with Ad Block plus installed.

If you're a user of Adblock Plus, you can re-enable these by:

  • go to a page which has them (e.g. http://tantek.com/2014/164/t1/web-idealists-have-a-point )
  • choose "Open blockable items" from the red "ABP" stop icon in the toolbar
  • note the blocked items in red in the list that opens in a pane below the web page (same window)
  • right-click / ctrl-click on each red item and choose "Disable Filter"
  • reload the page - the buttons / tweet actions should show up.

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

  • Cognition Blog Post Response CTA
  • phorkie federated forks using rel=vcs-* to discover repo URLs for a website. Sites could have <action do="fork"> which UAs then redirect to the code hosting service of the user’s choice
  • … Add more here, move to a separate page once there are too many

Delegate URLs

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.

Benefits:

  • No need to communicate directly between applications, avoiding all the auth/security complexity which comes with doing so (e.g. OAuth)
  • Apps only need to submit the data they know about; any other data can be provided at the second step. * Encourages tiny, focused UIs
  • reduces the need to update UIs when the delegated system changes

Apps which submit to to delegate URLs

  • pushups is a simple, standalone HTML+JS+CSS (download to clone) nose-activated pushup counting UI. Give it a URL, and when you’re done it delegates the data to the URL you provide, which is remembered using localstorage.

History

2011

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[7]), 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.

2012

Web actions were presented and discussed at OSBridge 2012:

Events

Session notes from events where web actions have been discussed:

Articles

See Also