So far we’ve only been using Atom/RSS for syndicating media.
It came about because it became apparent that a common pattern of websites was updating lists of information. What if these updating lists could be collected into a single, appropriate application so that you didn’t miss updates?
But there are also lots of updating lists I visit that I want to interact with:
Why can’t these all be syndicated together, along with the interface to deal with them?
Each Atom entry should become a dialog box, carrying a small form and a couple of button choices. The interaction gets pulled out of its home application, and together into this next generation feed reader.
The illustration above is a mockup of one way this could appear. A bugtracker entry first, then a moderation request, then a book to think about… Or perhaps this could all appear on my Chumby. I could sit with it, over breakfast, leafing through and responding to a stack of essentially modal dialog boxes that I need to do something about.
This model, Atom-A, is suitable for any application which models itself as a state machine, where I, the user, move information between states. This describes a whole lot of applications if you think about it… mostly very simple ones that you need to go back to but are too numerous to remember all the website addresses, just like good blogs and Atom-for-media.
Once you start thinking along these lines, it becomes apparent that bugtrackers would make more sense in an application custom-designed for state machines and dialogs, especially if people can apply the same interface knowledge to other applications in their work.
Perhaps the same interface could be used with two coupled Atom-A feeds for a game of chess or battleships, each feed carrying a picture and a bunch of options. Or it’d be really good as the primary interface into an editorial workflow system.
Matt Webb, S&W, posted 2006-09-21 (talks on 2006-09-03, 2006-09-17)