Web Actions: Identifying A New Building Block For The Web

on (ttk.me b/4DE1) using BBEdit

Every once in a while, design and development practices emerge on the web that enable a leap forward in our understanding of its potential. Developers' asynchronous use of JavaScript (JS) led to AJAX and breakthrough interactive web applications. Designers' semantic use of class names led to microformats and widespread portability of contacts, events, and more.

In the past few years we've seen the rapid proliferation of buttons on web pages that allow the user to do something with the current page or site over on another site or application. You've all seen them: Blog this, Digg, Read later, Follow, Like, Share, Tweet, +1. There's something more interesting going on here than mere social media self-promotion. We're witnessing the emergence of a whole new building block for the web: web actions.

Defining Web Actions

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. They're not a specific technology but use a variety of technologies. Typical web actions consist of:

  1. a visible hyperlink, button, iframe or other element (typically with a semantic class name) presented as an affordance to take a specific action
  2. ideally, initial declarative markup (linking or form submission) to perform the action
  3. JS (that uses AJAX techniques) to unobtrusively enhance said visible element to provide an inline and more responsive interaction
  4. often an interstitial or simulated pop-up window for confirmation, choosing an option, or providing additional information
  5. the execution of an action at another site or in another application

The most well designed web actions consist of all the items listed above. Ideally an interstitial should only be presented when necessary for specific reasons, e.g. authentication or a user choice or other additional input like a comment.

Web actions are not "just" hyperlinks. Hyperlinks are nouns and they reference destinations (sometimes with an explicit relation) with an implied action of navigation. In contrast, web actions are verbs and are first and foremost about a specific action that often but not always does something with the current page or site.

Web actions are also not "just" AJAX. AJAX typically refers to interactively responsive features (yes, often actions) on a site itself. While web actions often make use of AJAX techniques for responsiveness, they are distinguished by the fact that they work across sites. It is this cross-site interactivity that makes web actions explicitly web-like and thus named accordingly.

Twitter's "Web Intents" are perhaps the most exemplary of web action APIs created to date: they use well formed fairly minimal semantic markup (hyperlinks with class names) that work declaratively as-is on desktop and mobile browsers alike. They efficiently require only a single <script src="..."> to progressively enhance all Tweet actions and other Twitter buttons on the page.

If you're designing and building web actions for others to deploy, you'd do well to mimic Twitter's design. Twitter's documentation is also quite good with one minor-nit: they've appear to have used the phrase "web intents" confusingly to mean two different things. Twitter calls the overall feature "Web Intents", as well as referring to implying that the interstitial dialog windows asare "web intents" (From their documentation as of 2011-08-11: Web Intents don't require Javascript, but it makes it easier to pop them up ... recommend rendering each Web Intent at 550px by 420px - the emphasis added phrases seem to imply that the web intents are pop-up windows that are popped-up, and rendered at specific dimensions, though this implication is apparently unintended.). They do explicitly use the phrases "Tweet action" and "Follow button" though to refer to the buttons themselves, some form of which I think they should use for the overall feature as well.

From the user's perspective, the buttons and the actions they take are the feature. The interstitial dialog windows deserve their own term or phrase, perhaps something like "web action interstitialpop-up window".

To be fair, Twitter's documentation is for developers (it's on dev.twitter.com after all), and thus they're seemingly re-using the existing developer-centric phrase "Web Intents" to refer to the suite of API endpoints for performing actions on Twitter rather than the buttons and web actions as a whole.

This confusion/iteration has made me realize that it would be a good idea to diagram/write-up an "anatomy of a web action" that describes all the pieces (i.e. the five items listed above in Defining Web Actions) and how they interrelate.

Nonetheless, if you're considering adding web actions to your site, Twitter's Buttons and Tweet actions are a good place to start.

Two Tweet actions in particular made immediate sense to me personally, each in a specific context:

I've wanted to add reply, fave, retweet buttons to my self-hosted tweets for some time, however, it wasn't clear to me how to best present them, nor what the right "IndieWeb" interaction should be. At IndieWebCamp this past June, I led a hack session on "web intents user experience".

Erin Richey and I spent the better part of that day at IndieWebCamp iterating on how to best construct a UX with such buttons, made some progress, but found the terminology stifling and confusing (despite participating in Chris Messina's earlier "Standardizing Web Intents" session). Soon thereafter I decided to try referring to the buttons and experience as "web actions" which seemed to resonate with others and apparently had not been previously considered. In particular it was clear from discussions with Erin that such a more user-centric term really helped understand and explore the overall concept.

What was also clear from Erin and my analysis of the UX of these buttons was that current usage was all over the map. From sites that discretely used a few buttons here and there to outright "button sluts" which plastered their articles with a veritable NASCAR of social media logos. Their designs appeared to be driven more by fashion and brand fetishes than anything sensible or user-centric. There didn't seem to be any analysis of user motivations, nor emotional design: attempting to understand a user's reactions and motivations that might drive them to want to use any particular web action button. Erin has written more about this in her post Button Sluts and Web Actions.

Web Action Motivations and Clusters

Based on my research I've found that existing popular web actions can be placed into one of a few categories based on user motivations:

There are more categories; these are just the common ones.

By studying and classifying existing web actions from a user motivation perspective, we can better design user experiences that place the web actions such that a user will more likely see them when they are motivated to use them.

Intuitively a few thoughts come to mind, like perhaps place:

There's an opportunity to document existing research, do more research on different variations and approaches, and document their relative effectiveness.

The next step would be to try some of these out. In the coming weeks I'll be experimenting with them on my own site and encourage you to do so as well.

Once we have a better understanding of which simple web actions work best where, and which motivational scenarios drive users to use them, then I think we'll be able to better design standards for web actions and respective APIs. There's a lot of potential for web actions, but for that potential to be realized, it must lead with a good user experience first, and standardization second.

Web actions have the potential to change our very notions of what a web application is from a single site to loosely coupled interactions across multiple, distributed sites. In that regard, web actions have the potential to become a building block for distributed web applications.

Focus on the user and publish your work

I encourage everyone working on web actions to focus on user motivations and their experience on your site first and foremost.

If you're an implementer of web actions, follow something like Twitter's designs. If you're embedding web actions on your pages, choose actions and place them on your pages by matching them up with users' state of mind and motivations to act.

In both cases, share your work.

As an implementer of web actions, provide good documentation (as Twitter does, except consider describing your web actions feature primarily from a user-centric point of view, even to developers. A user-centric description will make your feature easier to understand for everyone, and will hopefully help your developers provide user-friendly documentation as well.). As a content/site publisher, share your visual design iterations and reasons why you chose to place specific web actions where you did/do.

I'll be sharing my work in progress on my blog and on IndieWebCamp.com. I encourage you to do the same.

Want to chat about it? Since the IndieWeb perspective is a good practical approach to using and developing web actions, let's chat in the #indiewebcamp channel on Freenode.

Update 2011-08-12: This article has been updated to correct the references to and descriptions of Twitter's Web Intents feature, in particular: Tweet action is lowercased (rather than "Tweet Action"), Tweet actions refer only to actions taken on a tweet (rather than all Twitter buttons), Twitter Web Intents are specifically the suite of endpoints for performing actions on Twitter, and the author's confusion regarding web intents referring to pop-ups has been documented via implying quotes from Twitter's documentation, as well as acknowledgment that such implication was unintended. Thanks to Ben Ward for feedback and corrections.