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.
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.
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.
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.
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.
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 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…)
1. Tom Clancy said on 6 February 2008...
That’s a really cool idea. It kind of flips the idea of workflow in a system like a CMS into work being a workflow queue. I look forward to being a factory line drone in the near future.
2. Boris said on 6 February 2008...
Good lord man, you’re putting HTML in RSS there. Why not just go back to “Active Bookmarks”? 😉
(kidding, but that’s way easier than any extensions to Atom et al. Most aggregators render HTML nowadays…)
You know I love this. Especially because I built a “snap-y” workflow back when I was Joi Ito’s human spam filter…
I built a system I called Jaegermeister (Master of the Hunt) which generated RSS feeds of weblog comments straight out of the MT database, and, yes, included links back into the MT UI for deleting, editing, getting more context n the comment etc…
3. Matt said on 6 February 2008...
Tom, it’s a worry to me that this is all a bit factory line. But then again, RSS turns us into machines for reading… I’ve been working a lot with queues and finite-state machines in programming recently. They’re powerful programming techniques, and powerful interaction models too. Not suitable for everything, sure, but definitely underused. You know, I’d *like* to have an inbox in my Documents folder where things get saved before they get filed. (Yes, it’s called my Desktop… but perhaps we could formalise that behaviour.)
Boris: so you can tell this idea feels really neat to me One of the reasons it feels neat is because it’s not new, it just needs a bit of corralling to get everyone to implement the pattern for their particular web apps. I’m selfish really, I just want to use Snap myself. Given that, and given I have an MT install I also use… do you distribute Jaegermeister as a plug-in? And how about a little forms magic and a custom landing page to make it all work in the newsreader?
4. Andrew said on 6 February 2008...
I’m wishing you’d called it “Synap” instead :-), but still, fantastic stuff.
This would be an amazing model for interacting with Mechanical Turk, which is essentially an API for creating and distributing many tiny tasks across a population of people. Currently those tasks have to be browsed, initiated, and completed on the Mechanical Turk website, but a Snap-enabled approach could be much more efficient.
5. Tom Clancy said on 6 February 2008...
“it’s a worry to me that this is all a bit factory line”
Don’t get me wrong, I’d love something like this as a way to keep pushing through the next TODOs for any project that can currently be worked on. I’ve just been reading too much Sci-Fi recently and it feels like we’re coming around to another trip through the cycle we saw at the start of the 20th century, Robber Barons and Taylorism, except this time the people working under unhealthy conditions for too little pay will be knowledge workers. The end of that cycle might be a glorious time to be alive, but I wonder if knowledge workers would ever notice if they were being exploited.
6. Andrew said on 7 February 2008...
Incidently: Google Spreadsheets as of today lets you set up a form front-end to any spreadsheet, which is then delivered via email. Not precisely the model here, but it is a way of distributing the interactions out into the world, and aggregating data from them.
7. Boris said on 7 February 2008...
Ohh Matt, after I posted this I ran off to try to find a working copy to no avail. It was so long ago. I don’t even remember what it looks like, and I don’t have the time atm to fix up an instance. It was really primitive though, just links back into the MT admin to delete or approve or spam comments. And it wasn’t a plugin bu trather a standalone PHP-based thing that would peek into the MT database. I think I’m the only one who ever used it (though it was deployed across my network of clients… 😉
In any case… I see whatcha gettin’ at here… mmhmm
8. Lance Lavandowska said on 7 February 2008...
Very reminiscent of Mark Woodman’s proposal from a couple years back, only with a working example
9. Matt said on 7 February 2008...
Andrew: So… could it be done? Get a public feed of available jobs with a ‘accept this’ button, then a password protected feed of your own jobs?
Lance: Awesome validation! I like this takeaway from the article: “The Immediate Action Credo: A link from information to action is not good enough. I will provide an immediate point of action to the user directly in my feed whenever possible.” — and the mockups are fantastic too. How do we make this happen, given more readers support HTML + forms now?
10. Ben said on 8 February 2008...
This is excellent.
Could it handle more serious stuff? I’d like a thing that could keep all my internet tasks in one place, with one click. Passwords and all. Blogging and banking. Facebook and ftp. And if I could log on to that anywhere…
11. Andrew said on 15 February 2008...
Matt, at the moment, no it couldn’t be done, because MechTurk has no public feed of available jobs (though if you want to screenscrape…) There’s no reason the content wouldn’t lend itself to being distributed via RSS, though.