Friday, December 10, 2010

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!

6 comments:

  1. For the record, I didn't mind the unified handle-menu approach.
    But, at this point, I like the Shift+number approach. Odds are, the user probably has multiple keys selected, and Shift is already pressed. Now its just a matter of adding in a number.

    ReplyDelete
  2. Sent this to bf-committers, but it's held for moderation because I have a new email address...

    Here's my hybrid approach. Pick a single naked hotkey that brings up the menu. Say it's the h-key, just for the sake of argument. H-key always brings up the menu. Ctrl-LMB on a menu item puts a little icon beside. Alt-LMB on another menu item puts a different designator beside it. Now, Ctrl-H calls that first item directly. Alt-H calls the other. This way, you can always use the menu if you want, but as you usually use tools in clusters (i.e. the same couple of tools over and over again) you can access them directly as needed. You don't have to have a separate hotkey for each menu item, and you always know that all of your handle direct shortkeys will be modifications of the H-key.

    harkyman

    ReplyDelete
  3. my problem is V or H, never remember wich one, but I like the menu... ctrl+numbers is a good one too, easy to learn!

    some -curve related- stuff:

    * ctrl 1 2 3 could be expanded.. see this from other software: http://yfrog.com/dytkeyj
    * request: couldn't knife work in curves too, subdividing is not an easy way to add points
    * and try this trick: a curve in edit mode, unselect all points and ctrl double click on it to kill blender and all your work ;)

    ReplyDelete
  4. previous setup was compounded by the fact that some keys worked like toggles but some set the type directly.. always was bizarre.

    I find the adobe method of editing curves (ps, illustrator) much better than those hotkey commands anyway, they're a bit heavy handed and curve editing in blender has always been quite slow. PS method of holding alt while dragging a handle to split the tangents etc is way easier.

    ReplyDelete
  5. ctrl+number is terrible i think. dont want to go down that road. I like the way blender is with direct keys not stupid menus and wizards everywhere.. convenience should be prioritized even over mnemonic keys, as its easy enough to find out what keys do what anyways if you dont know and it should be easy to use blender for production, not easy to remember some hotkey but sacrifice blenders unique speedy functionality in the process.. thats a terrrible thing to do
    SO i would say that perhaps z and Z for alligned/auto toggle and x and X for free/vector toggle or else use qw instead. i think two keys next to each other is easier to remember than mnemonic keys anyway, and that also groups them by functionality kind of as well. when you use a keyboard do you really think about a letter to remember where a key is or a position?
    and do you categorize something by an attribute irrelevant to its functionality or by its functionality itself?
    if theres really any need to change it then i vote for simplicity/accesibility not slight added convenience for noobs..
    my 2 cents :D

    ReplyDelete
  6. Aligorith, would it be not much better, when the Handlepoints get an other color than the curvepoint:
    http://blenderartists.org/forum/showthread.php?t=194411&page=5

    ReplyDelete