Thank goodness. I was really worried with all the code I was able to fit on my screen at one time. This will reduce my cognitive load by seeing less code and taking frequent scrolling breaks.

Hopefully soon we can get rid of all of those confusing keyboard shortcuts too. Maybe add a ribbon or two.

I know this is sarcastic but I wonder why I haven’t really seen a ribbon interface on IDEs. It seems like a good idea

I take much longer navigating the ribbon interfaces in any recent MS Office than I do the traditional drop-down menu and toolbar UI.

Scanning a list of words is much faster than tabs of differently sized icons. Having a choice of dockable and customisable toolbars made better sense, they achieved basically the same goal and could be tailored for the current task.

I hope no one at MS takes that idea seriously.

Coding is a lot more modal than document composition, so I think the paradigm fits better.

Sometimes you're in "understanding the codebase and tracing execution paths through tons of libraries you don't know" mode, sometimes you're in "debugging a specific problem with a specific function" mode, sometimes you're in "designing UI" mode, sometimes you're in "figuring out event propogation" mode, sometimes you're in "writing unit tests" mode, etc ... ...

I quite like the ribbons. It exposes a lot more control that the menu and toolbars, the contextual split makes sense and keyboard navigation works great. It's an interface you have to get used to but once you do it's actually more efficient.

I've been putting up with them for years and they still slow me down to a crawl. If you have to do anything except for the most common actions, it takes forever to hunt through the ribbon to find what you want. I curse them regularly.

I don’t know I think they are sorted fairly well and I use all the actions somewhat regularly. That’s for Excel and PowerPoint at least, no idea about Word but Word is just a poor piece of software ribbon or no ribbon.

FWIW, I hated the ribbons at first. I love them now. They are far faster than the old toolbar UI that they had prior to the ribbon due to the more recognizable items, and they've made a lot of tweaks to it over the years. You can now remove and pin your favorite things on the ribbons in MS Office, as well as make your own completely new ribbon with the buttons you want. It's a really good interface now.

I like OneNote's new Simplified Ribbon as well, that you can toggle.

Yeah. Especially after the popularity of the MS Office ribbon when it was first introduced in the mid-2000s - I'm surprised Microsoft didn't add it to their other products. Mainly their flagship dev IDE.

Oh, please no. Ribbons are terrible UI elements.

Really? I find them better because everything is laid out in a way that makes things easier to find, especially when you haven’t used the tool much before, and they look nicer too

My problem is the opposite -- I can never find anything but the most common actions in them without engaging in a time-consuming search. This is even worse if it's a program that I haven't used before or use rarely.

This is why there should just be a search box.

The ribbon is fine if they just leave it alone and stop moving shit around and changing icons.

In one version of outlook "delete" is a trashcan, in another its a big X.

I think you must be joking

No, I like them, I don't know if it would be a good fit but it seems worth trying

Seems like ribbons are quite a divisive issue

And it definitely needs a "side toolbar" on the right and, why not, also on the left.

The rest of the design looks modern with gray on gray and tiny scrollbars.

I will never understand 4 spaces vs 2 spaces as a code formatting standard.

I’m looking at you Python Black!

4 spaces and a default 80 char line length!

It’s wasted space!

It's interesting to compare this against the JetBrains UI refresh.

From the images, it looks like the VS team just increased the spacing a bit and made some sensible adjustment to the chrome. That's not necessarily a bad decision as screens get larger, but the JetBrains team also reconsidered how elements should be arranged in the UI.

For example, the JetBrains team identified the project-switcher, branch-switcher and run-widget as the most important widgets for the title bar. Nobody still uses undo, redo, save and open buttons so why are they in the VS interface by default? They did the same for their toolbar, their icons [1], the gutter...

As a result, the new JetBrains UI looks significantly cleaner even in compact mode (old spacing + new ui).

Without these fundamental reconsiderations the new VS interface looks just as cluttered, but larger.

