+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 <vincent(a)massol.net> wrote:
On 8 Aug 2017, at 10:54, Clément Aubin
<clement.aubin(a)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.aubin(a)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.aubin(a)xwiki.com
More about us at
http://www.xwiki.com
--
Clément Aubin
Web Developer Intern @XWiki SAS
clement.aubin(a)xwiki.com
More about us at
http://www.xwiki.com