Clarify the behaviour of Notification watch switches

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 :frowning:

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 :smile:. 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” :slight_smile:.

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 :laughing:)

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?

yes, definitely.
I meant a locationless targetless event.
Targeted events can indeed be easily locationless, but they are special because the logic that applies in that case is a little different: for a targeted event the assumption is that the “system knows better” which user is interested in that event and it’s rather normal that they’re “on” by default everywhere; for a targetless event the idea is that the user needs to express interest and today a key component in that expression of interest is the inclusion of that location…

As I explained on XWIKI-19070 and in the forum thread with the vote, I think the default behaviour of an out of the box XWiki instance will not change in practice.
Neither will the behaviour for any user that has at least one inclusive filter (because in this case the “global” inclusion is cancelled by the existence of a filter).
Targeted events will not be impacted by this, because they’re only impacted by exclusive filters.
I need to check for the Blog publishing event, but I am afraid location filter is applying to it, so as long as a user had an inclusive filter for a page and not one for the blog tree, they were not receiving blog publication events either, so not much will change for this either.

I think this is a topic for the thread with the vote. I personally couldn’t think of a case where a proper setup would get broken, mainly because I think it’s rather hard to have a proper setup with the current defaults, but if there are cases, I really would like to know them.