[1]: Although the VS icons still hold up well.

> that's not necessarily a bad decision as screens get larger

Maybe true for desktop monitors, but not laptops. They really need to add an optional compact mode if they go with this redesign. Visual Studio is already wasting too much vertical space as is.

Even on laptops it can work when you combine it with other adjustments. For example, in JetBrains, the distance from the top of the window to the first line of code has remained the exact same.

So their compact mode is now actually more compact than before.

Please! Give me the option to keep the tight spacing and small controls we currently have in VS.

Personally, I really prefer the compactness!

Even Visual Studio UI is not safe from inflation. Is making everything 10% bigger necessary?

Jetbrains also introduced a new inflated UI recently, and at least provided a compact mode.

I had the exact same thought. Hopefully a compact mode is being considered.

Why "less dense" is considered good design in something like this boggles my mind

IMHO, every single change looks worse and will feel worse

> We know that cognitive load is reduced by minimizing visual clutter

Powerful tools unavoidably have a significant cognitive load.

It’s quite possible to reduce that load by improving how some features work (for example, searchable command bars are better than endless menus) but if you’re not doing that you’re pretty much just reducing the power of the tool, as here.

I would say there’s a difference between cognitive load and visual clutter. One of the problems I have with the visual studio UI is that it tries to be everyone’s everything…all at once. I much prefer the searchable command bar in VSCode because everything I need is just a hot key and a couple key strokes away but when I’m just using the editor I don’t have to sacrifice space or deal with sifting through icons to get to the only ones I need 90% of the time. That being said presumably the features are still there just hidden under a menu item or something.

Ultimately it comes down to personal preference but I’ve basically gotten to the point where when I’m actually writing code I use VSCode and when I need access to more advanced tooling, or have to deal with some of our legacy build systems, I pop into visual studio proper. I think I’m just a bit more use to some of that dev tooling being outside of the editor but I would really love some bigger investments in the .NET dev tooling in VSCode and the .NET CLI so I can have an editor that’s just an editor most of the time and still be able to take advantage of the great debugger and everything else VS provides.

Honestly though, hardly anything is needed when writing code. Find code, edit code, run code, debug code (step, inspect).

I think something like Blender is a good example of a tool in which many menus are truly needed, but IDEs are simple in this regard.

vim focuses entirely on the content, by default with just two rows reserved for an editor interface. Emacs is similarly minimal.

The lack of avoidance of cognitive load is a choice, not a necessity,

Thanks, I hate it (all the unnecessary padding wastes even more precious screen space than before).

The Visual Studio team should take a close look at the Visual Studio Code UI, it's not perfect, but at least it's still relatively clutter free and compact.

If MS really wanted to make the app better you could stop drawing active elements in the Title bar.

Title bar should have window controls on the right (like the ones you copied from NeXT), and because you're windows, the app icon on the left. Centre justified there should be the application name.

And that's all thank you.

> If MS really wanted to make the app better you could stop drawing active elements in the Title bar.

So much this. Putting controls in the title bar is such an aggressively hostile thing to do, I'm really surprised that the trend has gained wider adoption. It's even worse than making the window frames nearly nonexistent.

I do get what they're going for and for folks with larger monitors this will probably be a nice change. That said, for those that prefer higher density of UI elements, this might seem like a change that's forced upon them.

> We know that cognitive load is reduced by minimizing visual clutter, which is often achieved by increasing the amount of spacing between controls. We also know that developers want as much space as possible for their coding environment. Balancing these two attributes against each other is a tricky proposition.

What I don't quite get is why couldn't you just have some "global padding multiplier" setting at the OS/UI framework/tool level, much like we have customizable font sizes across the board in both local and web software? Then you can leave that choice up to the users.

Others have commented on the excessive padding, there seems to be a cycle of increasing and decreasing the padding at Microsoft.

