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

[Nathan Vegdahl]

(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