Migration plan from old notifications settings to the new ones

[daniellekirkwood]

We're changing our notification settings. Users will not have the same selections available to them. We need to provide a way to migrate (or manage) the move from the old system to the new system.

Tasks

Beta Give feedback

1. Add a banner at the top of the settings page for existing users explaining that we've updated the screen but their previous choices remain the same
2. Add a "Custom" choice to the 'Default' section in the new global screen if the users previous selection does not match the new options
3. "Custom" should also be visible (and selected) if user's have set their notification settings on a different client and there's no obvious mapping back to our view here
4. Once unselected, "Custom" should not be available to choose.

[daniellekirkwood]

@justjanne
These are the only migration items I can think of currently but as we start to connect the existing push rules with the new buttons we might find more edge cases?
Please let me know where this issue is missing items and we'll update it with the new decisions

@amshakal
Looking at the designs, I think the only 'migration' thing you added was a banner at the top. Did I miss anything else? Do we want to talk more in other places about this sort of thing?

@clokep & @t3chguy
You both have knowledge here, what might I have missed that we should add/discuss.

[daniellekirkwood]

Suggestion:
All existing users map to 'custom' and we don't connect the new radio buttons with the old ones... Thoughts? Would that make life simpler?

[clokep]

You both have knowledge here, what might I have missed that we should add/discuss.

I think my only question is if the "Custom" choice is being displayed on a setting-by-setting basis?

I.e. if I have a random push rule that Element doesn't understand, I assume it would ignore it (on the settings page), as it does today?

[daniellekirkwood]

I.e. if I have a random push rule that Element doesn't understand, I assume it would ignore it (on the settings page), as it does today?

If that's today's behaviour then I'm happy to stick to that. But I want to be able to catch the folks that have settings we allowed them to create (but no longer support in the UI)...

[giomfo]

I think more and more that we should force the migration instead of supported "custom" option in the new layout.

• The "custom" option will be required for more than one section (for example the multiple "noisy" option in the existing layout will never match with the new "Play a sound for" section)
• There is a high probability to detect a custom configuration for an existing user whereas this user don't care of this custom config, and they would prefer to converge to the new rendering

I think we should prompt the user that we have updated our notifications settings, and invite them to migrate their configuration to this new rendering (this should be slight changes). A wizard should be used to ask the user to choose an option in case of conflict between their existing config and the new options.
The user may refuse to migrate their configuration, in that case, we may display a message that the user decided to not edit their notification settings on this client (we may try to display their config with the new options and display the message only in case of conflict). When the user refused the migration, the option "Match default setting" is not displayed at the room notification setting.

[t3chguy]

Worth keeping in mind that migration is only one case for the "Custom" options, when a user is using non-Element clients options in those clients may cause Custom even post-migration.

[giomfo]

Worth keeping in mind that migration is only one case for the "Custom" options, when a user is using non-Element clients options in those clients may cause Custom even post-migration.

That's why I let the option to refuse the migration in Element, and let the user use another client to edit their push rules

[daniellekirkwood]

We had a conversation in the GYU room internally that discusses the plan ahead:

https://matrix.to/#/!aREzkHGCDRZFBtnnxx:one.ems.host/$mGV5nBFtsyiNcFM8HUOg0XB_odThNBPJlPrQAhcP660?via=matrix.org&via=element.io&via=one.ems.host

We will be able to map most people to the new design - where we are not able to map folks we will have a banner at the top of the page with a button to move over, as suggested.

@justjanne & @Johennes please add any other details if i've forgotten some and @amshakal will be able to give us the copy and component to use

[t3chguy]

banner at the top of the page with a button to move over, as suggested.

Is this at the top of the settings notifications tab or a whole top of the app banner? If the latter can we consider a toast instead, we killed app top banners a long time ago

[Johennes]

I think we'll need @amshakal to figure that out exactly but what you say is good input for it.

[daniellekirkwood]

This was a draft idea but for illustration purposes only, what we're talking about for banner:

From a product perspective it should be clear yet contextual