[Proposal] Notifications - Round 2

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Proposal] Notifications - Round 2

Guillaume Delhumeau
Hello everybody.

*TL;DR:* Notifications are nothing but standard Events from the Observation
Manager, marked as "Storable" and stored by
the Event Stream. They can be displayed in the top bar of the wiki and/or
sent by e-mails periodically. Since this is
overlapping with the Watchlist features, the idea in the future is to
re-implement the watchlist using the notification
mechanism and to push the current Watchlist module to contrib. Need your
agreement to go in that way.


*Background:*

A few weeks ago I've sent a proposal about the Notifications feature. I've
made some work since, and talked with Vincent
to define a vision.

Let me introduce you what I've already done and what I'm going to do in the
following days:

* I am going to introduce 2 interfaces: *StorableEvent* and
*TargetableEvent* (currently I have only implemented a
  *NotificationEvent* that represent both).

* *StorableEvent*: when an event from the Observation Manager implements
this interface, it means this event will be
                 logged (stored) by the Event Stream.

* *TargetableEvent*: introduce a list of "targets", which are the IDs of
the entities who are targeted by this event.
                   Example: when someones replies to your forum topic, an
event called "someone has answered to your
                   topic" is sent with the topic creator as target.

* As I said, storable events are stored by the Event Stream, which is
currently implemented by the Activity Stream
  module. So it means a *StorableEvent* is currently stored as an
*ActivityEvent* but this remains technical and not visible
  from the outside.

* I have introduced the role *StorableEventConverter* which convert a
*StorableEvent* to an Event from the Event Stream.
  Each application can provide its own converter (to store additional
parameters for example) but there a default one
  that is used if nothing else is defined.
  See:
https://github.com/xwiki/xwiki-platform/blob/e5a3cc7b6a5cbe82b1668d9d30fbf6a61b026046/xwiki-platform-core/xwiki-platform-eventstream/src/main/java/org/xwiki/eventstream/NotificationConverter.java#L36-L36

* I have added the "target" field (a list of string) to the Event and the
*ActivityEvent* classes. I have also updated the
  hibernate mapping for *ActivityEventImpl* accordingly.
  See:
https://github.com/xwiki/xwiki-platform/blob/81172b2dfd994ddd727efe93daf8fa446dc4abce/xwiki-platform-core/xwiki-platform-activitystream/xwiki-platform-activitystream-api/src/main/resources/activitystream.hbm.xml#L63-L63

* I have introduced an *EventStatus* class (and *ActivityStatusImpl*) to
store in the wiki which notifications has been seen
  by a specified user. This is important because we want to distinguish new
notifications from those the user have
  marked as read. Hibernate mapping has been updated as well in the
Activity Stream module.
  See:
https://github.com/xwiki/xwiki-platform/blob/e5a3cc7b6a5cbe82b1668d9d30fbf6a61b026046/xwiki-platform-core/xwiki-platform-eventstream/src/main/java/org/xwiki/eventstream/EventStatus.java#L25-L25
  See:
https://github.com/xwiki/xwiki-platform/blob/81172b2dfd994ddd727efe93daf8fa446dc4abce/xwiki-platform-core/xwiki-platform-activitystream/xwiki-platform-activitystream-api/src/main/resources/activitystream.hbm.xml#L69-L69

* I am going to introduce the *StorableEventDescriptor* role. The
components will give some meta-information about a
  storable event: the pretty name of the event, the application that can
send it and a short text giving a description
  about the event. We need this to expose to the user the list of events
that she can subscribe to.
  (Right now I have implemented this as XObjects called "*NotificationType*"
which is an error)

* I have introduced the concept of NotificationPreference. It's an XObject
stored in the user profile. When a user wants
  to subscribe to a particular type of event, this xobject is created with
the id of the event and the media used for
  the notification ('web notification', 'email' or both).

  In the future, this preferences should handle some more precise filters.
Like: "I am interested in the notifcations
  sent by the Forum Application but only when it comes from the wiki A and
not the wiki B."

* I have introduced the role *NotificationDisplayer*. It's a component that
generates the XDOM to display in the
  notifications menu. Each application can implement its own displayer, but
failback to a default one.

* The *DefaultNotificationDisplayer* tries to render the template
'notifications/{eventType}.vm' and failback to
  'notifications/default.vm'. It means you can create your own displayer
either by implementing a custom
  *NotificationDisplayer* or by creating a template in the right location.

* The *NotificationManager* is responsible for getting the notifications
for the current user, according to its
  preferences.

* I have implemented a UI which load the notification asynchronously and
display them in the notification menu, just
  below the watchlist options.
  See:
http://jira.xwiki.org/secure/attachment/33586/WIP-NotificationsMenu.png

