I’m currently working on the watch buttons for fixing Loading.... My plan is to have a middle state of the watch page switches whenever a subset of the event is watched, like this:
Related to this change, I want to change the current behaviour when switching the buttons. Right now, we create filter when watching a location and we remove it when unwatching. But we do that only for the exact filter we created, so a filter for that location, for all events and for all formats.
It means that if you have created manually a filter for ignoring mention events by email on Sandbox, and you decide afterwards to click on the watch button for the space, you will end up with two filters:
the filter you created first to ignore mentions by email
a new filter to receive all events for the space both by email and alert
So there’s a contradiction created with the previous filter. Which was already reported with Loading....
So my proposal to solve this, is to automatically disable (and not delete) all custom notification filters (for a subset of events or formats) when manipulating the watch/unwatch API (the one used by the buttons).
Note that a slightly different option could be to introduce a different API that would do what I just say and use that new one for the watch buttons, to avoid changing behaviour for other extensions. But IMO it’s better to change directly the existing API.
The middle state looks good. I hope that users will understand it (make sure to have an ALT with a proper explanation when we hover over it).
You mean a subset of the Pages Application events I guess (since the watch feature is limited to Pages events). And by subset, it means some filters reducing the scope, either some pages not watched in the space or wiki or some events not applying (like adding a comments for ex), right?
If I understand correctly this means that if you unwatch and then rewatch, any custom filters that were manually set are lost and will need to be set again manually by the user?
Well, these are not contradictory filters. You can have an inclusive and an exclusive filter for the same location, for 2 categories of events. This means that for that page all events are interesting, with the exception of mentions by emails.
There is no contradiction but it’s true that it may be hard to represent the situation correctly in the UI.
So, to me, for the example you gave here, we have no reason to disable the exclusive filter if it was manually added. For this specific case, when the user disables the switch and we delete the filter we created, the user will not receive any notification, in practice, and thus we’d have no problem showing the switch as off.
I think it’s important that we still delete the filter we added when the user turned notifications to on, knowing that there is no bulk operation on the custom filters table. So, if we create a filter when the switch is turned to on, and then only disable it when the switch is turned to off, this would result in an accumulation of unused filters in the custom filters table. We need to avoid that, as it’s a current problem (that people don’t understand what they’re watching).
As I mentioned in the past, in order to perfectly fix these switches UI, we may need to re-think the way they are represented on the UI and how we explain to the user their meaning, I think trying to make all situations coherent with the current representation of the switches (which is to let the user know whether they'll receive notifications or not) may be unsolvable.
So, just to make it clearer of what is my point of view here:
Unless a larger review of the UX of the switches is planned, I think we can keep the current behaviour for now (add + delete) when turning switches on and off, even if this may mean some incoherency when turning the switch off (meaning that turning it off will take it to the middle state instead of the fully off state).
The situation when a filter already exists for that location that was manually added for another event is rather rare. After the fix of XWIKI-19070 we expect people to use these switches to subscribe to pages and unsubscribe when they’re not interested anymore, so I think we need to streamline this case. Not deleting the filter we created when the user turns the filter off would hinder this main usecase that needs to stay fluid.
They are since the second one to receive “all events” does include mentions. So for the mention event type there is a contradiction: it’s both supposed to be excluded AND included.
So my proposal only concerns what I called “custom filters”: i.e. filters targeting subset of events and/or subset of formats. I’m keeping current behaviour for filters targeting all events and all formats, as that’s the ones we automatically create / delete through the watch buttons.
IMO here it’s not only a UI issue: we currently have APIs to watch/unwatch location, and my proposal also concerns the behaviour of those APIs.
Actually it’s even worst than I thought: right now the watch switches don’t care at all about the notification formats. So if you create a filter to watch a space only for email notifications, the switches will be set to on. Then if you click on it to unwatch, it will create another filter to ignore the events on both formats.
So you end up with:
a first filter to be notified on all events on email format
a second filter to ignore all events on both email and alert formats
So I’m going to fix that too, so that the watched status is true only if no format is specified. Same as we have for event types. And consistently with the actual filters we automatically creates when manipulating the API.
To me this is not a contradiction, it’s how the filters algebra works (because otherwise all exclusive filters are contradictory). The idea is that the exclusion has priority over the inclusion, and is to be used like this.
For example, as part of normal filters functioning you’re supposed to create an inclusive filter for all events for one pagetree and then make an exclusive filter for one page for comments (because it turns out too verbose or so). Maybe we need to clarify this too, from a “what do we show to the user” pov.
Yes but this is because you know precisely how the notification filters works. From user pov I’m sure it feels contradictory that you’re not getting mentions after you specifically watched the page for all events, months after you had created a specific filter to ignore those events for the same page.
So I really think disabling the filter automatically in that specific case, will simplify users’ life.
how about if you’re filtering out mentions (exclusive filter) for a whole pagetree and then you watch a single page from that pagetree? Should the exclusive filter be disabled in this case? (knowing that in practice, for the actual notifications, it will win, IIRC how notification filters work).
Sure, my question was more about whether we consider that it should be disabled or not, given that it would create a contradiction (by the same logic as above, as you would watch a page and yet not receive all its notifications).
So my position right now is that it’s not strictly a contradiction here I consider there’s a contradiction when two filters are opposite (exclude / include) on the exact same location for a non empty set of events and of notification formats.
When the location is not exactly the same then it’s hardly a contradiction since it necessarily involve a set of pages (either a space or a wiki), so it makes sense to me to keep the filter enabled.
In any case, I wouldn’t go in the direction of automatically resolving (or even preventing users) such kind of contradictions, as it might be quickly a nightmare. At least not in short term.
So the question remains: are you ok if in 15.5 we do disable the custom filters that are in contradiction with new ones created automatically by the watch settings?
ok, go for it. I think it’s not optimal as it may be confusing, but it’s not a situation that should happen often. We don’t have better for now, so let’s go for it.
We’ll need to a make a full UX pass on all of this though (maybe when more items are fixed), to check their validity and coherence.
I consider there’s a contradiction when two filters are opposite (exclude / include) on the exact same location for a non empty set of events and of notification formats.