[Proposal] Notifications : Add "in-context" switches

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

[Proposal] Notifications : Add "in-context" switches

Guillaume Delhumeau
*TL;DR*

   - Add a button in each page that will allow you to subscribe to all
   events that happens to that page.
   - When you subscribe to a page with this "in-context" bell, it must not
   affect your other preferences regarding notifications.

*Full Post*

Hello developers,

With Clément Aubin, we are implementing new features in the Notifications
Application in order to be able to remove the Watchlist Application.

*Status*

Currently, a user can subscribe to different kinds of events (ex: "update",
"comment", "blog published", etc...). Recently, we have also added the
ability to restrict on which locations we are interested in, for each kind
of events. For example, we are now able to say, "for the *update* event,
show me notifications only about the wiki ABC and for the *blog post*
event, show me notifications only about the space XYZ".

If you have no restriction (a.k.a "filters") on an event type, then you
receive notifications for every event matching the event type in the wiki,
no matter the location of the entity it concerns.

*Objectives*

In the Watchlist Application, we had 3 switches on the top menu that was
displayed on every page, and these switches were "watch this wiki / watch
this space / watch this page". That would be great if we could have the
same for the notifications.

*Proposal*

   - Add the ability to subscribe to all events that happen in a given
   location, no matter their type (≈ what the watchlist does).
   - In each page, add a button to subscribe to the current location:
   https://pasteboard.co/GAqEi6M.png (thanks Caty for the mockup)
   - Problem: if you previously had no restriction, you suddenly add a new
      one that will prevent you to receive any notifications
concerning the other
      locations. A bit like the rights module: adding a right to
someone at some
      level will dismiss rights for all other people. I guess we all
agree it's a
      problem on the User Experience point of view.
      - Proposition: the restriction added by the "in-context" button
      should be *inactive if there is no other restriction enabled manually
      via the notification preferences UI*.
      - Rational:
         - When you are on the notifications preferences, you can actually
            see all restrictions, so you can understand that creating
one will make you
            lose all notifications that do not honor the restrictions.
            - However, when you are on a page, you don't see all the
            restrictions. If you click on the "subscribe" bell
naively, you might not
            expect it will impact all other notifications. It would
actually be very
            confusing.
            - In addition: if we add an "auto-watch" option, that add the
   page you just saved to the list of locations you are interested in, we need
   to have this feature too. Otherwise saving a document will make all other
   notifications silent.

That is our plan. Cast you ideas!

Thanks,

Guillaume
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal] Notifications : Add "in-context" switches

Marius Dumitru Florea
On Tue, Jul 11, 2017 at 7:26 PM, Guillaume Delhumeau <
[hidden email]> wrote:

> *TL;DR*
>
>    - Add a button in each page that will allow you to subscribe to all
>    events that happens to that page.
>    - When you subscribe to a page with this "in-context" bell, it must not
>    affect your other preferences regarding notifications.
>
> *Full Post*
>
> Hello developers,
>
> With Clément Aubin, we are implementing new features in the Notifications
> Application in order to be able to remove the Watchlist Application.
>
> *Status*
>
> Currently, a user can subscribe to different kinds of events (ex: "update",
> "comment", "blog published", etc...). Recently, we have also added the
> ability to restrict on which locations we are interested in, for each kind
> of events. For example, we are now able to say, "for the *update* event,
> show me notifications only about the wiki ABC and for the *blog post*
> event, show me notifications only about the space XYZ".
>
> If you have no restriction (a.k.a "filters") on an event type, then you
> receive notifications for every event matching the event type in the wiki,
> no matter the location of the entity it concerns.
>
> *Objectives*
>
> In the Watchlist Application, we had 3 switches on the top menu that was
> displayed on every page, and these switches were "watch this wiki / watch
> this space / watch this page". That would be great if we could have the
> same for the notifications.
>
> *Proposal*
>
>    - Add the ability to subscribe to all events that happen in a given
>    location, no matter their type (≈ what the watchlist does).
>    - In each page, add a button to subscribe to the current location:
>    https://pasteboard.co/GAqEi6M.png (thanks Caty for the mockup)
>


>    - Problem: if you previously had no restriction, you suddenly add a new
>       one that will prevent you to receive any notifications
> concerning the other
>

Maybe I didn't understood correctly, but if you have no restrictions and
you go to a page A then that page should appear as "watched" because you
are receiving notifications for that page (because you don't have
restrictions). So if the icon is "watched" then clicking on it will toggle
"don't watch". So you are actually removing that page from the list of
watched pages (i.e. you add an exclude).

It all depends on what's the initial state:

(1) receive notifications from everywhere => then when you go to a page you
can exclude it
(2) no notifications => then when you go to a page you can include it

So it depends what you understand by "no restrictions". Either all
notifications or no notifications.

Hope this helps,
Marius


>       locations. A bit like the rights module: adding a right to
> someone at some
>       level will dismiss rights for all other people. I guess we all
> agree it's a
>       problem on the User Experience point of view.
>       - Proposition: the restriction added by the "in-context" button
>       should be *inactive if there is no other restriction enabled manually
>       via the notification preferences UI*.
>       - Rational:
>          - When you are on the notifications preferences, you can actually
>             see all restrictions, so you can understand that creating
> one will make you
>             lose all notifications that do not honor the restrictions.
>             - However, when you are on a page, you don't see all the
>             restrictions. If you click on the "subscribe" bell
> naively, you might not
>             expect it will impact all other notifications. It would
> actually be very
>             confusing.
>             - In addition: if we add an "auto-watch" option, that add the
>    page you just saved to the list of locations you are interested in, we
> need
>    to have this feature too. Otherwise saving a document will make all
> other
>    notifications silent.
>
> That is our plan. Cast you ideas!
>
> Thanks,
>
> Guillaume
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal] Notifications : Add "in-context" switches

Guillaume Delhumeau
It makes sense. Creating an exclude filter is much more natural than the
complicated filter I was proposing...

But in the case of the auto-watch, it could be good to store somewhere the
list of pages where the user has contributed, in order to still include
them even if the user disable the notifications on a larger scope.

2017-07-12 10:57 GMT+02:00 Marius Dumitru Florea <
[hidden email]>:

> On Tue, Jul 11, 2017 at 7:26 PM, Guillaume Delhumeau <
> [hidden email]> wrote:
>
> > *TL;DR*
> >
> >    - Add a button in each page that will allow you to subscribe to all
> >    events that happens to that page.
> >    - When you subscribe to a page with this "in-context" bell, it must
> not
> >    affect your other preferences regarding notifications.
> >
> > *Full Post*
> >
> > Hello developers,
> >
> > With Clément Aubin, we are implementing new features in the Notifications
> > Application in order to be able to remove the Watchlist Application.
> >
> > *Status*
> >
> > Currently, a user can subscribe to different kinds of events (ex:
> "update",
> > "comment", "blog published", etc...). Recently, we have also added the
> > ability to restrict on which locations we are interested in, for each
> kind
> > of events. For example, we are now able to say, "for the *update* event,
> > show me notifications only about the wiki ABC and for the *blog post*
> > event, show me notifications only about the space XYZ".
> >
> > If you have no restriction (a.k.a "filters") on an event type, then you
> > receive notifications for every event matching the event type in the
> wiki,
> > no matter the location of the entity it concerns.
> >
> > *Objectives*
> >
> > In the Watchlist Application, we had 3 switches on the top menu that was
> > displayed on every page, and these switches were "watch this wiki / watch
> > this space / watch this page". That would be great if we could have the
> > same for the notifications.
> >
> > *Proposal*
> >
> >    - Add the ability to subscribe to all events that happen in a given
> >    location, no matter their type (≈ what the watchlist does).
> >    - In each page, add a button to subscribe to the current location:
> >    https://pasteboard.co/GAqEi6M.png (thanks Caty for the mockup)
> >
>
>
> >    - Problem: if you previously had no restriction, you suddenly add a
> new
> >       one that will prevent you to receive any notifications
> > concerning the other
> >
>
> Maybe I didn't understood correctly, but if you have no restrictions and
> you go to a page A then that page should appear as "watched" because you
> are receiving notifications for that page (because you don't have
> restrictions). So if the icon is "watched" then clicking on it will toggle
> "don't watch". So you are actually removing that page from the list of
> watched pages (i.e. you add an exclude).
>
> It all depends on what's the initial state:
>
> (1) receive notifications from everywhere => then when you go to a page you
> can exclude it
> (2) no notifications => then when you go to a page you can include it
>
> So it depends what you understand by "no restrictions". Either all
> notifications or no notifications.
>
> Hope this helps,
> Marius
>
>
> >       locations. A bit like the rights module: adding a right to
> > someone at some
> >       level will dismiss rights for all other people. I guess we all
> > agree it's a
> >       problem on the User Experience point of view.
> >       - Proposition: the restriction added by the "in-context" button
> >       should be *inactive if there is no other restriction enabled
> manually
> >       via the notification preferences UI*.
> >       - Rational:
> >          - When you are on the notifications preferences, you can
> actually
> >             see all restrictions, so you can understand that creating
> > one will make you
> >             lose all notifications that do not honor the restrictions.
> >             - However, when you are on a page, you don't see all the
> >             restrictions. If you click on the "subscribe" bell
> > naively, you might not
> >             expect it will impact all other notifications. It would
> > actually be very
> >             confusing.
> >             - In addition: if we add an "auto-watch" option, that add the
> >    page you just saved to the list of locations you are interested in, we
> > need
> >    to have this feature too. Otherwise saving a document will make all
> > other
> >    notifications silent.
> >
> > That is our plan. Cast you ideas!
> >
> > Thanks,
> >
> > Guillaume
> >
>