* Unread notifications are displayed with a different styling that others.

* The user has the ability to mark a notification as read.

* I have implemented a preferences page in the user profile, which list all
*StorableEventDescriptor*.
  See:
http://jira.xwiki.org/secure/attachment/33587/WIP-NotificationsPreferences.png

* As a proof of concept, I am going to make the Blog Application send some
custom events that will be displayed in the
  notifications menu.

Problems:

* We clearly have some overlapping of concerns with the Watchlist. The UI
is even very bad since the Watchlist options
  are displayed in the same "bell" menu than the notifications without
being connected together. It's confusing.

* That is why we propose, with Vincent, to remove the Watchlist as it is,
and re-implement its feature using the
  notifications abilities.

* The email sending is not implemented yet, and will not for the 9.2
release.

* We don't have a filter to not display similar notifications. For example,
a user saving a document 10 times in 10
  minutes will generate 10 notifications. Possible flooding.

* When a user registers, all the notifications that are stored since the
beginning of the wiki are unread by her. It
  does not make sense to tell her "you have 1 000 000 000 unread
notifications" so we need to store a starting date for
  each user.

Do you see any problem with that vision?

Thanks you,

--
Guillaume Delhumeau ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal] Notifications - Round 2

Thomas Mortagne
Administrator
On Wed, Mar 8, 2017 at 11:55 AM, Guillaume Delhumeau
<[hidden email]> wrote:

> Hello everybody.
>
> *TL;DR:* Notifications are nothing but standard Events from the Observation
> Manager, marked as "Storable" and stored by
> the Event Stream. They can be displayed in the top bar of the wiki and/or
> sent by e-mails periodically. Since this is
> overlapping with the Watchlist features, the idea in the future is to
> re-implement the watchlist using the notification
> mechanism and to push the current Watchlist module to contrib. Need your
> agreement to go in that way.
>
>
> *Background:*
>
> A few weeks ago I've sent a proposal about the Notifications feature. I've
> made some work since, and talked with Vincent
> to define a vision.
>
> Let me introduce you what I've already done and what I'm going to do in the
> following days:
>
> * I am going to introduce 2 interfaces: *StorableEvent* and
> *TargetableEvent* (currently I have only implemented a
>   *NotificationEvent* that represent both).
>
> * *StorableEvent*: when an event from the Observation Manager implements
> this interface, it means this event will be
>                  logged (stored) by the Event Stream.
>
> * *TargetableEvent*: introduce a list of "targets", which are the IDs of
> the entities who are targeted by this event.
>                    Example: when someones replies to your forum topic, an
> event called "someone has answered to your
>                    topic" is sent with the topic creator as target.
>
> * As I said, storable events are stored by the Event Stream, which is
> currently implemented by the Activity Stream
>   module. So it means a *StorableEvent* is currently stored as an
> *ActivityEvent* but this remains technical and not visible
>   from the outside.
>
> * I have introduced the role *StorableEventConverter* which convert a
> *StorableEvent* to an Event from the Event Stream.
>   Each application can provide its own converter (to store additional
> parameters for example) but there a default one
>   that is used if nothing else is defined.
>   See:
> https://github.com/xwiki/xwiki-platform/blob/e5a3cc7b6a5cbe82b1668d9d30fbf6a61b026046/xwiki-platform-core/xwiki-platform-eventstream/src/main/java/org/xwiki/eventstream/NotificationConverter.java#L36-L36
>
> * I have added the "target" field (a list of string) to the Event and the
> *ActivityEvent* classes. I have also updated the
>   hibernate mapping for *ActivityEventImpl* accordingly.
>   See:
> https://github.com/xwiki/xwiki-platform/blob/81172b2dfd994ddd727efe93daf8fa446dc4abce/xwiki-platform-core/xwiki-platform-activitystream/xwiki-platform-activitystream-api/src/main/resources/activitystream.hbm.xml#L63-L63
>
> * I have introduced an *EventStatus* class (and *ActivityStatusImpl*) to
> store in the wiki which notifications has been seen
>   by a specified user. This is important because we want to distinguish new
> notifications from those the user have
>   marked as read. Hibernate mapping has been updated as well in the
> Activity Stream module.
>   See:
> https://github.com/xwiki/xwiki-platform/blob/e5a3cc7b6a5cbe82b1668d9d30fbf6a61b026046/xwiki-platform-core/xwiki-platform-eventstream/src/main/java/org/xwiki/eventstream/EventStatus.java#L25-L25
>   See:
> https://github.com/xwiki/xwiki-platform/blob/81172b2dfd994ddd727efe93daf8fa446dc4abce/xwiki-platform-core/xwiki-platform-activitystream/xwiki-platform-activitystream-api/src/main/resources/activitystream.hbm.xml#L69-L69
>
> * I am going to introduce the *StorableEventDescriptor* role. The
> components will give some meta-information about a
>   storable event: the pretty name of the event, the application that can
> send it and a short text giving a description
>   about the event. We need this to expose to the user the list of events
> that she can subscribe to.
>   (Right now I have implemented this as XObjects called "*NotificationType*"
> which is an error)
>
> * I have introduced the concept of NotificationPreference. It's an XObject
> stored in the user profile. When a user wants
>   to subscribe to a particular type of event, this xobject is created with
> the id of the event and the media used for
>   the notification ('web notification', 'email' or both).
>
>   In the future, this preferences should handle some more precise filters.
> Like: "I am interested in the notifcations
>   sent by the Forum Application but only when it comes from the wiki A and
> not the wiki B."
>
> * I have introduced the role *NotificationDisplayer*. It's a component that
> generates the XDOM to display in the
>   notifications menu. Each application can implement its own displayer, but
> failback to a default one.
>
> * The *DefaultNotificationDisplayer* tries to render the template
> 'notifications/{eventType}.vm' and failback to
>   'notifications/default.vm'. It means you can create your own displayer
> either by implementing a custom
>   *NotificationDisplayer* or by creating a template in the right location.
>
> * The *NotificationManager* is responsible for getting the notifications
> for the current user, according to its
>   preferences.
>
> * I have implemented a UI which load the notification asynchronously and
> display them in the notification menu, just
>   below the watchlist options.
>   See:
> http://jira.xwiki.org/secure/attachment/33586/WIP-NotificationsMenu.png
>
> * Unread notifications are displayed with a different styling that others.
>
> * The user has the ability to mark a notification as read.
>
> * I have implemented a preferences page in the user profile, which list all
> *StorableEventDescriptor*.
>   See:
> http://jira.xwiki.org/secure/attachment/33587/WIP-NotificationsPreferences.png
>
> * As a proof of concept, I am going to make the Blog Application send some
> custom events that will be displayed in the
>   notifications menu.
>
> Problems:
>
> * We clearly have some overlapping of concerns with the Watchlist. The UI
> is even very bad since the Watchlist options
>   are displayed in the same "bell" menu than the notifications without
> being connected together. It's confusing.
>
> * That is why we propose, with Vincent, to remove the Watchlist as it is,
> and re-implement its feature using the
>   notifications abilities.
>
> * The email sending is not implemented yet, and will not for the 9.2
> release.
>
> * We don't have a filter to not display similar notifications. For example,
> a user saving a document 10 times in 10
>   minutes will generate 10 notifications. Possible flooding.
>
> * When a user registers, all the notifications that are stored since the
> beginning of the wiki are unread by her. It
>   does not make sense to tell her "you have 1 000 000 000 unread
> notifications" so we need to store a starting date for
>   each user.

