Post #163

Recently at Web Directions North, I introduced Snap, the syndicated next action pattern. It’s a way to get all those little interactions out of websites, and all in the same place: your newsreader. You can watch and read the presentation here.

In this post, I want to expand on those slides to introduce Snap and show it working.

What kind of ‘next actions’?

There are loads of small next actions. For example:

• Taking a new bug in a tracker, and accepting it, allocating it, completing it, or marking it as a duplicate
• For an email or weblog comment in a moderation queue, accepting or deleting it
• Clicking through and perhaps purchasing a recommended book

It’s tedious to move around the Web to do these actions. It would be better if they were all in the same place. We had this same problem with weblogs and other media, and RSS was invented to syndicate new entries to the desktop.

What I’ve previously suggested is that we need a kind of RSS for interactions–and you can see a mockup here. At the time, the concept got some attention.

Conceptually, each ‘object’ that requires interaction is a feed entry. The actions are shown as an HTML form, and using the form sends data to the website which updates that object. The feed is then updated, changing the original entry to show the new object state. The original object state is no longer visible. This requires the newsreader to allow HTML forms and respond sensibly when feed entries change.

I’ve been working together with Tom Armitage on a proof of concept (of which more in a minute), and the headline is this:

Feed entries can indeed represent interactions, and update to show new states. The user never needs to leave the newsreader.

This is the pattern I’m calling Snap. It works, and we have a demo.

Demo: Dentrassi

For the proof of concept, we created Dentrassi (Tom did the heavy lifting), a desktop todo list manager which can be run entirely through a newsreader.

Watch a screencast and transcript of Dentrassi in use.

The app demonstrates a number of ideas:

• There is an admin feed which has persistent entries. One entry includes a form, which is used to add new tasks
• New tasks appear in the inbox feed, until they are allocated to projects
• New project feeds are created dynamically: users can subscribe to a project feed from another persistent entry in the admin feed
• Every task feed entry is smart: each includes a form to show the available interactions, so tagging, task completion and editing all happen inside the newsreader
• Tasks move from feed to feed so you can focus on different lists of next actions at different times

Tasks only appear in feeds if they require actions. This means there’s a single place you look to find what to do next.

One interesting feature, not in the demo above, is the idea of the deferred task: a task can be pushed into the future by some day – a day, a week or a month – and it then disappears from the feeds, only to reappear when it’s valid again.

Dentrassi possibilities

Imagine having your todo list manager – whether it’s iCal or TaskPaper – expose a Snap interface, so you can use it entirely from your newsreader.

Tasks could then be mixed with interactions from all your other sources – like email moderation or bug tracking – and even tasks from other people in your company. Perhaps tasks from other people would be read-only, or maybe you could collaborate.

Lessons learned for Snap

We learned a lot from Dentrassi. Some points:

• Stale items: once you act on a feed entry, the entry is stale until the feed is refreshed. Problems are avoided, in Dentrassi, by giving each object a serial number which increments on updates, and refusing to accept updates from forms which don’t pass in the current serial. This isn’t great from a interaction design perspective. Instead each feed item should query the server when it’s viewed, showing a ‘stale’ badge if a refresh is required. If the user is offline, an ‘unknown’ badge should be shown instead.
• Disappearing entries: an entry will often disappear from a feed once it’s actioned. It’s important that a newsreader allows the entry to vanish, and doesn’t keep its old state as a duplicate entry (GUIDs help here).
• Keeping interaction in the newsreader: when the follow-up to submitting a form is a success or failure, Dentrassi shows a badge. It would be good to have a standard way of reporting status. But sometimes the follow-up to a form is another form, and that’s tough: the interaction has to move to a website. Using Ajax inside the feed entry will help.
• Subscribing to feeds from within the newsreader: inside feed entries, new feeds URL should be prefixed with ‘feed:’ to make sure the newsreader handles them directly, instead of opening a Web browser.
• Working offline: there is currently no way to work offline. It would be good to have the newsreader cache the form data to send… although this may pose a problem if Javascript is being used.

One point to look further at is how to improve newsreader support for this usage. Maybe there could be a Snap profile for Atom, in the same way podcasting is supported by enclosures? If forms were ‘enclosed’ in feed entries, they could be shown separated from the main body – more like a dialog box – and it would be clearer how to use them. This was the look that seemed to make most sense in Dentrassi. In my original mock-up, which just used the straight HTML, the forms look confusing.

Other possibilities

I’ve mentioned a number of possibilities for Snap in general:

• Mixing together multiple ‘next action’ feeds from different sources
• Having several feeds representing different states of a process, for example different Snap feeds for the different states of a bug in a tracker
• Desktop applications exposing a Snap interface, for local use. And using the location of the feed request to show full feeds or read-only feeds, for collaboration
• Having multiple people work on the same applications, each using a different mix of feeds

These are rather abstract, so here are some systems that use these patterns:

• Multi-player turn-based games, like Risk, or Scrabulous
• An editorial work-flow for a CMS, where each article goes through a number of states, dealt with by journalists, subeditors, editors and other sign-off parties. The documents could be links to the Web, or included as enclosures. A persistent item would allow the upload of new documents
• Similarly, an HR system. Employees would use a website or persistent feed item to submit a form, and then track its process using a single feed. The HR team would have an interactive version of the feed
• iPhoto exposing a Snap feed of all untagged photos, to encourage me to categorise them
• A blog feed which has all posts, and a comments feed which only shows comments from posts the reader is following. A reader follows and unfollows posts by using a persistent entry in the comments feed
• The Facebook activity steam, except each entry carries with is contextual interactions: see more/less of this type of item; add this person as a friend; join this group; enlarge this photo; add a comment
• Feed pipes, slim applications which take a single object through a number of steps in different applications. For example, the same feed entry could represent an untagged photo in iPhoto, then the same photo uploaded to Flickr, which then becomes an object which can be commented on
• A feed of ‘travellers you might know’ from Dopplr, each having a form to either share trips or ignore for a month

Snap as part of the Web

RSS/Atom is simple human interface to website content. A REST API is a simple machine interface to website functionality. Jabber/XMPP is gaining attention for being a machine interface to website events. Snap sits in this same constellation: Snap is a simple human interface to common actions, on a website or desktop application.

All of these are ways for websites to get blurry edges and mingle into one another. They offer ways for website to be recombinant, so that each can build on the functionality of others. They also offer ways for websites and applications to be more humane–to let us build around the tasks and experiences of people, rather than the features list of an individual website.

Snap isn’t a technology. Snap is an interaction pattern which works right now, and I’m convinced makes the experience of using websites better. I’m hoping you’ll give it a try.

Next action!

So, what’s next?

Go read Tom’s post on Snap, about building the proof of concept and the interaction design learnings that came out of it–in particular how the big tick is useful for hitting flow states. That’s first.

Second, if you have a web app, it’d be great to see Snap happening. Feel free to drop a mail if you want to bounce ideas around (and I’m sure Tom would be happy to speak with you about it too).

Thanks

Thanks again to Tom Armitage, WDN08 for giving me the opportunity to think about this, and Ben Hammersley for hosting the session which led to this, way back in 2004. (Also…)