Visual Studio is an undisputed king of IDEs in the Microsoft ecosystem. There is virtually nothing even remotely comparable with it on the market. It is so good (for a mainstream product) that it is even used outside of the Microsoft ecosystem, for example in cross-platform game programming, or in embedded development. With already cool and even more improving support of JavaScript and HTML5, it has chances to expand on to the enemy’s territory and begin to be used by (historically very LAMP-biased) masses of web developers. Some existing users of Visual Studio would remain in the Microsoft ecosystem just because they can use Visual Studio (I’ve been using Eclipse in the last 9 months, I know what I’m talking about). Thus, Visual Studio is one of the most critical products for Microsoft’s future. And this product absolutely deserves and needs the best UI that Microsoft’s smart and passionate guys can ever make.
Now, what is the Metro design language? If I had to describe it in one word, it is semantic zoom. The oversized captions abruptly cut on the right side make you believe you’ve zoomed in into a virtual surface larger than your screen. This is ingenious for smartphones with their small screen size. Just by taking a brief look, users immediately know that a) there is more info than currently shown b) the additional info is on the right, so it is natural how to navigate and c) they might think “my smartphone display is a small window into a virtual surface, much like a magnifying glass or a porthole, hey, cool, let’s explore!” I believe, everything else is just thinking this initial idea consequently through. For example, unlike iOS aestethics with their hyper-physical elements, expensive materials texture, stitching and virtual LEDs, the aesthetics of Metro is demonstratively symbolic and abstract. Maybe it is because if you would really start zooming into “physical” controls, what you will see is only ugly manufacturing details, not a new level of gorgeous controls. The emphasis on typography is apparently also consequence of the zooming metaphor: in Metro, we’re zooming close enough so that even non-typographers start recognizing font differences and typographical issues. Besides, in a symbolic and abstract zoomable world devoid of expensive-looking textures and stitching, users need something they can adore, and it can be only elegant graphics of icons and types, and pure vibrant colors.
So, how would you apply Metro to Visual Studio? You can take the “consequences” – large captions, vibrant colors and elegant two-dimensional icons – and mechanically apply them to the existing UI metaphor. It seems that this is what the UI team really did. Or, you can descend to the very root concept, to the semantic zoom. Software development is a activity of processing tremendous amounts of information. Non-programmers normally have no idea what a huge amount of information is being processed during development. This is the reason why programmers hate scrolling. They also hate employers who give them only one monitor, because they need two, or, better, four. It is not because four monitors would give them enough space to open the full source code of the software they’re working on. No program bar very trivial ones can be fully shown on just four monitors. Typically, they would put different things on different monitors, like, the solution explorer with the errors list and console output in one display, the source code into the other, and a help page or API reference into the third one, and a browser or simulator running the software they are writing into the fourth one. Even though they have four monitors, each can still display only a tiny bit of information they need. Now remember the porthole. Isn’t this a case ideally suitable for Metro – display size that is too small compared to amount of information that has to be shown?
So, if the Visual Studio team would be really radical, they should have had scrapped away the good-old MDI interface, and add semantic zoom inside of the each type of window Visual Studio has. Semantic zoom in the source code editor: captions represent class methods (with one additional caption to “show all”), the body represents the source code of the method. Semantic zoom in the solution explorer: captions are projects, body is the list of files. Move a file from project to project just like you move Win8 app from one group into another. Move a method from child to base class by dragging and dropping. Such things. Radical things. Revolutionary things. (Well, Smalltalk IDEs have already had most of this 30 years ago, but we’re speaking about the mainstream here.)
I don’t know why this hasn’t happened, and why the Visual Studio team has only adopted some visual ideas, without changing the core of the UI metaphor. The result is catastrophic in terms of community feedback. They write that they have added more energetic colors, but don’t explain why an MDI interface needs them. They use ALL CAPS in the ancient menu bar, pretending them to be zoomed in, but really making them to look just weird and unprofessional. They’ve replaced the old icons with new, less physical and more symbolic ones. This is old:
And this is new:
I like very much the elegance, modernity and simplicity of the new icons, but let me tell you one thing. Software developers are absolutely allergic to any changes, which do not improve their productivity in a visible and palpable way. They, too, might appreciate the new elegance. But they are paid for getting things done, and are struggling at the forefront, drowning in the massive amounts of information they have to handle. Give a drowning man a hand, and he will bless you, give him a flower, and he will curse you.
In my opinion, any of these changes, and even more radical visual changes (like OMG, making colorized source code more elegant, or removing tiny meaningless icons in front of file names in the solution explorer) would be eagerly accepted or at least tolerated by the community, if the UI metaphor was changed to be a more productive and more ergonomic one. But now, the Visual Studio UI team has to handle angry and vocal users of this very critical product, threatening to stay on the previous version, or even to start looking around and trying other IDEs.
I personally have no own practical opinion. Just by looking at the screenshots it seems to be more elegant, and it wouldn’t take more than a week to re-train all the source code processing reflexes. It is only a bad after-taste of a missed chance. Any bigger change will make users angry. You cannot make users angry two versions in a row. That means, Visual Studio 12 cannot be a radical change. And it feels that the opportunity for change in VS 11 is wasted. This is a dangerous situation for Microsoft. Ballmer was very right with his “Developers!” tirade. The way Microsoft ecosystem developers were handled lately is a series of mis-management, and I wonder, why this issue has not yet been escalated to the very top. I believe, this issue is important enough to be in the top 3 list for Ballmer.