--
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 : Add "in-context" switches

Ecaterina Moraru (Valica)
We could have a setting: "watch all locations" or "watch just particular
pages". Further more you have the ability to "watch all events" or play
with the on/off switches.

If the user sets to "just particular pages", than the "watch" icon appears
and we use the include list. Also when setting watch for particular pages,
the user might want to configure the "auto-watch" for the pages he created,
or commented, or edited. Those pages will be automatically added in the
include list, with the possibility to manually remove them from the page
(on the bell icon) or from the watched filters list.

Thanks,
Caty

On Wed, Jul 12, 2017 at 2:26 PM, Guillaume Delhumeau <
[hidden email]> wrote:

> It makes sense. Creating an exclude filter is much more natural than the
> complicated filter I was proposing...
>
> But in the case of the auto-watch, it could be good to store somewhere the
> list of pages where the user has contributed, in order to still include
> them even if the user disable the notifications on a larger scope.
>
> 2017-07-12 10:57 GMT+02:00 Marius Dumitru Florea <
> [hidden email]>:
>
> > On Tue, Jul 11, 2017 at 7:26 PM, Guillaume Delhumeau <
> > [hidden email]> wrote:
> >
> > > *TL;DR*
> > >
> > >    - Add a button in each page that will allow you to subscribe to all
> > >    events that happens to that page.
> > >    - When you subscribe to a page with this "in-context" bell, it must
> > not
> > >    affect your other preferences regarding notifications.
> > >
> > > *Full Post*
> > >
> > > Hello developers,
> > >
> > > With Clément Aubin, we are implementing new features in the
> Notifications
> > > Application in order to be able to remove the Watchlist Application.
> > >
> > > *Status*
> > >
> > > Currently, a user can subscribe to different kinds of events (ex:
> > "update",
> > > "comment", "blog published", etc...). Recently, we have also added the
> > > ability to restrict on which locations we are interested in, for each
> > kind
> > > of events. For example, we are now able to say, "for the *update*
> event,
> > > show me notifications only about the wiki ABC and for the *blog post*
> > > event, show me notifications only about the space XYZ".
> > >
> > > If you have no restriction (a.k.a "filters") on an event type, then you
> > > receive notifications for every event matching the event type in the
> > wiki,
> > > no matter the location of the entity it concerns.
> > >
> > > *Objectives*
> > >
> > > In the Watchlist Application, we had 3 switches on the top menu that
> was
> > > displayed on every page, and these switches were "watch this wiki /
> watch
> > > this space / watch this page". That would be great if we could have the
> > > same for the notifications.
> > >
> > > *Proposal*
> > >
> > >    - Add the ability to subscribe to all events that happen in a given
> > >    location, no matter their type (≈ what the watchlist does).
> > >    - In each page, add a button to subscribe to the current location:
> > >    https://pasteboard.co/GAqEi6M.png (thanks Caty for the mockup)
> > >
> >
> >
> > >    - Problem: if you previously had no restriction, you suddenly add a
> > new
> > >       one that will prevent you to receive any notifications
> > > concerning the other
> > >
> >
> > Maybe I didn't understood correctly, but if you have no restrictions and
> > you go to a page A then that page should appear as "watched" because you
> > are receiving notifications for that page (because you don't have
> > restrictions). So if the icon is "watched" then clicking on it will
> toggle
> > "don't watch". So you are actually removing that page from the list of
> > watched pages (i.e. you add an exclude).
> >
> > It all depends on what's the initial state:
> >
> > (1) receive notifications from everywhere => then when you go to a page
> you
> > can exclude it
> > (2) no notifications => then when you go to a page you can include it
> >
> > So it depends what you understand by "no restrictions". Either all
> > notifications or no notifications.
> >
> > Hope this helps,
> > Marius
> >
> >
> > >       locations. A bit like the rights module: adding a right to
> > > someone at some
> > >       level will dismiss rights for all other people. I guess we all
> > > agree it's a
> > >       problem on the User Experience point of view.
> > >       - Proposition: the restriction added by the "in-context" button
> > >       should be *inactive if there is no other restriction enabled
> > manually
> > >       via the notification preferences UI*.
> > >       - Rational:
> > >          - When you are on the notifications preferences, you can
> > actually
> > >             see all restrictions, so you can understand that creating
> > > one will make you
> > >             lose all notifications that do not honor the restrictions.
> > >             - However, when you are on a page, you don't see all the
> > >             restrictions. If you click on the "subscribe" bell
> > > naively, you might not
> > >             expect it will impact all other notifications. It would
> > > actually be very
> > >             confusing.
> > >             - In addition: if we add an "auto-watch" option, that add
> the
> > >    page you just saved to the list of locations you are interested in,
> we
> > > need
> > >    to have this feature too. Otherwise saving a document will make all
> > > other
> > >    notifications silent.
> > >
> > > That is our plan. Cast you ideas!
> > >
> > > Thanks,
> > >
> > > Guillaume
> > >
> >
>
>
>
> --
> 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 : Add "in-context" switches

Clément Aubin
Hi,

On 07/13/2017 02:28 PM, Ecaterina Moraru (Valica) wrote:
> We could have a setting: "watch all locations" or "watch just particular
> pages". Further more you have the ability to "watch all events" or play
> with the on/off switches.

If the proposal of Marius is implemented (adding exclusion filters to
notifications), then this should be easily doable, but we have to think
about how to include this feature in the notification center UI (which
is already a bit crowded).

> If the user sets to "just particular pages", than the "watch" icon appears
> and we use the include list. Also when setting watch for particular pages,
> the user might want to configure the "auto-watch" for the pages he created,
> or commented, or edited. Those pages will be automatically added in the
> include list, with the possibility to manually remove them from the page
> (on the bell icon) or from the watched filters list.
>
> Thanks,
> Caty
>
> On Wed, Jul 12, 2017 at 2:26 PM, Guillaume Delhumeau <
> [hidden email]> wrote:
>
>> It makes sense. Creating an exclude filter is much more natural than the
>> complicated filter I was proposing...

I do agree on that. Apart from the use case that we are currently
talking about, this could be useful in further notification center
improvements.

>> But in the case of the auto-watch, it could be good to store somewhere the
>> list of pages where the user has contributed, in order to still include
>> them even if the user disable the notifications on a larger scope.

So I guess that it would take too much time to get a list of
contributions directly from a query on the database (particularly for
large wikis with a lot of pages). We could add references to the
contributed pages of a user directly in XObjects linked to its profile.

