Tag Archives: workflow

Activity Streams: Queue and Flow

Awhile ago, when I was working with a team on activity stream related experience, I found myself thinking about two distinct concepts: queue and flow.

Until I came across this information stream related article, I had forgotten to share these concepts (e.g. to receive feedback).

So, about queue and flow…

When I say queue I refer to things such as alerts, things that require actions, things that indicate workflow, dependencies, bottlenecks, etc.

When I say flow I refer to context for queued activities (tasks) and also context to realize new tasks.

Feeds and inboxes are simply expressions of queue and/or flow. For example, wiki change notifications, mail list subscriptions, etc. are flow-like. Emails sent to me specifically may be queue-like. Tools like IFTTT make it clear that rules (or recipes) can be brought to bear on activity streams.

Queues can form automatically/implicitly and manually/explicitly. For example, business rules may be met, causing an activity to enter one or more queues. A colleague may signal a dependency to a teammate (need cross-check, need assistance, need answer/insight to take own action, etc.), resulting in a queued activity.

Flow should unfold itself based on need to know. For example:

  • Meaningful default (last X activities, filters apply, time-based, etc.)
  • Ability to expand view–up to a point (e.g. Twitter handles roughly previous 8~10 hours)

As I mentioned briefly above, an activity in the Flow can become an activity in a Queue:

  • Alert someone else (as a notification with no dependency)
  • Alert someone else and subscribe to subsequent activity from that alert
  • Alert and realize own dependency on that task being completed

Anyway, that’s my brain dump on the matter of activity streams. How are you using them in your user experiences (UX)? How are you helping your users avoid information overload?

Recall this message

Instead of recalling messages, delay their delivery long enough to confirm they’re truly right to send in the first place.

While reviewing my flagged and annotated items in Omea, I was reminded of Scott Hanselman’s post on Outlook’s “Recall this message” function being naive. When I first flagged Scott’s post, I annotated it to remember its familiarity with a post by Chris Sells some time before. Later, Lars Bergstrom shared a Outlook rule idea with Chris that Chris captured here.

Along with Scott, Chris and Lars, an effective delay rule is priceless and more importantly more reliable, effective and professional. Recommended!