You already have a starting date in each profile, the profile page
creation date.

>
> Do you see any problem with that vision?
>
> Thanks you,
>
> --
> Guillaume Delhumeau ([hidden email])
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project



--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal] Notifications - Round 2

Guillaume Delhumeau
Sure but it won't work when you upgrade an old wiki with users created
years ago. We would still end up with thousands of unread notifications.

2017-03-08 12:07 GMT+01:00 Thomas Mortagne <[hidden email]>:

> On Wed, Mar 8, 2017 at 11:55 AM, Guillaume Delhumeau
> <[hidden email]> wrote:
> > Hello everybody.
> >
> > *TL;DR:* Notifications are nothing but standard Events from the
> Observation
> > Manager, marked as "Storable" and stored by
> > the Event Stream. They can be displayed in the top bar of the wiki and/or
> > sent by e-mails periodically. Since this is
> > overlapping with the Watchlist features, the idea in the future is to
> > re-implement the watchlist using the notification
> > mechanism and to push the current Watchlist module to contrib. Need your
> > agreement to go in that way.
> >
> >
> > *Background:*
> >
> > A few weeks ago I've sent a proposal about the Notifications feature.
> I've
> > made some work since, and talked with Vincent
> > to define a vision.
> >
> > Let me introduce you what I've already done and what I'm going to do in
> the
> > following days:
> >
> > * I am going to introduce 2 interfaces: *StorableEvent* and
> > *TargetableEvent* (currently I have only implemented a
> >   *NotificationEvent* that represent both).
> >
> > * *StorableEvent*: when an event from the Observation Manager implements
> > this interface, it means this event will be
> >                  logged (stored) by the Event Stream.
> >
> > * *TargetableEvent*: introduce a list of "targets", which are the IDs of
> > the entities who are targeted by this event.
> >                    Example: when someones replies to your forum topic, an
> > event called "someone has answered to your
> >                    topic" is sent with the topic creator as target.
> >
> > * As I said, storable events are stored by the Event Stream, which is
> > currently implemented by the Activity Stream
> >   module. So it means a *StorableEvent* is currently stored as an
> > *ActivityEvent* but this remains technical and not visible
> >   from the outside.
> >
> > * I have introduced the role *StorableEventConverter* which convert a
> > *StorableEvent* to an Event from the Event Stream.
> >   Each application can provide its own converter (to store additional
> > parameters for example) but there a default one
> >   that is used if nothing else is defined.
> >   See:
> > https://github.com/xwiki/xwiki-platform/blob/
> e5a3cc7b6a5cbe82b1668d9d30fbf6a61b026046/xwiki-platform-
> core/xwiki-platform-eventstream/src/main/java/org/xwiki/eventstream/
> NotificationConverter.java#L36-L36
> >
> > * I have added the "target" field (a list of string) to the Event and the
> > *ActivityEvent* classes. I have also updated the
> >   hibernate mapping for *ActivityEventImpl* accordingly.
> >   See:
> > https://github.com/xwiki/xwiki-platform/blob/
> 81172b2dfd994ddd727efe93daf8fa446dc4abce/xwiki-platform-
> core/xwiki-platform-activitystream/xwiki-platform-
> activitystream-api/src/main/resources/activitystream.hbm.xml#L63-L63
> >
> > * I have introduced an *EventStatus* class (and *ActivityStatusImpl*) to
> > store in the wiki which notifications has been seen
> >   by a specified user. This is important because we want to distinguish
> new
> > notifications from those the user have
> >   marked as read. Hibernate mapping has been updated as well in the
> > Activity Stream module.
> >   See:
> > https://github.com/xwiki/xwiki-platform/blob/
> e5a3cc7b6a5cbe82b1668d9d30fbf6a61b026046/xwiki-platform-
> core/xwiki-platform-eventstream/src/main/java/org/
> xwiki/eventstream/EventStatus.java#L25-L25
> >   See:
> > https://github.com/xwiki/xwiki-platform/blob/
> 81172b2dfd994ddd727efe93daf8fa446dc4abce/xwiki-platform-
> core/xwiki-platform-activitystream/xwiki-platform-
> activitystream-api/src/main/resources/activitystream.hbm.xml#L69-L69
> >
> > * I am going to introduce the *StorableEventDescriptor* role. The
> > components will give some meta-information about a
> >   storable event: the pretty name of the event, the application that can
> > send it and a short text giving a description
> >   about the event. We need this to expose to the user the list of events
> > that she can subscribe to.
> >   (Right now I have implemented this as XObjects called
> "*NotificationType*"
> > which is an error)
> >
> > * I have introduced the concept of NotificationPreference. It's an
> XObject
> > stored in the user profile. When a user wants
> >   to subscribe to a particular type of event, this xobject is created
> with
> > the id of the event and the media used for
> >   the notification ('web notification', 'email' or both).
> >
> >   In the future, this preferences should handle some more precise
> filters.
> > Like: "I am interested in the notifcations
> >   sent by the Forum Application but only when it comes from the wiki A
> and
> > not the wiki B."
> >
> > * I have introduced the role *NotificationDisplayer*. It's a component
> that
> > generates the XDOM to display in the
> >   notifications menu. Each application can implement its own displayer,
> but
> > failback to a default one.
> >
> > * The *DefaultNotificationDisplayer* tries to render the template
> > 'notifications/{eventType}.vm' and failback to
> >   'notifications/default.vm'. It means you can create your own displayer
> > either by implementing a custom
> >   *NotificationDisplayer* or by creating a template in the right
> location.
> >
> > * The *NotificationManager* is responsible for getting the notifications
> > for the current user, according to its
> >   preferences.
> >
> > * I have implemented a UI which load the notification asynchronously and
> > display them in the notification menu, just
> >   below the watchlist options.
> >   See:
> > http://jira.xwiki.org/secure/attachment/33586/WIP-NotificationsMenu.png
> >
> > * Unread notifications are displayed with a different styling that
> others.
> >
> > * The user has the ability to mark a notification as read.
> >
> > * I have implemented a preferences page in the user profile, which list
> all
> > *StorableEventDescriptor*.
> >   See:
> > http://jira.xwiki.org/secure/attachment/33587/WIP-
> NotificationsPreferences.png
> >
> > * As a proof of concept, I am going to make the Blog Application send
> some
> > custom events that will be displayed in the
> >   notifications menu.
> >
> > Problems:
> >
> > * We clearly have some overlapping of concerns with the Watchlist. The UI
> > is even very bad since the Watchlist options
> >   are displayed in the same "bell" menu than the notifications without
> > being connected together. It's confusing.
> >
> > * That is why we propose, with Vincent, to remove the Watchlist as it is,
> > and re-implement its feature using the
> >   notifications abilities.
> >
> > * The email sending is not implemented yet, and will not for the 9.2
> > release.
> >
> > * We don't have a filter to not display similar notifications. For
> example,
> > a user saving a document 10 times in 10
> >   minutes will generate 10 notifications. Possible flooding.
> >
> > * When a user registers, all the notifications that are stored since the
> > beginning of the wiki are unread by her. It
> >   does not make sense to tell her "you have 1 000 000 000 unread
> > notifications" so we need to store a starting date for
> >   each user.
>
> You already have a starting date in each profile, the profile page
> creation date.
>
> >
> > Do you see any problem with that vision?
> >
> > Thanks you,
> >
> > --
> > Guillaume Delhumeau ([hidden email])
> > Research & Development Engineer at XWiki SAS
> > Committer on the XWiki.org project
>
>
>
> --
> Thomas Mortagne
>