Anyway, I welcome this effort. It will be very beneficial for fluent design if Microsoft tries to apply it to a serious app like Visual Studio. The current state is fine for smaller apps, simple list-detail views and so on. But there are a couple of problems for larger, productivity style apps. The menu bar is needlessly spacey, there are no rich list/detail views a la Explorer, keyboard navigation is tricky... If Microsoft is going all in on Fluent (with Office, Explorer, Terminal, Visual Studio), they will hit these limitations. And I hope that the new widgets they are developing will soon be available for others as well.

When was the time they decreased padding? I remember MS products being fairly consistent up until Win8, then it went all downhill with the fisher price tablet BS.

More air and space by some designer. Is that Designer actually using VS Code for software development? On a 13” MacBook?

The VSCode UI is actually much more compact. This is "Visual Studio proper" which only exists on Windows.

All the recent re-designs looks like they started with ignoring anything below 15" (looking at you AWS)

So most of this is just making things bigger, but ignoring that for a second I'm confused about the inconsistency between the changes to Menus and Active region styling.

The changes for active region styling create a clearer connection between the selected tab and the space it's about. This seems like a very sane change. Then for the menu they explicitly remove that connection, by separating the menu from its button entirely. They also dim the background color of the menu, making it much less clearly separate from everything behind it.

So disgusting round like any UI/Website refresh in the last few years. You can look at any of the comparing screenshots find an UI element which had a sharp corner previously, it is round now.

In every single example, at a glance, the old left image was clearer than the new right proposed ui with muted colors. I don't use this buggy software anyways so don't have a horse in this race but from a UI design doesn't seem better to me. They should really go back to the windows 2000 aesthetic. That was the peak imo.

Is there an easy way to go back to Win 95 style please? That's the UI I'm looking for.

Another example of designers not understanding their user base they are designing for.

Expert users like developers prefer higher information density. Give them the ability to configure this.

As a designer, don't ram your sense of beauty down your users' throats.

Visual Studio is one of my least favorite IDEs and judging from the examples in the article, none of these changes appear to improve it. But I'm not sure they make it worse, either. I guess I'll find out when I have to use it.

I dont like this newbie enlarged rounded ui PEGI 3 compliant.

I put 100% dpi on 4K monitor to get the most surface for actual code. this expanded UI will make it worse for all this devs using 250% scale factor on 15 inchs monitor .

That existing UI make me feel home.

My coworker does this. I have no idea how you people don’t get killer headaches. Good vision? Hats off to you.

I'm in the 100% scaling camp also. I love how good a 32" 4K display is forfitting mountains of content on a display. Don't need to bother with Portrait monitors anymore.

I'd once heard that VS was one of Microsoft's most potent assets for attracting developers, that rounded-off controls with some margins made buttons and other clickable elements more identifiable, and that strong keyboard bindings were preferable to toolbar clutter.

I don't really have much of an opinion, these changes are so subtle it's hard to care and I don't use VS anyway, but I'm surprised at the strong reactions and lack of advocacy for the above.

Of course it's perennial that a lot of users react negatively to change, which makes sense, too.

No. Please don't bring these floating and tearaway tabs that were popularised with the last Firefox (Photon?? Proton??) to menus. Why? They don't improve anything like this article is saying.

The list of options below the 'File' menu are to do with 'File'. This is unambiguous and has been since the days of Windows 3.1. Can anyone explain the benefit of changing these, and why it is better than what we had before?

So they made text bigger and increased text padding ?

So now not even developer tools are safe from enshittification and these horrible "modern user interface" trends.

I'd like for better discoverability. I only launch visual studio when I need to work on specific projects, so I don't have the muscle memory of a heavy user. Some project settings or features are buried far into dialogs, and other things don't even have keyboard shortcuts.

Meanwhile Visual Studio’s UI can’t keep up with a user repeatedly pressing F10 to step forward during debugging.

It doesn’t matter how pretty it is if it’s not functional.

Link: https://youtu.be/GC-0tCy4P1U

