Design exploration for improving experience for new users

[miguelsolorio]

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:

• Activity bar icons can sometimes be hard to understand if not familiar with them
• Some features (like the command palette and terminal) are hard to discover
• Desire to control overall density

We also wanted to take the opportunity to explore updating the overall aesthetics like:

• Create uniform sizing/padding (using multiples of 4)
• Update default color system
• Alternate placement of account/settings

Demo

Below is an example of this exploration. Here's a few ideas that we tried:

• Adding labels to the activity bar
• Moving account/settings to the top right
• Introducing an omni search to include commands, files, tasks, etc. (also combining text search into this)
• Introducing a "density" toggle (similar to email clients)
• Introducing a Terminal toggle in the status bar
• Introducing GUI features for Git
• Condensed color system into ~10 colors

vscode-northstar.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

• Friendlier activity bar labels for new users
• Omni search helps discoverability of command palette/search
• Moving settings/accounts in title bar helps separate views from menus
• Consistent spacing makes for a uniform UI
• Easy toggle for changing density

Cons

• Omni search
  • Can be hard to distinguish
  • Could be too advanced for new users
  • Takes up title bar space (will need to look into OS guidelines)
  • Need to evaluate relationship between Quick Open + Command Palette
  • Can take up dragging real estate for title bar
• Could be costly to maintain two designs w/ density mode
• Some prefer settings/accounts in activity bar

Happy to hear any additional feedback others have on this concept.

[SV9045]

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 !

[noman-work]

Make Floating Terminal Like IntelliJ IDEA 👀👀

[MvRemmerden]

@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.

[karuppasamy]

Suggestions.

1. Navigation option "< >" beside the new Omni Search bar to change the activity bar icons.
2. Dedicated option to navigate (back/forward) to the last cursor position.

[fabiospampinato]

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.

  • First of all visually it takes some extra vertical space always, which is not great. On Linux where no perfect custom titlebar is available it would probably make the app look more like IE, with those endless toolbars that waste so much vertical space (titlebar + menubar + omnibar + tabbar + statusbar, that's a lot of bars).
  • 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.
  • 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.
  • Why is the shortcut for that Cmd+Shift+K? Shouldn't that be Cmd+Shift+F?

• 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.

  • 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).

• 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.

[fabiospampinato]

• The dark theme shown in the new mockup might be too dark. I wasn't personally a fan of the old dark theme, which is more of a gray theme really, so I switched to a much darker one, and after having used it for a year or so I think very dark themes don't work so well because shadows break down on them, ~black on ~black just doesn't work and white shadows don't make sense.

[gjsjohnmurray]

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)

[SV9045]

@gjsjohnmurray , Yes This is what I was looking for , sorry I didn't check it, apologize.

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.

[gjsjohnmurray]

@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.

[jeffrafter]

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:
  

[tvanantwerp]

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.

[alefragnani]

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.

• 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.
• 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 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

[miguelsolorio]

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.

[fabiospampinato]

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?

[alefragnani]

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

[yume-chan]

Adding labels to the activity bar

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.

Moving account/settings to the top right

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.

Introducing an omni search to include commands, files, tasks, etc. (also combining text search into this)

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 👍

Introducing a "density" toggle (similar to email clients)

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.

[pixieaka]

@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.

[pixieaka]

@misolori #28409 Can this adds in new design? Because cursor with bigger Line height value looks bad actually.

[irvnriir]

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 .

[miguelsolorio]

Adding a couple of Fluent design concepts from Zee-Al-Eid Ahmad Rana that are relevant:

[ghost]

I'm a bit late to the party (just now had a moment to read this issue) and I'm probably in a minority of users, but I have to say that I really dislike putting UI elements in the title bar of a window. I dislike how browser occupy that space with tabs and also dislike putting a search bar there. The title bar has it's own UI function (be it to name a window, to give additional information, to grab the window and move it, to provide OS immanent functionality like the traffic light and the close button etc.). IMO it's a terrible design decision to misuse the title bar for anything else.

That's from a macos standpoint. Where to put Menu if not in the window title?

[mike-lischke]

The menu on other platforms is usually below the window title:

IMO the best solution.

[bigplayer-ai]

I find this https://github.com/illixion/vscode-vibrancy-continued
I wish someone can just enable auto light/dark vibrancy theme(acrylic/mica backdrop) based on visual studio theme(change extension settings based on system theme or visual studio application theme).

[xezrunner]

The menu on other platforms is usually below the window title:

IMO the best solution.

VS Code currently provides an option to change where the menubar resides, which is good to see.
I think the default behavior being the menubar residing inside the application is ideal as well.

I personally prefer menu bars not taking up the vertical space. macOS does it best with its global menubar.
I don't mind apps putting their menubars into the titlebar on Windows, as seen on the concepts here, as long as there's plenty of room to grab the window somewhere.

Search bars can be visually confusing, I would agree with that, but as long as they're grabbable for window movement, not much harm is done.

