Andy wants my blood but on an internal email thread both Don Box and Chris Sells also want it.

I was responsible for the new C# keybindings (I’ll let you have a moment to stick that pin into the Microsoft PM Voodoo doll you all have J). It all started when I was given the keyboard randomizing dice that the last person used to determine VS keybindings...

Seriously, we actually spent a lot of time thinking about the C# keybindings in VS 2005 before making any changes. To put this issue into perspective you need to know something of the history of keybindings.

In VS 2002 and 2003 we (the C# team, well actually me againJ) didn't really look at the keyboard bindings that closely. If you look at the Start Page in VS 2002/2003 and you select the C# Developer Profile you'll notice that we simply use the “VS Default” keybindings.

So who decided the “VS Default” keybindings? The short answer is individual teams within VS. As teams introduce new commands each team simply hunts for an open key binding, finds one and assigns it. Timing plays a big part in what keys you get and once you have a specific keybinding possession is 9/10’s of the law.

Now the good thing is that teams are usually consistent with the key bindings they have for their commands but with so many teams contributing many commands it can quickly fragment and of course every team believes that their commands are pivotal to the success of Visual StudioJ.

Let’s have a look at some of the VS Default keybindings in VS 2003. With no project opened the View Menu in VS 2003 has the following commands and keybindings:

  • Solution Explorer     Ctrl+Alt+L
  • Class View            Ctrl+Shift+C
  • Server Explorer       Ctrl+Alt+S
  • Resource View         Ctrl+Shift+E
  • Properties Window     F4
  • Object Browser        Ctrl-Alt-J
  • Toolbox               Ctrl-Alt+X

See any connections here? I didn’t think so.

If you start a debugging here's a subset of the commands and their keybindings under the Debug Menu:

  • Breakpoints           Ctrl+Alt+B
  • Autos                 Ctrl+Alt+V, A
  • Call Stack            Ctrl+Alt+C
  • Threads               Ctrl+Alt+H

The debugger team appears to have a consistent access method, but why is Threads H? (Answer: Ctrl+Alt+T was taken by View.DocumentOutline). Why does Autos have a two key combination etc?

In VS 2005 we have introduced the idea of profiles which allows each team to create a consistent experience for their developers. This essentially allows teams to actually look at the keybindings from an overall product perspective and decide the logical set of commands for their users and then map appropriate keybindings for them.

When I went about looking at the C# keybindings for VS 2005, the first thing I did was map all the Global and Editor keys from VS Default keybindings into a spreadsheet (oh the glamorous life of a PM). It was interesting to actually go through the process and watch a form of key bingo being played as teams searched for the last slot and the different key modifiers. If you are interested VS uses nearly all the modifier keys and their combinations. On the spreadsheet I mapped the following modifier keys: Ctrl, Ctrl+Shift, Alt, Shift, Shift+Alt, Ctrl+Alt, Ctrl-Alt-Shift.

Here’s how we went about coming up with new keybindings:

1.      Create command themes. We wanted to create some command themes that allowed us to gather common commands together. Examples of themes we used were: Design time windows, Debug time windows, Refactoring commands, IntelliSense commands, Bookmarks, Help etc. These themes make the group of commands more understandable as well as easier to learn. For each of these themes we created a two chord key combination, the first one activates the theme and the next one activates the command so: 

  • Ctrl+W, S   Window, Solution Explorer
  • Ctrl+W, C   Window, Class View
  • Ctrl+R, E   Refactor, Extract Method
  • Ctrl+R, R   Refactor, Rename
  • Ctrl+D, A   Debug, Autos Window
  • Ctrl+D, B   Debug, Breakpoints Window

2.      Prefer common C# commands. There were a number of places where common C# commands either didn’t have the obvious keyboard combination in VS2003, or there were natural conflicts with the commands. In these cases here, we preferred the command we thought would be more common for C# developers to use and if this didn't work then we preferred the old keyboard letter. 

3.      Push the new commands to the front. Commands in VS can have multiple keybindings. In order to encourage users to use the new keys we have moved the new keys to the front of the list so they get shown on all the menus. The other keybindings are still there, they just don’t get shown.

After applying this philosophy we obviously ended up with some a fair number of changes. Using the commands above this is what they now look like:

  • Solution Explorer     Ctrl+W, S
  • Class View            Ctrl+W, C
  • Server Explorer       Ctrl+W, L (we prefer S for Solution Explorer over Server Explorer)
  • Resource View         Ctrl+W, R (moved this off the main menu to submenu)
  • Properties Window     Ctrl+W, P (F4 is still bound)
  • Object Browser        Ctrl+W, J (preferred O for Output window, so we kept old letter)
  • Toolbox               Ctrl-W, X (preferred T for TaskList, so we kept old letter)
  • Breakpoints           Ctrl+D, B
  • Autos                 Ctrl+D, A
  • Call Stack            Ctrl+D, C
  • Threads               Ctrl+D, T

But while we think the new keybindings are a lot more logical and easier to learn we totally understand that people don’t like gratuitous changes and want to be able to use that muscle memory they have developed. So what we are going to do is make as many of the old keybindings available as well (the new ones will be shown by default but the olds ones will also work).

Unfortunately (you knew it was coming) in the Community Previews as well as the upcoming Beta for VS 2005 we haven’t actually put many of the “old” keybindings back into the C# profile (I promise this isn’t a conspiracy theory – we will get this in soon).

I’d be interested in what you think. Should we have:

  1. Left the keys alone . Let you discover the new commands and bind them to keys you think are appropriate.
  2. Left the keys alone and find new keys (no matter how unnatural) for any new commands we introduced
  3.  Do what we have currently done.