[ckan-dev] RFC: Activity streams on-site and email notifications

[Sean Hammond]

> OK, here's my thoughts on the ideal user experience for activity
> stream number badge newness thing:
> 
> Private activity streams Should track what the user has seen. It
> should be handled on page request, except on the notifications
> activity stream. Which requires action to 'un-new' an activity item.
> Each different view should have it's own 'seen' context. For example:
> a 'seen' activity item in the dashboard feed should not mean that they
> have 'seen' it in any other private feeds (e.g. notifications).
> 
> Public activity streams Should not track what the user has seen. These
> are: user public profiles, group/org public pages, etc.
> 
> This probably means that simply tracking by timestamp is not enough.
> However tracking by timestamp + view does work.
> 
> Does that make sense?

When you say "notifications activity stream" do you mean email
notifications? I think you're thinking of notifications as an activity
stream, whereas I'm thinking of email notifications and activity streams
as two distinct features, although one type of notification (the only
type of notification, at least at first) that we send are
"new activity in your private activity stream" notifications.

I think we're on the same page though if slightly different terminology.

> As a footnote I wrote a specification document on which activity items
> should appear in which views and which ones should be grouped. It's
> here for reference:
> https://docs.google.com/document/d/1VMJ00b3Eao07vbHTVGuYyKAeCWcA0Pm66hJiL-hQCsU/edit

This is useful, I'm implementing the group following now, and then I'll
have to change the contents of the group activity streams to make them
more interesting.