Open miguelsolorio opened 3 years ago
Make Floating Terminal Like IntelliJ IDEA 👀👀
@misolori I really like the concept of adding labels to the icons in the left nav sidebar, it would have been a huge help for me to understand what these are when I started using VS Code.
Have you already thought about how to deal with this is languages where the labels might be a bit longer? As an example, "Extensions" is "Erweiterungen" in German.
Suggestions.
Some random feedback:
Overall this mockup feels pretty modern to me, but on a closer inspection I see a lot of regressions.
Traffic lights buttons on macOS don't have equal vertical padding around them, especially in the non-dense version but also in the dense version, IMHO that's the kind of detail that drives people like me crazy. Those buttons can be repositioned dynamically at runtime and I think they should.
Labels in the activity bar are kind of only useful the first time one opens the app, you need people to understand what everything does, but you don't want to bloat the UI endlessly for ~everybody who has already used vscode for a few days. The compact design gets rid of them but IMHO we should get rid of the compact toggle too, I'll get to that later. I think Discord's approach to this is better, they show tooltips on hover and that's it, that way you also solve the issue of labels that are longer than "Extensions" and won't fit in the current design.
The height of the toolbar in the view container is ridiculously high, you can fit like 3 or 4 tree items in here, IMHO it just looks excessively tall for the sake of it and has no actual purpose, it actually wastes some vertical space and some horizontal space from toolbar buttons. It'd be much better IMO if it just aligned with the tabbar in height, currently it just looks odd.
The omnibar sounds like a terrible idea to me.
Moving the user and settings icons to the titlebar sounds like it might be nice at first, but you don't actually want a titlebar at all I think, and maybe the statusbar should be used for this, at the end of the day in this mockup it looks like a top statusbar got added, and we already have a bottom one.
The prompt for moving the settings and user buttons out of the activiy bar is because they are not activities, but maybe the solution is that they should be? I've been personally experimenting with something similar for another app, IMO for example with regards to settings this would be so much better (see image below). The graphical settings editor is kind of not ready for prime time yet (it tells you to use the JSON one to edit some settings), and the JSON editor is unusable in many cases, like if you have even 2 editors side by side the JSON editor becomes almost unusable in my 15" monitor, I think it should be prompoted to its own view (views that should be able to replace what's rendered in the main section fo the app too, and not be just constrained to editor tabs, this could also make the built-in extensions marketplace UIs more usable).
The padded line highlighting the active item in the activity bar looks nice, but maybe it's acually useless? Like it doesn't really have any purpose, it only makes the "Explorer" item more visibly active in the mockup because the git item has a blue badge too, once the badge is not the ~same color as active items anymore this problem disappears. Plus tabs can also have an highlight line like that, now should that be padded too for consistency? Probably, but that'd waste extra space for nothing too.
In the mockup custom menus are always used in place of native ones, IMHO that's a regression, and there are some things that custom menus can't really replicate, like being rendered outside of the app canvas. On the other hand though custom menus can display chorded shortcuts normally, but you've gotta use native menus anyway for app-level menus under macOS and Linux so maybe it's just better to be consistent in that regard too.
The compact mode toggle IMHO should be deleted, the UI should always be reasonably "compact", the only difference that actually matters in the mockup between the compact and non-compact mode is that items in the activity bar have labels, other than that we are getting 0 usefulness in any way in my opinion from the non-compact mode, and I don't think you need to render labels there at all, so no need for the compact toggle either. Interestingly the compact mode doesn't seem to have any effect on the tree component, which is the first thing I'd think a compact mode would have an effect on.
Removing the different background color and border around sidebar views headers I'm not sure how I feel about, at first this change just makes the sidebar look much more messy to me, but maybe I could get used to it and it would appear cleaner? I don't know.
The statusbar button for opening the terminal is kind of in a random position, I'm not sure how I feel about it. Maybe there should a more general button for toggling the panel, which will have the terminal view active by default, and that should be position at the right corner of the app? Then maybe that could be styled specially to make it blend with the open panel or something, maybe that would be nice. There's currently the notification button at the very right of the statusbar, but again that's kind of a useless thing, for example right now I have 0 notifications, if I click on the button it just tells me again that I have 0 notifications, there's nothing that I can do with it, useless things don't deserve to occupy space in the statusbar by default.
According to the mockup the enlargment effect when clicking on buttons might be gone for good, that'd be great, not many things get bigger when pushed in the real world so that just looked weird.
I hope I wrote some useful feedback in here, if it sounds harsh I had no intention to offend anybody or anything like that, I'm just an happy vscode user trying to steer vscode more into what I perceive to be the right direction.
I would like to suggest for 'merge' (merging branch) into the git command menu where all the commands such as push, pull, stash etc.. right now using it from command palate !
@SV9045 is this what you are looking for?
(screenshot from 1.52.1)
but I would like to suggest one enhancement though, I remember in my initial days when I started to using git it was confusing for me that I'm merging my own branch to the base branch but it's actually I'm merging base branch to my own branch while working in multi team environment. so, something like merge base branch or might be we can see base branch here and we have an option that, merge it into the current branch. It would be useful to avoid confusing and for understanding git flow when some new person will start using git through VS Code.
@SV9045 please don't use this issue for specific enhancement requests. Instead, start a new one. A convenient way to do this is from "Report Issue" off the Help menu. Pick "Feature Request" and enter details.
This looks fantastic ✨
Features that I use on a daily basis seem far more discoverable. My sense is that this will do more to increase productivity generally than simply target new users / onboarding. Which is great!
Some small feedback:
Moving the settings and user to the top toolbar is so obvious now that I see it... this is such a good move.
I am not sure I see enough of a distinction between the density modes - why not pick one and leave the other density to theme developers?
The search panel on the left is moved (now part of omnisearch?) - how do you display lists of results for things like find-in-files?
One small nit - I think the window controls on MacOS should be centered vertically:
Moving a search field and the user & settings icons into the top bar give it more of a Microsoft Office feel. Which IMO is unfortunate–VS Code is one of Microsoft's best products, and the others should be emulating it and not vice versa.
I like the left bar icon labels, though. I still haven't clicked on all of them because I don't know what they are.
I'm not sure why "Explorer" text is so much larger than everything else.
First of all, congratulations for the design and detailed information. It helps a lot with the understanding and feedback 👍
I understand, and agree, the idea for improving experience for new users, and indeed some of the features would help them. But as a long time user, I agree with a lot of @fabiospampinato comments , and would like to add comments on two areas that I fear most.
Remote - Containers
Extension as an example, the icon’s name is Remote Explorer
. How it would handle it? Line break or ellipsis? But, a simple context menu/setting to “hide” the labels would work.The new design follows a few of MS Teams identity, which is good on a guidelines point of view, but these two points are exactly the ones I struggle the most, specially the Omni search. Slack has the same issue.
Being new usersthe main audience for these changes, I would ask you to release it as opt-in, so current users aren’t affected.
Thank you
Thanks everyone for the feedback! Here's some responses to everyone's comments:
Have you already thought about how to deal with this is languages where the labels might be a bit longer? As an example, "Extensions" is "Erweiterungen" in German.
Adding labels to the Activity Bar icons is a waste of valuable space, and will probably break when you deal with translations and the new icons provided by extensions. Take the Remote - Containers Extension as an example, the icon’s name is Remote Explorer. How it would handle it? Line break or ellipsis? But, a simple context menu/setting to “hide” the labels would work.
I did think about this and that's the biggest hurdles with text labels. An alternative would be to add a bit more padding for languages that tend to have longer names, but we'd need to test that with users to see how much that is affected. I also thought we could add a "short name" property that allows an extension to have an abbreviated name, if the extension name is long.
Dedicated option to navigate (back/forward) to the last cursor position.
I did play around with adding this as < > icons like Slack, but because Windows uses the file menu caused this to not work well across other platforms.
Traffic lights buttons on macOS don't have equal vertical padding around them, especially in the non-dense version but also in the dense version, IMHO that's the kind of detail that drives people like me crazy. Those buttons can be repositioned dynamically at runtime and I think they should.
One small nit - I think the window controls on MacOS should be centered vertically:
Yes, this is a visual bug. Thanks for pointing it out!
Labels in the activity bar are kind of only useful the first time one opens the app, you need people to understand what everything does, but you don't want to bloat the UI endlessly for ~everybody who has already used vscode for a few days. The compact design gets rid of them but IMHO we should get rid of the compact toggle too, I'll get to that later. I think Discord's approach to this is better, they show tooltips on hover and that's it, that way you also solve the issue of labels that are longer than "Extensions" and won't fit in the current design.
Adding labels to the Activity Bar icons is a waste of valuable space...But, a simple context menu/setting to “hide” the labels would work.
We'd definitely create options to toggle these on/off, just like we do for our various settings 😄
The height of the toolbar in the view container is ridiculously high, you can fit like 3 or 4 tree items in here, IMHO it just looks excessively tall for the sake of it and has no actual purpose, it actually wastes some vertical space and some horizontal space from toolbar buttons. It'd be much better IMO if it just aligned with the tabbar in height, currently it just looks odd.
The padded line highlighting the active item in the activity bar looks nice, but maybe it's acually useless? Like it doesn't really have any purpose, it only makes the "Explorer" item more visibly active in the mockup because the git item has a blue badge too, once the badge is not the ~same color as active items anymore this problem disappears. Plus tabs can also have an highlight line like that, now should that be padded too for consistency? Probably, but that'd waste extra space for nothing too.
There are going to be users who prefer having more space/padding around items and those that do not, this would definitely be a setting to let users control.
It just breaks some workflows where one would go through search results, with search results on the left and editors on the right, now you can't see both at the same time. I suppose one could open searches on their own editors and manage them that way, but that's not the same thing at all, now you can't just collapse the sidebar temporarily and commands like the one for closing all tabs mess with your workflow.
The "replace search with omni search" is something we're definitely evaluating, there would likely be an option to place Search in the sidebar/panel/title. Lots of gaps to fill in.
Even visually I'm not sure it actually works, on macOS it looks good, on Windows not so much if you shrink the width of the window a bit more, what would happens if there isn't enough space for rendering the whole thing? Besides it's off-center all the time and that's already triggering my zen senses.
This would need to be dynamic and shrink to the area. It being off-center on Windows matches the current behavior with the title.
Moving the user and settings icons to the titlebar sounds like it might be nice at first, but you don't actually want a titlebar at all I think, and maybe the statusbar should be used for this, at the end of the day in this mockup it looks like a top statusbar got added, and we already have a bottom one.
The one drawback of placing an omni search in the title bar area is losing the title bar text, so again this would be something that could be configured. This is has also become a common pattern in a lot of apps and our main issue we were addressing here is that settings/accounts have menus and all activity bar items have views associated to them.
Maybe the idea is not to clutter the statusbar too much and to have those "special" items more easily discoverable, IMHO I'd much rather like to see the statusbar getting uncluttered, there's a fair amount of useless information getting shown there (0 errors and 0 warnings, ok, why is the statusbar item there then? Or for example the official github extension, which I'd imagine a lot of people have installed, last time I tried just wasted considerable amount of space just for telling me my own github handle all the time, maybe more focus should go into resolving these issues first).
You can actually right-click and hide items on the status bar. We've also have been doing work to improve the "accounts" experience with our authentication api, so extension should not be showing accounts in the status bar once they move to this. The GitHub PR extension uses this now.
In the mockup custom menus are always used in place of native ones, IMHO that's a regression, and there are some things that custom menus can't really replicate, like being rendered outside of the app canvas. On the other hand though custom menus can display chorded shortcuts normally, but you've gotta use native menus anyway for app-level menus under macOS and Linux so maybe it's just better to be consistent in that regard too.
The mockup is showing the native menus on macOS Big Sur, so those are not custom.
I am not sure I see enough of a distinction between the density modes - why not pick one and leave the other density to theme developers?
This is something we are experimenting with and why we are looking at the feedback. The main thing that the density controls is the amount of padding around items and the font size.
The search panel on the left is moved (now part of omnisearch?) - how do you display lists of results for things like find-in-files?
The Omni search can’t be a replacement for the Search nor the Command Palette. Being a two-step command, makes it hard to accomplish their simple task: Find file that contains a text or Find a command. Personally, I don’t remember an Omni search on any app/website, that ever knew what I want to search, and always forced me to take a second step, to filter on the result. IMHO, it’s the biggest regression compared to the productivity I have today.
The idea I was exploring here was using the Search editor for the replacement of find in files, so when you are typing the first item is always the option to open the find in files. You can also go directly to that mode via the keyboard shortcut (Cmd/Ctrl+Shift+F) and same would apply for the command palette and quick open. If users don't care for omni search, there'd be a toggle to turn it off and Search would go back in the activity bar.
Being new usersthe main audience for these changes, I would ask you to release it as opt-in, so current users aren’t affected.
I've mentioned this a few times, but yes of course we'd also include an option to toggle certain things on/off as we do with other settings. Customization is at the core of our product and we'd always want to strive to maintain that.
An alternative would be to add a bit more padding for languages that tend to have longer names, but we'd need to test that with users to see how much that is affected.
That doesn't work, a label could be arbitrarily long, you can't add an arbitrary amount of padding to account for that.
I also thought we could add a "short name" property that allows an extension to have an abbreviated name, if the extension name is long.
That'd be kinda ugly, and doesn't work either, there might not always be a short way to express a long label. The solution is that there shouldn't really be labels to begin with, or one accepts that labels can get truncated at some point, which somewhat defeats the whole purpose of labels depending on when the truncation happens.
We'd definitely create options to toggle these on/off, just like we do for our various settings 😄
That's great, I'd just like to uselessly emphasize (I'm not saying anything new) that defaults are important though, the more settings one needs to change to get the app to behave perfectly the more annoying it becomes to use. Now vscode has a lot of slack currently in this regard, like I don't even know which other comparable editor I could switch to, but if another really good editor shows up and they have much better defaults new users might just use that instead, defaults are important.
There are going to be users who prefer having more space/padding around items and those that do not, this would definitely be a setting to let users control.
This logic can't be extended indefinitely, like nobody actually prefers to have 2000px or more of padding around toolbar labels, in my opinion the percentage of people that would prefer to have that much padding around toolbar labels as shown in the mockup is approximately ~0%, and the ones who may actually prefer that are basically wrong really, like some people like to harm themselves, that should be discouraged even if they like it.
This would need to be dynamic and shrink to the area.
Right but what if the area available becomes ~0px? The menubar takes already a good amount of space, at some point there just won't be enough space left for the omnibar.
It being off-center on Windows matches the current behavior with the title.
Sure, that's not really a feature though, and depending on how the omnibar gets implemented it may be a lot more dynamic that the pretty much static title which I personally pay next to 0 attention to.
our main issue we were addressing here is that settings/accounts have menus and all activity bar items have views associated to them.
IMHO settings should have its own view (non constrained to an editor tab) to make it always usable again and the account icon should be moved to the statusbar or potentially gain a view too.
I understand though it there's a push to make the family of MS apps more consistent which it other, that's worth something, I'm just biased on this because I just personally don't care one bit about any other MS app.
You can actually right-click and hide items on the status bar.
Of course, but that's an approximation of what one wants, what one wants, or what I want anyway, is to have only useful information in the statusbar and no totally useless information, hiding or showing a statusbar item is only the perfect solution to the problem as long as the item is always useful or always useless, but I can't just hide the problems item or the notifications item only when they are being useless, they themselves should be more self conscious about how they use the limited amount of use space available. You guys obviously can't fix this for third-party items too, but I would expect the official ones to be more conscious about this.
The mockup is showing the native menus on macOS Big Sur, so those are not custom.
So on linux and windows they are custom? Would it not make sense to be consistent about this across platforms?
Hi @misolori ,
The idea I was exploring here was using the Search editor for the replacement of find in files, so when you are typing the first item is always the option to open the find in files. You can also go directly to that mode via the keyboard shortcut (Cmd/Ctrl+Shift+F) and same would apply for the command palette and quick open. If users don't care for omni search, there'd be a toggle to turn it off and Search would go back in the activity bar.
That’s great. Doing so, users who enjoy using Omni search will have it available, and those that don’t, still can use the original behavior. Just out of curiosity, would the Search feature still have its results show in the Side Bar, right?
BTW, I would suggest to add Settings
to the Omni search as well. Maybe, this is what the user is searching for 😬
Just to be clear, I don’t dislike the Omni search element itself. In fact, I think it uses the perfect location, and the Settings icons at top right fit great as well. My fear was you were adding the Omni search as a replacement to the Search icon. But if the Search feature is still available, that’s great!
There are going to be users who prefer having more space/padding around items and those that do not, this would definitely be a setting to let users control.
Looking at this, I remembered a pain point while using the Source Control panel today, which you solved with the non-dense mode. Today, it’s hard for me to use the Commit
button, specially with the revamped thinner icons. Maybe because the Commit
button is not the first, maybe because it is not always visible, but the Commit
button you added bellow the commit message, helped a lot. I’m not saying it should be used in the dense mode, but if I would change something in that view, it would be this one. Make the Commit
button easier to find/distinguish
Thank you, and congratulations for your hard work
I think Discord's approach to this is better, they show tooltips on hover and that's it
I prefer this solution. dock in macOS and taskbar in Unity Desktop environment also use this approach.
In the mockup the account icon has been replaced with an avatar. With support for multiple authentication providers, the account menu in Code is more like an "account hub", so randomly choose an avatar from all login services may not work.
For the location, although they are not "activities", they exist in the activity bar for a very long time, most users should have been used to them. And it's not like there's no space for them there.
I like the idea, but I think it can be better executed.
When it first opens, it should display a list of recent used or frequently used commands/files/tasks, etc.
When user typed something into it, results can be grouped into types, with the one type contains most relevant results displayed at top. There is also a line of links to quickly jump to each group, like
| Text Input Here |
Jump to commands Jump to files Jump to tasks
Commands -- result 1 -- result 2
Files -- result 1 -- result 2
Maybe views can also be added to omni search to allow quickly revealing them.
Dedicated option to navigate (back/forward) to the last cursor position.
I also want this, don't forget #41309 (Add an optional configurable toolbar below the menu) with hundreds of 👍
The compact mode toggle IMHO should be deleted, the UI should always be reasonably "compact"
I agree. I don't think the effort put into designing and implementing two sets of density worth the outcome. Also it's very difficult for all extension authors implementing webview-based custom editors and views to adopt.
@misolori Search in activity bar is so much clear to take overview of files and number of matches for each file more than search editor.
@misolori https://github.com/microsoft/vscode/issues/28409 Can this adds in new design? Because cursor with bigger Line height
value looks bad actually.
For me Activity Bar is distracting and takes too much space, so i use "Activitus Bar" Extension . Moving these menus to Title Bar would be a good addition .
Adding a couple of Fluent design concepts from Zee-Al-Eid Ahmad Rana that are relevant:
IMO those look amazing. I'm just somewhat concerned about wasted space. I'd be interesting to see what the app would look like under macOS, where there's one global menubar and it's fairly common not to have a titlebar at all.
The padding/density of the Win11 concepts is very good. This density is much better than the originally proposed slightly thick line. I'm a longtime/advanced user and I would prefer this myself, honeslty, at least as a optional toggle).
Looks really fantastic. The menus are moved below the title bar so that title bar looks no longer crowded. However, I think it can be better if the labels of "split editor" and "run" are removed.
I also have a few thoughts on this, especially after seeing the Win11 mockups.
Let's start with the omni search (not in the Win11 mockups, but could be added):
I believe a nice solution would be to "upgrade" the current command palette with some new functionality. In theory, the palette can already do all of the things offered by the proposed omni search, it simply looks different and works slightly different.
The changes required would be:
>
, @
) present in the search box>
to filter for commands, @
to search symbols, etc. Using backspace to remove the filter should be supported too.As for placement, it should be in the title bar, next to the window title. Align the window title to the left, and have the rest of the space taken up by the omni search
Next up, aethetics:
I prefer the rounded corners and distinct panels/areas from the Win11 mockup, for two main reasons:
The Win11 mockups could be more consistent though, for example:
As for the "density setting", it should be relatively straight-forward to implement for the Win11 mockups:
The density setting only affects the padding of things like Activity Bar items, tabs, the file tree in the explorer view and other listings such as the Outline or Timeline panels.
This should never cause the design to break down, it would simply mean less or more scrolling, depending on the user's preference.
Changing the density could be done by choosing from a dropdown or even manually supplying padding values for each item type.
Finally, moving the text search (ctrl+f) into the omni search will be a challenge. It has some options (case sensitivity, regex) that don't really fit in there, and the whole "replace" field is even harder to integrate. Maybe just leave it be and only use the omni search for local and global fuzzy text search?
Sorry for this lengthy comment, but I hope it will be useful.
I would also suggest you try to get one of the Windows 11 designers on board for this in order to make sure the design is consistent with the new OS :)
Adding a couple of Fluent design concepts from Zee-Al-Eid Ahmad Rana that are relevant:
These look absolutely fantastic! They align with Windows 11's design quite well, perhaps even perfectly. I wonder how conceivable this would be in regards to the Electron framework (unless WinUI would be used in some form).
I'd be interesting to see what the app would look like under macOS, where there's one global menubar and it's fairly common not to have a titlebar at all.
If we consider the titlebar as just the row that contains the app title and the window controls, that doesn't seem like an issue.
While I do not use macOS, based on what I've seen so far, the titlebar consists of just the app title and the window controls.
The window menubar is on a different row and could be hidden, as the global menubar hosts the menus instead (unless configured otherwise - not sure whether window.menuBarVisibility
or similar exists on macOS).
These look absolutely fantastic! They align with Windows 11's design quite well, perhaps even perfectly.
Zee's concepts use the WinUI figma toolkit. Their styles can actually exported directly to CSS making replicating WinUI components quite viable on electron. I have a personal project that's highly unfinished which remakes some of the styles into svelte components.
not to beat a dead horse, but while we're talkign about trying to improve user experience for new users, is having REAL actual opt-in configurable toolbars still off the table? I feel like that's one of the biggest shortcomings of code, and probably the first thing new users run up against... the fact that people are expected to just memorize 110k commands and figure out how to use command pallete.
MANY MANY MANY issues have been created to address this... and its fallen on deaf ears (probably more likely just really really really stubborn decision makers on the vscode project)
I know my PR for Acrylic and macOS vibrancy has been closed, but I'd be very happy to start new and make one for Mica and the newer vibrancy APIs, if wanted, to make these styles integrate better with the OS.
It might be helpful for an easier implementation ... You can use VS Code already with a Fluent UI look via extensions: with 'Vibrancy Preview' and 'Fluent UI for VSCode'. Unfortunately, after each update you've to enter commands to reactivate the patches.
It's very much based on the Fluent design concepts of Zee-Al-Eid Ahmad Rana.
Would be nice to see something like this as a built-in theme on Windows 11.
@hampoelz I know, I had a PR which added support for this natively (see #52707), and those extensions where created after my PR was rejected, to supplement it.
~I want this title bar in Windows~
~let's add an toggle icon to right-bottom status bar~
Introducing a Terminal toggle in the status bar
some like VS 2019, VSCode waste too much space,especially for laptop PC.
Introducing a "density" toggle (similar to email clients)
move action Icon from tabs container to alt place
~want a new another sidebar, only one sidebar is in the soup~ that is done now. 💯 #132893
Hello! Will an external PR solve this issue? If so, I can begin working on it. Is all the responsible code in src/vs/workbench/contrib/webview/browser/?
@NuraliMedeu this is not an issue meant for a PR, please see the good-first-issues or help-wanted if you'd like to help out.
Honestly sounds another example of the vscode team dodging UX concerns that countless community members have tried to bring up only to be repeatedly shot down or just ignored all together.
@NuraliMedeu this is not an issue meant for a PR, please see the good-first-issues or help-wanted if you'd like to help out.
@misolori , I am sorry, right now I am only interested in improving the appearance of the app. I don't want to deal with its backend problems, which most of the help-wanted issues seem to be.
Improve the UI of the buttons (make them more rounded) [Windows 11]
What if, instead of changing the entire VSCode GUI for Windows, Mac, and Linux to our like, we introduce a more flexible theming API (that uses CSS)? This way we could have native Mac, Windows 11, and Gnome/Yaru themes.
Sounds like a great idea, but besides the better theming API I hope they can also provide "better defaults" like more rounded corners or something like that.
any update when this design will release ? 🤔 🎉🎉🎉
I can't wait for this to happen, if ever.
The first simple thing should be to introduce an acrylic effect to the context menu and menubar menu
If you really can't fix the whole design at once, focus on the parts that should be changed first - the parts that are easy in terms of programming and design.
This looks great on a doc, but on real world application things change. For instance, how would it look if the background was custom? What about Windows? Its text rendering (and overall rendering) and buttons are different. Then what about the themes? There would be incompatibilities. I love the design don't get me wrong. But things change when doing the HTML code
With that said, i would love to use this.
Mica (Windows) and vibrancy (macOS) effects are rendered by the system, not the app, so the effect works as expected with custom backgrounds.
App just need to invoke the interface provided by OS.
Mica (Windows) and vibrancy (macOS) effects are rendered by the system, not the app, so the effect works as expected with custom backgrounds.
Was not speaking about transparencies. Your design for Windows 11 looks awesome ;)
Overview
As you can see in the screenshots, in both macOS and Windows native controls, the context menu uses a Gaussian blur effect. So VSC could follow it. Although I know that there are some 3rd party plugins that can do this.
Guidelines In Windows' Design Guidelines it states:
Use background acrylic for transient UI elements, such as context menus, flyouts, and light-dismissable UI. Using Acrylic in transient scenarios helps maintain a visual relationship with the content that triggered the transient UI. https://docs.microsoft.com/en-us/windows/apps/design/style/acrylic Apple HIG
On Apple platforms, a material imparts translucency and blurring to a background, creating a sense of visual separation between foreground and background layers. ……use the menu material for a menu in your macOS app https://developer.apple.com/design/human-interface-guidelines/foundations/materials
Common Point Through these contents, we can easily extract some common features:
Menu uses rounded corners
Translucent material
Gaussian blur
Inner Glow Stroke (in Dark Mode) and Drop Shadow.
Highlights are marked with rounded rectangles
At Last This provides a possibility for this application to not only ensure a consistent experience across platforms, but also conform to the design styles of each platform. Although in order to ensure concise code and maintenance work, we will not prepare different menu styles for different operating systems, but only the above common points, we can already get a relatively good result.
AFAIK Windows 11 native menus are not an option unless we make a feature request on electronjs server and they add it, since now they only have chrome like menus.
What I'm trying to say is that I'm not requesting a native menu, I'm just requesting an updated menu style to better match the design style of the new generation system.
By the way, I don't reject native menus, it would be great if it could! But it seems like, unlikely?
@Shomnipotence AFAIK VS Code will not support native OS' transparency effects until Electron will do.
If Electron allow to have Mica, Acrilyc, Vibrant or to go complete transparent with custom effect using background (image) as canvas, then every app built on Electron could implement such effect. Until then, VS Code will not offer the feature
https://github.com/electron/electron/issues/29937 This is a good place to follow the possible progress of Mica in Electron.
electron/electron#29937 This is a good place to follow the possible progress of Mica in Electron.
Glad they began to work with it. But as far as I see, there is much to improve, and Mica support is far from production-ready.
Overview
This design exploration aims to improve the overall experience for new users while also providing value for existing users. Going through feedback from new and existing users we've heard that:
We also wanted to take the opportunity to explore updating the overall aesthetics like:
Demo
Below is an example of this exploration. Here's a few ideas that we tried:
https://user-images.githubusercontent.com/35271042/106675880-c02c4e80-656a-11eb-8f5f-ead5e96300ba.mp4
Feedback
Here's the feedback I've received on this concept from our team. I'll break down the concepts into individual issue for those we are interested in pursuing more. Note: since this concept touches several ideas at once, it would be good to break down some changes (like density changes and showing more/less UI should be separate).
Pros
Cons
Happy to hear any additional feedback others have on this concept.