(1 item) |
|
(1 item) |
|
(5 items) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(6 items) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(4 items) |
|
(2 items) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(2 items) |
|
(5 items) |
|
(3 items) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(3 items) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(8 items) |
|
(2 items) |
|
(7 items) |
|
(2 items) |
|
(2 items) |
|
(1 item) |
|
(2 items) |
|
(1 item) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(5 items) |
|
(1 item) |
|
(3 items) |
|
(2 items) |
|
(2 items) |
|
(8 items) |
|
(7 items) |
|
(3 items) |
|
(7 items) |
|
(6 items) |
|
(1 item) |
|
(2 items) |
|
(5 items) |
|
(5 items) |
|
(7 items) |
|
(3 items) |
|
(7 items) |
|
(16 items) |
|
(10 items) |
|
(27 items) |
|
(15 items) |
|
(15 items) |
|
(13 items) |
|
(16 items) |
|
(15 items) |
There has been a fair amount of discussion about key bindings in VS.NET, and the fact that they seem to be changing yet again in VS.NET 2005.
I have mixed feelings about this. Every time the bindings change, I've been mildly annoyed, but I've always learned the new ones, and have usually grudgingly accepted that I end up slightly preferring the new ones. Although I can't help wondering if the current set were designed by someone who knows how to play the piano. I say this because I find it quite natural to use multi-key 'chords' but I've noticed a lot of people seem to find them really quite awkward. I often wonder if the main reason I find them easy is because I used to play the piano to a reasonably good standard...
But the thing that bugs me most about the current set of bindings is the amount of arbitrary stuff you have to remember. JoeN provides some fine examples of this. (It's precisely this kind of nonsense that means I can no longer bear to use Emacs, which has these kinds of issues in droves.) As a general rule I'm fine with the shortcuts I use regularly, but the lack of consistency means that it's all too easy to forget the slightly more obscure bindings. For example, it seems like the time it takes me to forget the binding for the Solution Explorer is approximately half a day less than the usual interval between each use of that shortcut...
I'm all in favour of anything that improves consistency. One of the things I like about the .NET Framework is that in a lot of cases I don't have to remember exactly how each API works - I can just guess how it will probably work, and the reasonably high degree of consistency means that these guesses tends to be right most of the time. So I'm a big fan of Brad Abrams' efforts to ensure consistency in .NET class libraries that emerge from Microsoft, and I think it's great that they are giving 3rd party component developers the necessary tools to do the same. For me at least, this consistency is a major productivity boost - I don't have to spend my whole time looking up the documentation to deal with API-specific idioms.
Given the choice, I therefore typically prefer a breaking change that fixes inconsistency to the alternative of preserving backwards compatibility at all costs. (So this is more or less the opposite of what Joel Spolsky infamously described as the Raymond Chen approach.) But I do of course see the importance of not breaking existing code, so I understand that changing platform APIs after they're published would be a bad idea. But changing things other than the platform in order to improve consistency is surely pure goodness. Changing key bindings doesn't break anyone's code, so that should be a no-brainer.
So if new key bindings really are an improvement, bring 'em on!. But like Craig, I would like to know how methodical the thinking behind these new bindings really is - if they're going to change again, it would be good to know that every effort has been made to make them as consistent and learnable as possible.