Activity Stream Refactoring 6.2 Focus and separation of concerns

Last modified by Ecaterina Moraru (Valica) on 2018/07/12 16:23

 Requirements
 Dormant
 
 

[xwiki-devs] Alternative Activity Stream experiment - http://markmail.org/thread/4y7uchppqq7clgpd (Jun 3, 2013)
[xwiki-devs] [Proposal][UX] Recent Changes Improvements - http://xwiki.markmail.org/thread/jcnlii4v4c4qdwx4 (Aug 30, 2010)

 

Initial proposals of how to display events in AS - ActivityStreamReviews

Description

There should be a clear separation between the tasks that approach the user's attention in XWiki, primarily at the UI level and secondarily at the implementation level. The current implementation tries to mix everything (both UI and implementation) into a single mammoth that suffers from poor performance and confuses users to the point where it ends up not being used at all.

The clearer separation should consist of the following:

  • Notifications for "system-to-user" messages
    • Either XWiki itself or one of its applications is trying to communicate with the user
    • Persistent or expirable (temporary with an application-configured deadline) private messages
    • Read/Unread status
  • Messages for user-to-user messages
    • Persistent and private messages
    • Read/Unread status
  • Activity Stream for a flow of user generated actions
    • Displaying C(reate)U(pdate)D(elete) activities on XWiki's model or on the entries of applications
    • User statuses are just entries of the User Status application, being displayed on the activity stream.
    • Temporary, not vital events that can be overlooked

As it can easily be observed, from an implementation POV and depending on the sender, messages and notifications can be seens as the same back-end feature, with two separate UIs. However, AS handles a different type of events and it should not be mixed with the other two.

Agreeing that AS should only handle and display user generated activities based on CRUD operations, we also need to consider the current implementation`s focus when displaying these events.

There are two or three (depends how you see it) approaches to Activity Stream that we have considered until now:

  • User centered
    • Demo: http://design.xwiki.org/xwiki/bin/view/Main/ActivityUserCentered
    • Facebook-style display where we see the 1) User, 2) the action he performed and 3) the result, location or object of his action.
    • This was the original proposal that was made for XWiki's implementation of AS
    • Pros: This seems to be what everybody else is doing as it has a good focus on what is going on in the environment (i.e. wiki). Also, this has the ability to easily display the event's (contextualized) details like a preview for the attached document or of the posted comment, etc. Another advantage is that it can be easily and logically reused in various other locations (and applications) to display the activity for that environment (i.e. using filters), because it does not focus on documents which might not make sense in some apps.
    • Cons: It might be a bit noisy in high-activity environments, as the "stream" of the users' activity might flow too quickly.
  • Page centered/grouped
    • Demo: http://design.xwiki.org/xwiki/bin/view/Main/Activity
    • Content oriented display where you see 1) the content that was modified in a day, and a date-ordered list of [2) users and their 3) actions on that content].
    • This is the current implementation of AS in XWiki
    • Pros: This type of display has the ability to provide an overview over changed content (pages).
    • Cons: It hides the people that did the work. Also, if you want to see people or details, you always end up expanding sections and sections as you drill-down the event details, turning AS not into a "stream" (as the name would imply), but into an Activity "Browser" that requires the user's action/clicks to reveal its contents. Most people are not aware of the full possibilities to expand details and end up seeing partial or not useful information. Not very good for integrating in every environment, as some applications or environments might not be interested in displaying what documents were changed, but might want to focus on the activity of users. The chronology of events is also completely disturbed by such an approach, making it almost impossible to understand the user's actions.
    • Alternate prototype that delivers 90% of the information but with a much better performance:
  • Time centered/grouped
    • Demo: http://design.xwiki.org/xwiki/bin/view/Proposal/ActivityTimeCentered?max=20&delay=20
    • Timeslot oriented display where, in groups defined by a (configurable) 5 minute timeslots, 1) a list of pages is changed by 2) a list of users, each user displayed with 3) the number of changes he did. Each timeslot can then be expanded (directly or through javascript) to show its detailed activities.
    • Some more details: http://markmail.org/thread/4y7uchppqq7clgpd
    • Cons: Same cons as the page centred approach, with the addition that the time grouping will add an extra layer of clutter that will make the first level of displayed information irrelevant for the end-user. Also, the chronology is yet again affected, since events can easily fall in 2 or more timeslots.

 

Tags:
    

Get Connected