>> 2017-07-12 10:57 GMT+02:00 Marius Dumitru Florea <
>> [hidden email]>:
>>
>>> On Tue, Jul 11, 2017 at 7:26 PM, Guillaume Delhumeau <
>>> [hidden email]> wrote:
>>>
>>>> *TL;DR*
>>>>
>>>>    - Add a button in each page that will allow you to subscribe to all
>>>>    events that happens to that page.
>>>>    - When you subscribe to a page with this "in-context" bell, it must
>>> not
>>>>    affect your other preferences regarding notifications.
>>>>
>>>> *Full Post*
>>>>
>>>> Hello developers,
>>>>
>>>> With Clément Aubin, we are implementing new features in the
>> Notifications
>>>> Application in order to be able to remove the Watchlist Application.
>>>>
>>>> *Status*
>>>>
>>>> Currently, a user can subscribe to different kinds of events (ex:
>>> "update",
>>>> "comment", "blog published", etc...). Recently, we have also added the
>>>> ability to restrict on which locations we are interested in, for each
>>> kind
>>>> of events. For example, we are now able to say, "for the *update*
>> event,
>>>> show me notifications only about the wiki ABC and for the *blog post*
>>>> event, show me notifications only about the space XYZ".
>>>>
>>>> If you have no restriction (a.k.a "filters") on an event type, then you
>>>> receive notifications for every event matching the event type in the
>>> wiki,
>>>> no matter the location of the entity it concerns.
>>>>
>>>> *Objectives*
>>>>
>>>> In the Watchlist Application, we had 3 switches on the top menu that
>> was
>>>> displayed on every page, and these switches were "watch this wiki /
>> watch
>>>> this space / watch this page". That would be great if we could have the
>>>> same for the notifications.
>>>>
>>>> *Proposal*
>>>>
>>>>    - Add the ability to subscribe to all events that happen in a given
>>>>    location, no matter their type (≈ what the watchlist does).
>>>>    - In each page, add a button to subscribe to the current location:
>>>>    https://pasteboard.co/GAqEi6M.png (thanks Caty for the mockup)
>>>>
>>>
>>>
>>>>    - Problem: if you previously had no restriction, you suddenly add a
>>> new
>>>>       one that will prevent you to receive any notifications
>>>> concerning the other
>>>>
>>>
>>> Maybe I didn't understood correctly, but if you have no restrictions and
>>> you go to a page A then that page should appear as "watched" because you
>>> are receiving notifications for that page (because you don't have
>>> restrictions). So if the icon is "watched" then clicking on it will
>> toggle
>>> "don't watch". So you are actually removing that page from the list of
>>> watched pages (i.e. you add an exclude).
>>>
>>> It all depends on what's the initial state:
>>>
>>> (1) receive notifications from everywhere => then when you go to a page
>> you
>>> can exclude it
>>> (2) no notifications => then when you go to a page you can include it
>>>
>>> So it depends what you understand by "no restrictions". Either all
>>> notifications or no notifications.
>>>
>>> Hope this helps,
>>> Marius
>>>
>>>
>>>>       locations. A bit like the rights module: adding a right to
>>>> someone at some
>>>>       level will dismiss rights for all other people. I guess we all
>>>> agree it's a
>>>>       problem on the User Experience point of view.
>>>>       - Proposition: the restriction added by the "in-context" button
>>>>       should be *inactive if there is no other restriction enabled
>>> manually
>>>>       via the notification preferences UI*.
>>>>       - Rational:
>>>>          - When you are on the notifications preferences, you can
>>> actually
>>>>             see all restrictions, so you can understand that creating
>>>> one will make you
>>>>             lose all notifications that do not honor the restrictions.
>>>>             - However, when you are on a page, you don't see all the
>>>>             restrictions. If you click on the "subscribe" bell
>>>> naively, you might not
>>>>             expect it will impact all other notifications. It would
>>>> actually be very
>>>>             confusing.
>>>>             - In addition: if we add an "auto-watch" option, that add
>> the
>>>>    page you just saved to the list of locations you are interested in,
>> we
>>>> need
>>>>    to have this feature too. Otherwise saving a document will make all
>>>> other
>>>>    notifications silent.
>>>>
>>>> That is our plan. Cast you ideas!
>>>>
>>>> Thanks,
>>>>
>>>> Guillaume
>>>>
>>>
>>
>>
>>
>> --
>> Guillaume Delhumeau ([hidden email])
>> Research & Development Engineer at XWiki SAS
>> Committer on the XWiki.org project
>>

Thanks,

--
Clément Aubin
Web Developer Intern @XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal] Notifications : Add "in-context" switches

Marius Dumitru Florea
On Mon, Jul 17, 2017 at 1:06 PM, Clément Aubin <[hidden email]>
wrote:

> Hi,
>
> On 07/13/2017 02:28 PM, Ecaterina Moraru (Valica) wrote:
> > We could have a setting: "watch all locations" or "watch just particular
> > pages". Further more you have the ability to "watch all events" or play
> > with the on/off switches.
>
>

> If the proposal of Marius is implemented (adding exclusion filters to
> notifications),


Or inclusion list. It depends what you think is best: start with no
notification or start with all notifications.


> then this should be easily doable, but we have to think
> about how to include this feature in the notification center UI (which
> is already a bit crowded).
>
> > If the user sets to "just particular pages", than the "watch" icon
> appears
> > and we use the include list. Also when setting watch for particular
> pages,
> > the user might want to configure the "auto-watch" for the pages he
> created,
> > or commented, or edited. Those pages will be automatically added in the
> > include list, with the possibility to manually remove them from the page
> > (on the bell icon) or from the watched filters list.
> >
> > Thanks,
> > Caty
> >
> > On Wed, Jul 12, 2017 at 2:26 PM, Guillaume Delhumeau <
> > [hidden email]> wrote:
> >
> >> It makes sense. Creating an exclude filter is much more natural than the
> >> complicated filter I was proposing...
>
> I do agree on that. Apart from the use case that we are currently
> talking about, this could be useful in further notification center
> improvements.
>
> >> But in the case of the auto-watch, it could be good to store somewhere
> the
> >> list of pages where the user has contributed, in order to still include
> >> them even if the user disable the notifications on a larger scope.
>
> So I guess that it would take too much time to get a list of
> contributions directly from a query on the database (particularly for
> large wikis with a lot of pages). We could add references to the
> contributed pages of a user directly in XObjects linked to its profile.
>
> >> 2017-07-12 10:57 GMT+02:00 Marius Dumitru Florea <
> >> [hidden email]>:
> >>
> >>> On Tue, Jul 11, 2017 at 7:26 PM, Guillaume Delhumeau <
> >>> [hidden email]> wrote:
> >>>
> >>>> *TL;DR*
> >>>>
> >>>>    - Add a button in each page that will allow you to subscribe to all
> >>>>    events that happens to that page.
> >>>>    - When you subscribe to a page with this "in-context" bell, it must
> >>> not
> >>>>    affect your other preferences regarding notifications.
> >>>>
> >>>> *Full Post*
> >>>>
> >>>> Hello developers,
> >>>>
> >>>> With Clément Aubin, we are implementing new features in the
> >> Notifications
> >>>> Application in order to be able to remove the Watchlist Application.
> >>>>
> >>>> *Status*
> >>>>
> >>>> Currently, a user can subscribe to different kinds of events (ex:
> >>> "update",
> >>>> "comment", "blog published", etc...). Recently, we have also added the
> >>>> ability to restrict on which locations we are interested in, for each
> >>> kind
> >>>> of events. For example, we are now able to say, "for the *update*
> >> event,
> >>>> show me notifications only about the wiki ABC and for the *blog post*
> >>>> event, show me notifications only about the space XYZ".
> >>>>
> >>>> If you have no restriction (a.k.a "filters") on an event type, then
> you
> >>>> receive notifications for every event matching the event type in the
> >>> wiki,
> >>>> no matter the location of the entity it concerns.
> >>>>
> >>>> *Objectives*
> >>>>
> >>>> In the Watchlist Application, we had 3 switches on the top menu that
> >> was
> >>>> displayed on every page, and these switches were "watch this wiki /
> >> watch
> >>>> this space / watch this page". That would be great if we could have
> the
> >>>> same for the notifications.
> >>>>
> >>>> *Proposal*
> >>>>
> >>>>    - Add the ability to subscribe to all events that happen in a given
> >>>>    location, no matter their type (≈ what the watchlist does).
> >>>>    - In each page, add a button to subscribe to the current location:
> >>>>    https://pasteboard.co/GAqEi6M.png (thanks Caty for the mockup)
> >>>>
> >>>
> >>>
> >>>>    - Problem: if you previously had no restriction, you suddenly add a
> >>> new
> >>>>       one that will prevent you to receive any notifications
> >>>> concerning the other
> >>>>
> >>>
> >>> Maybe I didn't understood correctly, but if you have no restrictions
> and
> >>> you go to a page A then that page should appear as "watched" because
> you
> >>> are receiving notifications for that page (because you don't have
> >>> restrictions). So if the icon is "watched" then clicking on it will
> >> toggle
> >>> "don't watch". So you are actually removing that page from the list of
> >>> watched pages (i.e. you add an exclude).
> >>>
> >>> It all depends on what's the initial state:
> >>>
> >>> (1) receive notifications from everywhere => then when you go to a page
> >> you
> >>> can exclude it
> >>> (2) no notifications => then when you go to a page you can include it
> >>>
> >>> So it depends what you understand by "no restrictions". Either all
> >>> notifications or no notifications.
> >>>
> >>> Hope this helps,
> >>> Marius
> >>>
> >>>
> >>>>       locations. A bit like the rights module: adding a right to
> >>>> someone at some
> >>>>       level will dismiss rights for all other people. I guess we all
> >>>> agree it's a
> >>>>       problem on the User Experience point of view.
> >>>>       - Proposition: the restriction added by the "in-context" button
> >>>>       should be *inactive if there is no other restriction enabled
> >>> manually
> >>>>       via the notification preferences UI*.
> >>>>       - Rational:
> >>>>          - When you are on the notifications preferences, you can
> >>> actually
> >>>>             see all restrictions, so you can understand that creating
> >>>> one will make you
> >>>>             lose all notifications that do not honor the restrictions.
> >>>>             - However, when you are on a page, you don't see all the
> >>>>             restrictions. If you click on the "subscribe" bell
> >>>> naively, you might not
> >>>>             expect it will impact all other notifications. It would
> >>>> actually be very
> >>>>             confusing.
> >>>>             - In addition: if we add an "auto-watch" option, that add
> >> the
> >>>>    page you just saved to the list of locations you are interested in,
> >> we
> >>>> need
> >>>>    to have this feature too. Otherwise saving a document will make all
> >>>> other
> >>>>    notifications silent.
> >>>>
> >>>> That is our plan. Cast you ideas!
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Guillaume
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> Guillaume Delhumeau ([hidden email])
> >> Research & Development Engineer at XWiki SAS
> >> Committer on the XWiki.org project
> >>
>
> Thanks,
>
> --
> Clément Aubin
> Web Developer Intern @XWiki SAS
> [hidden email]
> More about us at http://www.xwiki.com
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal] Notifications : Add "in-context" switches

