Vscode: UI - explore improved notification UX

[stevencl]

Goal: to explore an improved notification experience that resolves the current notification UX problems

Plan of action

• [x] Compile list of notification UX issues
• [x] Storyboards on two different options
• [x] Socialisation and discussion with team
• [ ] Customer research

[Srekel]

In case it's not on your list of things to fix: One of the more annoying things is that there's no way to disable popups, at least for plugins.

I've installed the CMake plugin to get syntax highlighting, but it complains about not having cmake installed/configured, and it pops up a notification very very frequently. Preferably all such notifications should have a "disable this notification" button. For extra fancy points, allow the user to disable just for the session, per file (?), and permanently in the user/workspace settings.

[NickCraver]

To throw a concrete case on that's growing:
When dealing with .NET Core especially, the amount of prompts to run a restore is absolutely maddening. Can this scenario please be coordinated and improved on?

Yes, VS Code, I know I just changed the project file. I was right here when I did it. PLEASE STOP PROMPTING ME BEFORE I'VE HAD A CHANCE TO EVEN DO ANYTHING. Holy crap that's an insanely annoying behavior. Some other plugins do the same. I absolutely want to mute some plugins outright, possibly based on verbosity level.

[HawkenKing]

hi @bpasero you wondered what type of warnings I was getting while using Unity.

By default Unity will add a few lines to the top new .cs files, these are in basically every file. The "using" includes are not always used, so appear with green squiggle underlines.

However every time you start up VSCode, it warns you about these.


The warning isn't really necessary, I'd trade access to my tabs for this warning anyday.

[bpasero]

@HawkenKing I see, you could also report this to their extension asking for a more pleasant experience (e.g. allow to never show the warning again).

[pieandcakes]

We also have an issue in the C++ extension where the users stop at some library code that the debugger "knows" the source path for but the user doesn't have that source on the computer. Our users would like a way to turn off notification for these files and I think a per file/filepath or per session method would be helpful.

[razvan-flavius-panda]

A very important issue with the notifications is being able to see full text for it:

A closed issue about it is this one: https://github.com/Microsoft/vscode/issues/31815

@stevencl Could you please add the required change to this issue?

[CTimmerman]

