The Handle-Type Hotkeys Debate

Today there were some changes to the hotkeys for setting the handle types for keyframes and also for standard curve editing back towards the old 2.4x style keymappings. While I admit that the implementation in the Animation Editors was a bit clunky - namely, the menu being a bit unwieldy/ugly - the key benefit of this approach over the old one was that the handle-type hotkeys were now accessible in a logical + consistent grouping.

Therefore, I think this brings up a very natural point at which we should re-evaluate how we're doing this. As I see it, both ways have their pros and cons, though perhaps we need to be looking for another (better) alternative still!


Among the points of contention/consideration are:

1. Frequency of use of these hotkeys - is the handle type really changed that frequently?
2. Direct Mapping or A Single Master
3. Consistency, Efficiency, and Memorability/Learnability/Logicality

The Old 2.4x Ways
Back in 2.4x, all the handle types were mapped so that there was a direct 1-1 hotkey mapping between handle types and hotkeys. Perhaps at one stage back at NeoGeo, having such direct access was paramount for some project being worked on where heavy curve usage was involved. In such a case, having direct mapping would have been beneficial for workflow efficiency.

However, in practice the chosen hotkeys have a number of problems:

• Hard to remember - Personally, I could never remember what they were, even when editing curves for a concentrated period. Indeed, it seems that I am not alone in this regard, otherwise I might still have left this alone... (I sometimes wonder if many of the people complaining about Blender's hotkeys at every opportunity over the years were actually just complaining about this issue only in fact.)
• Not very discoverable - There's a reason why they weren't easy to remember: most of the time you couldn't even find them! This is because they had...
• Very little logic/consistency to them - With most of Blender's hotkeys, we have a kind of consistent logic to them: Ctrl for do/make operation for less commonly used things, Shift for add, Alt for undo/invert/remove, and mnemonics for the actual key name (i.e. G = Grab, R = Rotate, Ctrl-P = Make Parent). However, for these handle-type hotkeys, this consistency is lacking. Some are on HKEY, while some are on VKEY, and all the while, all have different modifier combinations. This leads to a lack of consistent and logical grouping of the handle-types: you cannot think, "change handles" -> use-this-base-hotkey-grouping then branch out. They are just spread out all over, as if they were whatever left-over keys we could muster to put operations on but which still maintained some scrambled mnemonic resemblance.
• Not efficient for many users - I shy away from saying all, as from the sounds of things, there are some people out there who have managed to beat this into their heads. But, if all the above can't happen, the chances of users getting to "expert"-level with this are quite slim.

2.5 Introduces Some New Ways
When doing the complete redesign of the Graph Editor (and animation editors in general), I decided to try and improve the situation by placing all the handle-type editing for the new editors under a single hotkey. A single hotkey to rule them all!

At the time, I chose the logical mnemonic choice: HKEY. From there, a popup menu lists the various handle types.

However, there is one problem with this approach. For the consistency, memorability, and learnability that comes from just having just a single (rather obvious) hotkey for change handle types, we sacrifice a bit of efficiency and had a slightly awkward menu to deal with everytime when changing handle types. This would not really be a huge issue if handle types aren't frequently changed, but can quickly become an issue otherwise.

Now, IIRC at the time, the curve tools had yet to be ported to 2.5 (that was probably still several months away!). Furthermore, I had assumed that animators didn't actually change the handle types on their F-Curves that often at all - at least the Blender animation culture up to that point was just to try and do as much as possible in the viewport, and then just use the DopeSheet/Action Editor to cleanup the timing a bit, probably since the IPO Editor was close to useless or at most a limited + restricted pain to use. So, in the hope of improving things immediately (and possibly influencing changes to the curve workflow too, where such changes might not be received so readily), I chose this menu-based workflow.

At some time in the months that followed, a new developer stepped up and started porting and improving the curve tools in 2.5. Among the changes that followed was the adoption of a single-hotkey workflow too, but using the VKEY instead. Why VKEY I don't know for sure, but maybe for it's handy location on the LHS of the keyboard (standard layout)?

However, in the Animation Editors currently, this hotkey is taken for visibility enabling. It might be possible to swap the hotkeys, but then we'd need to have a semantic swap too, as VKEY in Graph Editor is for isolating stuff to work on, while standard HKEY is for hiding areas that aren't interesting. There's a big difference between these, as using the "hiding" paradigm on the Graph Editor would require a lot more effort to select all the info that isn't as relevant at the moment.

Where we're at now
So overnight, there were a few bugreports about these issues, and mainly about consistency issues between the two systems. Somehow this ended up with the evil old 2.4x style hotkeys coming back again.

A new alternative
Ok, so we've now tried several approaches: the classic 2.4x scattered+illogical direct mapping minefield, and two different "single hotkeys" launching a grand menu of the world. Both have their benefits and their disadvantages as we've seen now.

With regard to the consideration 2, Ton has stated already that he prefers direct operation vs menu first.

Now, if we pursue this avenue, we must strive to have some kind of consistent/logical grouping that people can remember when trying to do this sort of thing.

The first option would be to use mnemonics, and load everything around the HKEY with various modifiers. However, because HKEY also plays roles in hiding and showing geometry/data in many other places and in curve editmode too, this option is less attractive and/or probably infeasible. A variation of this would be to use another base key, but then we loose the mnemonic benefit of trying to do this, so that effectively rules out this option too.

Another option therefore would be to use some set of keys that are adjacent to each other on the keyboard. For example, "TYUI". However, this is probably not so good either, as that rules out some future mnemonic possibilities and also occupies some prime key real-estate for mapping "bigger" tools. Besides, I'm sure that a few of these are probably in use now for some other functions already, and no other set of adjacent keys like this exist.

Fear not though. Gazing around my keyboard for other options, the row of number buttons above the letters came to mind. This could well be a very good set of hotkeys to use for this, which both the 3D View and Animation Editors don't currently have anything mapped to. Therefore, may I suggest:

Ctrl-1, Ctrl-2, Ctrl-3, Ctrl-4, etc. be used for Setting Handle Types

NOTE: when I originally thought of this, I was thinking that the layer keys 1,2,... and Shift-1,2,... were already taken, hence I chose Ctrl-1,2,... As it turns out, this might be a nice match, as Ctrl-0,1,2,... are already used in Object Mode for Subsurf levels, so this mapping is not totally absurd. In a way, setting the handle type changes the "sharpness" of a curve control point, depending on how you look at things ;)


Over to the audience
So, thoughts/opinions on which of these is our best option moving forward. Let the debates begin!