Email notification grouping

Development
#1

Hi everyone,

I’m opening this thread so that we can brainstorm about the UX of grouping of email notifications. To be transparent we have a company sponsoring some work for the grouping of notifications, and they have a hard requirement that for their instance they should only receive email notifications grouped “per type”: e.g. only the notifications related to a change in a page for one email, and only the changes related to the blog application in another email.
They also want this policy to apply for any kind of interval chosen by their users (daily/weekly/monthly/live email notifications).

So I want to discuss here what we want to provide in XWiki Standard, knowing that some of the requirements they have could maybe be done as separated extension, not delivered in standard, but we’d need APIs anyway for this.

Right now the situation in XWiki is that the daily/weekly/monthly mail notifications are always “digest” emails that summarize all notifications that happened and send a single email with all those info. On the contrary, the Live email notifications, implies that users will probably receive multiple emails, even if some emails might contain grouped notifications.

So from a UX point of view, we already consider daily/weekly/monthly emails like digest emails, vs Live notifications with multiple mails. Allowing to always send notifications email per types for any kind of interval, would break that behaviour, and we need our users to be able to keep saying that they only want to receive a single email per day/week/month.

So for now I see two possibilities:

  1. We add a new setting in the email notifications, that allows user to specify that they’re ok to receive multiple emails, whatever the interval the duration they chose. Then it will depends on the grouping notifications policies defined by the different applications (that’s another topic for a brainstorming) and on the events to know how many emails they will receive.
  2. We don’t add a new setting, however we provide in the APIs a parameter specifying that the user are ok or not to receive multiple emails: we’d consider in XS that Live email notifications would mean “ok for multiple emails” while all other durations would mean “not ok”. And for the sponsoring company we could provide an extension or a custom work that would automatically flag this to “ok” for all duration.

Honestly right now XWiki notifications are already very complex, so I’m not sure I’m willing to add a new layer of complexity in XS for our users. So I’d be more inclined to go towards solution 2 for now, knowing that if we have the APIs in any case we could go to solution 1 at any moment.

Now it’s also a question of the direction we want to go for those email notifications: maybe I’m wrong and it would be an interesting feature to have right away for our users.

wdyt?

#2

I think it’s interesting to be able to group notifications by different criteria. For example, from xwiki.org I’m receiving notifications for documents I touched every day. I’m not sure that’s good, but it’s also not bad enough that I would have already disabled them. However, I think I should also be receiving notifications from the security advisory application once an advisory is ready to be published. It would be good to have them in separate emails so I can filter them separately so I notice when there is something to be done and I can’t just ignore the email. Similarly, I could imagine that users might want to split notifications by space to receive notifications for a certain space separately if that space is particularly important for them.

I would therefore be +1 for option 1 to have a setting to allow multiple emails/to enable grouping. Grouping by application could be an interesting option I think but it could also be interesting to set a group in a notification filter. The grouping options could be hidden unless the user enables grouping to not to overload the interface.

#3

As a user, I don’t want to say “I want to receive several emails”. It doesn’t make sense as it’s a technical requirement and not a business one. What I want to be able to say is “I’d like to receive one email per app”.

As @MichaelHamann is mentioning, I think we should make this more generic to be able to receive emails based on different criteria (one email par app type, a different email for that wiki or that space, etc).

I also agree that these are edge cases and that we should not make the Notifications UI more complex.

What about delegating the sending of the emails to the schedulers (if it’s not already the case). By schedulers, I mean the underlying components with the hints defined in “EMAIL FREQUENCY” (ie currently “daily”, “monthly”, “weekly” and “live”). And then allowing to install more schedulers. There could be an extension (Contrib?) that would provide a “Daily per Application” scheduler (hint = “dailyperapp”).

WDYT?

Thanks

#4

So I didn’t want to enter yet in those considerations, for info the full design page about the different criteria is on Notification Grouping (Proposal.NotificationGrouping) - XWiki

So I’m not sure I entirely agree with this. I mean, well, that’s what I’m actually looking for: how do we present the choice for users to specify their wish in terms of number of emails. One option could be “I’d like to receive at most one email per app”. But what if a user always wants to receive a single email? What if a user just don’t care the number of emails and wants to receive them as they are designed by the app (because you could have extensions willingly wanting to separate some specific notifiation events from their other events).

So my goal here is to try finding how to expose those options and what level of details to give.