Web Actions: Identifying A New Building Block For The Web

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:

a visible hyperlink, button, iframe or other element (typically with a semantic class name) presented as an affordance to take a specific action
ideally, initial declarative markup (linking or form submission) to perform the action
JS (that uses AJAX techniques) to unobtrusively enhance said visible element to provide an inline and more responsive interaction
often an interstitial or simulated pop-up window for confirmation, choosing an option, or providing additional information
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.

Whither Web Intents, Introducers, Activities?

There have been previous attempts at identifying and describing web actions, but they've either been far too developer/technology (rather than user) centric, or burdened with too broad a scope or complexity. However, these early attempts have helped explore many related concepts and thus merit mentioning.

Web Intents - named after a feature of the Android platform (Android Intents) that permits applications to register their "intent" to handle certain types of actions, the API-centric framing of web intents makes it difficult to discuss them from a user experience perspective. As user-centric technologists we must always deliberately think of the users first, and choose user-centric terms to guide our thinking accordingly. And users take actions, not intents. Nonetheless, there's been good iteration on web intents from an underlying API/plumbing perspective and it's worth watching.
Web Introducer - an early attempt at iterating on Web Intents, the abstraction of a Web Introducer was perhaps a premature attempt at providing a web-based action delegation service from generic actions to specific action providers, so you could choose, purely using the web, where you wanted your "likes" or "favorites" to go for example.
Web Activities - most recently, Mozilla Labs introduced the notion of Web Activities (nothing to do with Activity Streams), with the example of using one site as a web application to edit photos from or on another site. While this separation of editor and content host is potentially a useful one (having personal experience with early pre-web attempts at such), Web Activities go far beyond the simple click-do-one-thing-and-continue user experience of existing web actions. We can make more progress faster by first understanding and solving the simple existing uses simply.

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 ~~interstitial~~pop-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:

"Follow" - a logical upgrade to simply linking to my Twitter profile in the sidebar of my home page
"Tweet" - a quick way to share a specific post, a logical addition to the shortlink, permalink, and citation hypertext copy/paste fields in the sidebar of my blog posts

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:

later: "I don't have time or this is too long!" - AKA tldr or more positively put: I want to read this later. Readability and Instapaper are examples.
save: "This is interesting and I want to save it!" - similar to "later", but primarily a collection impulse. Some use saving as a read later function, but this is more about collecting, categorizing, and knowing it's somewhere you might find it again since it might be useful some day. Bookmarking is a form of saving.
props - "This is cool, I like this, I want to praise it." - This item is worthy and deserves recognition. Digg, Like, Favorite, +1 are all examples. Sometimes favoriting is used as a method of saving, but it's special in that it indicates a positive evaluation.
share - "This is so good that I feel compelled to share it, my friends will want to see this, or sharing it will make me look smart, in-the-know etc." - This item is worth passing on to friends, perhaps with commentary. Tweet, Blog This, and Tumblr are all examples.
follow - "I want to hear more from this author/site!" - I like this site/author, perhaps based on this post, and want to see more from them in the future. While Twitter's Follow button is the obvious example, the earliest occurrences of this web action date back to the late 1990s and the emergence of "subscribe to my feed / RSS" buttons. This may be the oldest web action.

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:

"later, save, props" actions near the top of a post
"save, props, share" actions near the bottom of a post
"follow" actions somewhere global to the site, like a sidebar

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.