Lipstick on a Pig is Not UX

AlexTatiyants

Rate me:

4.00/5 (1 vote)

12 Mar 2012CPOL2 min read

7.9K

Microsoft's new Visual Studio attempts to "engender the impression that VS feels lighter and less complex". In other words, instead of radically rethinking what a great development experience would be like, they focused on obfuscating the problem.

Microsoft’s recent announcement of a new version of Visual Studio has a fascinating quote in it (a colleague of mine pointed it out to me). Here’s the quote (emphasis mine):

Through reductions in toolbar command placements, line work, iconography, and color usage, Visual Studio 11 manages to simultaneously devote more space to your content while at the same time engendering the impression that VS feels lighter and less complex.

To paraphrase:

We heard you loud and clear about how Visual Studio got too complex and unwieldy. No problem, we will try to make it look less so.

Now, I appreciate Microsoft’s almost disarming honesty. After all, they could have easily ignored the naysayers, pretending as if Visual Studio’s Mardi Gras parade of options and menus is just what the doctor ordered.

But they did not. Visual Studio team owned up to the well deserved criticism and decided to do something about it. It’s just a shame that they took the old “lipstick on a pig” approach. Instead of radically rethinking what a great development experience would be like, they focused on obfuscating the problem.

Sadly, it didn’t have to be this way. It just so happens that the timing of this announcement almost coincided with the release of Bret Victor’s fantastic talk on (at least in part) what a great IDE would look like. In many respects, his vision is almost literally the opposite of Visual Studio’s:

Bret Victor – Inventing on Principle from CUSEC on Vimeo.

Now, I’m not nearly naive enough to pretend that his ideas will work perfectly in every situation where Visual Studio comes up short. I’m sure that there is a lot more work and refinement to be done before this can become viable for everyday development. That said, which of these two visions are closer to your idea of a great dev workflow?