Guillaume Delhumeau
2017-07-17 12:50 GMT+02:00 Marius Dumitru Florea <
[hidden email]>:

> On Mon, Jul 17, 2017 at 1:06 PM, Clément Aubin <[hidden email]>
> wrote:
>
> > Hi,
> >
> > On 07/13/2017 02:28 PM, Ecaterina Moraru (Valica) wrote:
> > > We could have a setting: "watch all locations" or "watch just
> particular
> > > pages". Further more you have the ability to "watch all events" or play
> > > with the on/off switches.
> >
> >
>
> > If the proposal of Marius is implemented (adding exclusion filters to
> > notifications),
>
>
> Or inclusion list. It depends what you think is best: start with no
> notification or start with all notifications.
>

Well, we currently start with all notifications. Changing that would break
compatibility so that's why we need to implement an exclusion list to go on.


>
>
> > then this should be easily doable, but we have to think
> > about how to include this feature in the notification center UI (which
> > is already a bit crowded).
> >
> > > If the user sets to "just particular pages", than the "watch" icon
> > appears
> > > and we use the include list. Also when setting watch for particular
> > pages,
> > > the user might want to configure the "auto-watch" for the pages he
> > created,
> > > or commented, or edited. Those pages will be automatically added in the
> > > include list, with the possibility to manually remove them from the
> page
> > > (on the bell icon) or from the watched filters list.
> > >
> > > Thanks,
> > > Caty
> > >
> > > On Wed, Jul 12, 2017 at 2:26 PM, Guillaume Delhumeau <
> > > [hidden email]> wrote:
> > >
> > >> It makes sense. Creating an exclude filter is much more natural than
> the
> > >> complicated filter I was proposing...
> >
> > I do agree on that. Apart from the use case that we are currently
> > talking about, this could be useful in further notification center
> > improvements.
> >
> > >> But in the case of the auto-watch, it could be good to store somewhere
> > the
> > >> list of pages where the user has contributed, in order to still
> include
> > >> them even if the user disable the notifications on a larger scope.
> >
> > So I guess that it would take too much time to get a list of
> > contributions directly from a query on the database (particularly for
> > large wikis with a lot of pages). We could add references to the
> > contributed pages of a user directly in XObjects linked to its profile.
> >
> > >> 2017-07-12 10:57 GMT+02:00 Marius Dumitru Florea <
> > >> [hidden email]>:
> > >>
> > >>> On Tue, Jul 11, 2017 at 7:26 PM, Guillaume Delhumeau <
> > >>> [hidden email]> wrote:
> > >>>
> > >>>> *TL;DR*
> > >>>>
> > >>>>    - Add a button in each page that will allow you to subscribe to
> all
> > >>>>    events that happens to that page.
> > >>>>    - When you subscribe to a page with this "in-context" bell, it
> must
> > >>> not
> > >>>>    affect your other preferences regarding notifications.
> > >>>>
> > >>>> *Full Post*
> > >>>>
> > >>>> Hello developers,
> > >>>>
> > >>>> With Clément Aubin, we are implementing new features in the
> > >> Notifications
> > >>>> Application in order to be able to remove the Watchlist Application.
> > >>>>
> > >>>> *Status*
> > >>>>
> > >>>> Currently, a user can subscribe to different kinds of events (ex:
> > >>> "update",
> > >>>> "comment", "blog published", etc...). Recently, we have also added
> the
> > >>>> ability to restrict on which locations we are interested in, for
> each
> > >>> kind
> > >>>> of events. For example, we are now able to say, "for the *update*
> > >> event,
> > >>>> show me notifications only about the wiki ABC and for the *blog
> post*
> > >>>> event, show me notifications only about the space XYZ".
> > >>>>
> > >>>> If you have no restriction (a.k.a "filters") on an event type, then
> > you
> > >>>> receive notifications for every event matching the event type in the
> > >>> wiki,
> > >>>> no matter the location of the entity it concerns.
> > >>>>
> > >>>> *Objectives*
> > >>>>
> > >>>> In the Watchlist Application, we had 3 switches on the top menu that
> > >> was
> > >>>> displayed on every page, and these switches were "watch this wiki /
> > >> watch
> > >>>> this space / watch this page". That would be great if we could have
> > the
> > >>>> same for the notifications.
> > >>>>
> > >>>> *Proposal*
> > >>>>
> > >>>>    - Add the ability to subscribe to all events that happen in a
> given
> > >>>>    location, no matter their type (≈ what the watchlist does).
> > >>>>    - In each page, add a button to subscribe to the current
> location:
> > >>>>    https://pasteboard.co/GAqEi6M.png (thanks Caty for the mockup)
> > >>>>
> > >>>
> > >>>
> > >>>>    - Problem: if you previously had no restriction, you suddenly
> add a
> > >>> new
> > >>>>       one that will prevent you to receive any notifications
> > >>>> concerning the other
> > >>>>
> > >>>
> > >>> Maybe I didn't understood correctly, but if you have no restrictions
> > and
> > >>> you go to a page A then that page should appear as "watched" because
> > you
> > >>> are receiving notifications for that page (because you don't have
> > >>> restrictions). So if the icon is "watched" then clicking on it will
> > >> toggle
> > >>> "don't watch". So you are actually removing that page from the list
> of
> > >>> watched pages (i.e. you add an exclude).
> > >>>
> > >>> It all depends on what's the initial state:
> > >>>
> > >>> (1) receive notifications from everywhere => then when you go to a
> page
> > >> you
> > >>> can exclude it
> > >>> (2) no notifications => then when you go to a page you can include it
> > >>>
> > >>> So it depends what you understand by "no restrictions". Either all
> > >>> notifications or no notifications.
> > >>>
> > >>> Hope this helps,
> > >>> Marius
> > >>>
> > >>>
> > >>>>       locations. A bit like the rights module: adding a right to
> > >>>> someone at some
> > >>>>       level will dismiss rights for all other people. I guess we all
> > >>>> agree it's a
> > >>>>       problem on the User Experience point of view.
> > >>>>       - Proposition: the restriction added by the "in-context"
> button
> > >>>>       should be *inactive if there is no other restriction enabled
> > >>> manually
> > >>>>       via the notification preferences UI*.
> > >>>>       - Rational:
> > >>>>          - When you are on the notifications preferences, you can
> > >>> actually
> > >>>>             see all restrictions, so you can understand that
> creating
> > >>>> one will make you
> > >>>>             lose all notifications that do not honor the
> restrictions.
> > >>>>             - However, when you are on a page, you don't see all the
> > >>>>             restrictions. If you click on the "subscribe" bell
> > >>>> naively, you might not
> > >>>>             expect it will impact all other notifications. It would
> > >>>> actually be very
> > >>>>             confusing.
> > >>>>             - In addition: if we add an "auto-watch" option, that
> add
> > >> the
> > >>>>    page you just saved to the list of locations you are interested
> in,
> > >> we
> > >>>> need
> > >>>>    to have this feature too. Otherwise saving a document will make
> all
> > >>>> other
> > >>>>    notifications silent.
> > >>>>
> > >>>> That is our plan. Cast you ideas!
> > >>>>
> > >>>> Thanks,
> > >>>>
> > >>>> Guillaume
> > >>>>
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Guillaume Delhumeau ([hidden email])
> > >> Research & Development Engineer at XWiki SAS
> > >> Committer on the XWiki.org project
> > >>
> >
> > Thanks,
> >
> > --
> > Clément Aubin
> > Web Developer Intern @XWiki SAS
> > [hidden email]
> > More about us at http://www.xwiki.com
> >
>



