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

Tue Oct 23 12:45:03 UTC 2012

Hullo,

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?

.jm

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

On Tuesday, 23 October 2012 at 12:46, Sven R. Kunze wrote:

> On Tue, 23 Oct 2012 13:33:21 +0200, Sean Hammond <sean.hammond at okfn.org (mailto:sean.hammond at okfn.org)> 
> wrote:
> 
> > > One issue here might be that users have different activity streams
> > > to look at. So it would be rather nice to know which activity stream
> > > I have looked at since when.
> > > 
> > 
> > Hi Sven, I can see what you're getting at here, but I think we only want
> > to track unseen activities for the user's dashboard activity stream,
> > i.e. the private activity stream that she controls the contents of by
> > following and unfollowing things, and not for all the other public
> > activity streams on the site.
> > 
> 
> 
> Hi Sean,
> 
> sorry, I didn't point it out correctly. I was not talking about public 
> activity streams. I was referring to personal activity streams such as 
> activity streams for followees and subscriptions. I thought John already 
> have a spec for them. So, it might be prudent to let him answer this, to 
> see how it makes sense for the UX to have several bubbles and therefore 
> several timestamps in the db.
> When there is only one timestamp, just logging in (because the user will 
> be redirected to dashboard immediately) will cause all bubbles to 
> disappear.
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20121023/b56eee92/attachment-0001.html>