Last time we had a look at how Microsoft reinvented
the wheel the Visual Studio UI into a colourless ‘metro’ version. This time I’m going to look at some lessons we can learn from the story.
The first lesson is: Know the limits of a good idea.
Microsoft made quite a big thing of the idea that icons in VS2012 are simplified in order to improve developer productivity. So let’s look at some icons. In Visual Studio 2010, if you had a mixed C#/VB project, the solution explorer would look like this:
Look at the C# and VB file icons. Not only are they complicated, but on a quick glance they look very similar: For both icons, the dominant feature is the file symbol.
In VS2012 the icons changed to these:
That’s much clearer, and makes it much easier to distinguish a VB file from a C# one. Now I admit I have a vested interest in this: On more than one occasion, I’ve created a VB project, typed in some C# code, and then spent 20 seconds staring blankly at the screen trying to figure out why
refuses to compile. So I rather like these particular icon redesigns.
But look at the folder icons in the same screenshots: They’ve also been slightly simplified, mostly by changing them from yellow to black. Why? The yellow folder icon has been a clear and very easily identifiable marker of a folder for a long time. Changing it to black changes the aesthetics, and you may or may not like that – but it doesn’t obviously make the icon easier to see.
It gets worse: Look at the icon for running a test. The old one:
And the new one:
The beaker shape is presumably taken from the way beakers can be used for testing chemicals in chemistry, so there’s some logic to the symbol. However, the green arrow of the old icon is a very clearly recognized icon for running something (such as a program, or a test). Not only has that familiarity been lost, but the new colourless icon is arguably just as complicated! So much for simplifying the icons to make them easier to recognize!
So we started with the very sensible idea of simplifying the icons, but it seems that someone didn’t know where to stop, and we ended up seeing perfectly good, functional, icons being needlessly redesigned just for the sake of it.
Now let’s talk about productivity. The new UI is supposed to improve productivity, for example by allowing people to recognize icons more quickly. Now I find this curious because I’ve been using VS2010 and VS2012 side by side for some months in order to compare them. While VS2012 does have productivity-improving functionality (the merged solution explorer and class view, for example, is great!), I haven’t noticed that the monochrome appearance is any easier to use.Personally I’d say that even after several months of getting used to the new UI, I find the monochrome icons slightly harder to recognize, even though I quite like the style. So why is my experience so different from what Microsoft claimed?
Well that’s easy…. Because there’s something I reckon the Microsoft Visual Studio team has forgotten: People are different.
Let’s emphasize that: People are different. Different people’s brains work differently. That’s why whenever I want to know how to get somewhere, I look at Google maps in aerial view to see what the road layout is, but whenever my partner wants to know how to get somewhere she looks at Google streetview to see what the buildings look like: I navigate primarily by forming a 2d mental map of road layout, but she navigates primarily by recognizing buildings and features.
It’s why when my employer of a few years back asked a couple of us to learn WPF, I quickly went out to buy a book and spent several days reading it (actually Chris Sells and Ian Griffith’s one – very good by the way) while the guy on the next desk started experimentally copying and paste bits of WPF code from the Internet. I learn best by reading and understanding the technology, he presumably learns best by experimenting.
It’s why accessibility guidelines suggest making sure tasks can be accomplished with a mouse (some people find the mouse easier) or with the keyboard (some people find the keyboard easier).
The world is of course good because Google Maps provides both an aerial view and streetview – so I’m happy and my partner is happy.
The world is good because some people write books explaining WPF and other people post code snippets online – so I’m happy and my colleague was (I hope) happy.
And in just the same way, different people’s brains work differently when it comes to colour. It’s easy to see that different developers react differently to colour: You only have to look at the mixed reaction to VS2012, and how some people loved the lack of colour, while other people hated it. Incidentally, I get reminded of this difference every time I design what I think is a brilliant user interface full of pretty colours and my colleagues shout ‘too bright! Tone it down!’
Let’s go back to that folder icon that Microsoft changed from yellow to black. The black is clear. It’s bold. Depending on your point of view, it’s either elegant or ugly. And it’s colourless.
And I’m going to hazard a guess that people who identify icons primarily by shape will find the black slightly easier to recognize. Enough to make a tiny fraction of a second’s difference, without you even being consciously aware of it.
And I’m also going to hazard a guess that people whose brains rely more heavily on colour will find the black slightly less easy to recognize.
And of course the world isn’t good because Microsoft didn’t provide both types of icon: They have decreed that *all* developers should use the black folder icons.
The lesson is obvious: One size does not fit all! What Microsoft has done is a bit like a sock manufacturer that once upon a time only made small (size 6) socks. Suddenly management realized that its socks were too small for some feet, and in response, decidedhenceforth to make only size 10 socks, failing to recognize that feet sizes vary and so really both sock sizes (and actually, a lot of other sizes too) are required.
Now let’s think a bit more about this issue of only having one style of icon.
Visual Studio 2012 comes with two built-in themes, and when it was released many developers quickly started investigating whether they could write new themes. The answer is that yes, you can, up to a point. You can change colours, and you can change fonts. But you can’t replace the icons.
Why not? Visual Studio is after all written in WPF,and WPF is specifically architected to facilitate separating the user interface from the backend logic, precisely to allow (amongst other things) plugging in a different UI.
Now to be fair to Microsoft, although WPF allows easy separation of the user interface from the code, that doesn’t out of the box automatically mean users can replace all the icons. You’d need to do some coding work on the application to allow that. And yes, adding such a feature would be time that’s not spent doing something else (Just like time spent redesigning perfectly good icons is time that’s not spent doing something else!). On the other hand, if a WPF application has been well architected from the start, that shouldn’t be a huge amount of work, and it would be a good answer to a very large number of unhappy customers. So it seems reasonable to ask why Microsoft hasn’t at least provided the framework to do that. There are two possible answers:
Firstly, maybe the effort to allow icon replacement is really far too great.
Secondly, maybe a decision was made that, for whatever reason, Microsoft did not want users to be able to replace icons.
Now I have no inside access to Microsoft, so I have no way to tell which hypothesis is correct. However it seems likely that Visual Studio would be sufficiently well architected that pluggable icons wouldn’t be a massive effort: Microsoft does after all have a lot of resources and many very clever developers working for it. On the other hand, pushing out inappropriate user interfaces because of some higher abstract ideal that doesn’t actually work doesn’t seem too far removed from Windows 8! That makes me suspect the second reason is more likely. And ironically, that would reinforce the point about taking a great idea too far (In this case: Simplifying UI features so they work well on mobile devices: Not good for Visual Studio).
So what lessons can we draw from all this?
Well, firstly, that separation of UI and business layer is good. I’m sure that even before you read this article you could already think of dozens of reasons why it’s good. Now you have another reason: Because it means that if you have lots of customers who love your application but hate your user interface, it becomes a lot easier to let them customize the user interface!
Secondly, understand the limits of a good idea. Simplifying a user interface is good. And when it improves productivity, it’s great! But that doesn’t mean you have to change everything. If some parts of the old UI were great, then leave them alone!
Next time: Concerns, Services and Dll’s