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?-Craig