On 08/08/2017 10:09 AM, Vincent Massol wrote: > Hi Clement, > >> On 8 Aug 2017, at 10:03, Clément Aubin <[email protected]> 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 >> [email protected] >> More about us at http://www.xwiki.com > -- Clément Aubin Web Developer Intern @XWiki SAS [email protected] More about us at http://www.xwiki.com
