New wording in notification filter settings

Development
#1

Hi everyone,

as part of my work on notification settings and more specifically on https://jira.xwiki.org/browse/XWIKI-18406 I changed the wordings especially when creating new custom filter to help users understanding what they’re doing. Now there’s an ambiguity on the wording if we should talk about events / events and notifications or just notifications.
To give you some context, we’re now talking about “Notification filters” that are triggered on “event types” and are related to “notification formats”.

I was starting to make changes so that we are talking about “Notification filters that applies on events types and locations to trigger proper notifications (with right formats)”. IMO we’re keeping clear that there’s both events and notifications, and the notifications are only created when the events are handled. This is technically accurate, and it also allows us to keep the wording “events” that we have at several places in the notifications settings (even in the name of some systems filters, such as “Minor event filter”).

Another solution proposed by @lucaa is to get rid of events and talk only about Notifications everywhere. This have the advantage to be more simple for users, now it means we probably need to do it everywhere in Notification settings in time.

Note that for now I’m focusing on the two livetables I worked on as part of https://jira.xwiki.org/browse/XWIKI-18406 and on the Add notification modal. Here’s the first screenshot I have for it:
notification-add-filter-v1 notifications-filters-settings-v1

So to sum up, my proposal is to keep Events and notifications in the wording of Notification settings for now, with the wording you can see in those screenshots.
@lucaa will probably comment this proposal with her own to keep only Notifications in the wording.

Note that this work (with the wording in screenshot) is already committed for 13.2RC1, we can of course improve later but I’d like to reach a first conclusion before the release date (which is planned for the 22nd of february).

Thanks.

#2

Thanks Simon for working on this.

Quick remark on the first hint:

Create a custom location filter: this filter applies on events related to specific locations and allow to ignore or notify them based on the event type and the notification format.

I think we could improve this:

  • No need for a colon. A dot would be better or use “which” instead to avoid the repetition of “filter”
  • “allow” → “allows”
  • I don’t understand what “notifying a specific location” means. It doesn’t seem to work.
  • “applies on events” → “applies to events”
  • No need to say it’s custom IMO.
  • It would be more clear to explain what a location means. I’d even propose to replace location by pages.

Proposal:

“Create a filter for events happening on specific pages. The filter can trigger the sending of a notification or prevent one from being sent.”

Then:

  • Location → Pages
  • Event Type → Events (simpler to read for the user, they don’t need to differentiate between abstract and actual IMO). At least use the plural since several can be selected.

PS: I haven’t reviewed the other hints

Question: Can you show a screenshot of the UI when there’s no Custom Filter?

#3

OK for that but I’d prefer to keep the wording used for the “Action” select in the UI: options are “Notify of the event” or “Ignore the event” right now. So I would go more on “The filter can notify of the event or ignore it.”

Not a big fan of this change: you can have a filter on the whole wiki, or on a space. No need to be a page.

It show an empty LT right now:
image

#4

Yes I know, I thought about this but AFAIK everything is about pages: pages in a space, pages in a wiki.

I think an improvement would be to replace the LT by a message saying that there are currently no filter defined when there are no entries. But it’s probably minor.

#5

Here is my analysis, that I also sent on the the community chat:

so, either:

  • the filters filter events
  • the announcement of such an event to the user is a notification. One event is not one notification, an event can be announced in multiple ways (email, alert)

or

  • the filter filters notifications
  • all activated events are potentially announced (there is one or more notifications for them), and the filters allows to filter out or in some of those notifications, depending on the source of the event that triggered the notification and the type of notification

Now, for the filter dialog, the second approach may be easier to present (since it’s actually mixing the events and notifications), but, in reality, users are actually interested by the events that happen and the configuration of the channels for announcing those events (notifications) come only after. So much so that we should not even talk about notification channels just yet, we should think of this problem in 2 steps:

  • what events do you wanna know about?
  • how do you want to be informed about them?

but this is a much bigger revamping, we should do it later. As I was also saying on the chat, we should imagine this UI for many more notification channels than what we have today.

So, as a conclusion to all this:

  • events happen on pages (or other entities of the wiki?)
  • the user’s interest is defined around the events that happen
    • thus, they want to filter events, to select the ones they care about
  • one or more notifications is sent, on one of more channels, to announce such an event to the user
    • this is where the filter thing becomes a little tricky, we will propose (at least in this version) the filter as something that applies to a channel and can be different from a channel to another, as if it was filtering notifications…

In next post I will send my feedback for the specific current improvements.

#6

I think I agree with Vincent here, as far as I know the current events are always ocurring on a page, right? (and then that page can be in a subtree or in a wiki) but it’s always on a page, no?

Although I must say, the Custom filters table looks really good with the “Location” column…

So I don’t actually have a fixed opinion here, both are fine for me.

