It would be interesting to dig the sources of these decisions…
Just to align vocabulary, I guess what you’re calling “System events” here is what I called “Page Notifications” in my first message:
IMO it makes sense with the strategy you propose for the default event types (create/update/delete/addComment) and even the one provided by bundled extension in XS (like and mention, which is actually already enabled by default).
Now I’m not so sure it would be right to enable notifications globally for events provided by a new extension you just installed. Maybe that could be a value to declare when you provide a new event descriptor: to specify what should be its default setting (enabled or not).
My recollection about using an opt-in for the watch was that we were enabling the notifications so that users would discover the feature by having notifications automatically when some activity starts to happen on the wiki. I’m now not sure it’s needed, but we need to remind that currently the only location where you can decide to watch/unwatch a page easily (aka without creating a complicated filter and just by pressing switches) is through the notification area. IMO it’s unlikely users would discover that location by mistake, so I think that if we want to go in the direction you propose we should also provide a better discoverability of that feature. Maybe a way for doing that would be to specify in the page information tab if the page is watched or not, and allow to modify it here too.
I guess what you’re calling “System events” here is what I called “Page Notifications”
Indeed, sorry for that.
Probably, but it’s not currently the case by default in the wiki.
Currently, the first user of a wiki (e.g. admin when running the demo distribution) watches all the pages (because they watch nothing) but doesn’t receive any notifications because the Page Notifications are disabled in the “Applications” section (btw, didn’t we say we’d call that “event types”?).
So it’s discoverable but not really, the administrator still needs enable notifications on the wiki, and they would do that by going to the global notification administration and configure the event types to enable page notifications. So it still requires an action from this first user running the demo distribution in order to make the feature discoverable.
This is what I meant in my previous message when I said that we seem to be focusing management on event types when we should focus them on locations.
And this is also what I meant that we’re doing opt-in by starting with an opt-out and then hacking it.
Now, this way of doing things was probably also limited by the absence of the global filters, today (after XWIKI-18406) it would be simpler to allow the admin to enable notifications everywhere (to make users discover them) even if the default would be that they watch nothing: the admin would just need add a global inclusive filter for the whole wiki and notifications would be pushed to all users. Thus, we don’t really have a reason, from my pov, to keep the behaviour of “not watching anything means watching everything”.
One more argument against this behaviour is the fact that once the administrator activates the event types in the global administration, all users receive notifications for all locations on the wiki (including, for example, the XWiki space). The fact that users receive notifications for the XWiki can be a problem, and in the past the absence of global filters made it impossible for an administrator to fix it otherwise than by deactivating all notifications or running a script to update the notification preferences of all users.
What would be wrong in enabling the new event types globally? That users that are not interested in those events would receive them.
My take on this is the following: since the admin is the one that is installing the application, I wouldn’t put this situation in the “side-effect” category (a user doing something that is wrongfully impacting another user). The admin is a special user who should be concerned by the wellbeing of the users when doing actions on the wiki and if the admin worries about the events, they can go to the administration and disable that specific event type globally (would this work?).
Also, if we consider that the focus of the user is locations and they need to manifest that interest by watching some locations, we can consider that as an implicit agreement to notify about whatever happens in those locations (current and future event types). Of course, they can then opt-out if it turns out that the locations are interesting but not that specific event.
Yes this would work.
So just to be a bit more precise: we should not forget that some notifications are not about locations: they can target directly groups or users, some for some event types the location watch is not used at all. But I admit it’s rare, and in general when events targets people it means you really want them to receive the notifications.
So all in all, I think I agree with you that your strategy would be better. My only concern now is about the backward compatibility of such behaviour change: I don’t think it would be really a problem for upgrades since it won’t impact users having already specific settings, now it could be surprising for administrators that have habits using old version of XWiki.
Maybe we can handle that with a specific property to allow fallback on the old mode, when we’ll change it.
Yeah, I know about that, but to me this kind of notif is for a usecase that I call “the system knows better” - which means that the wiki will determine that this event is interesting for this user beyond what the user has expressed (which is why targeted events are not restricted to followed locations), and in that case you probably really want them to receive the notif.
Yeah, it’s true that it has backwards compat impact which in principle is a bad thing, but as I said above, if anyone is relying on those defaults it means they understand them which means someone has managed to find meaning in chaos. I want to meet those people, let’s break the compatibility so that they come complain on the forum so that I meet them and express my admiration 
.
I just created an issue describing this change https://jira.xwiki.org/browse/XWIKI-19070 .
Should anyone have anything against this change or see something wrong with it, please speak now!
1 Like
@surli has opened a vote about it at Change the behaviour of notification switches and default notification event type switches
Hello everybody. I will reply here to avoid hijacking the vote.
Thanks @lucaa for pinging me on this.
I like the simplicity of your proposal, which is really focused on the user experience - which should be our first concern every day.
The first design was done incrementally, and it quickly became messy.
Actually, there is an inherent problem with notifications. We have a single UI to manage 2 different types of notifications.
1 - we have the “regular” XWiki notifications. They are about what is happening to the pages (create, edit, delete, comment), and for which we have designed toggle switches on the top bar of any page. They should be easy to handle: you watch a location, you block some others.
2 - we have the “extension” notifications. For those, we do not really take care of their location: a blog post is published, a new invitation to join a private forum has been received, a new version of the extension X is available on extension manager, etc…
Let me find you a better example. Imagine you implement a RSS reader in XWiki, and you want this application to send notifications when a new article is published on some external website. What “location” from the XWiki pages point of view do you want to link these events to?
Do you need to watch the page “WikiA.RSSReader.gizmodo” to watch “gizmodo.com”? Is it… logical?
no filter means no notifications at all : not watching anything means not watching anything
So if someone sends you an invitation to join a private forum, installed on a location you have never heard of, you need to watch this location to be able to get the notification?
I know we don’t even have this kind of notifications yet, and trying to cope with these tricky use-cases makes the every-day life of the simple users more complicated than necessary. But as developers of a platform, I think we have to think about it.
Maybe we should focus on the simple use-cases (1) first and make a great user experience for them, and think about handling (2) with a different strategy afterwards - with a better UI.
But I’d like to know what you think about this.
when a user watches a location - manually or automatically - they will start receiving whatever event types they have configured in their profile (or inherit from global level).
It’s even the opposite of the very first logic (the one before the autowatch thing that we have thrown together afterwards). First we enabled the even types, and then we applied filters on them. It’s this way that the UI of the notifications in the user profile has been created.
What is unclear for me is do you want to throw away the ability to create filters per event types? Or do you want to create a new UI where you select a location first and then decide which type of events you want to be notified of?
Actually, that usecase exists today, it’s the mentions notifications, which are using the concept of targetable events https://extensions.xwiki.org/xwiki/bin/view/Extension/Notifications%20API/#HTargetableEvent which, in recent versions of XWiki, don’t need the user to include a location in order to be notified of.
They do respect the exclusive filters, though, so that a user can “mute” a location if they need to.
I’m not sure I understand fully what you mean here, but I think we’re talking about the same thing and the same order. What I mean in this line is the same logic and order: the event types are configured in the profile, as a “base” and then the filters are added afterwards (chronologically), when a user either watches a page from the switches or adds it as a filter in their profile.
So the focus would be the same: first defining “what events” and then “on what scope”
No no, not at all neither one nor the other.
The only thing I want is to change the default of receiving notifications for the whole wiki when no filter is defined. If we change this default, we’ll be able to enable all event types by default on a user profile (page or application related) and not be afraid of spam. Because as long as the user doesn’t have any filter, they will not receive page events, they’ll only receive targetable events targeted to them, which is exactly what we want at this point. Then, for non-targetable events such as page events, they will need to subscribe to pages in order to start receiving the notifications, which they will be able to do by actioning the switches on notifs menu for a page or from the profile using the filters UI.
Note: this proposal doesn’t really handle or address specifically the ambiguity of the watch switches on a page, which will still remain somewhat ambiguous from a user experience point of view:
- do they represent the state of all events or only page events? If a mixed state exists for a location, should the switch be on or off? See https://jira.xwiki.org/browse/XWIKI-17787 and https://jira.xwiki.org/browse/XWIKI-19069
- do they apply to targetable events? In reality they sometimes will apply and sometimes won’t, depending on where the “off” state comes from: the absence of an inclusive filter or an explicit exclusive filter.
- should they change the enabled event types like they do today or they should just illustrate the state of the filters for those locations? My opinion is that they shouldn’t and they only do today because we didn’t find a better way to actually make sure we send notifications for a watched location when by default all event types were disabled. But this remains to be discussed.
- should they offer a complete UI for handling all the notifs setup or they can only handle a given angle (for example page events) and then leave all the other configurations for the notifs prefs on the user page?
- etc.
The attempt of this proposal is not necessarily to fix these issues with the notif switches UI, but just to change the default to make the implementations of the the most frequent usecases less convoluted.
From my experience, the most frequent usecase is that by default a user receives only a few selected “pushed” notifications (such as mentions or the forum invite you mentioned or other) and then they need to manifest their interest for some content in some way in order to start receiving notifs for that content. Autowatch is an assumption of this interest (if one edited a page we assume they’re interest in that).
I think this is the same usecase that was targeted when the current defaults were put in place, but because the notifications tools & features are more mature today, we can do it in a better, clearer way.
It’s indeed a better starting point for the first user-case, the one about XWiki pages. Again, it is not for the other use-case (2). If I enable the RSS notifications, I already express my interest in those. I don’t want to explain that I want the RSS notifications AND specifiy a location for those.
Actually, to help me understanding your proposal better, could you tell me if you want to change the mechanism to “no filter = no data” instead of today (“no filter = no limits”) only for the first use-case (create, edit, comment, delete)? Or do you want to change the mechanism for all use-cases (I enable the “blog” event type, but if I don’t watch the location of the blog, I don’t receive anything)?
I’m OK for the first use-case. I’m not sure about the second one. And if we change the behavior only for 1, then it will become inconsistent.
A technical way to implement this would be to add, by default, an “exclude the wiki” filter + having the pages notifications enabled. This way you don’t change the current mechanism (no filter = no limit) but you still have a better experience in the everyday life without spamming (and I think it would not even break retro-compatibility).
This is incompatible with the targetable events behaviour, unfortunately: an exclusive filter will exclude the targetable events too, and this is not what we want.
In order for this to work, that exclusive filter would need to only apply to page events, which I also tried, but I hit XWIKI-19069 which seems to me like an undesired side effect of XWIKI-17787, and all this workarounding and convolutions made me think again at the default 
, which is how this topic ended up on the table again.
I personally find that exclusive filters are a complex thing to handle mentally, so I would say that the defaults should not encourage their usage, but provide a way to obtain the same thing with includes (just like the ‘deny’ for rights which exists but it’s better if you do everything with ‘allows’).
Ok, so if I understand correctly, this usecase is about a (new?) event type: a locationless event, an event which doesn’t occur in relation with a scope on the wiki but just occurs (we could consider it at a “farm” level).
You consider the blog published event a locationless event, I consider it a locationfull event 
(there can be multiple blogs on the wiki and one only wants publicatoin events for a given blog) - but this is not necessarily the topic here, we can use the RSS example which is obviously a locationless event, and also a targetless event (contrary to the forum invite which can be considered locationless but is definitely targeted).
From an user experience point of view, the way I think this should work is that the locationless events should be somehow identified as such in the UI of the notif preferences and they would only present an on/off switch (like the one for the event types). Technically, I don’t know if we could handle this, I guess we can, I guess when such a locationless event is fired, we know it has no location and we’d know to filter it differently.
Another thing that is worth mentioning at this point is that the RSS example is a hypothetical example that doesn’t exist yet and it’s rather improbable that it would exist as a real-life usecase, although it is possible. I think that given the difficulty of the UX of this topic, it would make our life easier to focus on the existing and probable usecases, at least for UI purposes, even if this means limiting the capacities of the notification system.
Just to clarify: no filter = no data, for all, not only for page events, knowing that all events that I know about are actually locationfull - including the blog one.
The real-life usecase for a locationless event, which doesn’t exist yet but it should is the “wiki creation event”.
I’m not even sure one receives page events for the page creations of the pages of the new wiki, because those are muted to avoid spam in activity stream.
Thinking of how I would implement the wiki creation notification from a user experience pov, I would definitely go for a clear distinction between locationless events and locationful events, and not present the locationless events at all in relation with filters (for example, not present them in the list of events a location filter applies to).
Note: another thing that was done in the mean time in the notifications is to better present the filters as a “location” thing ( https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/13.2/#HDistinguishbetweensystemfiltersandcustomfiltersinnotificationsettings ) the general purpose presentation that we had before was closer to what filters can technically do but completely incomprehensible from a user pov.
It’s a shame 
Unfortunately, I think we need both. When you want to unwatch a space, you don’t want to do it by manually watching all the other spaces and the ones to come. To me, in the rights UI, the exclusion feature is not the problem, the problem is the inheritance of rights from different levels…
Yes, you are right. This is very hypothetical, and it was done when the feature did not exist at all and everything was hypothetical at that point 
. Just kidding, because today, it is still very hypothetical.
Your proposal of handling locationless events in a separate way sounds very good to me. It is what make the more sense to me.
I’m still unsure about no filter = no data, because I think it is weird to have an event type enabled and not see any notification because you don’t have any filter yet. I have always seen a filter as a “limit” instead of a “fish net” .
It’s very interesting that this was thought like this.
Practical experience shows (at least to me) that filters are actually much easier to comprehend as “subscriptions” rather than “exclusions” and, from this point of view, it feels more natural that “no subscription means no data”…
I really cannot wrap my head around an approach of “no filter = no limit”, at least in the context of the current presentation (on/off switches on pages, inclusive subscriptions filters created every time notifications are needed for a page, the fact that as soon as the user manifests interest in some page it automatically is assumed disinterest in the rest)…
But this is exactly the twist, right here: in very little situations one wants to unwatch something as an exclusion. From a functional point of view, it all starts with an inclusion (they wanted to watch it in the past) and then the exclusion comes as a cancellation of the inclusion (remove the subscription).
There is indeed a usecase where actual exclusion is needed, but that one is rare (a user watching a whole wiki and deciding that a subtree of that wiki is “too much noise” and removing it); as you said, we should keep the possibility to exclude things, but reserve it to those special cases and definitely not have an exclusion as a default setting.
Which is why, to me, it’s very important to highlight the various types of notifications:
- targeted - for which it would be weird to need to add a location filter, even if they do occur at a location and could be turned off based on their location, in addition to be able to be turned off based on the type of event.
- locationful - which can be enabled but empty as long as no subscription exists - it just means that when I will subscribe I want to receive stuff.
- locationless - which are on/off, for which location doesn’t even apply.
Thus, the locationful events should endup presented as close as possible to the subscription list, because they are, together, composing the same feature, they’re not actually 2 layers, they’re a single “layer”.
Actually, scratch that, this is completely wrong.
The wiki creation event is a locationful event, its location is the wiki that was just created, just as for a page creation the location is the page that was just created.
I think that currently the filters UI (not sure about the backend) doesn’t accept the “farm” or “root” as a scope, but this is how this should work: if one is interested in the wiki creations, they need to add an inclusive filter for the farm scope for the wiki creation event, so that the scope of the filter covers the location of the event.
May be complex to present on the UI, but this is how it should work.
Whether an event has or not location can also be thought of from the events stream (activity stream) point of view: if we display the events that ocurred on a certain location, should this event be included or not? Wiki creation is the first event that should appear in the activity stream restricted to the subwiki.
So, with this, I think I don’t have examples of real life locationless events anymore…
You can think of message stream events for a real life usecase: message between users are unrelated of any locations, they just target users and they shouldn’t be related to how the messages are stored.
It’s funny how the terminology determines the way we think.
- if you use the word filter, then you are more inclined to think about exclusions, in a mathematical way ;
- if you use the work subscription, then it’s more intuitive to think about inclusions.
So all our UI experience is ruined because of that. People expect subscriptions where they have filters… (it’s a bit like the bookmark feature of the browser. You want to bookmark the website you like, not to exclude all the other websites of the world 
)
To me, the whole thing become way more logical when you change the terminology, and I am 100% in favor of what you propose.
But how do we do that without breaking all the existings?