+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 <vinc...@massol.net> wrote:

>
> > 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.
>
> 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
> >>> 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