--
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 : Add "in-context" switches

Clément Aubin
In reply to this post by Guillaume Delhumeau
Hi devs !

So, about a month ago, Guillaume Delhumeau started this thread in order
to determine how we could implement the "in-context" switches of the
notification center. For those who don’t want to read the original mail,
it’s about moving the current watchlist mechanism inside of the
notification center (and by "moving", I mean "rewriting it in a more
scalable and performant way").

We talked a lot about how those switches should act if a user is
subscribed to the page he’s on, or if he is subscribed to a parent page.
Today, with Guillaume, we managed to implement exclusive notification
filters that allows us to reproduce the comportment of the current
watchlist ; so this subject is somehow resolved.

But, we didn’t talked about how the "in-context" switches should look
like in practice. Here is what we proposed at the time :

>    - In each page, add a button to subscribe to the current location:
>    https://pasteboard.co/GAqEi6M.png (thanks Caty for the mockup)

With this solution, this would mean removing the current watchlist
indicators present in the notification tray
(https://pasteboard.co/GEFyXkR.png).

What do you think ? Should we keep using those switches or moving them
in the breadcrumb ?

Here is my point of view :

The alert bell in the breadcrumb looks more modern that the toggles that
we currently have for the watchlist but we have to add a new UIX for the
breadcrumb if we want to do that.

Therefore, if we keep the same kind of switches in the notification
tray, maybe we could profit from this occasion to make them more modern.

Thanks,

On 07/11/2017 06:26 PM, Guillaume Delhumeau wrote:

> *TL;DR*
>
>    - Add a button in each page that will allow you to subscribe to all
>    events that happens to that page.
>    - When you subscribe to a page with this "in-context" bell, it must not
>    affect your other preferences regarding notifications.
>
> *Full Post*
>
> Hello developers,
>
> With Clément Aubin, we are implementing new features in the Notifications
> Application in order to be able to remove the Watchlist Application.
>
> *Status*
>
> Currently, a user can subscribe to different kinds of events (ex: "update",
> "comment", "blog published", etc...). Recently, we have also added the
> ability to restrict on which locations we are interested in, for each kind
> of events. For example, we are now able to say, "for the *update* event,
> show me notifications only about the wiki ABC and for the *blog post*
> event, show me notifications only about the space XYZ".
>
> If you have no restriction (a.k.a "filters") on an event type, then you
> receive notifications for every event matching the event type in the wiki,
> no matter the location of the entity it concerns.
>
> *Objectives*
>
> In the Watchlist Application, we had 3 switches on the top menu that was
> displayed on every page, and these switches were "watch this wiki / watch
> this space / watch this page". That would be great if we could have the
> same for the notifications.
>
> *Proposal*
>
>    - Add the ability to subscribe to all events that happen in a given
>    location, no matter their type (≈ what the watchlist does).
>    - In each page, add a button to subscribe to the current location:
>    https://pasteboard.co/GAqEi6M.png (thanks Caty for the mockup)
>    - Problem: if you previously had no restriction, you suddenly add a new
>       one that will prevent you to receive any notifications
> concerning the other
>       locations. A bit like the rights module: adding a right to
> someone at some
>       level will dismiss rights for all other people. I guess we all
> agree it's a
>       problem on the User Experience point of view.
>       - Proposition: the restriction added by the "in-context" button
>       should be *inactive if there is no other restriction enabled manually
>       via the notification preferences UI*.
>       - Rational:
>          - When you are on the notifications preferences, you can actually
>             see all restrictions, so you can understand that creating
> one will make you
>             lose all notifications that do not honor the restrictions.
>             - However, when you are on a page, you don't see all the
>             restrictions. If you click on the "subscribe" bell
> naively, you might not
>             expect it will impact all other notifications. It would
> actually be very
>             confusing.
>             - In addition: if we add an "auto-watch" option, that add the
>    page you just saved to the list of locations you are interested in, we need
>    to have this feature too. Otherwise saving a document will make all other
>    notifications silent.
>
> That is our plan. Cast you ideas!
>
> Thanks,
>
> Guillaume
>

--
Clément Aubin
Web Developer Intern @XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal] Notifications : Add "in-context" switches

vmassol
Administrator
Hi Clement,

> On 8 Aug 2017, at 10:03, Clément Aubin <[hidden email]> wrote:
>
> Hi devs !
>
> So, about a month ago, Guillaume Delhumeau started this thread in order
> to determine how we could implement the "in-context" switches of the
> notification center. For those who don’t want to read the original mail,
> it’s about moving the current watchlist mechanism inside of the
> notification center (and by "moving", I mean "rewriting it in a more
> scalable and performant way").
>
> We talked a lot about how those switches should act if a user is
> subscribed to the page he’s on, or if he is subscribed to a parent page.
> Today, with Guillaume, we managed to implement exclusive notification
> filters that allows us to reproduce the comportment of the current
> watchlist ; so this subject is somehow resolved.
>
> But, we didn’t talked about how the "in-context" switches should look
> like in practice. Here is what we proposed at the time :
>
>>   - In each page, add a button to subscribe to the current location:
>>   https://pasteboard.co/GAqEi6M.png (thanks Caty for the mockup)
>
> With this solution, this would mean removing the current watchlist
> indicators present in the notification tray
> (https://pasteboard.co/GEFyXkR.png).
>
> What do you think ? Should we keep using those switches or moving them
> in the breadcrumb ?
>
> Here is my point of view :
>
> The alert bell in the breadcrumb looks more modern that the toggles that
> we currently have for the watchlist but we have to add a new UIX for the
> breadcrumb if we want to do that.
>
> Therefore, if we keep the same kind of switches in the notification
> tray, maybe we could profit from this occasion to make them more modern.

Thanks for asking. Here’s my POV:

* I would really like that we don’t add an additional visual cue to the UI. We’re already too crowded and we’re trying to reduce the clutter and make it as lean as possible.
* In addition having 2 bells makes it even more complex to understand what is doing what for a new user.
* I don’t think that users need to know at every moment if the current page is being watched or not. I feel it’s perfectly acceptable if this info is hidden under one click as it is now in the Alert zone in the top nav bar.
* The on/off bell idea only allows 2 states but doesn’t allow choices such as: watching only this page, watching page + children or watching the current wiki.

So I’d really like that we find a solution that doesn’t involve adding a new UI element.

For me the current solution with the 3 switches in the Alert zone is good and has the big advantage of not introducing a new UI element.

Thanks
-Vincent

> Thanks,
>
> On 07/11/2017 06:26 PM, Guillaume Delhumeau wrote:
>> *TL;DR*
>>
>>   - Add a button in each page that will allow you to subscribe to all
>>   events that happens to that page.
>>   - When you subscribe to a page with this "in-context" bell, it must not
>>   affect your other preferences regarding notifications.
>>
>> *Full Post*
>>
>> Hello developers,
>>
>> With Clément Aubin, we are implementing new features in the Notifications
>> Application in order to be able to remove the Watchlist Application.
>>
>> *Status*
>>
>> Currently, a user can subscribe to different kinds of events (ex: "update",
>> "comment", "blog published", etc...). Recently, we have also added the
>> ability to restrict on which locations we are interested in, for each kind
>> of events. For example, we are now able to say, "for the *update* event,
>> show me notifications only about the wiki ABC and for the *blog post*
>> event, show me notifications only about the space XYZ".
>>
>> If you have no restriction (a.k.a "filters") on an event type, then you
>> receive notifications for every event matching the event type in the wiki,
>> no matter the location of the entity it concerns.
>>
>> *Objectives*
>>
>> In the Watchlist Application, we had 3 switches on the top menu that was
>> displayed on every page, and these switches were "watch this wiki / watch
>> this space / watch this page". That would be great if we could have the
>> same for the notifications.
>>
>> *Proposal*
>>
>>   - Add the ability to subscribe to all events that happen in a given
>>   location, no matter their type (≈ what the watchlist does).
>>   - In each page, add a button to subscribe to the current location:
>>   https://pasteboard.co/GAqEi6M.png (thanks Caty for the mockup)
>>   - Problem: if you previously had no restriction, you suddenly add a new
>>      one that will prevent you to receive any notifications
>> concerning the other
>>      locations. A bit like the rights module: adding a right to
>> someone at some
>>      level will dismiss rights for all other people. I guess we all
>> agree it's a
>>      problem on the User Experience point of view.
>>      - Proposition: the restriction added by the "in-context" button
>>      should be *inactive if there is no other restriction enabled manually
>>      via the notification preferences UI*.
>>      - Rational:
>>         - When you are on the notifications preferences, you can actually
>>            see all restrictions, so you can understand that creating
>> one will make you
>>            lose all notifications that do not honor the restrictions.
>>            - However, when you are on a page, you don't see all the
>>            restrictions. If you click on the "subscribe" bell
>> naively, you might not
>>            expect it will impact all other notifications. It would
>> actually be very
>>            confusing.
>>            - In addition: if we add an "auto-watch" option, that add the
>>   page you just saved to the list of locations you are interested in, we need
>>   to have this feature too. Otherwise saving a document will make all other
>>   notifications silent.
>>
>> That is our plan. Cast you ideas!
>>
>> Thanks,
>>
>> Guillaume
>>
>
> --
> Clément Aubin
> Web Developer Intern @XWiki SAS
> [hidden email]
> More about us at http://www.xwiki.com

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

Re: [Proposal] Notifications : Add "in-context" switches

Clément Aubin
On 08/08/2017 10:09 AM, Vincent Massol wrote:

> Hi Clement,
>
>> On 8 Aug 2017, at 10:03, Clément Aubin <[hidden email]> wrote:
>>
>> Hi devs !
>>
>> So, about a month ago, Guillaume Delhumeau started this thread in order
>> to determine how we could implement the "in-context" switches of the
>> notification center. For those who don’t want to read the original mail,
>> it’s about moving the current watchlist mechanism inside of the
>> notification center (and by "moving", I mean "rewriting it in a more
>> scalable and performant way").
>>
>> We talked a lot about how those switches should act if a user is
>> subscribed to the page he’s on, or if he is subscribed to a parent page.
>> Today, with Guillaume, we managed to implement exclusive notification
>> filters that allows us to reproduce the comportment of the current
>> watchlist ; so this subject is somehow resolved.
>>
>> But, we didn’t talked about how the "in-context" switches should look
>> like in practice. Here is what we proposed at the time :
>>
>>>   - In each page, add a button to subscribe to the current location:
>>>   https://pasteboard.co/GAqEi6M.png (thanks Caty for the mockup)
>>
>> With this solution, this would mean removing the current watchlist
>> indicators present in the notification tray
>> (https://pasteboard.co/GEFyXkR.png).
>>
>> What do you think ? Should we keep using those switches or moving them
>> in the breadcrumb ?
>>
>> Here is my point of view :
>>
>> The alert bell in the breadcrumb looks more modern that the toggles that
>> we currently have for the watchlist but we have to add a new UIX for the
>> breadcrumb if we want to do that.
>>
>> Therefore, if we keep the same kind of switches in the notification
>> tray, maybe we could profit from this occasion to make them more modern.
>
> Thanks for asking. Here’s my POV:
>
> * I would really like that we don’t add an additional visual cue to the UI. We’re already too crowded and we’re trying to reduce the clutter and make it as lean as possible.

I do agree that the UI is a bit crowded, but the idea would be to move
the switches of the watchlist in one single bell, so in the end, we gain
one icon and we loose 3 switches.

> * In addition having 2 bells makes it even more complex to understand what is doing what for a new user.

I don’t get what you mean, the idea was to have one bell that changes
regarding the context (the idea came from what YouTube does, see
https://pasteboard.co/GEFTyTe.png and https://pasteboard.co/GEFTOzJ.png).

> * I don’t think that users need to know at every moment if the current page is being watched or not. I feel it’s perfectly acceptable if this info is hidden under one click as it is now in the Alert zone in the top nav bar.

I agree.

> * The on/off bell idea only allows 2 states but doesn’t allow choices such as: watching only this page, watching page + children or watching the current wiki.

We could display the watch parameters when the user is hovering the bell.

>
> So I’d really like that we find a solution that doesn’t involve adding a new UI element.
>
> For me the current solution with the 3 switches in the Alert zone is good and has the big advantage of not introducing a new UI element.
>
> Thanks
> -Vincent
>
>> Thanks,
>>
>> On 07/11/2017 06:26 PM, Guillaume Delhumeau wrote:
>>> *TL;DR*
>>>
>>>   - Add a button in each page that will allow you to subscribe to all
>>>   events that happens to that page.
>>>   - When you subscribe to a page with this "in-context" bell, it must not
>>>   affect your other preferences regarding notifications.
>>>
>>> *Full Post*
>>>
>>> Hello developers,
>>>
>>> With Clément Aubin, we are implementing new features in the Notifications
>>> Application in order to be able to remove the Watchlist Application.
>>>
>>> *Status*
>>>
>>> Currently, a user can subscribe to different kinds of events (ex: "update",
>>> "comment", "blog published", etc...). Recently, we have also added the
>>> ability to restrict on which locations we are interested in, for each kind
>>> of events. For example, we are now able to say, "for the *update* event,
>>> show me notifications only about the wiki ABC and for the *blog post*
>>> event, show me notifications only about the space XYZ".
>>>
>>> If you have no restriction (a.k.a "filters") on an event type, then you
>>> receive notifications for every event matching the event type in the wiki,
>>> no matter the location of the entity it concerns.
>>>
>>> *Objectives*
>>>
>>> In the Watchlist Application, we had 3 switches on the top menu that was
>>> displayed on every page, and these switches were "watch this wiki / watch
>>> this space / watch this page". That would be great if we could have the
>>> same for the notifications.
>>>
>>> *Proposal*
>>>
>>>   - Add the ability to subscribe to all events that happen in a given
>>>   location, no matter their type (≈ what the watchlist does).
>>>   - In each page, add a button to subscribe to the current location:
>>>   https://pasteboard.co/GAqEi6M.png (thanks Caty for the mockup)
>>>   - Problem: if you previously had no restriction, you suddenly add a new
>>>      one that will prevent you to receive any notifications
>>> concerning the other
>>>      locations. A bit like the rights module: adding a right to
>>> someone at some
>>>      level will dismiss rights for all other people. I guess we all
>>> agree it's a
>>>      problem on the User Experience point of view.
>>>      - Proposition: the restriction added by the "in-context" button
>>>      should be *inactive if there is no other restriction enabled manually
>>>      via the notification preferences UI*.
>>>      - Rational:
>>>         - When you are on the notifications preferences, you can actually
>>>            see all restrictions, so you can understand that creating
>>> one will make you
>>>            lose all notifications that do not honor the restrictions.
>>>            - However, when you are on a page, you don't see all the
>>>            restrictions. If you click on the "subscribe" bell
>>> naively, you might not
>>>            expect it will impact all other notifications. It would
>>> actually be very
>>>            confusing.
>>>            - In addition: if we add an "auto-watch" option, that add the
>>>   page you just saved to the list of locations you are interested in, we need
>>>   to have this feature too. Otherwise saving a document will make all other
>>>   notifications silent.
>>>
>>> That is our plan. Cast you ideas!
>>>
>>> Thanks,
>>>
>>> Guillaume
>>>
>>
>> --
>> Clément Aubin
>> Web Developer Intern @XWiki SAS
>> [hidden email]
>> More about us at http://www.xwiki.com
>

--
Clément Aubin
Web Developer Intern @XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal] Notifications : Add "in-context" switches

vmassol
Administrator

> On 8 Aug 2017, at 10:54, Clément Aubin <[hidden email]> wrote:
>
> On 08/08/2017 10:09 AM, Vincent Massol wrote:
>> Hi Clement,
>>
>>> On 8 Aug 2017, at 10:03, Clément Aubin <[hidden email]> wrote:
>>>
>>> Hi devs !
>>>
>>> So, about a month ago, Guillaume Delhumeau started this thread in order
>>> to determine how we could implement the "in-context" switches of the
>>> notification center. For those who don’t want to read the original mail,
>>> it’s about moving the current watchlist mechanism inside of the
>>> notification center (and by "moving", I mean "rewriting it in a more
>>> scalable and performant way").
>>>
>>> We talked a lot about how those switches should act if a user is
>>> subscribed to the page he’s on, or if he is subscribed to a parent page.
>>> Today, with Guillaume, we managed to implement exclusive notification
>>> filters that allows us to reproduce the comportment of the current
>>> watchlist ; so this subject is somehow resolved.
>>>
>>> But, we didn’t talked about how the "in-context" switches should look
>>> like in practice. Here is what we proposed at the time :
>>>
>>>>  - In each page, add a button to subscribe to the current location:
>>>>  https://pasteboard.co/GAqEi6M.png (thanks Caty for the mockup)
>>>
>>> With this solution, this would mean removing the current watchlist
>>> indicators present in the notification tray
>>> (https://pasteboard.co/GEFyXkR.png).
>>>
>>> What do you think ? Should we keep using those switches or moving them
>>> in the breadcrumb ?
>>>
>>> Here is my point of view :
>>>
>>> The alert bell in the breadcrumb looks more modern that the toggles that
>>> we currently have for the watchlist but we have to add a new UIX for the
>>> breadcrumb if we want to do that.
>>>
>>> Therefore, if we keep the same kind of switches in the notification
>>> tray, maybe we could profit from this occasion to make them more modern.
>>
>> Thanks for asking. Here’s my POV:
>>
>> * I would really like that we don’t add an additional visual cue to the UI. We’re already too crowded and we’re trying to reduce the clutter and make it as lean as possible.
>
> I do agree that the UI is a bit crowded, but the idea would be to move
> the switches of the watchlist in one single bell, so in the end, we gain
> one icon and we loose 3 switches.

The idea is not to remove features; it doesn’t matter if we have more features provided the UI you see at all instant is not more complex.

Gaining one icon that’s 100% visible all the time is a big UI clutter and it’s definitely not the same as 3 switches behind a menu/button.

If you prefer the bell UI, I’m fine with having something similar in the Alert zone too but I think it’s less explicit and more magical and that you’d be reducing the usability a bit by doing so.

>
>> * In addition having 2 bells makes it even more complex to understand what is doing what for a new user.
>
> I don’t get what you mean, the idea was to have one bell that changes
> regarding the context (the idea came from what YouTube does, see
> https://pasteboard.co/GEFTyTe.png and https://pasteboard.co/GEFTOzJ.png).

How do you name the icon in the top bar that represents the Alert zone? (what does it represent?) :)

>
>> * I don’t think that users need to know at every moment if the current page is being watched or not. I feel it’s perfectly acceptable if this info is hidden under one click as it is now in the Alert zone in the top nav bar.
>
> I agree.
>
>> * The on/off bell idea only allows 2 states but doesn’t allow choices such as: watching only this page, watching page + children or watching the current wiki.
>
> We could display the watch parameters when the user is hovering the bell.

Less explicit. A bit magical but possible. You’d need 3 different icons representing the 3 states though.

Thanks
-Vincent

>
>>
>> So I’d really like that we find a solution that doesn’t involve adding a new UI element.
>>
>> For me the current solution with the 3 switches in the Alert zone is good and has the big advantage of not introducing a new UI element.
>>
>> Thanks
>> -Vincent
>>
>>> Thanks,
>>>
>>> On 07/11/2017 06:26 PM, Guillaume Delhumeau wrote:
>>>> *TL;DR*
>>>>
>>>>  - Add a button in each page that will allow you to subscribe to all
>>>>  events that happens to that page.
>>>>  - When you subscribe to a page with this "in-context" bell, it must not
>>>>  affect your other preferences regarding notifications.
>>>>
>>>> *Full Post*
>>>>
>>>> Hello developers,
>>>>
>>>> With Clément Aubin, we are implementing new features in the Notifications
>>>> Application in order to be able to remove the Watchlist Application.
>>>>
>>>> *Status*
>>>>
>>>> Currently, a user can subscribe to different kinds of events (ex: "update",
>>>> "comment", "blog published", etc...). Recently, we have also added the
>>>> ability to restrict on which locations we are interested in, for each kind
>>>> of events. For example, we are now able to say, "for the *update* event,
>>>> show me notifications only about the wiki ABC and for the *blog post*
>>>> event, show me notifications only about the space XYZ".
>>>>
>>>> If you have no restriction (a.k.a "filters") on an event type, then you
>>>> receive notifications for every event matching the event type in the wiki,
>>>> no matter the location of the entity it concerns.
>>>>
>>>> *Objectives*
>>>>
>>>> In the Watchlist Application, we had 3 switches on the top menu that was
>>>> displayed on every page, and these switches were "watch this wiki / watch
>>>> this space / watch this page". That would be great if we could have the
>>>> same for the notifications.
>>>>
>>>> *Proposal*
>>>>
>>>>  - Add the ability to subscribe to all events that happen in a given
>>>>  location, no matter their type (≈ what the watchlist does).
>>>>  - In each page, add a button to subscribe to the current location:
>>>>  https://pasteboard.co/GAqEi6M.png (thanks Caty for the mockup)
>>>>  - Problem: if you previously had no restriction, you suddenly add a new
>>>>     one that will prevent you to receive any notifications
>>>> concerning the other
>>>>     locations. A bit like the rights module: adding a right to
>>>> someone at some
>>>>     level will dismiss rights for all other people. I guess we all
>>>> agree it's a
>>>>     problem on the User Experience point of view.
>>>>     - Proposition: the restriction added by the "in-context" button
>>>>     should be *inactive if there is no other restriction enabled manually
>>>>     via the notification preferences UI*.
>>>>     - Rational:
>>>>        - When you are on the notifications preferences, you can actually
>>>>           see all restrictions, so you can understand that creating
>>>> one will make you
>>>>           lose all notifications that do not honor the restrictions.
>>>>           - However, when you are on a page, you don't see all the
>>>>           restrictions. If you click on the "subscribe" bell
>>>> naively, you might not
>>>>           expect it will impact all other notifications. It would
>>>> actually be very
>>>>           confusing.
>>>>           - In addition: if we add an "auto-watch" option, that add the
>>>>  page you just saved to the list of locations you are interested in, we need
>>>>  to have this feature too. Otherwise saving a document will make all other
>>>>  notifications silent.
>>>>
>>>> That is our plan. Cast you ideas!
>>>>
>>>> Thanks,
>>>>
>>>> Guillaume
>>>>
>>>
>>> --
>>> Clément Aubin
>>> Web Developer Intern @XWiki SAS
>>> [hidden email]
>>> More about us at http://www.xwiki.com
>>
>
> --
> Clément Aubin
> Web Developer Intern @XWiki SAS
> [hidden email]
> More about us at http://www.xwiki.com

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

Re: [Proposal] Notifications : Add "in-context" switches

Eduard Moraru
+1 to stay within the notifications UIX area for notifications related
tasks and not add new elements to the immediately visible UI. This also
helps in not spreading a feature in multiple places and makes it easier for
the user to find it.

Thanks,
Eduard

On Tue, Aug 8, 2017 at 11:59 AM, Vincent Massol <[hidden email]> wrote:

>
> > On 8 Aug 2017, at 10:54, Clément Aubin <[hidden email]> wrote:
> >
> > On 08/08/2017 10:09 AM, Vincent Massol wrote:
> >> Hi Clement,
> >>
> >>> On 8 Aug 2017, at 10:03, Clément Aubin <[hidden email]>
> wrote:
> >>>
> >>> Hi devs !
> >>>
> >>> So, about a month ago, Guillaume Delhumeau started this thread in order
> >>> to determine how we could implement the "in-context" switches of the
> >>> notification center. For those who don’t want to read the original
> mail,
> >>> it’s about moving the current watchlist mechanism inside of the
> >>> notification center (and by "moving", I mean "rewriting it in a more
> >>> scalable and performant way").
> >>>
> >>> We talked a lot about how those switches should act if a user is
> >>> subscribed to the page he’s on, or if he is subscribed to a parent
> page.
> >>> Today, with Guillaume, we managed to implement exclusive notification
> >>> filters that allows us to reproduce the comportment of the current
> >>> watchlist ; so this subject is somehow resolved.
> >>>
> >>> But, we didn’t talked about how the "in-context" switches should look
> >>> like in practice. Here is what we proposed at the time :
> >>>
> >>>>  - In each page, add a button to subscribe to the current location:
> >>>>  https://pasteboard.co/GAqEi6M.png (thanks Caty for the mockup)
> >>>
> >>> With this solution, this would mean removing the current watchlist
> >>> indicators present in the notification tray
> >>> (https://pasteboard.co/GEFyXkR.png).
> >>>
> >>> What do you think ? Should we keep using those switches or moving them
> >>> in the breadcrumb ?
> >>>
> >>> Here is my point of view :
> >>>
> >>> The alert bell in the breadcrumb looks more modern that the toggles
> that
> >>> we currently have for the watchlist but we have to add a new UIX for
> the
> >>> breadcrumb if we want to do that.
> >>>
> >>> Therefore, if we keep the same kind of switches in the notification
> >>> tray, maybe we could profit from this occasion to make them more
> modern.
> >>
> >> Thanks for asking. Here’s my POV:
> >>
> >> * I would really like that we don’t add an additional visual cue to the
> UI. We’re already too crowded and we’re trying to reduce the clutter and
> make it as lean as possible.
> >
> > I do agree that the UI is a bit crowded, but the idea would be to move
> > the switches of the watchlist in one single bell, so in the end, we gain
> > one icon and we loose 3 switches.
>
> The idea is not to remove features; it doesn’t matter if we have more
> features provided the UI you see at all instant is not more complex.
>
> Gaining one icon that’s 100% visible all the time is a big UI clutter and
> it’s definitely not the same as 3 switches behind a menu/button.
>
> If you prefer the bell UI, I’m fine with having something similar in the
> Alert zone too but I think it’s less explicit and more magical and that
> you’d be reducing the usability a bit by doing so.
>
> >
> >> * In addition having 2 bells makes it even more complex to understand
> what is doing what for a new user.
> >
> > I don’t get what you mean, the idea was to have one bell that changes
> > regarding the context (the idea came from what YouTube does, see
> > https://pasteboard.co/GEFTyTe.png and https://pasteboard.co/GEFTOzJ.png
> ).
>
> How do you name the icon in the top bar that represents the Alert zone?
> (what does it represent?) :)
>
> >
> >> * I don’t think that users need to know at every moment if the current
> page is being watched or not. I feel it’s perfectly acceptable if this info
> is hidden under one click as it is now in the Alert zone in the top nav bar.
> >
> > I agree.
> >
> >> * The on/off bell idea only allows 2 states but doesn’t allow choices
> such as: watching only this page, watching page + children or watching the
> current wiki.
> >
> > We could display the watch parameters when the user is hovering the bell.
>
> Less explicit. A bit magical but possible. You’d need 3 different icons
> representing the 3 states though.
>
> Thanks
> -Vincent
>
> >
> >>
> >> So I’d really like that we find a solution that doesn’t involve adding
> a new UI element.
> >>
> >> For me the current solution with the 3 switches in the Alert zone is
> good and has the big advantage of not introducing a new UI element.
> >>
> >> Thanks
> >> -Vincent
> >>
> >>> Thanks,
> >>>
> >>> On 07/11/2017 06:26 PM, Guillaume Delhumeau wrote:
> >>>> *TL;DR*
> >>>>
> >>>>  - Add a button in each page that will allow you to subscribe to all
> >>>>  events that happens to that page.
> >>>>  - When you subscribe to a page with this "in-context" bell, it must
> not
> >>>>  affect your other preferences regarding notifications.
> >>>>
> >>>> *Full Post*
> >>>>
> >>>> Hello developers,
> >>>>
> >>>> With Clément Aubin, we are implementing new features in the
> Notifications
> >>>> Application in order to be able to remove the Watchlist Application.
> >>>>
> >>>> *Status*
> >>>>
> >>>> Currently, a user can subscribe to different kinds of events (ex:
> "update",
> >>>> "comment", "blog published", etc...). Recently, we have also added the
> >>>> ability to restrict on which locations we are interested in, for each
> kind
> >>>> of events. For example, we are now able to say, "for the *update*
> event,
> >>>> show me notifications only about the wiki ABC and for the *blog post*
> >>>> event, show me notifications only about the space XYZ".
> >>>>
> >>>> If you have no restriction (a.k.a "filters") on an event type, then
> you
> >>>> receive notifications for every event matching the event type in the
> wiki,
> >>>> no matter the location of the entity it concerns.
> >>>>
> >>>> *Objectives*
> >>>>
> >>>> In the Watchlist Application, we had 3 switches on the top menu that
> was
> >>>> displayed on every page, and these switches were "watch this wiki /
> watch
> >>>> this space / watch this page". That would be great if we could have
> the
> >>>> same for the notifications.
> >>>>
> >>>> *Proposal*
> >>>>
> >>>>  - Add the ability to subscribe to all events that happen in a given
> >>>>  location, no matter their type (≈ what the watchlist does).
> >>>>  - In each page, add a button to subscribe to the current location:
> >>>>  https://pasteboard.co/GAqEi6M.png (thanks Caty for the mockup)
> >>>>  - Problem: if you previously had no restriction, you suddenly add a
> new
> >>>>     one that will prevent you to receive any notifications
> >>>> concerning the other
> >>>>     locations. A bit like the rights module: adding a right to
> >>>> someone at some
> >>>>     level will dismiss rights for all other people. I guess we all
> >>>> agree it's a
> >>>>     problem on the User Experience point of view.
> >>>>     - Proposition: the restriction added by the "in-context" button
> >>>>     should be *inactive if there is no other restriction enabled
> manually
> >>>>     via the notification preferences UI*.
> >>>>     - Rational:
> >>>>        - When you are on the notifications preferences, you can
> actually
> >>>>           see all restrictions, so you can understand that creating
> >>>> one will make you
> >>>>           lose all notifications that do not honor the restrictions.
> >>>>           - However, when you are on a page, you don't see all the
> >>>>           restrictions. If you click on the "subscribe" bell
> >>>> naively, you might not
> >>>>           expect it will impact all other notifications. It would
> >>>> actually be very
> >>>>           confusing.
> >>>>           - In addition: if we add an "auto-watch" option, that add
> the
> >>>>  page you just saved to the list of locations you are interested in,
> we need
> >>>>  to have this feature too. Otherwise saving a document will make all
> other
> >>>>  notifications silent.
> >>>>
> >>>> That is our plan. Cast you ideas!
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Guillaume
> >>>>
> >>>
> >>> --
> >>> Clément Aubin
> >>> Web Developer Intern @XWiki SAS
> >>> [hidden email]
> >>> More about us at http://www.xwiki.com
> >>
> >
> > --
> > Clément Aubin
> > Web Developer Intern @XWiki SAS
> > [hidden email]
> > More about us at http://www.xwiki.com
>
>
Loading...