[Bf-committers] Improving Blender's keymap: a proposal

[Nathan Vegdahl]

Everyone:
In order to avoid cluttering the development mailing list, I'm moving
to the functionality board mailing list for further discussion.  There
we can break this up into other topics, with different threads for
each.  Please follow me there if you would like to continue
participating! :-)

You can join the functionality board list here:
http://lists.blender.org/mailman/listinfo/bf-funboard

--Nathan


On Thu, Apr 5, 2012 at 8:30 PM, Nathan Vegdahl <cessen at cessen.com> wrote:
> (When I say "keymap" in this email, I mean to include the mouse as
> well.  Basically, key/mouse-map.)
>
> A great deal of things about Blender were improved with the 2.5
> project, but the keymap is still more-or-less the same as it was in
> the 2.4x days.  This keymap has built up over the years, with new
> functionality being crammed into the ever dwindling unused hotkey
> combinations in a somewhat haphazard way.  The result is a keymap
> that, while capable, isn't nearly as efficient as it could be.
>
> I propose to start developing a new keymap for Blender.  The goal will
> be to update the keymap to optimize for current typical usage, and to
> develop some guidelines and principles that will help the keymap grow
> in a reasonable way in the future.  It's impossible to make anything
> _completely_ future proof, but let's aim for a keymap that will
> hopefully be sufficient for the next, say, 7-10 years (if we're not
> all using dynamic multi-touch computers by then!).
>
> I think we should also keep in mind future UI developments.  For
> example, it sounds like there is still an interest in adding pie menus
> to Blender.  So to whatever extent we can design the key map to be
> ready to take advantage of pie menus when we get them, but without
> compromising usability right now, we should probably do so.
>
> Here are some (proposed) principles for designing the keymap (the
> order has nothing to do with importance):
>
> == Principle 0 ==
> No principle is sacred.  Including this one.  Every rule has a time
> and place to be broken, and we shouldn't be dogmatic about things.  We
> should instead be practical and have real user experience guide
> things.
>
> == Principle 1 ==
> One thing that Blender's keymap already does well is consistency
> across different areas and modes of Blender.  The quintessential
> example of this is the G, R, and S hot keys for grabbing, rotating,
> and scaling selections.  No matter what part of Blender you are using,
> if those concepts apply at all, then those hot keys are what you use
> to do them.
>
> That kind of consistency helps users switch between different areas
> and modes of Blender without having to think about it.  I think this
> is very important, and we should seek to preserve and even expand upon
> this.
>
> == Principle 2 ==
> Most-used functionality should have prime real-estate on the keyboard.
>  The more often a tool is used, the less acceptable it is for its
> hotkey to involve five modifier keys, three repeat key presses, and a
> complex mouse gesture.  Ideally the most-used functionality of Blender
> should be a single key-press away.
>
> == Principle 3 ==
> Hand-strain is bad.  Hotkey combinations that are uncomfortable for
> the human hand should be avoided.
>
> == Principle 4 ==
> Confusion is bad.  Hotkey/mouse/whatever combinations that frequently
> cause confusion should be avoided.
>
> A good example of this are the current hot keys for object mode
> switching.  I've been using Blender for years, and I've been doing
> serious rigging ever since BBB, and I _still_ get confused switching
> between object/edit/pose mode with armatures ("I'm in pose mode right
> now... if I hit tab, will that take me into edit mode, or exit into
> object mode...?  Okay, it put me in edit mode.  What if I hit tab now?
>  Will it take me back to pose mode, or exit into object mode...?
> Gah!").
>
> == Principle 5 ==
> Consistency with other software.  Tautology: unless there are good
> reasons to not adhere to an existing ubiquitous UI standard, then
> there is no good reason to not adhere to an existing ubiquitous UI
> standard.
>
> We can deal with this on a case-by-case basis.  There are plenty of
> cases where there are good reasons to be different.  But in some cases
> there aren't.  In the latter cases, we should pull from existing
> standards to avoid unneccesary mental "mode switching" when users
> switch between Blender and other software (including, e.g., their
> operating system).
>
> This also applies to not changing things in the keymap just for the
> sake of changing them.  We should try to be consistent with Blender's
> old keymap where reasonable as well.
>
> == Principle 6 ==
> Muscle memory.  The more the keymap can take advantage of people's
> muscle memory to speed up workflow, the better.
>
> == Principle 7 ==
> For common OS's (Windows, OSX, popular linux desktop environments) we
> should seek to avoid hotkey conflicts.  For example, we should
> probably avoid using ctrl-alt-delete as a hotkey, due to Windows.  And
> OSX makes heavy use of the function keys for OS functions.
>
> Related to this is differences in keyboard layouts.  Many laptops do
> not have numeric keypads, and yet people are more and more frequently
> using laptops for serious graphics work.  There are also differences
> in keyboard layouts between countries.
>
> Also: number of mouse buttons?  People using tablets? Etc.
>
> How to deal with all of this is not obvious to me.  We probably don't
> want to end up with the least-common-denominator, either, because that
> would be very limiting.  In any case, it's something we should keep in
> mind as we proceed.
>
> ====
>
> Lastly: process.  A keymap can be great in theory, but suck in
> practice.  So I would like to err on the side of "try things out"
> rather than "discussion".  Discussion is still important, of course!
> Especially for figuring out guidelines for the future.  But the
> discussion should, as much as possible, be based around seeing what
> works and what doesn't.  Let's treat keymaps as cheap, and not be shy
> about trying things out and throwing them away.
>
> In that same spirit, I propose that the new keymap should be developed
> over several Blender releases, being included in releases as a
> "alpha/beta" keymap, as an option (not default).  This will allow
> users to test it out and put it through its paces and provide feedback
> as well.  I'm not an expert in all areas of Blender, and it's
> important for people who are experts in various areas to have an easy
> chance to provide feedback.  Hopefully this way we can iron out and
> change the things that don't work well in practice, even if they
> sounded good in theory.
>
> In short, I'm volunteering to take the lead on this.  I'm working on
> some key map improvements already, but I wanted to establish some
> big-picture stuff before moving forward too quickly.
>
> --Nathan