Since a very long time Microsoft thinks you are disabled if you press a key multiple times.

So you are actually naking it worse for anybody who doesn't use 64 inch screen. Awesome.

So they... increased padding on all elements? Is that really what this is?

I suppose it could be worse. They could have done what jetbrains just did and replace all the text with meaningless heiroglyphs.

I'm guessing that whoever came up with these changes doesn't use the product. I wouldn't be surprised to discover they don't even use Windows.

Welcome changes. I like these changes since I run at higher than 2560x1440 resolution (fractional scaling in between 1440p and 2160p), and it won't look as squashed together.

Now try running it on 13 inch laptop.

I have 1920*1080 screen and it still takes me a fair amount of tweaking to reduce clutter to something workable.

No thanks, I don't do laptops. Besides, there is no reason why everything needs to be optimized for the small screen - there should be options for varying sizes.

I hate how it seems two spaces are visible before the "using" statements. At the very least give the margin a different color than the actual code area.

I wish they would invest more time in improving their dark theme. It is OK, but kind of jarring still.

Cool, so they're increasing paddings a bit while apparently still not making the layout make more sense.

seems a very minimal change but thats ok, vs layout is good as it is, would be nice if they would sync key shortcuts betweens vs and vs code.

now you need a larger screen to use this software.. microsoft will never learn, that's impressive

I don't care what they do the menus and toolbars one way or the other, so long as they're still able to be customized and hidden, and so long as fonts remain universally customizable and resizable.

Increased granularity for font selection would be nice, e.g., using a proportional font for some file types and a monospaced font for others, enabling or disabling ligatures on a per-file type basis, changing fonts or sizes of specific editor and tool windows, etc.

But what I've really wanted since forever is some lightweight extension mechanism that'd allow me to define custom commands and assign them to keystrokes, menu commands, and events — from directly within the IDE, without the overhead of building, testing, and installing a VSIX package.

As a simple example: I'd love to be able to toggle between sets of predefined font selections with a single command, which could be trivially defined in terms of the already existing settings import mechanism, if only there were a simple way to automate it.

Another example: while VS allows me to launch an external command on the current file or project, it'd be nice if it'd allow me to post-process the result into a list or tree view, which, again, would be easily defined in terms of existing IDE functionality, or to filter the current text selection through a function or external program.

Finally, in conjunction with the above, it'd be nice to be able to define custom keyboard shortcuts, menu options, and toolbar buttons in the editor for particular file types, in the spirit of Emacs auto-mode-alist.

In the distant past, a form of what I want existed in terms of VBA macro support in the IDE, but this was removed, IIRC, when they migrated the UI to WPF.

In recent versions, the only way I've been able to do any ad hoc scripting is via the (undocumented) $DTE variable in the NuGet Package Manager Console:

    ~>  ($DTE.ActiveDocument | Get-Member).Name -join ', '
    Activate, ClearBookmarks, Close, MarkText, NewWindow, Object, PrintOut, Redo, ReplaceText, Save, Undo, Extender, ActiveWindow, Collection, DTE, ExtenderCATID, ExtenderNames, FullName, IndentSize, Kind, Language, Name, Path, ProjectItem, ReadOnly, Saved, Selection, TabSize, Type, Windows
    ~>  $d = $DTE.ActiveDocument
    ~>  $s = $d.Selection
    ~>  $s.Text
                            var tokenText = Encoding.UTF8.GetString(
                                pBuffer + tokenOffset,
                                endOffset - tokenOffset
                            );
    ~>  $s.Text -match '^\s*' >$null
    ~>  $s.Unindent(($matches.0).Length / $d.IndentSize)
    ~>  $s.Text
    var tokenText = Encoding.UTF8.GetString(
        pBuffer + tokenOffset,
        endOffset - tokenOffset
    );

    ~>  

But even if I could find a way to use this to create assignable commands, using arbitrary COM objects from PowerShell can be painful.