I recently worked with Matt Webb on a proof-of-concept for a new interaction pattern for web applications, that we’ve nicknamed Snap. Matt demonstrated this pattern in his closing keynote at Web Directions North. Matt’s presentation, entitled “Movement”, is now online, as is a longer explanation of the Snap pattern at the Schulze & Webb blog.

Given Matt’s side of things is now online, it seemed only right that I share my side of the story.

We’re demonstrating a concept that’s previously been referred to as RSS-I – “RSS for Interaction“. This is an idea Matt mentioned in his ETech 2007 keynote, from Pixels to Plastic, and also in a presentation from Barcamp London in 2006. Here’s Cory Doctorow writing about the first mentions of the idea. Matt’s new name for this pattern is a bit catchier: Snap, which stands for “Syndicated Next Action Pattern”.

If you’ve read those links, it’ll describe a certain pattern for interaction. If you’re lazy, and haven’t read them, in a nutshell: what if RSS feeds could prompt you not only to updated and new content, but also actions that need to be performed?

This is the kind of thing best explained with a demonstration. And so Matt asked me to build a small application – a to-do list program – to demonstrate Snap at WDN. Our application isn’t anything fancy, and it won’t replace your GTD app of choice just yet, but it does demonstrate some of the interactions that Snap affords rather neatly.

You can watch a short screencast of the application here (The application is called “Dentrassi”. For more on that, see this footnote).

In the application, a user can add todo-list items to it, set a priority, and “tag” them as belonging to a project. There are several listing views of the data in the application. The inbox shows all items in progress that don’t belong to a project (ie: aren’t tagged). There are list views for each tag, and also for items that have been deferred to the future. So far, so good.

All of this data is also available as Atom feeds. The Atom feeds present the same information as the website, with one neat difference: at the bottom of every item, there’s a form embedded. And in that form, you can do everything you can do to the item on the site: defer it, tag it, complete it, or trash it.

So not only can you read all the data you’d normally see on the site, you can also interact with it, without leaving your feed reader. When you complete a successful interaction, a big tick appears.

The big tick was something we stubmled upon whilst we were making Dentrassi. If you’re on the web-app side of Dentrassi, and you mark an action completed, you get a typical Rails-style “flash message” letting you know what’s happened. This was also the case in the feed, to begin with – you’d post the form, and then the web page would render inside the feedreader’s viewport. Which is OK, but not great. Then we hit upon the idea of treating requests from feedreaders and browsers differently. There’s no magic user-agent-sniffing – the RSS feeds have an extra hidden field, that’s all. When that field is set, you get a big tick (or a big cross, if you try to work on stale data). You can see in the video that Matt’s added a really simple “add another task link” to the “big tick” page in certain states, to speed up task entry. Once the big tick was in place, it started to feel like I was actually making a thing, rather than a hack.

There’s also an extra feed, which we’ve called the admin feed. This only ever has two items: a generic message telling you the state of the system – how many things are in it, how many are completed – and a form that lets you create a brand-new todo. From your RSS reader.

That’s it. It’s not very sophisticated, but it demonstrates the interaction Matt’s described pretty well: the syndication of interaction, rather than content.

What’s the future for this kind of thing? I don’t know. “Enclosures for interactions” was the best way I could describe one future I’d like for it: the idea that endpoints for interactions could be specified just as we currently specify things like referenced media files; then the user interface for Snap is down to the tool, rather than the feed itself. That’s easily the most exciting future, but it requires standards, and toolmaker support, and people like Tim or Sam to be onboard (or whoever the Tim and Sam of Snap might be), and all that takes time.

(And: when you can let the agent define the interface, what interfaces you could build! I suggested pedals – I can have my yes/no tasks up in a window and rattle through them with my feet whilst I’m reading, or writing email, or whatever, just like foot-controlled dictation machines. Because Snap emphasises, rather than obscures, the natural flow state we get into when we’re working our way down a list, it generates a sense of immediacy around the simple action of “doing tasks”. The forms can be contextual to the actions in question – complete/wontfix, yes/no, attend/watch – whilst the actual interaction the user performs remains the same.)

Snap also demands different kinds of RSS readers. Traditionally, readers cache all information, meaning as items “fall out” of the feed they remain within your feed reader. But we don’t want that; we’d like items that fall out to disappear. A Snap feedreader should be an exact mirror of all the atom feeds available to it, not a partial mirror.

