> On 8 Aug 2017, at 10:54, Clément Aubin <clement.au...@xwiki.com> wrote:
> 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.

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.


>> 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
> clement.au...@xwiki.com
> More about us at http://www.xwiki.com

Reply via email to