--
Guillaume Delhumeau ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal] Notifications - Round 2

Thomas Mortagne
Administrator
On Wed, Mar 8, 2017 at 12:27 PM, Guillaume Delhumeau
<[hidden email]> wrote:
> Sure but it won't work when you upgrade an old wiki with users created
> years ago. We would still end up with thousands of unread notifications.

Which notifications ? You will start getting new notifications only
when you have new notification system, no ?

>
> 2017-03-08 12:07 GMT+01:00 Thomas Mortagne <[hidden email]>:
>
>> On Wed, Mar 8, 2017 at 11:55 AM, Guillaume Delhumeau
>> <[hidden email]> wrote:
>> > Hello everybody.
>> >
>> > *TL;DR:* Notifications are nothing but standard Events from the
>> Observation
>> > Manager, marked as "Storable" and stored by
>> > the Event Stream. They can be displayed in the top bar of the wiki and/or
>> > sent by e-mails periodically. Since this is
>> > overlapping with the Watchlist features, the idea in the future is to
>> > re-implement the watchlist using the notification
>> > mechanism and to push the current Watchlist module to contrib. Need your
>> > agreement to go in that way.
>> >
>> >
>> > *Background:*
>> >
>> > A few weeks ago I've sent a proposal about the Notifications feature.
>> I've
>> > made some work since, and talked with Vincent
>> > to define a vision.
>> >
>> > Let me introduce you what I've already done and what I'm going to do in
>> the
>> > following days:
>> >
>> > * I am going to introduce 2 interfaces: *StorableEvent* and
>> > *TargetableEvent* (currently I have only implemented a
>> >   *NotificationEvent* that represent both).
>> >
>> > * *StorableEvent*: when an event from the Observation Manager implements
>> > this interface, it means this event will be
>> >                  logged (stored) by the Event Stream.
>> >
>> > * *TargetableEvent*: introduce a list of "targets", which are the IDs of
>> > the entities who are targeted by this event.
>> >                    Example: when someones replies to your forum topic, an
>> > event called "someone has answered to your
>> >                    topic" is sent with the topic creator as target.
>> >
>> > * As I said, storable events are stored by the Event Stream, which is
>> > currently implemented by the Activity Stream
>> >   module. So it means a *StorableEvent* is currently stored as an
>> > *ActivityEvent* but this remains technical and not visible
>> >   from the outside.
>> >
>> > * I have introduced the role *StorableEventConverter* which convert a
>> > *StorableEvent* to an Event from the Event Stream.
>> >   Each application can provide its own converter (to store additional
>> > parameters for example) but there a default one
>> >   that is used if nothing else is defined.
>> >   See:
>> > https://github.com/xwiki/xwiki-platform/blob/
>> e5a3cc7b6a5cbe82b1668d9d30fbf6a61b026046/xwiki-platform-
>> core/xwiki-platform-eventstream/src/main/java/org/xwiki/eventstream/
>> NotificationConverter.java#L36-L36
>> >
>> > * I have added the "target" field (a list of string) to the Event and the
>> > *ActivityEvent* classes. I have also updated the
>> >   hibernate mapping for *ActivityEventImpl* accordingly.
>> >   See:
>> > https://github.com/xwiki/xwiki-platform/blob/
>> 81172b2dfd994ddd727efe93daf8fa446dc4abce/xwiki-platform-
>> core/xwiki-platform-activitystream/xwiki-platform-
>> activitystream-api/src/main/resources/activitystream.hbm.xml#L63-L63
>> >
>> > * I have introduced an *EventStatus* class (and *ActivityStatusImpl*) to
>> > store in the wiki which notifications has been seen
>> >   by a specified user. This is important because we want to distinguish
>> new
>> > notifications from those the user have
>> >   marked as read. Hibernate mapping has been updated as well in the
>> > Activity Stream module.
>> >   See:
>> > https://github.com/xwiki/xwiki-platform/blob/
>> e5a3cc7b6a5cbe82b1668d9d30fbf6a61b026046/xwiki-platform-
>> core/xwiki-platform-eventstream/src/main/java/org/
>> xwiki/eventstream/EventStatus.java#L25-L25
>> >   See:
>> > https://github.com/xwiki/xwiki-platform/blob/
>> 81172b2dfd994ddd727efe93daf8fa446dc4abce/xwiki-platform-
>> core/xwiki-platform-activitystream/xwiki-platform-
>> activitystream-api/src/main/resources/activitystream.hbm.xml#L69-L69
>> >
>> > * I am going to introduce the *StorableEventDescriptor* role. The
>> > components will give some meta-information about a
>> >   storable event: the pretty name of the event, the application that can
>> > send it and a short text giving a description
>> >   about the event. We need this to expose to the user the list of events
>> > that she can subscribe to.
>> >   (Right now I have implemented this as XObjects called
>> "*NotificationType*"
>> > which is an error)
>> >
>> > * I have introduced the concept of NotificationPreference. It's an
>> XObject
>> > stored in the user profile. When a user wants
>> >   to subscribe to a particular type of event, this xobject is created
>> with
>> > the id of the event and the media used for
>> >   the notification ('web notification', 'email' or both).
>> >
>> >   In the future, this preferences should handle some more precise
>> filters.
>> > Like: "I am interested in the notifcations
>> >   sent by the Forum Application but only when it comes from the wiki A
>> and
>> > not the wiki B."
>> >
>> > * I have introduced the role *NotificationDisplayer*. It's a component
>> that
>> > generates the XDOM to display in the
>> >   notifications menu. Each application can implement its own displayer,
>> but
>> > failback to a default one.
>> >
>> > * The *DefaultNotificationDisplayer* tries to render the template
>> > 'notifications/{eventType}.vm' and failback to
>> >   'notifications/default.vm'. It means you can create your own displayer
>> > either by implementing a custom
>> >   *NotificationDisplayer* or by creating a template in the right
>> location.
>> >
>> > * The *NotificationManager* is responsible for getting the notifications
>> > for the current user, according to its
>> >   preferences.
>> >
>> > * I have implemented a UI which load the notification asynchronously and
>> > display them in the notification menu, just
>> >   below the watchlist options.
>> >   See:
>> > http://jira.xwiki.org/secure/attachment/33586/WIP-NotificationsMenu.png
>> >
>> > * Unread notifications are displayed with a different styling that
>> others.
>> >
>> > * The user has the ability to mark a notification as read.
>> >
>> > * I have implemented a preferences page in the user profile, which list
>> all
>> > *StorableEventDescriptor*.
>> >   See:
>> > http://jira.xwiki.org/secure/attachment/33587/WIP-
>> NotificationsPreferences.png
>> >
>> > * As a proof of concept, I am going to make the Blog Application send
>> some
>> > custom events that will be displayed in the
>> >   notifications menu.
>> >
>> > Problems:
>> >
>> > * We clearly have some overlapping of concerns with the Watchlist. The UI
>> > is even very bad since the Watchlist options
>> >   are displayed in the same "bell" menu than the notifications without
>> > being connected together. It's confusing.
>> >
>> > * That is why we propose, with Vincent, to remove the Watchlist as it is,
>> > and re-implement its feature using the
>> >   notifications abilities.
>> >
>> > * The email sending is not implemented yet, and will not for the 9.2
>> > release.
>> >
>> > * We don't have a filter to not display similar notifications. For
>> example,
>> > a user saving a document 10 times in 10
>> >   minutes will generate 10 notifications. Possible flooding.
>> >
>> > * When a user registers, all the notifications that are stored since the
>> > beginning of the wiki are unread by her. It
>> >   does not make sense to tell her "you have 1 000 000 000 unread
>> > notifications" so we need to store a starting date for
>> >   each user.
>>
>> You already have a starting date in each profile, the profile page
>> creation date.
>>
>> >
>> > Do you see any problem with that vision?
>> >
>> > Thanks you,
>> >
>> > --
>> > Guillaume Delhumeau ([hidden email])
>> > Research & Development Engineer at XWiki SAS
>> > Committer on the XWiki.org project
>>
>>
>>
>> --
>> Thomas Mortagne
>>
>
>
>
> --
> Guillaume Delhumeau ([hidden email])
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project