I suggest a notification log tab. (https://github.com/Microsoft/vscode/issues/32136)

Issues related to this one (which appers to be a duplicate of https://github.com/Microsoft/vscode/issues/1135):
https://github.com/Microsoft/vscode/issues/37038 (would keep https://github.com/Microsoft/vscode/issues/32034)
https://github.com/Microsoft/vscode/issues/8073 (parent of this one)

[razvan-flavius-panda]

@CTimmerman A notification log tab would be great.
In addition to that, there should at least be some way to expand the pop-up notifications text either inline or by redirection and focus to the notification log tab.

[LeoLozes]

Sorry if it shouldn't go here, but it's something I've been thinking about for a while: sometimes it would be nice to have small notifications when something has worked (for example, number of files updated when a git pull was successful, or number of files pushed after a git push).

Most of the times when something works VSCode is simply silent about it, and you just assume that since it didn't showed any error, well then, should be ok.

JetBrains products (for example) handle it quite nicely:

[sambigelow]

I have one extension that I really like. My only problem is that it sends a ton of popup notifications. It would be great if I could just disable a certain extension from notifications.

[stevencl]

We would like to share our design proposal for feedback.

Introduction

To begin with, we'd like to describe the key problems that we aim to solve with this iteration. Today, when notifications or other messages are presented to the user they are shown in a short, wide strip at the top of the screen:

There are several problems with this design. We aim to tackle the following problems with this revision of the notification UX:

• Once a notification is dismissed without taking any action on it (e.g., by pressing Esc, pressing the Close button), there is no way to retrieve it later. You are effectively forced to keep the message around until you are ready to deal with it.
• The action buttons are all squashed up together at one side of the message with no separation between the buttons.
• If the message is truncated due to lack of space, there is no way to see the full message without hovering over the message.

As well as solving these problems, a good notification system should make users aware of notifications without distracting or disturbing the user.

Messages and Notifications

In VS Code, some notifications can be safely ignored or postponed while others require more immediate attention. Our design needs to distinguish between these. We call those that need more immediate attention messages and those that do not, notifications.

Messages

We propose to show messages that need more immediate attention like so:

Messages are shown expanded such that the full text of the message is shown, the source of the message is displayed, and the full set of actions are visible. These messages remain on screen until the user dismisses the message or takes an action.
Note the use of an icon on the left hand side to provide some indication about the intent or the source of the notification or message.

Notifications

In contrast, notifications that do not require immediate attention are shown like so:

Notifications are collapsed by default and will fade out from view within some specific period.

If the user wishes to interact with such a notification they can click on it to expand it and see any actions that they can take:

The notification or message can be repositioned by dragging it left and right, similarly to how the debug toolbar can be repositioned.

Notification Centre

If the user dismisses a message or a notification without taking any action on it, they can view that message or notification again by opening the VS Code notification centre (via some visible affordance in the UI or a keyboard shortcut):

The notification centre shows all messages and notifications that the user has not taken any action on.

Messages are shown at the top with the most recent one at the top. Notifications are shown underneath the messages.

The notification centre will have a maximum height (likely half the height of the window). When there are more notifications or messages than can be shown the user can scroll through the list.

One button at the bottom of the notification centre allows all notifications and messages to be dismissed. The intent is to minimise the number of controls that are exposed by the notification centre.

Most of the interaction will take place within the notifications or messages themselves.

Notifications can be expanded and collapsed at will while the notification centre is open. Messages remain in expanded state and cannot be collapsed.

Notifications or messages can display a progress bar if they are reporting on some long running operation.

When an action is taken on a notification or message it will typically disappear from view. For example:

We know that many people would like a way to manage notifications and messages so that for example, certain notifications are not shown.

As with most other things in VS Code, we propose that this level of control be provided through a group of settings. These would allow users fine grained control over which notifications should be displayed.

[CTimmerman]

For important stuff, a draggable, resizable, copyable, modal dialog like in Windows would be nice. For everything else, a notification center like in Windows. Both can be done cross-platform in Code.

[levrik]

I think the new layout for notifications (especially with buttons) is too big. Loved the old one for it's obtrusiveness. The new one looks a bit bloated (even though it has the same content).

[borekb]

• Same first impressions as @levrik, the new notifications feel heavy. One-liner without too many colors is what I'd prefer, most of the time.
• 👍 for Notification Center.
• Could it be implemented like the Problems panel? The current floating thing doesn't look like anything else in VSCode.

[mwalton-esendex]

My big concern would be what we see on Android - apps get to choose what the default priority of their notifications is, so most of them set them to maximum priority, when they actually aren't. Are VS Code extension authors going to do the same thing?

Android has user-level controls to override notification priorities. They're not perfect but you get to deal with some of the more annoying stuff at least.

A big popover notification centre introduces a new kind of UI panel - is that really necessary? I'm thinking something more like what thecodingdude suggested in a sidebar would be good, or something which opens in its own tab and could luxuriate in all the space available there. Popping up a panel over everything means you're subject to all the usual issues with something that may or may not behave like a menu - accidental out of area clicks closing it - or out of area clicks _not_ closing it, which is a surprise because it looks like it should close when you do that.

The other thing that is annoying about notifications is that they cover up the tab bar, which this proposal doesn't even acknowledge as an issue. Even if the notification is going to go away in its own time, it's still sitting over the bit I want to click on and thus getting in my way. There have been various comments here about various extensions producing far too many notifications, and that problem is never going to go away, so we need a notification system which can make those extensions as minimally annoying as possible.

So my suggestions are:

Notification centre or whatever you call it is either a new sidebar pane or lives inside a standard tab.

The less important notifications don't appear over the tab bar.

If a notification is associated with a particular tab, it appears within that tab's UI. Notifications triggering for tabs in the background should cause a marker to appear on the tab so the user knows there's something over there to have a look at. I suspect association with specific tabs is not something the notification system understands at the moment though.

The example given of a notification requiring action by the way is not something I'd consider important enough to need that. For recommended extensions that'd be the perfect use for an in-tab notification, which might appear by pushing the tab's content area down a bit and being a bar across the top of the tab.

[stevencl]

Thanks for all the feedback so far. This is very helpful.

We had considered a design where the notification centre exists as a viewlet inside the side bar or as a panel on the horizontal panel. We discussed the pros and cons of these options amongst ourselves and as a result decided to go with the completely separate panel. Our main concern with the side bar or horizontal panel was that the notification centre would then be a permanent fixture in the UI and would be something that would take space or real estate away from other parts of the UI whenever you wanted to read a notification. For example, let's just say you are in the SCM viewlet when a notification comes in. If you click on it (and the notification centre exists as a viewlet) you would be taken out of the SCM viewlet and moved to the notification centre. This takes you out of your context which then makes it harder to get back into context once you have dealt with the notification. It would be even worse if the notification was related to the SCM viewlet. We wanted to reduce the disruption involved when dealing with notifications and so landed on the idea of the notification centre being hosted in it's own unique panel.

One thing that I should have expanded upon in my description of our design above is that with the addition of the notification centre, we can now provide many more ways to customise how and when notifications are displayed. With the settings we are considering you could decide that you never want a notification to be displayed automatically. Instead, you just want them to accumulate in the notification centre such that you can read them when you choose by clicking on the affordance to open the notification centre. So if you detest being bothered by notifications, you could decide to turn them off. Or, you could choose to turn notifications off from particular extensions. Or notifications of a particular type. We haven't fleshed out these settings yet, but this is how we want to resolve the issue of managing notification spam. Notifications will always land in the notification centre but the extent to which you are told about them will be configurable by you.

Regarding the size of the different boxes shown in the mockups, when we started working on these designs we realised that there are some cases where our API is being used not too display a notification but to prompt the user for some action or a choice. In some cases, the wrong API is being used and the native dialog should be used instead. (For example: https://github.com/Microsoft/vscode/issues/42050).

But there are legitimate cases where you want to ask the user for some input but you don't want to block them with a modal dialog. So in these cases we are proposing to use the same UI to show these modeless dialogs or messages. We understand the concern with these becoming very obtrusive so we hope to set expectations and best practices by carefully combing through all the places where we prompt the user in this way and making sure that this is the correct thing to do. Our hope is that in the majority of cases you will see notifications instead of messages. So the disruption will be kept to a minimum. We just don't think we can get away with not offering this option.

We do recognise that notifications cover up the tab bar - we are proposing that notifications disappear automatically after a set period of time so that this disruption is reduced. Another option we have looked at is whether or not notifications can appear next to the affordance that shows the notification centre. So if the notification centre was in the status bar, the notification would pop up from above the status bar. No matter what we do, notifications will cover something. In this case, it would cover some of the editor and sidebar area. So we haven't come up with a way to display notifications such that they don't cover something in the workbench. Making notifications disappear automatically after some period of time is one way we think we can reduce the disruption caused by a notification.

Does this resolve any of the concerns? If not, let us know what concerns remain and why and we will look into ways we think we might be able to accomodate those concerns while still satisfying the other goals of this redesign.

[mwalton-esendex]

Thanks for the detailed feedback, it's good to see some more of the reasoning.

It's clear that it's not possible to have transient notifications that don't cover up _something_. Pick your path of least annoyance I guess. For me, the tab bar is not something I want to have to wait to get access to (or interact with something and make decisions on it). Other people may feel differently.

[bpasero]

@mwalton-esendex we also envision that you could move (and maybe resize?) the notification widget. E.g. to move it to the far right of the editor tabs area (similar to the debug toolbar). Would that improve things?

[mwalton-esendex]

@bpasero Perhaps. I think once it's up though it's not enormously relevant where it goes because it's going to be your primary focus until you deal with the notifications you want to deal with. My doubt about it was whether it was necessary to introduce what feels like a new kind of overlay.

[bpasero]

@mwalton-esendex can you clarify what you mean with "new kind of overlay"?

[stevencl]

Thanks @thecodingdude, I tried to capture what you described in my earlier post. You will have the option to never be bothered by notifications. They will just accumulate in the notification centre. We will have a number of affordances for showing the notification centre.

[borekb]

Thanks for the detailed explanations. A couple more points:

1. Did you look at how JetBrains IDEs do it? It's in bottom right corner for "full" notification, then it collapses to a small icon in status bar, clicking of which shows a standard panel. I quite like it, did you consider this design and was there anything you didn't like?
   
   
   
   • BTW I personally don't mind the current visuals of notifications at all; I agree that there are UX issues to solve but the visual appearance of them is fine by me.
   
   
2. You have a gear icon in the bottom left corner in VSCode, already showing some notifications sometimes. Maybe it could be used somehow?
3. More radical suggestion: GitLens does pretty amazing things from the Quick Pick (Ctrl+P) UI, maybe notification center could be something like Show notifications command + a list of notifications in this list.
4. Status bar also sounds like a semi-natural place for notifications to me.

[mwalton-esendex]

@bpasero The mockup of the notification centre appears to me to be a new kind of overlaid UI element which doesn't currently exist in VS Code. That's what I meant.

[bpasero]

@mwalton-esendex not really, we already have such a UI today with the current notifications, how is the notification center different (except for having the ability to scroll and maybe looking a bit more polished)?

[mattacosta]

With regard to the location of the notification, I would prefer the status bar area, or possibly a new button where the gear icon is. Yes, it will cover something, but a smaller percentage of the editor and sidebar area would be covered compared to the tab bar, which makes it less likely to cover something important.

Like what @mwalton-esendex said, I also do not want to wait any amount of time to click a tab either. The notification needs to last long enough for someone to be able to read it, but if it is a notification that I have read in the past or expect (and is important enough that I do not want it to always be hidden) then I may already be on my way to fixing it, and could be hindered by the wait period or extra click to dismiss the notification.

As for resizing and moving the notification area, previous experience with the debug toolbar says that it would not work. For example, I could be working with tabs open on the left or center of my screen, and notification X comes up, so I move it to the right. Later on, I'm working on tabs to the right, and notification Y comes up, so I move it to the left. Rinse and repeat. Resizing bigger doesn't solve anything, and resizing smaller would probably hide the message as well.

Another alternative would be to get rid of the gear icon and its menu, and replace it with something like Window's notification button. It would open a sidebar-like overlay that has the change theme, settings, and check for update buttons along the bottom as well as notifications in the main area.

[NickCraver]

It's hard to judge the auto-disappear thoughts on if they're be less intrusive on tabs with the images presented, but it could certainly help. However, the much larger notifications than current presented feel like a regression. While my main complaint is certainly the blocking on the tab bar currently, the overwhelming theme is: notifications happen too often and are "in the way". I'm not sure the designs presented here allay that any.

Take a look at Visual Studio, the drawer collapses and often all I see is the flag icon. It's prominent, it says click me, and almost always I ignore it until I want to see them. I should be the boss of my IDE, not the other way around. With the notifications taking over UI whenever any addon says they should we are putting the control of that section of the UI in control of everyone but the user. This feels very wrong to me. It's giving addon authors too much to play with and we've already seen how that goes. And I don't blame them necessarily, because it's not their fault specifically or solely, but it really adds up.

[bpasero]

Since I am seeing a lot of people complaining about notifications covering the tabs when they show up, I want to make one thing clear: one difference of VS Code to VS (or maybe other IDEs) is that we chose to avoid modal dialogs as much as possible in favour of lightweight notifications with action buttons within. Always hiding notifications behind a flag in the status bar could mean a severe regression for the user experience, for example if an extension uses a notification with buttons as a way to drive a feature. If you would never see this notification in the first place you would probably think that the extension is broken.

We never distinguished notifications that are just "fyi" from notifications with buttons that require some input. This has the advantage that we never block you from doing your task, even if a notification asks for input via actions (as opposed to showing a blocking modal dialog that you have to react to no matter what). The disadvantage is that we are covering a prominent location over the tabs with notifications to draw attention to.

I think we cannot simply switch to a model where notifications are hidden by default or even at a different location that is hard to notice with our current model where notifications are both "fyi" and also potentially asking for input.

An alternative solution that we discussed was to distinguish notifications having action buttons (aka "message boxes") to notifications without and use different UI for them. This did not seem very appealing because then you suddenly have to deal with 2 different things that potentially are hard to distinguish (what makes a notification a message box and what makes it a pure notification?). Even if we had API for extensions to bring up the one or the other, chances are high that an extension would always chose that API that makes a notification more prominent by picking the "message box" type of notification.

[borekb]

@bpasero Agree that notifications (incl. "message boxes") need to be fully visible for some time. Again, I think that Jetbrains IDEs do this well: full notification in bottom right where it usually doesn't cover anything important, then it disappears after a while and there is a small status bar notification that leads to "Notification center".

[bpasero]

Imho it is very weird to popup a message box asking for input anywhere else than top and center of the screen.

[borekb]

That is true. Do you see message boxes that _require_ input often? I'm not quite sure but think that most of the time, the notifications I deal with are:

• There's been a new major version of something. Quokka and Git Lens do this, I am not too bothered as this happens once or twice a month (and I actually like reading release notes :) ).
• If I install some extension that needs GitHub access, it prompts me to enter my Personal Access Token. I would call this a "message box" in a sense that I should take action.
• TypeScript SDKs message comes up from time to time.

That's probably it. Maybe I'm lucky but I don't see that many notifications in VSCode, and their minimal display in the current version make them quick and quite pleasant to deal with. I'd still appreciate some "notification center" and small UX improvements but I'm not too unhappy about the current state.

(For the record, I've got 28 extensions installed.)

[NickCraver]

I think we cannot simply switch to a model where notifications are hidden by default

Can we at least have the option for this? The main complaint is notifications are unthrottled, in complete control of addon authors, and in the way blocking the tabs. The proposals I see here (unless I'm missing something!) make them larger (blocking even more area) with the tradeoff of making them disappear faster. Notwithstanding on whether that tradeoff is a good one or not - it doesn't address any of the problems I have on a daily basis with notifications.

Examples:

• Windows allows me to turn them off.
• macOS allows me to turn them off.
• VS allows me to hide them easily (and doesn't block anything when showing them).

If we're unwilling to not block what I was launching the editor to do in the first place, please at least offer the setting letting me do it. The user experience with notifications is broken at the moment, they actively block what I was trying to do: work. I'll happily take (via non-default setting) a rare break by hiding them by default. Or for settings: make the duration they're shown (before fade out) configurable, and allow it to be 0 or almost zero. This allows me to see a flash that they're there but not long enough to block with minimal proposed design changes.

[LeoLozes]

As @borekb said, I think there are very few notifications that really need user input. It's usually an optional link / action.

Intellij Idea usually show me these notifications in the right bottom of the screen when:

• There's a new version. Optionally, I can choose to upgrade.
• Number of files pulled from / pushed to git, with a link to details.
• Unhandled exception with a link to send it to their website.
• There's some framework automated configuration available for the project. I can go check it clicking in the provided link or choose to do it later.

The other stuff is more like pop-ups that can be used for several things (refactors, git options, searches), that are also used as message boxes (screen centered) with OK / Cancel that are used in very few cases:

• Opening a new project in the same or other window.
• Confirmation to exit the IDE.
• ... not much else

It makes sense for the message boxes that _require_ action to be in the center of the screen, but I guess the majority will have some kind of optional action and then should be positioned on the top / bottom right.

[mattacosta]

@bpasero I don't think anyone actually wants notifications to be hidden by default, just that they should show up in the bottom left or bottom right corner. You also make a good point about the difference between a notification and a dialog box. To me, a notification is simply a title (either customizable or set to the extension name) and message. There would be no (textual) buttons, but the notification could have an associated action if desired. A message (or dialog) box would include buttons, and these should still show up in the top center.

So for example, I think the ideal notification UI would be similar to that used by Windows and Chrome. There would be two types:

1. Simple notifications that just go away.
2. Notifications that are actionable (this could be by including a message saying as much and making the notification area clickable, or by having clickable links, or some other method), and would trigger a dialog box.

A new device notification in Windows 10.

The key part of the second type is that by clicking the notification, the user has indicated that it is OK to block other important UI elements because they want to take this action. This is contrary to the current scenario where extensions force users to deal with something before getting back to their intended action (i.e. clicking tabs).

As you mentioned though, having something like this available, and whether it is actually used are two different things and I'll leave that decision up to you guys. I do however think that extension authors (or those contributing to extension repos) would choose the best option if both the UI was done well and the API (both existing and new) were intuitive enough.

[thecodingdude]

I posted this before, but is there any reason why something like this couldn't be used?

I think it'd be the best of both worlds, easily hideable, can resize it, doesn't cover anything. It _feels_ like it's a natural place for notifications to live and doesn't disturb your workflow (unless it pops-up randomly).

[brianloweongit]

My view...
The obvious place for 'messages' requiring a response is high and centre, and it should stay until dismissed. Responses should accept mouse, touch or keyboard, so a good add-on author can enable the user to respond with minimal detraction from the interrupted task. (A bad author can abuse the feature but risks his users voting with their feet by uninstalling). Visuals should use the current theme, but allow custom icons, fonts, colours. (A good add-on author would deviate from the current theme only when necessary. Ugly or unnecessary visuals would quickly be punished by users uninstalling :) )

A 'notification' is quite different, and I like some of the suggestions above. The gear icon at bottom left is already a location for non-critical messages, and there's space to add a flag like the one used in Visual studio with a count of unacknowledged notifications. Showing notifications when requested as textual items within a document in the editor, with individual dismiss buttons seems intuitive (to me at least).

Having a notice pop up near the flag icon, then fade after a preset time leaving the flag counter incremented also makes sense. Maybe the popup could include a dismiss button (and shortcut key) for immediate acknowledgement. The length of time the popup stays visible should be configurable, with the option to never show at all - maybe differentiated by some classification or notification type?

[mattacosta]

@thecodingdude That was touched on by stevencl earlier.

We had considered a design where the notification centre exists as a viewlet inside the side bar or as a panel on the horizontal panel. We discussed the pros and cons of these options amongst ourselves and as a result decided to go with the completely separate panel. Our main concern with the side bar or horizontal panel was that the notification centre would then be a permanent fixture in the UI and would be something that would take space or real estate away from other parts of the UI whenever you wanted to read a notification. For example, let's just say you are in the SCM viewlet when a notification comes in. If you click on it (and the notification centre exists as a viewlet) you would be taken out of the SCM viewlet and moved to the notification centre. This takes you out of your context which then makes it harder to get back into context once you have dealt with the notification. It would be even worse if the notification was related to the SCM viewlet. We wanted to reduce the disruption involved when dealing with notifications and so landed on the idea of the notification centre being hosted in it's own unique panel.

Another problem with using a horizontal panel would be that it simply wouldn't look right on large monitors. A short message (which most notifications should be) would result in a lot of dead space to fill up the rest of the area. Also, if that panel is in addition to the existing problems panel, then opening a terminal for example would further shrink the editor area. Two stacked horizontal panels would easily make the editor area tiny when not in full-screen mode.

[mattacosta]

Here is another option for a new "toast" UI that tries to bridge the gap between the pure notifications, dialog boxes, and the VSCode API.

Clicking the notification could either open the notification center or be the same as the down arrow, which would expand the notification to full size (which would be good for long messages) and show additional buttons, such as a "report bug" button in the above image.

Theoretically, the existing showInformationMessage (or warning/error) methods could show this if the modal property is false, and use the existing UI otherwise. The same would be true for showInputBox and ignoreFocusOut, which would probably be similar to this (after expanding the notification):

[ashclarke]

If you were going to have a notification centre approach, I'd give a +1 for adding it to the action bar panels. Then it can be a non-permanent feature if people don't want it, hiding it via the right click menu as per the debug, git and other panes.

I think a side panel is a perfect target and is akin to the Windows action/notification centre.

Add a badge for the count of notifications, allow notifications to all be auto-dismissed when you close Code, via a setting in settings.json, and a Dismiss all button in the panel itself.

EDIT: If something _must_ have a response, or is a result of direct user action, then a toast of some sort would likely remain the best choice, even if it also goes in the notification centre.

[Nysosis]

One thing I've noticed from time-to-time, is that I don't always notice the notifications at the top of the screen.

This is usually when I'm pushing to a repository that requires authentication, I'll hit the sync button down in the bottom left, I'll get a standard windows dialogue that this is going to push and pull all commits, which I'm immediately aware of because; A) It's in the middle of the screen, and B) the colour scheme of it is a stark contrast to the colour scheme of VSCode, so its appearance sticks out more in my peripheral vision,I get the standard [Ok]/[Ok, and don't show again]/[Cancel] options (I keep this around for peace of mind that I'm not about to do anything stupid), I press [Ok], and direct my eyes to the bottom left of the window to watch the spinner to know when it's done. However if I'm required to enter my credentials then it just spins indefinitely whilst a dialogue has popped up at the top of my screen, out of direct eye-line, waiting for my credentials, and because this dialogue blends in with the colour scheme I don't notice it suddenly appear.

This could just be a one-off situation, and a fix would be to have the spinner change to a warning exclamation mark, that would then direct me to look at the notifications area (wherever it is), to see what the issue is.

[AdrianoCahete]

Most of my problems with notifications are that i'm not seeing it.
They stay on very top, one liner and black notification on black VSCode background. This is aggravated when you have big monitors (24"+).

I like the idea about toaster, like Android Studio does (and Windows 10). It's directly on user view, regardless of monitor setup.
Android Studio still keep some notification icons on bottom toolbar (which think is underused in vscode).

About Notification Center, the way that Visual Studio 2017 does is pretty good too.

[loganintech]

I don't see why it can't be a new section on the sidebar like Explorer or Debug. While I understand it may interrupt flow, dealing with multiple built-up notifications at the top of the screen is just as flow-breaking as doing a quick key command for the notification center. Perhaps Ctrl+Shift+C for 'Notification Center'. Right now that opens a native terminal window but that could become Ctrl+Alt+T for 'Terminal'

If that were the case, it would be quick enough to navigate to and from the panel quickly. Bottom line is I don't think larger notifications at the top are the way to go, regardless of how briefly they are displayed.

[ghost]

I'd personally like to see the UI affordance (in addition to whatever keyboard shortcut or menu option) for opening the notification center be an icon above the settings icon in the bottom left. This space is totally unused as of now, and putting it next to settings makes sense in how my mind groups information. The coupling of these two types of information is common, both android and windows put links/buttons to the main settings in the notification panels.

[loligans]

I'm going to describe what I think should be changed and/or configurable in VSCode. I refer to the "center" of the workspace a lot but what I really mean is the "top-center" of the workspace.

What I think is wrong with notifications.

• I don't like notifications showing up in the center of my workspace.
  
  
  
  • My opinion is the center of the workspace should be used for running commands from the command palette.
  
  
  • Putting notifications in the center of a workspace makes sense if you're on a phone or tablet (which we are not).
  
  
• The location of notifications seems a _little_ inconsistent to me compared to how the operating system and other applications behave.
  
  
  
  • In macOS notifications show as an overlay on the top right of the screen.
  
  
  • In Windows 10 notifications show as an overlay on the bottom right of the screen.
  
  
  • In Linux depending on your environment notifications can be anywhere.
  
  
  • In browsers like Chrome or Safari, notifications from websites show in the top right of the screen.
  
  

What I think should change with notifications.

• Notification location should be configurable in the settings.
  
  
  
  • Something like Top-Left, Top-Center, Top-Right, etc...
  
  
• Notifications should be expandable.
  
  
  
  • If a user runs a task to compile their typescript and it fails, an error notification should pop-up with a brief message of what went wrong and allow the user to click an arrow to expand the notification and show a stack trace if the trace was available.
  
  
  • Allowing notifications to be expandable would provide more valuable information to the user. It would also let them decide if they want to dismiss the notification or look deeper into it.
  
  
  • I should be able to interact with the body of an expanded notification. In the case of a stack trace if I CTRL+Click a file in the stack trace I would expect to be taken to where the error occurred. This is similar behavior to how the terminal behaves.
  
  
  • Personal Opinion: Expanding a notification in the center of the workspace takes up a fair amount of vertical screen real estate and thus makes the notification feel out-of-place. Having the notification off to the right side makes more sense because most people read code from left to right and by that assumption the notification would likely cover whitespace instead of their working environment; unless of course they have multiple editors open side-by-side.
  
  
• Notifications should have a configurable timeout.
  
  
  
  • Every notification should not require the user to dismiss them.
  
  
  • Having a timeout would be convenient for most informational notifications.
  
  
  • There are times notifications should not be automatically timeout because they _require_ user interaction.
  
  
  • As older notifications get timed out or dismissed newer notifications should slide up to the top.
  
  
• Notification types should be obvious
  
  
  
  • We should know the type of a notification just by looking at it. I like how Atom handles this by making error notifications red, warning notifications yellow, and information notifications blue. I don't have to read anything I just look and immediately know.
  
  
• Expanding a notification should have a setting to enable/disable wordwrap
  
  
  
  • If we receive an error and I as a user expand the notification to see the stack trace, I would like to be able to see the entire trace line-by-line without having the text wordwrapped.
  
  
• Similar Notifications or Notifications from the same Extension should be grouped together
  
  
  
  • Notifications should be grouped if many occurred in the same time frame.
  
  
  • Grouped notifications should show a count of the total number of notifications.
  
  
  • Expanding a group should show a scrollable list of notifications.
  
  
  • Closing a group should dismiss all notifications in that group unless it requires user interaction
  
  
  • If a user tries to close the group again all notification requiring user interaction should be dismissed
  
  
  • To prevent abuse extensions should be limited to an allowable number of notifications they can spawn in a specific time period. Something arbitrary like 5 notifications per every 10 seconds.
  
  

Thanks for reading

Let me know what you think.

[mattacosta]

@loligans Excellent job. I think you hit the major issues dead on.

As for the changes, here are some of my thoughts:

• Notification location should be configurable in the settings.
  This would be easy enough to do.
• Notifications should be expandable.
  Agreed, but not for the same reason. In my opinion, stack traces never belong in a notification, and aren't a good use-case. Full content like that would be like getting a news notification on your phone that contains the entire web page. In such a scenario, it would be better to just have a short error message and a "show error log" button that opens the output or terminal panel. That said, notifications still need to be expandable for extensions that try to send long messages.
• Notifications should have a configurable timeout.
  Agreed, but they should always have a timeout. By definition, notifications should never require user input. To expand the phone analogy, it would be like a notification that prevents you from unlocking the home screen until you acknowledge it. Something that requires input, would be a dialog box, which should have it's own distinct UI and in-your-face location right in the middle of the screen. Furthermore, if a notification with a required interaction were to show up in a corner, and the user didn't notice, then they would be confused as to why something isn't working.
• Notification types should be obvious
  This would also be easy to do.
• Expanding a notification should have a setting to enable/disable wordwrap
  I'm going to have to disagree on this one. Notifications should stick to being short natural language sentences that tell you what happened ("An error occured during...") or what needs to be done ("You need to configure the 'x.y.z' setting."). If something is complex, then that message should tell you where to find more information, but not actually contain it.
• Similar Notifications or Notifications from the same Extension should be grouped together
  This could also be done, maybe not right away, but eventually.

[OneCyrus]

why not use the native notification of the OS? e.g. chrome is going this route as well.

[bpasero]

We revisited our approach and now think that notifications can possibly permanently move to the bottom right corner to stay out of the way of the editor:

Some details of the approach:

• messages can expand/collapse to reveal potentially longer message text
• messages can show buttons and with that will show expanded by default
• messages can specify their source (e.g. for extensions)
• message text can include links (this avoids having to introduce "Read more" buttons)
• messages can have more actions under the "gear" dropdown, e.g. "Never show again"
• the message list is keyboard accessible and screen reader proof

Next steps are to implement the actual alerting of notification messages when they appear. Thinking is that they would appear also bottom right possibly with some animation to draw attention to it.

[mwalton-esendex]

@bpasero I really appreciate your willingness to revisit things based on our rather large volumes of feedback!

From my point of view this looks like a much better design and it certainly seems to address the issues I had.

[loligans]

@bpasero When a terminal window is open how should notifications behave?

I think notifications being in the top right corner would be a better location.

The reason is because:

1. Having notifications in the bottom right corner seems a little awkward because they might overlap the terminal, output, debug console, or problems panel.
2. Having notifications at the bottom of the screen forces newer notifications to show at the bottom while older notifications are at the top. This seems unintuitive to me.

Ideally newer notifications should show at the top and let older notifications fall down toward the bottom of the window.

What do you think?

[levrik]

@loligans What about moving the notifications above the bottom panels? So in the bottom right corner of the code view.

[loligans]

@levrik I think that is a better solution, but it doesn't address the notifications showing in reverse (ie. newer notifications on the bottom, older notifications on top).

People are use to newer notifications being on top and older notifications being on bottom. That is how it is currently done in the application. Changing that behavior is likely to cause confusion.

[mattacosta]

My initial thoughts:

• Is the "notification center" really just a show/hide button in the status bar or is that because this is still a work in progress?
  
  
  
  • An actual notification center would have sooo much more potential...
  
  
• Will there be a setting to change the location, or is the location somewhat bound to the status bar button?
  
  
  
  • A lot of people asked for this; I don't personally care as long as it isn't over the tab bar. If the sidebar is open, a left notification wouldn't even cover that much of the editor either.
  
  

@loligans What? The picture shows the 4th and 5th notifications being added to the top of the stack (ie newer on top, older on bottom). This is expected for notifications anchored to the bottom. The opposite would be true for notifications anchored to the top, otherwise you would end up with something like this:

Edit: You guys may also want to switch the arrow and gear icons to reduce the likelihood of misclicks that accidentally close the notification.

Edit 2: Removed annoying image.

[loligans]

@mattacosta Wow you're right I totally misinterpreted that gif. My mistake, I'm sorry.

It looked like when the notification was expanded that a new one was added to the bottom of the stack.

[bpasero]

Having notifications at the bottom of the screen forces newer notifications to show at the bottom while older notifications are at the top. This seems unintuitive to me.

@loligans Well we would show newer notifications to the top and not the bottom, same as Windows 10 does. Also, when new notifications appear, we would not push down the current notification you are hovering with the mouse (if any).

An actual notification center would have sooo much more potential...

@mattacosta If you are referring to making this notification center an actual view or panel, we have reasons to not do that (I think we already mentioned that). The main issue with going down that path is that it forces you to leave your context only to deal with notifiations. E.g. imagine you are in a debug session with the debug view open and the repl open as panel and you suddenly want to look at notifiations. You would loose either the debug view or the repl panel and have to get back to it afterwards. We want you to deal with notifications without leaving your context.

You guys may also want to switch the arrow and gear icons to reduce the likelihood of misclicks that accidentally close the notification.

I do not understand this?

I think having notifications at the top right would equally run into potentially overlapping something, either another editor or tabs or also the panels if they are moved to the side. I think we will always have a location where notifications overlap "something".

[mattacosta]

No, I'm not referring to an actual view or panel (and yes, stevencl did mention that). I was thinking more along the lines of a view-shaped overlay. Unlike the other views, it would slide in over the debug view/editor/terminal. When you're done, it would then slide out, and you could continue exactly where you left off.

Edit: Since a picture is worth a thousand words, here's a rough example that was still in my recycle bin. You'll have to use your imagination for the buttons, ideal colors, background blur effect, etc. The show/hide trigger would have been a new button, where the gear is now. Extensions could have also contributed custom buttons (in turn, this could have also reduced their need to put everything in the status bar too).

This is all extra though. Just moving the current notifications is good enough for me.

[bpasero]

I merged the majority of this work to master. Compared to the previous animation I showed, there is now support to fly-in notifications when they appear as well as support for long running operations within the notification:

Fly-in

Progress

This will be in tomorrows insider build so that we can start to collect some real feedback from using them. I am sure we will still tweak quite a bit of things, so do not take this as the final solution yet.

[eamodio]

@bpasero Its hard to tell from the videos, but what is the dismissal interaction mode. Is there a time-out and the notification goes away? If you click the close X are they gone? Can you dismiss something to get it out of your way, but have it stay in the "notification center"?

[AdrianoCahete]

@bpasero I miss the "dismiss" animation too, like when they appear, but in reverse or something like this.

[borekb]

This looks like an awesome start! Looking forward to trying that in practice, first impression is that they could be narrower.

[levrik]

@borekb Yep. I have that one too. It's too wide. At least on that resolution of the GIF. The first example looked fine with the larger resolution.

[mattacosta]

While it is looking better and better, I also agree that the size seems off. In my opinion, that width plus the added height of the ones with buttons, makes them look like glorified popups. Add in a wall of text, and you would have a quick way to make me want to hide stuff by default.

I see two possible issues with the "long running operation" one though. First, I wouldn't want a ~notification~ dialog box hanging around on my screen for a long time (there is a timeout right?). Second, the design makes it somewhat ambiguous as to whether the "x" acts like "cancel" and would stop the operation in progress too. If the message is dismissed though, can it still be shown via the notification button, or is the ability to stop the operation lost forever?

Finally, does the status bar really have to say "hide notifications"...

[bpasero]

@eamodio

Its hard to tell from the videos, but what is the dismissal interaction mode. Is there a time-out and the notification goes away? If you click the close X are they gone? Can you dismiss something to get it out of your way, but have it stay in the "notification center"?

Notifications will disappear after a timeout only if they carry no buttons to interact with. And then, the timeout is determined by the severity (e.g. 10 seconds for infos, 12 for warnings, 15 for errors).

You can press ESC to dismiss all toasts and they will still show up in the notifications center. If you click the X, the notification is gone for good.

I am not 100% sure we need another animation when the notification flies out. I am trying to keep distraction to a minimum and I think doing yet another animation just for the purpose of having an animation is odd. The initial animation makes sense to me to draw attention but I am not sure about a secondary one.

Btw I changed the width of the toast to be 450px (same as Windows toasts). The notification center will still show as 600px given that the user intentionally wants to deal with notifications.

Finally, does the status bar really have to say "hide notifications"...

Not necessarily. I just wanted to somehow indicate that the notification center is active. And since there is no global X button for the notification center to close it, I thought this would make it more discoverable.

[levrik]

@bpasero I would propose a subtle fade out animation when dismissing a notification. Should not distract too much but still looks a bit nicer.

[bpasero]

@levrik you mean an animation when the user explicitly clicks on the X or when the notification disappears on its own after a timeout?

[levrik]

@bpasero I would say both.

[Tekbr]

-- Sorry for the English, I used Google Translator --

@bpasero
1- I think the output of the notification is on the right instead of the down. Simulate Windows 10 notifications. And when they disappear, the other ones would come down, as it does today.

Notifications will disappear after a timeout only if they carry no buttons to interact with. And then, the timeout is determined by the severity (e.g. 10 seconds for infos, 12 for warnings, 15 for errors).

2 - I think the notifications that need our attention could be a little transparent after the predetermined time, getting the normal color as soon as you move the mouse over it and return to the transparent if you take the mouse.

3- What maximum number of notifications? What I mean is: would it be half the VSCode window?

4- [Suggestion] Make the Windows taskbar icon blink when a background installation has finished (and we need to restart VSCode - I think that would be interesting) - this would happen when VSCode is minimized.

5- A small detail: Put the notification a little further left to follow the scroll bar line. Place the nearest notification to Status bar. So when you turn off the Status bar it will be close to the taskbar.
See in the gif that there is a misalignment when the Status bar is enabled / disabled.

[levrik]

@Tekbr I kinda like the idea with making important notifications transparent after some time instead of letting them disappear.

[AdrianoCahete]

I am not 100% sure we need another animation when the notification flies out. I am trying to keep distraction to a minimum and I think doing yet another animation just for the purpose of having an animation is odd. The initial animation makes sense to me to draw attention but I am not sure about a secondary one.

Isn't about just to have an animation. It's because UX things.
When you animate to show that it's new and you click to close/ok/cancel/action (or timeout close), is expected a "close" animation, just because you have a "open" animation. It's a start/finish flow.
Without that animation, end user can be not understanding whats happened here. "Why the notification is gone?", "Where's the notification?", "Whats happened with that notification?" are the questions that the users will ask.

[bpasero]

@Tekbr currently the oldest notification would hide if the overall stack of notifications exceeds 600px, so it is not bound by number but rather by size (currently, we might want to change that).

@Tekbr can you explain where you see a misalignment with the notification center when status bar is disabled, for me it looks OK? I can check about aligning the center to the scrollbar of the editor, though not sure that makes sense, because the notification center is floating on top of everything.

@AdrianoCahete that is good reasoning, but it does not necessarily have to be the same animation that was used to show them. I find the fade-in animation quite heavy already and we might want to revisit that one (e.g. to fade an animation in from the bottom instead of from the right because the notification center is on the bottom).

[AdrianoCahete]

Yep, you can make any animation to dismiss, as long as user can clearly see that is dismissing. A small (0.3s~0.5s) timeframe animation is enough.
You can try a fade-out animation too, i think it's ok for that.

[Tekbr]

-- Sorry for the English, I used Google Translator --

@Tekbr currently the oldest notification would hide if the overall stack of notifications exceeds 600px, so it is not bound by number but rather by size (currently, we might want to change that).

@bpasero Thanks for the info!

@Tekbr can you explain where you see a misalignment with the notification center when status bar is disabled, for me it looks OK? I can check about aligning the center to the scrollbar of the editor, though not sure that makes sense, because the notification center is floating on top of everything.

@bpasero Here's the picture of what I'm talking about. Remembering that it is only a detail ... If you can not leave it as it is.

[Tekbr]

-- Sorry for the English, I used Google Translator --

4- [Suggestion] Make the Windows taskbar icon blink when a background installation has finished (and we need to restart VSCode - I think that would be interesting) - this would happen when VSCode is minimized.

@bpasero For those who have the active Status Bar it is easy to see that there have been notifications. But for who deactivates? Or when we have ZenMode enabled (if using two monitors)?

Even for those who leave the Status bar enabled, it would be interesting to have a contactor in the taskbar icon. Showing notification.

Here are some examples that could be put (remembering that I do not know how complex this would be to implement).

[bpasero]

@Tekbr I actually intentionally wanted to leave a gap from the status bar (or bottom window) to the notification center, but we can revisit that to make it more obvious that the center belongs to the status bar entry. Though it can also be opened when the status bar is hidden, so in that regard it is also independent from the status bar.

As for feature suggestions like the task bar decorations I think we should start to separate them out into individual issues. It gets hard to track that here in the issue. Anyone feel free to file issues for individual things (both bugs or features) as you like. Make sure to not put more than one issue into a single issue 👍

I think the task bar decoration would not work unless it was clear from within the app how to dismiss the badge. And if the status bar is hidden, this would be hard.

[PKief]

@bpasero I just would like to mention that the name of the source is overlapped by the buttons which does not look very nice (at least in my case):

Maybe you could use dots for very long source names with (text-overflow: ellipsis)

But all in all I really like the new notification concept.

[AdrianoCahete]

Maybe you could use dots for very long source names with

Or just move the "source name" to a line below, leaving the "button bar area" just for buttons.

[Tekbr]

-- Sorry for the English, I used Google Translator --

@bpasero Thanks for your response! Let's wait for the opinion of some people, to be able to create new cases. I believe that after a formed opinion you can extract yourself to avoid duplicate cases.

@Tekbr I actually intentionally wanted to leave a gap from the status bar (or bottom window) to the notification center, but we can revisit that to make it more obvious that the center belongs to the status bar entry. Though it can also be opened when the status bar is hidden, so in that regard it is also independent from the status bar.

About the border on the bottom and the direct part (next to the scroll bar). If you stay very full you can leave as is, they are small details even. Your explanation with Google Translate was not very clear. 😢 Sorry. 😊 😊

About the notification in the taskbar, since the Status bar is hidden I thought of a temporary icon above the gear. It would have the same function as the icon in the status bar. If the person has Status bar active, this icon will not even appear.

By clicking, it would show the notifications and also hide. If you have read all the notifications this icon will disappear !! And it would delete the notifications in the taskbar.

And someone disables this bar, I have no idea. 😆 😆 😆

Maybe you did not show any notifications in the taskbar, only the blinking option, without the indicator numbers.

Any other ideas?

[eamodio]

@Tekbr I really like the look/idea of having the notification center icon/badge in the activity bar rather than the status bar.

[Tekbr]

Or just move the "source name" to a line below, leaving the "button bar area" just for buttons.

-- Sorry for the English, I used Google Translator --

Or put this option to show / hide the rest of the text by scrolling the buttons.

[Tekbr]

@Tekbr I really like the look/idea of having the notification center icon/badge in the activity bar rather than the status bar.

-- Sorry for the English, I used Google Translator --

@eamodio I think the current position is more intuitive, since the notifications appear that position. That is, you would not have to move the mouse many times. Everything is very close.

I'm glad you enjoyed it, but vote for this option as a secondary if Status bar is disabled.

But I believe it is possible to have a choice.
Example:
"workbench.notification": Status Bar or Activity Bar

@bpasero Do you think it's possible?

[kumarharsh]

Would the 'bell' icon not be more suitable for notifications instead of the megaphone? In my mind, it seems to denote 'feedback' (Uservoice might have spoilt it for me 😉)

[stevencl]

Thanks for all the feedback on the notifications UX. We really appreciate all your suggestions and the time you have taken to help us make this a better experience.

I'll respond to the recent comments and issues here, but as @bpasero has suggested, we'd really appreciate it if you could create new issues for any new suggestions you have or anything else that comes up so that we can track them more easily.

Animating when closing a notification: I don't think this is necessary. We don't animate anything else out of view when closing it. Clicking the close icon and having the thing you click on disappear is sufficient feedback I believe. The reason we animate it in is because the user didn't take an explicit action to make the notification appear. So we have to do something to attract the users attention. But we don't when closing it because that was an explicit action by the user.

Detached from the status bar: we are still working on the notification centre and will be working on additional capabilities such as adding UI to dismiss all notifications in one go. Once that UI is in place it might make the notification centre look less detached from the rest of the workbench.

We could choose to position the notification centre affordance in the activity bar but I think we would want to show the notification centre next to the affordance. Thus this would possible obscure more code if the activity bar is on the left hand side as we would then show notifications on the left. But that could be an option I suppose.

Regardless of where the notification centre affordance is displayed (status bar or activity bar) we have commands to show and hide the notification centre. So that allows users who want to focus on their code and not be distracted by the status or activity bar to continue to work but still be able to access the notifications. If we place the affordance on the status bar and then the user chooses to hide the status bar we would not move the notification centre affordance to the activity bar. The reason that somebody hides a piece of UI is more than likely because they don't want to be distracted by that piece of UI. So taking some of the UI that they have chosen to hide and putting it somewhere else would not be satisfactory.

Thanks again for all the feedback. I'm going to close this issue now as we have explored and delivered a new notification UX but again, as @bpasero has suggested, we'd really appreciate it if you could create new issues for any new suggestions you have or anything else that comes up so that we can track each of those issues more easily.

[mattacosta]

I had this on hand already. I'll try to keep it updated with any created issues (please reference this issue in your descriptions) and possibly make a few myself.

List of requested notification features

• [ ] Let users decide if they want notifications (let them accumulate in the notification center)
  
  
  
  • stevencl: https://github.com/Microsoft/vscode/issues/22388#issuecomment-363055323
  
  
  • various others
  
  
• [ ] Provide a way to disable notifications (by type)
  
  
  
  • stevencl: https://github.com/Microsoft/vscode/issues/22388#issuecomment-363055323
  
  
• [ ] Provide a way to disable notifications (by extension)
  
  
  
  • Srekel: https://github.com/Microsoft/vscode/issues/22388#issuecomment-287318118
  
  
  • sambigelow44: https://github.com/Microsoft/vscode/issues/22388#issuecomment-361067400
  
  
  • NickCraver: https://github.com/Microsoft/vscode/issues/22388#issuecomment-294288837
  
  
  • HawkenKing: https://github.com/Microsoft/vscode/issues/22388#issuecomment-300442247
  
  
• [x] View full notification message.
  
  
  
  • razvan-panda: https://github.com/Microsoft/vscode/issues/22388#issuecomment-341972389
  
  
  • stevencl: https://github.com/Microsoft/vscode/issues/22388#issuecomment-361915332
  
  
• [x] Notifications should be able to include links
  
  
  
  • stevencl: https://github.com/Microsoft/vscode/issues/22388#issuecomment-361915332
  
  
• [x] Notifications should include their source
  
  
  
  • stevencl: https://github.com/Microsoft/vscode/issues/22388#issuecomment-361915332
  
  
• [ ] Create a "notification tab" or history (i.e. an actual notification center)
  
  
  
  • CTimmerman: https://github.com/Microsoft/vscode/issues/22388#issuecomment-342352046
  
  
  • mattacosta: https://github.com/Microsoft/vscode/issues/22388#issuecomment-366114528
  
  
• [x] #44123: Dismissed notifications are lost forever
  
  
  
  • stevencl: https://github.com/Microsoft/vscode/issues/22388#issuecomment-361915332
  
  
  • mattacosta: https://github.com/Microsoft/vscode/issues/22388#issuecomment-366816409
  
  
• [x] Notification action buttons are "squished" together
  
  
  
  • stevencl: https://github.com/Microsoft/vscode/issues/22388#issuecomment-361915332
  
  
• [ ] #44128: Notifications should not require user interaction (improve notification workflow)
  
  
  
  • mattacosta: https://github.com/Microsoft/vscode/issues/22388#issuecomment-364608988
  
  
• [ ] Let users control where notifications are shown
  
  
  
  • loligans: https://github.com/Microsoft/vscode/issues/22388#issuecomment-364550387
  
  
• [ ] Group related notifications
  
  
  
  • loligans: https://github.com/Microsoft/vscode/issues/22388#issuecomment-364550387
  
  

List of requested notification API features

• [ ] #44121: Improve APIs to reduce misused notifications and dialog boxes
  
  
  
  • stevencl: https://github.com/Microsoft/vscode/issues/22388#issuecomment-363055323
  
  
• [ ] #44122: Extensions should be able to control their notification history
  
  
  
  • mattacosta: (no comment)
  
  

[AdrianoCahete]

Animating when closing a notification: I don't think this is necessary. We don't animate anything else out of view when closing it. Clicking the close icon and having the thing you click on disappear is sufficient feedback I believe. The reason we animate it in is because the user didn't take an explicit action to make the notification appear. So we have to do something to attract the users attention. But we don't when closing it because that was an explicit action by the user.

From VS UX Guidelines:

Fade-in and fade-out
With this pattern, a UI element transitions from not visible (0% opacity) to visible (100% opacity) or vice versa.
This is the most commonly recommended UI animation. It's a subtle effect that adds interest without interrupting flow. In some cases, the user might not even realize that there's an animation, perceiving a smooth and flowing UI system.

Animation properties

• Starting opacity: 0% for fade-in, 100% for fade-out
• Ending opacity: 100% for fade-in, 0% for fade-out

https://docs.microsoft.com/en-us/visualstudio/extensibility/ux-guidelines/animations-for-visual-studio#fade-in-and-fade-out