That’s precisely the opposite behaviour of existing, content-oriented feedreaders. Right now, most of what we’ve shown is a little bit of a hack: we’re relying on the fact that, for whatever reason, you can use <form> elements in an Atom feed, we’re relying on this being a local application, for a single user, and we’re relying on it working on a very limited number of user agents (I’ve only tested NetNewsWire and Vienna so far). There’s a way to go before full-scale RSS-I is possible – but there’s nothing to stop people taking a simple, hacky approach right now.

And so that’s what we did. Because a simple, hacky approach that exists beats any amount of RFC-drafting and hypothesising. The most valuable thing we have to show for this so far is that it works.

How it works doesn’t really matter. As such, you’re almost certainly never going to be able to download the source code for this application. The code really isn’t important; it’s not bad at all, but to distribute it would be to miss the point. What we’re trying to demonstrate with this is a particular interaction, and that can be demonstrated through narratives, screengrabs, and screencasts.

That’s all there is to say; Matt’s longer post on his company blog encompasses everything I’ve not mentioned here (and a few things I have), and as such, should be viewed as a companion piece. It’ll be interesting to see what happens from here – how, as things like Action Streams take hold, patterns like Snap have a growing place in the web ecology. It’ll also be interesting to see what happens with, say, standards for these kinds of things – enclosures and the like – and how the tool manufacturers react. All in all, it was a fun project to work on, and I hope other people find the interaction as exciting as Matt and I do.

(Matt mentions that I nicknamed that application “Dentrassi”. I find it useful to have names for things; when I’m sitting at ~/Sites/ and am about to type rails foo to kick off a new project, it’s nice to have something – anything – to call the application. I thought about DEmonstrating RSSI, and the only word in my head that had things in the right order was DEntRaSSI. The Dentrassi, for reference, are an alien race from the Hitch-Hiker’s Guide to the Galaxy. I’m not a Douglas Adams nut, or anything – it was just the only word in my head at the time. So rails dentrassi it was, and off we went.)

2 comments on this entry.

  • Amit | 12 Feb 2008

    A really nice piece of work here Tom. It strikes me that the possible payloads that can go back and forth in (a) creating a new feed entry in an inbox and (b) spawning an action to/for a subscribing listener or application – essentially entails defining what state a current “event” or process is at. To give you an example, the process of booking a meeting with someone begins with a request action with a payload of date, time, etc. and continues on for x amended requests and responses until a confirmed meeting time is reached.

    Of course, the manifested form of Dentrassi is a clear demo of what can be done, but a possible, if more intricate scenario is a multi-transaction process such as that used by multi agent systems, for example the Contract Net Protocol (see diagram and note interesting “deadline” part on the first pass) to arrive at a negotiated best fit. Finding a way to cater for exchanged transactions, statefully is the key to the interaction possibilities reaching a point when they can really work for human actions and processes via a feedreader.

    By moving from a subscribe/notify model for content to actions, snap has introduced an inherent responsibility to cater for events and processes, under the constraints posed by the orthodox aims of newsreaders. If a model for how actions feed to other actions existed, there’s a basis for an awesome way to handle everyday processes despite their twists and turns, although I think this is a solid example of the pattern already. Other uses:

    – use the inbox feed to pipe action requests as SMS requests via twitter (similar to facebook’s “you have a friend request from Joe Bloggs”)

    – a firefox plugin to initiate an action from a page with a given set of verbs which then asks the target recipient to subscribe to a feed, in which this action and multiple actions exist. Simple example – if I wanted to email this page to a friend, I can right click, and instead of filling out email addresses, send my friend a one-time only “feed subscription request” – which then sends actions to that new friend as an established contact, without emails for each action request. Eliminates future email once subscribed, and allows my friend to receive my action requests implicitly rather than by bombarding their inbox.

    – the ability to comment within feedreading applications is already the subject for various startups (can’t remember them at this time of day!) but extending that would open an entirely new business model where commerce transaction requests don’t appear as feed advertising – they appear as actions – for example to fill a survey

    – If you could figure out a foreign subscribers’ identity beyond their newsreader user agent, for example capture information from a stranger before they subscribe to their inbox feed, it presents the possibility of contextual actions targeted towards them. I don’t mean in an advertising sense, I mean aggregating their action requests from their various services across the web. This would be a proactive and explicit action request mechanism, in contrast to a facebook mini-feed, which lies in the dimension of reporting on your trust network historically and implicitly.

  • Selem | 13 Feb 2008

    come on,

    notice the date? but maybe timing wasn’t right.

  • 7 Feb 2008

    Trackback: links for 2008-02-07 (Leapfroglog)

  • 10 Feb 2008

    Trackback: plus six » links for 2008-02-10