+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 <[email protected]> wrote: > > > On 8 Aug 2017, at 10:54, Clément Aubin <[email protected]> wrote: > > > > 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. > > 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 > >>> [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 > >
