On 08/08/2017 10:09 AM, Vincent Massol wrote:
> Hi Clement,
>> On 8 Aug 2017, at 10:03, Clément Aubin <clement.au...@xwiki.com> 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
>> clement.au...@xwiki.com
>> More about us at http://www.xwiki.com

Clément Aubin
Web Developer Intern @XWiki SAS
More about us at http://www.xwiki.com

Reply via email to