Provide mute and enable/disable functionality for notifications

[daviddossett]

As requested in #46676 and many other similar issues, I think it would be super useful to be able to mute notifications as well as enable and disable notifications for specific extensions.

Exploration

Here's how this could look:

• Expose a menu on the notification list header to manage notifications for all or specific notifications
• Expose a mute action on the notification list header that toggles the mute state. This could also be extended to mute for a specific duration (e.g. "Mute for 1 hour")

mute-enable-disable.mp4

I'm not happy with the icon choice for muting yet—let me know if there are any ideas here. I think the "bell with slash" icon is clear enough as a way to represent "muted" but I don't like using the regular bell icon for the mute action since it duplicates the main notification icon.

[daviddossett]

I played with a more scalable version of this using the quick pick + sections for core and extension notifications. I still need to see how muting and enable all/disable all would fit into this. Removed those concepts for the moment.

CleanShot.2022-03-04.at.11.04.37.mp4

[miguelsolorio]

I personally liked the context menu better since it's closer to the user's focus and quicker to parse, but understand the scalability issues with a menu (though we do use long menus in other areas). You could also look at directing people to Settings UI where there's more options for scaling and it persists across settings sync.

And to me, muting feels like a temporary state when you want to focus that goes away after some time (maybe configurable). I think the second layer of this is if we allow users to disable/mute by severity but maybe not for errors since those are pretty critical (info and warnings are more secondary anyways).

[daviddossett]

Good point. We could use submenus for long extensions lists to still feature distinct core and extension sections:

[daviddossett]

And to me, muting feels like a temporary state when you want to focus that goes away after some time (maybe configurable). I think the second layer of this is if we allow users to disable/mute by severity but maybe not for errors since those are pretty critical (info and warnings are more secondary anyways).

Agreed on muting. My sense is that it could be, at minimum, a toggle state to mute all notifications. Users would get a visual indiciation on the notification bell/center that they are muted. Later, we could add durations e.g. "Mute for 1 hour" and even for specific sources "Mute this extension". I'll tune up the interaction/icons there.

I think the second layer of this is if we allow users to disable/mute by severity but maybe not for errors since those are pretty critical (info and warnings are more secondary anyways).

I'm still chewing on how to integrate severity as a dimension. Is the idea that we take the filtered notifications (let's say core notification categories A and B and extension X and Y are enabled), and then filter them further by severity? In other words, I could enable notifications from certain sources, but I could also then filter to only show warning notifications?

[miguelsolorio]