Tabs are a different story though - most browsers usually compensate for the taken space by adding extra padding above the tabs acting as grabbable space, but it's often not enough, and if it were any more, it would look bad.
You can't make tabs act as dragging space either, as they can detach and attach to windows.

[plashenkov]

The menu on other platforms is usually below the window title:

IMO the best solution.

@mike-lischke You use VS Code on large screens only, right? :)

Personally I like the main menu is on the titlebar since we have more useful space inside the window (to work with code). We also have really enough space to the right of the menu to drag the window and to display the title. This is especially important for smaller screens such as 13-inch laptops, etc. But really enough controls in the titlebar, there should be enough free space to drag the window, etc.

P.S. It's great to see you here. I used your GraphicEx and VirtualTreeView a lot in the good old days.

[mike-lischke]

hey @plashenkov glad you liked my work :-) For the design: it's definitely a matter of taste and preferences, which is why most people state what they like, not what they believe is the best. These days things should probably be configurable.

[Kroc]

To all doing mockups: Now switch to 1366x768.

If your design doesn't work in the most common resolution, it needs adjusting. I hate having to fight with loss of code space because devs with 4K screens had empty space to fill!

[mike-lischke]

You probably have the overall screen resolution average in mind, which includes all kinds of mobile devices. For desktops (VS Code's domain) the situation is different. The 4K resolution is now most common (~25%): https://gs.statcounter.com/screen-resolution-stats/desktop/worldwide. And the trend goes clearly to 4K: https://gs.statcounter.com/screen-resolution-stats/desktop/worldwide#monthly-201801-202301. But anyway, as I wrote above, it should all be configurable. While on a low resolution you have to decide what to show (and more importantly: what not), it makes a lot of sense to utilize higher resolutions for additional stuff.

[WntSumMo]

The menu on other platforms is usually below the window title:

IMO the best solution.

Fire

[Kroc]

For desktops (VS Code's domain)

You know what they say about assumptions :P 1366x768 still remains a minimum, widely used resolution. For corporate laptop fleets the user may have had no choice over spec/screen resolution. If VSCode doesn't consider this to begin with then users suffer. "Mobile first" applies here; start with the smallest resolution and add more in larger resolutions rather than starting big and hacking away to get it down to a sub-par experience on smaller resolutions.

[zelosleone]

The menu on other platforms is usually below the window title:

IMO the best solution.

Let's hope by the end of 2026, we get this.

[carlocardella]

It is already available (but honestly I don't like it, I prefer the compact menu)

[wildybytes]

i like the concept
beautiful and elegant

[Diegorro98]

Recently Mica and Acrylic support in Windows has been pushed to electron repo (and backported to v24 and v25). It would be awesome to see some of the concepts posted here become real!
See electron/electron#38163

[EmrecanKaracayir]

Also there is another design language proposed by Microsoft, Microsoft Edge UI. I thought VS Code can benefit from tabular design that Edge concepts show.

Here is an experiment.
#183486

[wyatt-herkamp]

I love the concept! Tho, I would make the window head a bit smaller, like this:

I recently migrated from using JetBrains to VSCode (Because how bad Rust Rover got) and the only thing I despise about VS Code is the lack of the run button and run menu.

I would do anything VS Code to get a run button and drop down in the top row of the editor.

[Meligy]

I would do anything VS Code to get a run button and drop down in the top row of the editor.

@wyatt-herkamp, I saw this and thought "There must be some extension that does it!". So, I searched extensions for: debug button.

The first result was Quick Run and Debug Buttons.

It adds 2 buttons "Start Debugging" and "Start Without Debugging":

The next one was Launch Buttons:

And there are also many extensions that run/debug active file.

[shafayetejaman]

This looks awesome, I wish we could apply this theme

[MOMINUR-R]

The transplant design looks perfect. The external extensions are too bugy, it will be nice to get a built-in theme that is more seamless.

[TheBlckbird]

@MOMINUR-R

I really like this design but what about Linux and macOS users? This design is very fitting for Windows but would look totally out of place on th other OSs.

[Daydreamer-riri]

Is there any progress here? I want to know if the vscode team has any plans for the new design.

[yvvt0379]

Maybe they has completely ignored this issue, I suppose. 🙁

[Daydreamer-riri]

Maybe they has completely ignored this issue, I suppose. 🙁

Based on the roadmap, it's possible that the vscode team really has no plans for this at the moment.

[spatel96]

Any way to get this prioritised? Would surely be a simple change but would certainly help my "plugin scawl".

[Natriss]

The menu on other platforms is usually below the window title:

IMO the best solution.

I do wish Microsoft would apply WinUI 3 more in there bigger apps.
I love the concept and wished it was real.

[ntdash]

Make Floating Terminal Like IntelliJ IDEA 👀👀

1 level up, let consider the whole panel instead [output, error, ..., terminal]