Muting email and/or in-app notifications

[Dieuwertje Bloemen]

Hi all,

Eryk and I have been looking at the option to customize your notifications and emails as this is something we would want in our (KU Leuven RDR) installation and it’s something that has been mentioned before by others in the community (https://github.com/IQSS/dataverse/issues/7492).

In Eryk’s screenshot in #8530, you can get a first idea of how notifications and mails can be turned on or off by users in our current testing set-up.
We’ve been discussing it a bit more, and we wanted input from others on whether they should be able to truly customize it notification per notification or whether installations should provide users with some basic settings, or maybe even another set-up would be better. Here are some suggestions that we came up with for now:

Scenario 1: Leave it all up to the users. They are able to mute each notification and email separately.

Scenario 2: Only allow users to choose between ‘all notifications’ and ‘essential notifications’ (e.g. access request notifications and API token expiration notifications), with the admin then being able to decide what ‘essential notifications’ are for the dataverse via the admin dashboard or via API.

Scenario 3: The feature is only manageable from the admin level and not up to the users individually. Users don’t have any choice and the admin decides for the entire dataverse what the notifications are that a user receives for datasets in that dataverse.

Please provide us with some input and maybe further suggestions as we continue to work on this feature to make it a bit more user friendly.

Dieuwertje

[Eunice Soh]

Hi Dieuwertje 

This would be awesome.

Could it be a mix of scenario 1 and 3? 

For example, admin gets to decide what kinds of emails can be sent but if users still find it too overwhelming, there should be an option to turn off the specific email notification. 

Thanks! 

[Laura Huisintveld]

Hello Dieuwertje,

This is an interesting new feature. I wanted to share our use case at DataverseNL as well.

We have an institutional Dataverse, so every institute (university/university of applied sciences/research institute) has his own subdataverse. We also work with groups. Based on their affiliation, users will be automatically part of a group for their own institute.
If institute X creates a new subdataverse, and assigns a role to the group that has affiliation X, this whole group now receives the  'notification.typeDescription.ASSIGNROLE'. Most of this group members are not aware they are part of this group, and it might even not be relevant for them that they are able to create a dataset in this new dataverse. In our case it would be useful if we can somehow prevent this e-mail from being sent, as it causes confusion.

So for us, I think scenario 3 will be useful, but only if this can be indicated at a subdataverse level.

Kind regards,

Laura

Op dinsdag 29 maart 2022 om 04:37:35 UTC+2 schreef Eunice Soh:

[Dieuwertje Bloemen]

Hi,

@Eunice: what Eryk currently worked out would sort of work like that. As in; the admin can set a series of 'essential' notifications/mails that users can't individually turn off and then set the other notifications/mails as something the users themselves can configure.

@Laura: thank you for the input. So, it would be better if it was also possible to turn off a notification on the admin level for all users. And you would need the configuration to be possible on the dataverse collection level as well. This is a great use case to get a different perspective on the issue because we only have a root dataverse right now.

I also had the overall question if an admin dashboard would be necessary. For us, we only have one root dataverse right now, so we would just set it and forget it in bundle.properties. However, is there maybe a need to provide an admin dashboard for each dataverse collection to keep the notification/email settings manageable? Because that would be something we would have to look into a bit more then.

Kind regards,

Dieuwertje

[Philipp at UiT]

Hi Dieuwertje,

For curated Dataverse installations/collections, I think we need to make sure that users cannot opt out of important curation-related messages, e.g., the notification about a dataset having been submitted for review or sent back to author.

Best,

Philipp

[Dieuwertje Bloemen]

Hi Philipp,

That's definitely an import one to keep in mind.- At KU Leuven, we would also want for the admin to make sure that certain notification/emails can't be turned off by the user, so we will probably make it configurable by the admin what notifications can or cannot be configured by the user.

[James Myers]

FWIW – I also think that having cases where an admin can’t tell if someone received a notification or not could be hard to explain/hard to manage. Would it be possible to think about this more as display-level filtering rather than something where notifications never go out. I’m imagining something where your filters basically hide/show classes of notifications and if the filter is not showing that type, it might still indicate that there are 30 unread notifications of that type. That, and perhaps a way to select/delete all notices of a given type might make them easier to manage without making it ambiguous as to whether they had been sent/seen. (If there are messages that certain roles just should not be seeing, or ones where they should not be sent as email, or users might opt to get a daily digest instead, perhaps some additional type-specific changes could also help.)

 

-- Jim

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-commu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/41322acd-2c44-45e2-9dc7-dfa17d27e173n%40googlegroups.com.

[Dieuwertje Bloemen]

Hi all,

Eryk and I ran through all the feedback and have some comments and further questions:

1. An admin dashboard doesn’t seem like something we want to focus our attention to at this moment. So, as a first iteration of the feature we would suggest making the settings manageable via API. This will ensure that the basic functionality is available and that our set-up doesn’t become too complicated from the get-go and that we can focus on first making the notifications and emails configurable. Is this something you’re all okay with?
2. We thought about the option to make the settings manageable on a dataverse collection. However, this would make the UI and overall feature a lot more complicated. For example, what do you do with users of multiple collections in a dataverse installation? So, as a basic release, we don’t want to include this option as it’s also not something we would use ourselves and would require more resources.
3. @Jim: We wondered what the reasoning was to prefer display-filtering over the current set-up. Because without the feature, you can also not see if someone received a notification or not, I believe. We also thought that display-filtering could lead to issues if someone turned a notification off temporarily because they’re about to upload a lot of files or create some datasets over API and don’t want to get that many notifications/email. What happens if they turn it back on afterwards, wouldn’t they then get all the notifications anyway? And the same goes for a notification/email that an admin doesn’t want to send out about role changes and therefore the admin turns that one off temporarily, wouldn’t it still be sent afterwards? Maybe if you could explain why you would prefer this option, we can think of another solution.

So, what we currently have as a concept is the following:

• The admin can set a series of 'essential' notifications/mails that users can't individually turn off and set notifications as ‘always muted’ that users can’t turn on. You can then set the other notifications/mails as something the users themselves can configure in the notifications tab.

Please let me know if you have any questions or comments.

Kind regards,

Dieuwertje

[James Myers]

Re: @Jim: We wondered what the reasoning was to prefer display-filtering over the current set-up. Because without the feature, you can also not see if someone received a notification or not, I believe. We also thought that display-filtering could lead to issues if someone turned a notification off temporarily because they’re about to upload a lot of files or create some datasets over API and don’t want to get that many notifications/email. What happens if they turn it back on afterwards, wouldn’t they then get all the notifications anyway? And the same goes for a notification/email that an admin doesn’t want to send out about role changes and therefore the admin turns that one off temporarily, wouldn’t it still be sent afterwards? Maybe if you could explain why you would prefer this option, we can think of another solution.

My main concern is that stopping message creation ends up being more complex and requires more training – minimally that admins have to decide which notifications are required, and you’ve seen that collection managers may also want to choose those independently. Users also have to remember to turn notifications on and off in your scenario above. To me, just being able to hide certain types of notifications (but still see a count, and to view them if/when I want), to be able to delete notifications in bulk, and perhaps to let users choose whether to get individual emails or some form of daily digest, is a simpler way to let people manage the times when many notifications are coming in without having to worry about whether a notification didn’t get sent due to some problem or was just turned off for that user at that time ( and possibly just in that collection). In a display-filtering design, if you uploaded lots of datasets via api, the user would still end up with, for example, one email that says you received 192 dataset creation notices today (might be nice to make sure that number matches how many you though you created with the API) and, on the notification tab, they’d either want to not display dataset creation notices so they can see any others, or just bulk delete notices at the end of the day to clear the backlog. (And there would be no admin setting.)

 

I also can see display-filtering serving the user case where an admin does want to see all the activity but doesn’t want to be bothered by it, e.g. by getting hundreds of emails a day or having one type of notification hide a few of another type. I think the ability to bulk delete notifications has already been asked for in this use case (not sure if it is an issue or not).

 

This is probably also a design philosophy issue where there is no best answer, and since notification are not records (i.e. you don’t mark them as read, you delete them and they’re gone), it’s probably not as important to know whether  a user ever got a notification or not. So, while I’m advocating for the display-side approach, there are pros and cons to both approaches.

 

-- Jim

[Dieuwertje Bloemen]

Hi Jim,

I think your concern can partially be solved by the admin setting our current system up correctly. I don't know if it was made clear, but our current set-up allows different settings for notifications and mails. So, on an admin level, you could say that users can't configure the notifications and only the mails.

I do agree that grouping together of notifications or mails could be a great improvement just like bulk deleting could be. This maybe would be something to work on in a next iteration. I'm also aware that the ability to configure it on a collection level would be a great improvement, but it would involve making the feature a lot more complicated. And because we ourselves don't use any collections with separate admins, we also don't have a good insight into their needs. Again, something to work on in a possible future update of the feature.

Maybe it's also important to point out that the current set-up is not very invasive with its code changes, it's very surface level and therefore easy to implement. We have made sure that it's an optional feature, so installations that don't want to use it yet, because it doesn't have the options and configurability they need, don't have to fear what this feature would do to their set-up.

In the GitHub, there was a request for a demo, which we're definitely open to, so maybe that's also a great place to discuss what possible future adaptations and needs are, so that the basic set-up is as 'buildable' as possible.

Dieuwertje

[Philip Durbin]

Thank you, Dieuwertje and Eryk, for demoing the proposed "muting notifications" feature yesterday during the community call!

For anyone who missed it, the recording for the demo is now up at https://harvard.zoom.us/rec/share/sFlpmpsfBOFyGHUiWcrLpLwnjpAa_CaHkV6WU1mBB56cUDXJ8hWUF50qcNIIQ_yV.alzT560S9diRN1TT

Dieuwertje also presented some slides: https://kuleuven-my.sharepoint.com/:p:/g/personal/dieuwertje_bloemen_kuleuven_be/EY4OnkcGx39BhA6vLWpizmEBC71P4MfgKfg2hF63S_sD7A

Thanks again!

Phil

--

You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-commu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/ef2dbafd-a7f1-4a9c-bec8-d8a136cfe390n%40googlegroups.com.

--

Philip Durbin
Software Developer for http://dataverse.org
http://www.iq.harvard.edu/people/philip-durbin