Improving the Visual Studio 2010 UI Menu System – Part 4

[ In this series – Part 1, Part 2, Part 3, Part 4 ]

Please note that updates have been made to Part 3.

In this final part of the series, I’ll be covering suggested changes to the UI for future versions of Visual Studio. Originally this series was only meant to cover the toolbars and menus, however I’ll expand the scope slightly in this final part.

In March this year I was fortunate to attend the 2011 MVP summit in Seattle. In one of the sessions, Scott Guthrie gave a demo and he needed to change the startup project in a solution. He right clicked the project in Solution Explorer and then he paused for around 3.5 seconds, scanning the context menu for what he wanted, before clicking ‘Set as StartUp Project’. This is the exact kind of experience which inspired me to write this series and illustrates what needs to be accomplished in future versions of Visuals Studio; reduce the Pause Effect.

Reducing the Pause Effect

What is a pause? I would call any moment of development when you ‘stutter’ a pause. It may be 1 second, it may be 10. Why do we pause? A simple answer would be that we are new to it and are still finding our way around. For those using Visual Studio for 40+ hours every week, that simply wouldn’t be true. The reason we pause is that there is too much displayed to us. Too many toolbars. Too many context menu options. Too many icons which look the same. I’ve even been told by a fellow MVP that some people don’t develop with Visual Studio because it’s intimidating!

Something has to be done; here are few possibilities.

 

Bring on the Ribbon

This is bound to be the most controversial suggestion but I’m a firm believer in the ribbon. Before Office had the ribbon, I would frequently pause and wonder which menu held the item I wanted. I don’t find myself pausing nearly as often now that my entire Office 2010 suite has the ribbon interface. I think there would have to be some tweaks in the way the ribbon is currently implemented, however this could provide one of the largest usability fixes to Visual Studio, pleasing existing users and perhaps drawing in those who have previously been too intimidated to try the product.

 

Toolbars

I wonder how many developers sit with toolbars open that they never, ever, use? 80%? In Part 2 we saw how bad the situation is. The start up experience for new users could be tweaked (minimal investment, minimal benefit), however one word describes the solution here. Ribbon.

 

Categorise and Consolidate the Context Menus (embrace widescreen)

Various context menus in Visual Studio show a collection of common scenario based menus together, grouped by grey split lines at the top and bottom, e.g. Version Control

Image: Context menu on a Project

Some of these items are used extensively, some not. Rather than a flat list like this, the less often used commands should be moved to a 2nd level menu. Perhaps we could even have a single line for Version control. Take for example the standard Cut Copy Paste menu:

Image: the standard Cut Copy Paste menu

That’s a lot of real estate. Now compare that to a consolidated menu offered in Google’s Chrome web browser:

Image: Google Chrome’s consolidated Edit menu

The consolidated group is identified by the label on the left, Edit. Vertical real estate is still expensive to users, however horizontal is no longer an issue with the broad adoption of wide screens. This consolidation may seem odd at first, but it’s a very effective use of space. Perhaps the Project context menu shown above could simply be

Image: consolidated TFS Project menu. Arrow leads to 2nd level menu.

I don’t know if Visual Studio even provides the ability to host multiple buttons on a single line, but if it doesn’t, it should. All applications should provide context menus which fully utilise todays widescreen market.

 

Smarten up the Context Menus

You would expect a context menu to be smart by design right? Not always, e.g. why is it that when we have one project in a solution, we still have the ‘Set as StartUp Project’ context menu available? Its clutter and it’s adding to the pause effect.

 

Clean up the Icons and Text

In Part 2 we saw that several icons in Visual Studio are the same

Image: Identical Icons. Different actions.

This is insanity. Each icon should be unique and distinctive. This is definitely easier said than done, however an exercise in attempting this should be done. In cases where a distinction is not possible, text should be used.

I think an exercise in reviewing all Menu items text should be undertaken to ensure it is concise and whether it could be shortened. We have menus to perform actions, not to read a bunch of text to perform the action, e.g. We have ‘Check In…’, but not ‘Check Out…’, its ‘Check Out for Edit…’. And what’s with the three dots after some menus and not after others? There must be a reason, but we don’t need them.

 

Herd up the 3rd Parties

The UI is overloaded after a fresh install, yet Microsoft still allows 3rd parties free reign to add menu items anywhere they choose, e.g.

Image: StyleCop installer adds two Context menu items.

Throw on ReSharper and a few extensions and before you know it, you have scrolling context menus and a bad case of pause effect. Visual Studio allows you to configure your menus, but this is a horrible experience. Instead of the onerous task being thrown at the end user, perhaps 3rd parties should all be given a 2nd level menu by default. If the user wants a specific menu from the 3rd party application, they can ‘easily’ copy it to wherever they want on the UI.

 

The Option is Where?

All the changes above would no doubt lead to further options being added to the options dialog. How much time have you spent looking for an option in a complex product like Visual Studio, Office, IE or any other company’s product? I was inspired the other day when I saw the search box in Chrome. This search functionality would be a great addition to any product that delivers the scale of options which these products do.

Compare for example, the options dialog provided by IE 9 and Chrome 12

Image: IE9 provides many tabs and trees of options to hunt through

Image: Chrome provides the ability to search through options.

Imagine being able to search through Visual Studio’s options in a second. It would save you time and frustration. It would reduce instructions in documentation. It would be great!

Note, I’ve been told about Quick Access in the Productivity Power Tools, however I don’t think this offers the same level of user experience because:

1. I have to install an extension
2. If I go to tools options, I can’t search anyway (even with the extension installed)
3. I have to know about CTRL-3
4. If I do use it, it doesn’t work. I clicked CTRL-3, entered “tab” clicked the result item and nothing happened.

Image: Click the arrow line highlighted and nothing happens

I’ll give future versions a try though and see how it develops.

 

Conclusion

Given the incredible software we can create with Visual Studio, it is ironic that Visual Studio itself is in need of a makeover. Radical overhauls to product UI’s will typically displease the current user base as  they are taken from their comfort zone and thrown into a fresh new world.

Given Microsoft’s experience with updating the Office UI, I’m confident that a radical overhaul to Visual Studio can be a success and provide a limited short term discomfort to the user base while providing a next generation development environment with significantly reduced ‘pause effect’.

This is a high investment ticket with debatable reward. The current UI could probably be tweaked a bit for a version or two with minor benefit, but I think its time to at least start the debate on a larger investment in a near future release.

Acknowledgements

• I’d like to thank Adam Cogan for his feedback on this series.

Mike