Clarify the behaviour of Notification watch switches

Development
#1

Hi everyone,

we currently have in XWiki 3 switches at the top of the Notification area:
notification-switches but I discovered while working on https://jira.xwiki.org/browse/XWIKI-17787 and https://jira.xwiki.org/browse/XWIKI-17799 that their behaviour was far from being obvious. And on the contrary I now think it’s too ambiguous to be properly used since it could cause unexpected behaviour for the end user.

So right now manipulating those switches will call the watch/unwatch script service API on a specified location. But those APIs are now doing two things:

  1. they create a filter to be used in ScopeNotificationFilter, the filter is inclusive for watch, exclusive for unwatch, it concerns all event types and it’s about the chosen location (current page/space/wiki).

  2. if no notifications preferences for at least one of the type “create/update/delete/addComment” (I will call them Pages Notifications, since they appear in the UI like that) is enabled, it enables the notifications preferences for all those types on both formats alert and emails.

The first behaviour is expected since it’s exactly what’s about watching a location means for XWiki: it’s having the right notifications filter for this location.
Now the second behaviour is more problematic: it has been created in order to allow auto-watching a page, basically when you create a page and you haven’t enabled any notifications yet then a location filter is created on that page (behaviour 1) and then the Pages notifications are enabled to be sure the user will receive notifications about the page just created. We even have the following comment in the code for this behaviour:

// If the notifications for the XWiki app (create, update, delete, addComment) are not enabled but autowatch
// is on, then we need to enable the notifications in the user preferences.
 // We do that because it has no sense for a user to use the "AutoWatch" feature when the notifications are
// not enabled.
// Moreover, it makes the notifications feature discoverable. It means that, by default, all pages where the
// user has made a contribution will generate notifications. That's probably what users expect from a
// notification area.

The problem is that, as I specified behaviour 1 concerns all events types, while behaviour 2 concerns only Page Notifications. So if for example you install the Blog Extension, you enable Blog Notifications and you want to watch a space (for receiving Blog Notifications), you will in fact also enable the Pages Notifications automatically without noticing it.
So we are not explicit enough about what type of events exactly those switches should act on, and I propose that we change that.

