Sunday 8 March 2009

Design considerations for a generic activity stream desktop tool

I was just reading fellow Headshift'er Jon Mel's overview of Social Text's new Signals and Desktop extensions (also cross posted on his own blog) - basically it provides support for microblogging (the "Signals" part) along with a nifty desktop widget ("Desktop") for monitoring them and the activity stream of things you are watching on the wiki.

This reminded me that I was only just reading about a similar desktop tool (in the sense its another Rich Internet Application-based widget) for Alfresco. Now, without getting under the hood of the thing myself, I'm assuming that its essentially just a customised RSS feed widget - a bit like Snackr - designed to work with a secure feed for a particular URL pattern suited to a single application. Of course this is a just a one-way view of activity.

In theory then, there should be no reason why any modern Web 2.0 influenced messaging, wiki, collaboration or Web content management system couldn't all offer the same style of desktop applications. So this morning I was thinking about what if we were to build a generic desktop activity stream application, what design considerations might we need to think about?

  • Do we support a single microblogging APIs, just RSS/ATOM or multiple methods?
  • Should it also help out as an email and calendaring notifier, and instant messaging widget (like the Google Talk Labs Edition)? Maybe also the ability to start a voice or video call with someone.
  • Should we provide support for multiple user or enterprise defined channels (like the way Social Text separate "Signals" messages and other activity) or a single combined activity feed?
  • Should you be able to taken action on the stream without opening the Web-browser interface? And should we be able to book mark and tag items from the stream for future reference?
  • Do you aggregate all the activity data in a central place or on the user's desktop?
  • Do we develop our activity widget as a traditional fat client application or build it as a Rich Internet Application (e.g. Adobe AIR)?

Personally, I think the first three points might depend on user and organisational requirements. However, for the last two I think it would make sense to provide a cross-platform tool and to centralise feed and activity data for users that use different devices to access their stream. Of course in attempting the design a generic tool the whole design starts to sound quite complicated, but it shouldn't if we keep to open standards and make it extendable (this deals with the first three points more elegantly). It would also be nice to perhaps think of this as the next generation messaging tool that has the potential to finally push the old email client into the background where it belongs.

What do you think? Would you like a desktop activity stream tool like this in your workplace or would you prefer a vendor specific widget? What other design considerations or user requirements can you think of?


  1. Anonymous11:24 am

    Hi James
    2 things we learn't back when we built ZapTXT:
    1. Ubiquity: Adoption risk is drastically lowered when using ubiquitous, existing consumption mechanisms (IM, Skype, Email, Mobile etc) that users are already comfortable with vs. a client. I realize this might be a little easier in the enterprise where such things can be centrally managed.
    2. Presence: Probably more important than ubiquity, employees are increasingly mobile and perishable information needs to find them. So there needed to be smart routing to bounce filtered updates from IM to SMS or Phone when a user is away. Desktop apps might have limitations when you need to let the information find the user, not the other way around.

  2. Anonymous6:13 pm

    Hi James, Congratulations on your new role (annnounced in today's Australian IT section).

    Wasn't able to use the chat function above - came up with an Error 404 - but it's probably the firewall issues here.

    Andrea Lai


Note: only a member of this blog may post a comment.