I think this will be something we'll definitely need get feedback on and a great candidate for the ux sync, but my initial thinking is that Severity is actually the first level of hierarchy (i.e. don't show any info notifications) and the second level is Extension/Core notifications (i.e. don't show any notifications from XX extension).

I don't think we'd want to go down the matrix of mixing and matching of certain severity from certain extensions as that might complicate things. Keeping it simple is a great start.

[daviddossett]

Got it, that makes enough sense. I'll try a few versions to bring to the ux sync 👍

[daviddossett]

Here are a handful of explorations from this week looking at enable/disable and mute concepts:

Basic on/off states for each source

This shows a simple menu that enables users to toggle notifications on/off for a specific source. The list is grouped into notifications from core and notifications from extensions.

basic-enable-disable.mp4

With severity

Here I include severity as a dimension to filter all notifications by. If I uncheck "Info" notifications, I won't receive info notifications from any source, even if the source remains enabled.

with-severity.mp4

Using Quick Pick

This is an alternate version that uses the quick pick to handle long lists better. The multi-select style follows the new "Customize Layout" quick pick with right-aligned arrows.

using-quick-pick.mp4

Mute specific notifications

This shows the ability to mute a specific notification for some amount of time. It also shows a shortcut to turn off notifications from that source.

Using the existing context menu

mute-with-existing-menu.mp4

Using a dedicated context menu

mute-with-dedicated-menu.mp4

Mute all notifications (a la Do Not Disturb)

This shows a global command to toggle a global mute on all notifications. Users could mute them for some preset amount of time, or indefinitely. Note the bell-with-slash icon indicating a global mute state in the status bar.

mute-all-notifications.mp4

[isidorn]

Cool explorations. I personally prefer if we could use the context menu near the notifications center, and not go to the quick pick. But I think we will know much more once we have something to try out. Since the context menu might not scale, and we we might figure that out once we try it.

Mute all notifications -> we could also introduce alternative clicks in the status bar. Thus alt+click on notifications center would mute / unmute it.

Thinking about info / warning / error. I would not do this in step 1. My feeling is that the users will just choose to mute info and warning. So let's just behave like that out of the box, and if that needs fine tuning we can add control for this as well.

So I am suggesting if the user mutes all notifications, or notifications from Python that they still get error notifications from that source. We'll see if extensions abuse this - I would expect not.
Also I believe that zen mode currently mutes all notifications but allows errors.

[daviddossett]

I personally prefer if we could use the context menu near the notifications center, and not go to the quick pick. But I think we will know much more once we have something to try out. Since the context menu might not scale, and we we might figure that out once we try it.

👍 That's my preference as well.

Mute all notifications -> we could also introduce alternative clicks in the status bar. Thus alt+click on notifications center would mute / unmute it.

That would be a nice shortcut! Still unsure if an icon button on the notification center's title bar is also a good idea. Certainly more discoverable but adds clutter.

So I am suggesting if the user mutes all notifications, or notifications from Python that they still get error notifications from that source.

I've been thinking about this too. Errors seem like a different class of notification altogether. I agree that it would be dangerous to mute them entirely. It does somewhat confuse the notion of muting or toggling notifications since it's really only just some of them.

@bpasero curious to hear your thoughts here too.

[bpasero]

Yeah, not muting errors sounds reasonable to me if the user selected an action to "Mute all". Though I think we do silence even errors when in zen mode, isn't it like that @isidorn ?

[daviddossett]

[isidorn]

Yeah we show errors as David found in the setting.
For reference here's the code https://github.com/microsoft/vscode/blob/main/src/vs/workbench/browser/layout.ts#L1107

[bpasero]

Then it makes sense to behave the same, given we likely had this discussion before already.

[daviddossett]

Cool. I'll consolidate the feedback and bring some updates to the next UX sync

[daviddossett]

Here's the latest version after collecting feedback last week:

• Boolean state for each notification source
• Global boolean state for all notifications. This version adds a dedicated item to the menu so users can get visual feedback that it applies to all notification sources when toggling. Also note the status bar item indication once muted.

As I've thought about it more, I think it was too complicated to have both on/off concepts as well as mute/unmute. I'm now thinking about all of it as one single concept. We can call mute, on/off, or whatever else resonates.

CleanShot.2022-03-14.at.11.34.44.mp4

[isidorn]

Looks good to me!
Have in mind that clicking on the context menu item will actually close the context menu (like all our other context menus). I think this is the best experience since the native context menu (on mac) blocks the renderer, so there would be no visual change (hiding the notification) before the context menu get closed.

[miguelsolorio]

I also wonder if we need some sort of indicator on the notification itself that everything is muted, can be hard to tell just by the status bar icon. iMessages shows a little bell w/ a slash when it's muted:

[bpasero]

One thing that may have an impact on the design is that today we don't have the full set of extensions or core-categories that send notifications upfront. We only know about the existence of a notification when it is being sent. We could introduce some kind of notification category system for our core notifications but for extensions no such API exists.

The consequence is that we cannot easily provide a unified menu with notifications to enable or disable unless the extension has sent a notification. We can maybe remember that an extension has brought up a notification to be able to show the extension in the menu at any time, but for the user this would mean the menu is quite dynamic and would grow over time.

As a user I would probably expect that I can disable notifications from the notification itself (either the toast or in notification center). I imagine that a spammy notification appears over and over again and draws my attention. I would then look at a command inside the notification to disable it for good. We would still need the overall filter menu to allow the user to bring the notification back.

Just to compare with how it works with status bar entries: you can hide an entry by right clicking the entry (this would be the analogy to being able to mute a notification from the notification itself):

And then when you right click on the empty space in the status bar, a menu allows to bring it back:

I am still not entirely clear about the difference between muting notifications and enabling/disabling. If I understand correctly, muting would disable all notifications for a time period while enabling/disabling would be permanent but limited to a core category or an extension? I wonder if we really need both to begin with. My feeling is that being able to disable notifications per category might help sufficiently enough that muting is not needed?

And would we still allow access to notifications from the notification center even when muted or disabled? I see no reason for not allowing access because it would be a fallback solution to figure out what is going on when an extension really needs to communicate something and the user has muted or disabled the notification. That said, I am not entirely sure that we need to render notifications dimmed in the center that are disabled.

Overall I think we decided that error notifications are never impacted, neither from muting nor from disabling.

[daviddossett]

Great questions/feedback!

We only know about the existence of a notification when it is being sent. We could introduce some kind of notification category system for our core notifications but for extensions no such API exists.

Good to know. How would it look if we were to attempt to recognize which extensions send notifications? Would it need to be opt-in? In other words, would we need to rely on extensions contributing something like sendsNotifications? Or could we somehow pick through the code for instances of notification API usage? A dynamic list would probably be a bit jarring for a user, so I think it would likely need to be all or nothing to be useful.

As a user I would probably expect that I can disable notifications from the notification itself

Agreed. I think it would be super useful to have a baked in "Don't show again" for specific notifications instead of extensions having to expose that themselves. I also like the idea of having a shortcut to turn of extensions from that extension's source e.g.

I am still not entirely clear about the difference between muting notifications and enabling/disabling.

In later explorations I've focused more on a simple on/off model given the mild confusion the "Mute" concept has causes. The basic idea would be to silence a specific notification or all notifications for a temporary amount of time. As I've thought about it more, I think this cound be introduced later as a global state. I think it's less useful for specific notifications or sources. It could look something like:

And then we indicate the state somehow:

And would we still allow access to notifications from the notification center even when muted or disabled? I see no reason for not allowing access because it would be a fallback solution to figure out what is going on when an extension really needs to communicate something and the user has muted or disabled the notification. That said, I am not entirely sure that we need to render notifications dimmed in the center that are disabled.

That was the idea. My sketch for this was to indicate the muted state in the menu and to give a visual indication that the on/off states for each source have been preserved, but are temporarily affected. Unchecking the muted state would re-enable the menu items below:

[daviddossett]

After showing these various concepts to various teams this week, the general feedback has been:

• Lots of support for the general idea of notification management.
• Could be very confusing to have all notifications turned off for an entire extension. Many information and warning notifications serve as core interaction points for an extension.
• Hard to tell difference between on/off and muting.
• Support for the idea of a "Do Not Disturb" mode. This would be the equivalent of the "Mute All Notifications" mode pictured above.

[bpasero]

How would it look if we were to attempt to recognize which extensions send notifications

I do not think we can do that, esp. since declaring such a capability needs buy in from extensions. I think we have to plan a UX solution without knowing the extensions that do send notifications. Alternatively we could just show all extensions in the menu that are installed, but it would not be accurate either.

I think it would be super useful to have a baked in "Don't show again" for specific notifications

Again, we couldn't really do this without new API to have some kind of identifier for the notification.

[daviddossett]

This morning's discussion on language status had me thinking about another possible option for dealing with notification noise. What if there was a setting to simple turn off the toasts and instead rely on a more noticeable animation on the bell in the status bar?

We would still allow errors to come through as toasts as discussed above. But this might be a less risky way of minimizing annoyance without swallowing important notifications entirely. This way we also don't need to know about all extension sources/types ahead of time.

cc @jrieken @bpasero

The actual animation/pattern here can change—more just thinking about how we can extend whatever we land on for language status to other areas like this.

[isidorn]

@daviddossett cool idea, let's try it out!

[daviddossett]

@daviddossett cool idea, let's try it out!

I'll see if I can get this working in a branch later in the month 🙏

[bpasero]

Happy to review a PR in that area.

[bpasero]

Fyi just realised we can currently not snooze/hide error notifications (not sure whether this was planned or not) because we use them to show errors when saving a file. I noticed this while looking into #150931. Even if we turn some save notifications to dialogs, we still have the case of auto save failing and in that case I would never want to bring up a modal dialog.

tl;dr; error notifications need to get through always. Or we need to find a way to enlist certain critical notifications to show even when snoozed. But then again, extensions may have a similar problem so it is only fair to allow all error notifications.

[isidorn]

@bpasero makes sense to always allow error notifications.
If some extensions abuse this we can talk to them.

[daviddossett]

Yeah I tend to agree even though it does somewhat dilute the meaning of "Do Not Disturb".

It was also brought up that there are some extensions that rely information notifications for showing progress, accepting terms of use, etc. I think progress is a solveable problem since it can be displayed in the status bar or in a view. But I'm not sure what to do yet for extensions that use notifications as critical ux prompts. Forcing them to use a modal doesn't help as a workaround.

[isidorn]

@daviddossett those extensions should adapt to the changes we do... And I hope they will. We do not want notifications used as critical ux prompts.

[daviddossett]

Merged #149645 which adds a "Do Not Disturb" mode.

[bpasero]

Fyi now also made the changes in notifications land to allow to DND per source: