Visual Studio Monochrome – Part 1

To a developer, bugs are things like, returning the wrong value, or a textbox being disabled where it should be enabled. Or when you’re given the honour of a 20 minute audience with the CEO to show him the brilliant new settings dialog you just spent 2 months writing and after 3 seconds it crashes.

If someone said that your app looked aesthetically unappealing then – sure – that may mean it needs some work, but calling it a bug is arguably twisting the definition of the word a little. Yet when last year someone raised a bug, Microsoft Visual Studio 2012 – is ugly as hell, no fewer than 55 people claimed to be able to reproduce the issue, and 164 devs have so far upvoted it. Microsoft has closed the bug as ‘Deferred’.

The subject of the ugly-as-hell bug was of course the metro-inspired redesign that changed Visual Studio from looking like this:

VSMonoPt1_VS2010 Code

to this:


Microsoft is no stranger to unpopular product releases (Vista, anyone?), but I can’t recall a Visual Studio release ever being so – umm – shall we say, controversial.

Of course Microsoft believed they had good reasons for the UI changes. They claimed that the aim of the new UI was to focus your attention on the code instead of on all the other bits around it – because the code would be the only part of the screen that had full colour. The change is also in line with the metro-ization of the Windows look, with the emphasis in Windows 8 on simple design and showing only the content, leaving out the chrome. Microsoft also claimed that their tests showed the simpler monochrome icons improved productivity. And it has to be said that the new design wasn’t universally unpopular – some developers do like the new focus-on-the-code theme.

It strikes me though that there are some grounds to question Microsoft’s reasoning.

For a start, if I was starting with VS 2010 and I wanted to change it to focus attention on the codewindow, this is the first solution I’d try.

VSMonoPt1_VS2010 Code Highlighted

Now I’ll grant you that screenshot is a bit rough-and-ready, and it’s also incomplete. Ideally I’d also like to reduce the chrome by making the borders paler. But in my defence, it too me all of a minute to do (using Paint.NET). I wouldn’t like to even begin to estimate how many man-decades of work went into Microsoft’s Visual Studio redesign. If I had a few man-decades to spare on some product, I could implement a lot of new (real) functionality!

Now, while we’re on the subject of highlighting code, here’s what the UI for editing web performance tests in VS 2010 looked like.

VSMonoPt1_VS2010 WebTest2

As you can see, for web tests the main ‘coding’ window was designed as quite a nice graphical tree. Now here’s how that UI changed in VS 2012.

VSMonoPt1_VS2012 WebTest

Can you spot the coding window that Visual Studio 2012 has specially emphasized for you? (If you need a clue: It’s the big grayish window with black icons surrounded by all the other grayish windows with black icons).


Now let’s talk about the metro look.The big thing about the metro look in Windows 8 is that you are really emphasizing content. You take away all the chrome and all you see is the stuff you need. And for many apps the idea works really well. Here for example is a random PDF (actually the UK highway code) viewed in Adobe’s metro PDF viewer app.

VSMonoPt1_Highway Code Metro

That compares very favourably with the old style look, with all the controls.

VSMonoPt1_Highway Code Win7

However, the reason that works so well is you don’t need any of the chrome – or any of the controls – to read the PDF. So hiding the controls away makes a lot of sense.

The same thing doesn’t really hold for Visual Studio because when you’re coding, you rely on having the controls always available. If you’re anything like me, you’re continually navigating to different classes, checking search results, etc. So the Windows that Visual Studio 2012 has de-emphasized are actually Windows that you need most of the time. I’d argue that, the new Visual Studio look isn’t a true metro look at all – a true metro look would have the code window occupying the whole screen. That probably would look good (and it is available as an option in both VS2010 and VS2012) but a lot of the time it’s not what you need when you’re coding.

So what we’ve ended up with in VS2012 is a hybrid – an attempt at metro-ization in a scenario that metro-ization was never really appropriate for.

And the result is a set of radically new Visual Studio aesthetics that have left some developers very happy, and other developers fuming – detracting attention from the very real improvements that have been made to VS functionality.

Well picking holes in Microsoft’s work is always a fun developer pastime, but I’m sure you’re asking what lessons and conclusions we can draw from this all. The answer is, quite a lot interesting stuff about application architecture and separation of concerns and UI design.But, you don’t really think I’m going to destroy that cliffhanger when I want you back reading TechieSimon next week do you?

To be continued… Next Week… funnily enough… Visual Studio Monochrome, Part 2.


One thought on “Visual Studio Monochrome – Part 1

  1. I once had to demonstrate some software to the President of Rwanda, on the fringes of a conference. Just as he was approaching, some newspaper photographer decided to get a better angle by going behind my desk, treading on the power cables and causing the PC to shut down abruptly. Does that qualify as a bug?

Comment on this article (your first comment on TechieSimon will be moderated)

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s