I see currently 3 solutions:

  1. We force those switches to only act on Page Notifications, it means changing behaviour 1 to create only filters for create/update/delete/addComment event types. Doing that also mean that those switches should never been able if the Pages notifications are not enabled (right now they are enabled if any Notification type is enabled). In order to avoid a UI regression we could still display them as enabled if a filter is created for all event types on a specific space I guess.

  2. We consider that watching a location should apply for all event types (except maybe Targetable Event types, see the related proposal: https://forum.xwiki.org/t/change-the-way-scopenotificationfilter-handle-targetable-events/7461/), so we modify Behaviour 2 to enable all event types instead of only Page Notifications ones if none is enabled.

  3. We provide a configuration to allow admin to chose between solution 1 or solution 2.

wdyt?

#2

For me the most logical is solution 2, i.e. consider that the watch toggles apply to all notification types and they simply create a filter based on the location.

Thanks

#3

So solution 2 is not exactly what you suggest, we already create a filter only based on the location. See:

So what you’re mentioning is actually the first behaviour that we already do. Now the question is about the second behaviour, from your answer I can imagine two things:

  • either you agree with my proposal 2 which was:
  • or you want that we completely discard this second behaviour: meaning that if no notification type is enabled, the filter would be created but would be useless until the user enabled one notification type.
#4

hmm I don’t get it. You proposed this solution2:

I agree with this. How is that not " i.e. consider that the watch toggles apply to all notification types and they simply create a filter based on the location."?

In any case your solution seems the best to me: the toggles apply to all notif types.

#5

Maybe it is but the sentence is ambiguous:

they simply create a filter based on the location

If you’re saying we only need to do this, then it’s wrong. It’s not sufficient, even if you imply that the filter will act on all event types.
We need to do that (actually we already do) AND to enable all event types in Notification Preferences instead of only Page Notifications: here it’s not a filter in the Notification vocabulary.

#6

Ok then yes we agree. I didn’t mean that it was enough to do just that.

1 Like
#7

Hi, pointed here from Matrix by @surli, IMHO we could first clarify the meaning of the various settings, notably make explicit that:

  • the triggering events will be computed from the intersection of application/event type and location filters (“what if a location filter enables an event type that was not enabled in app/event types filters?”)
  • System events are default, non-app-related pages (“a blog post being a page, should I also enable page events beyond Blog events?”)
  • admin settings are default settings applied to users not having interacted with the personal notification settings nor contributed any content (in autowatch) (“are all users affected by my changes as wiki admin?”)
  • when a user will explictly or implicitly (through a contribution) watch something, his personal app/event type filters will be enabled (the current topic) so there is no need for the wiki admin to switch on the System type event…
  • … given that enabling an app/event type currently notifies new users about all events from the whole farm, displays all 3 watch toggles as “on” on all pages, and that one can’t explictly watch a specific page or space without unintendedly excluding the wiki in the first place.

Then, I think the cohabitation of Blog and System (standard page) as same-level event type filters is also a source of the confusion this topic addresses. Am I supposed to subscribe to a blog by watchnig the blog space, or by switching on the blogpost publication event type in my notifications profile (which lacks the individual blog names, btw)?

If I correctly understand that post publication is a fully distinct event from a page creation, it could be clearer to have a “subscribe” button/link on the blog page (wich would enable the appropriate filter) and to dedicate the toggle triplet of the notification drawer to standard page events only. Thus you wouldn’t need to make assumptions on the types to implicitly enable when a first page is watched.

Furthermore, because of the everything-notified & exclude-wiki problem when page notification types are enabled without any location filter, I suggest not using the location-dependent toggles to reflect an implicit behavior induced by the global event type filters. It could be clearer to have a distinct setting for being notified of all or no wiki events as long as a user has no explicit watch set.

#8

Hello Simon,

so, this is awfully complicated, for a single reason: that the System events are de-activated by default and whenever someone watches something we need to actually activate them so that that watch actually makes sense.

Now, the only reason I find for those events to be deactivated by default - which is very counter intuitive - is because by default not watching anything means watching everything, and I guess we want to avoid spamming.This has at least 2 other unexpected effects:

  • all watch switches appear turned on everywhere, so the user cannot subscribe to anything, yet they don’t receive any notification
  • if autowatch is enabled (and it is, by default), strange things will happen when they will modify their first page - for example, if they activated the events and they were receiving notifications for the whole wiki, that will stop (they will only receive events for the page they modified). If they haven’t, they will at least stop seeing all switches on (they’ll magically go off and they’ll need to turn them on).

So it appears that we’re trying to achieve an opt-in for notifications but starting with a default of opt-out and hacking it to stop it. Also, it appears that we’re focusing the management of notifications on the event types (and making an assumption about location), when, I think, it would be easier to focus it on locations (and make an assumption that all events are interesting).

So, I would say we should just drop this magical enabling of things upon watch (neither solution 1 nor solution 2 from your proposal, @surli ) and go back to a simpler solution for the opt-in that we seem to be targeting (let’s call this “Solution 3”):

  • all event types are enabled by default - at global level
  • no filter means no notifications at all : not watching anything means not watching anything
  • 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).
    • if we want to avoid confusion of the user here (which may wonder why they don’t receive any notification when all events are enabled), maybe we can display, in their profile, a warning that they haven’t yet subscribed to any location and they should use the switch in the bell menu to do so.

So, to me, none of the 2 solutions you proposed, @surli, does the job because they’re actually overwriting the user’s settings, as far as I understand, which can be difficultly defended as a reasonable thing to do. To me, this overwrite only makes sense when the user’s settings are the default ones (once the user has made a setting in their profile, overwriting that setting is completely wrong). IMO, we only made this choice (of overwriting), because the default is incomprehensible. So I would say the solution is to have a default that is more comprehensible, and never overwrite those settings (which is Solution 3 above).

I think there are issues open for a bunch of this incomprehensible behaviour (e.g. https://jira.xwiki.org/browse/XWIKI-17540 but probably more). I would probably also rollback the fix for https://jira.xwiki.org/browse/XWIKI-17787 , I think I prefer to see the switch as on, if there is at least one event that I’m watching for that location. With the new default it would make more sense…

I think all this would imply a rather good amount of breaking changes in terms of default behaviour, but I personally can hardly imagine anyone relying on this default, it’s so so messy.

Question A:
I personally don’t see anything that is part of the default behaviour now and that Solution 3 would change in a bad way. Can anyone think of such a case?

Question B:

  • no filter means no notifications at all : not watching anything means not watching anything

Maybe we can make this part of Solution 3 configurable, and allow to configure this in a configuration in xwiki.properties or so, to allow someone to setup a spamming wiki by default (a fully opt-out), if they wish to. But then again, we have global filters now, so having such a spammy wiki is really not hard now for an admin. WDYT?

#9

It would be interesting to dig the sources of these decisions…

#10

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.

#11

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.

#12

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.

#13

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.

#14

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

#15

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
Change the behaviour of notification switches and default notification event type switches
#16

@surli has opened a vote about it at Change the behaviour of notification switches and default notification event type switches

#17

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?

#18

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.

#19

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

#20

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 :slight_smile: , 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 :wink: (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.