--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal] Notifications - Round 2

Guillaume Delhumeau
Actually, all existing entries in the Activity Stream are considered as
notifications, as soon as there is a descriptor for their type (in my
screenshot, we see only "notifications" that are actually activities from
AS).

I know that existing events do not implement the "StorableEvent" interface,
but all events that are currently saved in AS are de-facto "storable".

Said differently, the notion of notification is merged with the notion of
Event/Activity. The only difference is the way we display them.

2017-03-08 13:31 GMT+01:00 Thomas Mortagne <[hidden email]>:

> On Wed, Mar 8, 2017 at 12:27 PM, Guillaume Delhumeau
> <[hidden email]> wrote:
> > Sure but it won't work when you upgrade an old wiki with users created
> > years ago. We would still end up with thousands of unread notifications.
>
> Which notifications ? You will start getting new notifications only
> when you have new notification system, no ?
>
> >
> > 2017-03-08 12:07 GMT+01:00 Thomas Mortagne <[hidden email]>:
> >
> >> On Wed, Mar 8, 2017 at 11:55 AM, Guillaume Delhumeau
> >> <[hidden email]> wrote:
> >> > Hello everybody.
> >> >
> >> > *TL;DR:* Notifications are nothing but standard Events from the
> >> Observation
> >> > Manager, marked as "Storable" and stored by
> >> > the Event Stream. They can be displayed in the top bar of the wiki
> and/or
> >> > sent by e-mails periodically. Since this is
> >> > overlapping with the Watchlist features, the idea in the future is to
> >> > re-implement the watchlist using the notification
> >> > mechanism and to push the current Watchlist module to contrib. Need
> your
> >> > agreement to go in that way.
> >> >
> >> >
> >> > *Background:*
> >> >
> >> > A few weeks ago I've sent a proposal about the Notifications feature.
> >> I've
> >> > made some work since, and talked with Vincent
> >> > to define a vision.
> >> >
> >> > Let me introduce you what I've already done and what I'm going to do
> in
> >> the
> >> > following days:
> >> >
> >> > * I am going to introduce 2 interfaces: *StorableEvent* and
> >> > *TargetableEvent* (currently I have only implemented a
> >> >   *NotificationEvent* that represent both).
> >> >
> >> > * *StorableEvent*: when an event from the Observation Manager
> implements
> >> > this interface, it means this event will be
> >> >                  logged (stored) by the Event Stream.
> >> >
> >> > * *TargetableEvent*: introduce a list of "targets", which are the IDs
> of
> >> > the entities who are targeted by this event.
> >> >                    Example: when someones replies to your forum
> topic, an
> >> > event called "someone has answered to your
> >> >                    topic" is sent with the topic creator as target.
> >> >
> >> > * As I said, storable events are stored by the Event Stream, which is
> >> > currently implemented by the Activity Stream
> >> >   module. So it means a *StorableEvent* is currently stored as an
> >> > *ActivityEvent* but this remains technical and not visible
> >> >   from the outside.
> >> >
> >> > * I have introduced the role *StorableEventConverter* which convert a
> >> > *StorableEvent* to an Event from the Event Stream.
> >> >   Each application can provide its own converter (to store additional
> >> > parameters for example) but there a default one
> >> >   that is used if nothing else is defined.
> >> >   See:
> >> > https://github.com/xwiki/xwiki-platform/blob/
> >> e5a3cc7b6a5cbe82b1668d9d30fbf6a61b026046/xwiki-platform-
> >> core/xwiki-platform-eventstream/src/main/java/org/xwiki/eventstream/
> >> NotificationConverter.java#L36-L36
> >> >
> >> > * I have added the "target" field (a list of string) to the Event and
> the
> >> > *ActivityEvent* classes. I have also updated the
> >> >   hibernate mapping for *ActivityEventImpl* accordingly.
> >> >   See:
> >> > https://github.com/xwiki/xwiki-platform/blob/
> >> 81172b2dfd994ddd727efe93daf8fa446dc4abce/xwiki-platform-
> >> core/xwiki-platform-activitystream/xwiki-platform-
> >> activitystream-api/src/main/resources/activitystream.hbm.xml#L63-L63
> >> >
> >> > * I have introduced an *EventStatus* class (and *ActivityStatusImpl*)
> to
> >> > store in the wiki which notifications has been seen
> >> >   by a specified user. This is important because we want to
> distinguish
> >> new
> >> > notifications from those the user have
> >> >   marked as read. Hibernate mapping has been updated as well in the
> >> > Activity Stream module.
> >> >   See:
> >> > https://github.com/xwiki/xwiki-platform/blob/
> >> e5a3cc7b6a5cbe82b1668d9d30fbf6a61b026046/xwiki-platform-
> >> core/xwiki-platform-eventstream/src/main/java/org/
> >> xwiki/eventstream/EventStatus.java#L25-L25
> >> >   See:
> >> > https://github.com/xwiki/xwiki-platform/blob/
> >> 81172b2dfd994ddd727efe93daf8fa446dc4abce/xwiki-platform-
> >> core/xwiki-platform-activitystream/xwiki-platform-
> >> activitystream-api/src/main/resources/activitystream.hbm.xml#L69-L69
> >> >
> >> > * I am going to introduce the *StorableEventDescriptor* role. The
> >> > components will give some meta-information about a
> >> >   storable event: the pretty name of the event, the application that
> can
> >> > send it and a short text giving a description
> >> >   about the event. We need this to expose to the user the list of
> events
> >> > that she can subscribe to.
> >> >   (Right now I have implemented this as XObjects called
> >> "*NotificationType*"
> >> > which is an error)
> >> >
> >> > * I have introduced the concept of NotificationPreference. It's an
> >> XObject
> >> > stored in the user profile. When a user wants
> >> >   to subscribe to a particular type of event, this xobject is created
> >> with
> >> > the id of the event and the media used for
> >> >   the notification ('web notification', 'email' or both).
> >> >
> >> >   In the future, this preferences should handle some more precise
> >> filters.
> >> > Like: "I am interested in the notifcations
> >> >   sent by the Forum Application but only when it comes from the wiki A
> >> and
> >> > not the wiki B."
> >> >
> >> > * I have introduced the role *NotificationDisplayer*. It's a component
> >> that
> >> > generates the XDOM to display in the
> >> >   notifications menu. Each application can implement its own
> displayer,
> >> but
> >> > failback to a default one.
> >> >
> >> > * The *DefaultNotificationDisplayer* tries to render the template
> >> > 'notifications/{eventType}.vm' and failback to
> >> >   'notifications/default.vm'. It means you can create your own
> displayer
> >> > either by implementing a custom
> >> >   *NotificationDisplayer* or by creating a template in the right
> >> location.
> >> >
> >> > * The *NotificationManager* is responsible for getting the
> notifications
> >> > for the current user, according to its
> >> >   preferences.
> >> >
> >> > * I have implemented a UI which load the notification asynchronously
> and
> >> > display them in the notification menu, just
> >> >   below the watchlist options.
> >> >   See:
> >> > http://jira.xwiki.org/secure/attachment/33586/WIP-Notificati
> onsMenu.png
> >> >
> >> > * Unread notifications are displayed with a different styling that
> >> others.
> >> >
> >> > * The user has the ability to mark a notification as read.
> >> >
> >> > * I have implemented a preferences page in the user profile, which
> list
> >> all
> >> > *StorableEventDescriptor*.
> >> >   See:
> >> > http://jira.xwiki.org/secure/attachment/33587/WIP-
> >> NotificationsPreferences.png
> >> >
> >> > * As a proof of concept, I am going to make the Blog Application send
> >> some
> >> > custom events that will be displayed in the
> >> >   notifications menu.
> >> >
> >> > Problems:
> >> >
> >> > * We clearly have some overlapping of concerns with the Watchlist.
> The UI
> >> > is even very bad since the Watchlist options
> >> >   are displayed in the same "bell" menu than the notifications without
> >> > being connected together. It's confusing.
> >> >
> >> > * That is why we propose, with Vincent, to remove the Watchlist as it
> is,
> >> > and re-implement its feature using the
> >> >   notifications abilities.
> >> >
> >> > * The email sending is not implemented yet, and will not for the 9.2
> >> > release.
> >> >
> >> > * We don't have a filter to not display similar notifications. For
> >> example,
> >> > a user saving a document 10 times in 10
> >> >   minutes will generate 10 notifications. Possible flooding.
> >> >
> >> > * When a user registers, all the notifications that are stored since
> the
> >> > beginning of the wiki are unread by her. It
> >> >   does not make sense to tell her "you have 1 000 000 000 unread
> >> > notifications" so we need to store a starting date for
> >> >   each user.
> >>
> >> You already have a starting date in each profile, the profile page
> >> creation date.
> >>
> >> >
> >> > Do you see any problem with that vision?
> >> >
> >> > Thanks you,
> >> >
> >> > --
> >> > Guillaume Delhumeau ([hidden email])
> >> > Research & Development Engineer at XWiki SAS
> >> > Committer on the XWiki.org project
> >>
> >>
> >>
> >> --
> >> Thomas Mortagne
> >>
> >
> >
> >
> > --
> > Guillaume Delhumeau ([hidden email])
> > Research & Development Engineer at XWiki SAS
> > Committer on the XWiki.org project
>
>
>
> --
> Thomas Mortagne
>



--
Guillaume Delhumeau ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Loading...