#7

I don’t know why, at this moment somehow I find this very clear and explicit.
Maybe we should append a “, depending on the event and the notification channel.” at the end, if we want to be exhaustive about what it does:

“Create a filter for events happening on specific pages. The filter can trigger the sending of a notification or prevent one from being sent, depending on the event and the notification channel.”

I like very much how naturally it goes from the concept of event to the concept of notification, although technically it’s not the filter that triggers the sending of the notification.

Location or Pages, both are fine for me
Hint: “This filter applies on the events happening on the pages from the locations selected here. Select one or more locations.”
Whatever we do, we should avoid using the “event is sent” phrase. An event is not sent, an event is happening (ocurring). One or more notifications can be sent to announce to the user that that event has happened.

Action → ok
Hint: “This filter can either notify of or ignore the events happening on the selected pages. Choose the action you want to take for the events.”
Hesitating between this and “This filter can either send notifications or ignore the events […]”
Options can be: “notify of the event” and “don’t notify of the event” (or ignore, as you initially proposed)

+1 here. Although technically correct, Event type feels unnecessarily complicated for a normal person.
Hint: “This filter applies to the events selected here, on the pages in the locations selected above. Choose one or more events.”

Format → Notification Channel or just “Channel” or a more mundane synonym? To me, “format” does not at all evoke the way in which the events are announced to me…
Also, here, I think the best default for the checkboxes is that they are both checked when a new filter is created. The objective being that in most cases users will probably are interested in the same things regardless of the channel and they will want to focus on filtering the events.

Hint: “This filter applies only to the notifications sent on the communication channels selected below. Choose one or more communication channels.”
Also, the “Alert” option should probably say “Wiki” or “Website” or “Web” or “Browser” or something to evoke that it’s about the notifications received in the Wiki application when accessed from a browser.

I tried to give a common format to the hints: a sentence explaining at what moment the option comes into play in the filtering / notification process followed by an indication of what the user should do (an imperative verb), but it’s late and I may not have the needed level of focus…

#8

So I applied the changes you both proposed to obtain the following:
notification-add-filter-v2

The only thing I didn’t change is pages/locations.

Actually that’s not necessarily true: in theory events might even not be related to any reference (see https://jira.xwiki.org/browse/XWIKI-17055), but they also could be related to a space reference or even wiki reference. IMO we should not tight the concept of event to a page, that’s especially true if we want to allow covering new usecases in the future not related to pages.

#9

Note: The screenshot is not consistent since it talks about both Pages and Locations now :slight_smile:

#10

Yes but we talked about this and this custom filter UI is for pages events only. We said that other event types would get a different UI in the future should we need a UI for the user (we also said that right now they’d need to use Java).

#11

Oups I fixed some but I also forgot some others… Here’s the right one:

notification-add-filter-v2

This custom filter UI is for EntityReference events only. No need to be send for a page IMO and I wouldn’t limit it to it.
Now if you’re -1 to use “Locations” I’ll change it to “Pages”.

#12

I can still see a mix of “pages” of “locations” in the hints :slight_smile:

#13

Right now I don’t see how this UI could be used for anything else than pages since the Location picker is a page picker…

#14

You can select a whole wiki or a space with it.

#15

We could imagine adding attachments or xobjects to the location picker in the future. But then we’d also need to filter the Events list to only match selected locations (i.e. only events that are used for attachments or xobjects for ex). But then we could change it at the point, no?

This is not a big deal for me. I just find it simpler for users to understand what a page is than what a location is. So I don’t have a problem if you prefer to keep locations.

#16

That’s actually more consistent with what’s displayed in that kind of LT:
notifications-filters-settings-v1

You can see “Wiki” and “Page and children” so it’s not page only.

#17

Then I don’t understand what it does if you select “Like > A watched page is liked” and a WikiReference. Or do you mean that we should change “A watched page is liked” by “A watched location is liked”? (this is just an example).

#18

The event is about a page, that part is good. But the filter is about a location. It will filter all events related to that location. So if the filter is about a wiki, it will filter all events coming from that wiki, not only events related to a page of that wiki.

#19

Ok. So for example we should probably have a notification event for the WikiCreatedEvent listener event an users should be able to select it in the list.

Makes sense.

Note 1: Right now if I want to know whenever a new subwiki is created, I can’t for example.
Note 2: Can a user create an event to be notified when a page with a given xobject is created in the wiki? That could be useful. I was thinking about the XWikiServerClass (for note1) initially but you can imagine lots of other cases when the location is not always fixed.

#20

Note quite sure about this example: since it’s a new wiki not yet created you cannot by definition select it in the location before it exists. And there’s no “farm” location capability AFAIK.

There’s XObjectAddedEvent for that, you’d need an EventDescriptor for them so that you can switch on notifications for those events.