Dan Kaminsky's Blog

Analogous Key Arrays, or AKA´s, are command arrays with keyboard
hotkeys that correspond to the physical location of the onscreen
commands. For example, given a 3×3 array(the standard size for an
AKA) of commands on screen, a 3×3 array on the keyboard should be
chosen. Consider the following illustration, created from the DoxSTAR
modification to the popular game Starcraft by Blizzard Entertainment.

3×3 Command Box from Starcraft with corresponding hotkeys overlaid
for this illustration.

It should be noted quickly that AKA´s do not document the effects of a
given command, nor do they require any graphical modification to
command icons. (The graphical modifications here are for illustration
purposes only.) Position alone specifies a command array as an AKA.
This, of course, means the user is dependant upon some other means of
determining that an AKA is being used–tooltips are the ideal means
here, and were chosen for this function in DoxSTAR.
AKA´s are quite powerful, but have a number of caveats to their
usage. They have, I think, popped up in small numbers throughout the
history of GUI´s. This document is an attempt to codify their
properties. I shall attempt to explain their advantages and
disadvantages with candor; this page shall be updated if additional
observations come with time. Peer review is a good thing.

Much of the science that supports Pie Menus(see also this Mactech
article) applies to Analogous Key Arrays. Pie Menus, unlike linear
menus, place commands in a circle around a central point, thus making
all commands equidistant from eachother. There´s some decent research
showing this is a significantly quicker method of making commands
accessible. The link applies in that since most multidimensional
command arrays form pie-menu like structures anyway, a positional
keyboard equivalent of those structures should gain the positive
effects noted in much of the research for Pie Menus.

In fact, AKA´s should hold a substantial speed advantage over Pie
Menus due to the intrinsically faster nature of key entry versus
coordinate based mouse clicks. Provided a modicum of famliarity with
the keyboard´s layout, it is faster to move one´s fingers to the
appropriate key and press it than to move the mouse to a specific
onscreen location and click. This does not, however, mean it is
faster to execute a command via keyboard than via mouse–that´s just
not true. Mouse access is much easier in general, because “Open File”
is significantly more descriptive than “Ctrl+O”. In other words,
mouse-driven actions use the screen to self-document themselves,
whereas keyboard driven actions usually require shortcuts to be
memorized.

AKA´s are therefore designed to address this state of affairs. The
first thing they do is maximize the intrinisic advantage of the
keyboard. With all keys in the AKA being in close proximity, travel
time to execute a given command is significantly reduced–Fitts´ Law
at work(side note: This link extends interestingly on Fitts´ Law, as
well as explains it). The tight proximity also aids non-touch
typists–AKA´s take the form of either positionally relative
arrays(key is two left from other command) or, especially in the 3×3
case, positionally cardinal arrays(key is in the upper right hand
corner). Even the touch typer benefits from the tight array, since
the hand position doesn´t have to shift to contact the heavily used
keys in the AKA. The intrinsic speediness of the keyboard is extended
to its maximum capacity.

The second action of the Analogous Key Array is to make keyboard
hotkeys easily memorable. Loose Prime Character hotkey naming(the
system in which the hotkey usually corresponds to the first letter of
the command) makes the assumption that all commands need to be
accessable at all times, and thus each command needs a separate
hotkey. In many situations(not all!!!) this is not the case. Often,
an application is in a specific mode with a limited number of
commands. Consider the case of Starcraft. All commands for all units
reduce to 3×3 arrays–and these arrays show their available options at
any time the user might wish to execute commands. Only the slightest
glance at the onscreen array is necessary to deduce the appropriate
hotkey for any given command. This is a significant improvement over
either guesswork or tooltip-checking that the LPC method enforces.
Additionally, there is no extra labor required to memorize commands
for a new unit–once any unit is learned, every unit is learned. In
DoxSTAR-modified Starcraft, the mouse is allowed to roam freely around
the battlefield doing what it does best–pixel level selection–while
the keyboard is designated to trigger commands.

In conclusion, the Analogous Key Array applies instinctual properties
such as relative position and cardinal direction to keyboard hotkey
assignment by relating onscreen location with keyboard location.
Fitts´ Law and ergonomic efficiencies mean this system is
significantly faster that competing assignment methodologies, and the
consistent and efficient method of observing screen position to derive
command hotkey significantly reduces short term memory load.

This is an attempt at a semi-scientific paper, and while the concept
of creating a new(?) command methodology is appealing to my ego, the
eventual destruction by the peer-reviewing public would rip said ego
to micron-thin shreds. Therefore, the following are caveats and
observations regarding the usage of Analogous Key Arrays.

1. AKA´s are biased towards 3×3 arrays with 8 or 9 options.

   3×3 arrays are superior, because they tie directly in with the
   cardinal directions(up, down, down-right) we understand
   instinctually. With the center point optional, this means eight
   or nine options are available. This leads to a bit of weirdness
   for the user if only a few of these boxes are filled. This
   shouldn´t be too much of a problem though– DoxSTAR-enabled
   Starcraft has plenty of incomplete arrays.
   With regards to what alternate array dimensions can be used, here
   are a few observations:

2. It is better to be wider than to be taller.

   Consider a building–it´s easier to access additional rooms on the
   same floor than to take the stairs to additional floors. This
   applies to keys–it´s easier to hit keys that are on the same row
   rather than to constantly change rows. Just look at your
   hands–how many rows of fingers do you have?

3. Work your way left to right, then down.

   The farther down a key is, the more likely a user is to curl his
   or her finger. Finger curling is more work than finger shifting.
   It is arguable that when localizing your product for areas in
   which the language is read in a different order then
   Left-Right-Down, you should change the order. This is because of
   the visual system´s seek patterns.

4. Avoid AKA´s with a width of 4.

   Single width AKA´s are suboptimal but may be necessary for real
   estate purposes. Double width AKA´s fall into the left/right
   classification. Triple width AKA´s form left/middle/right.
   Quintuple width AKA´s form Likert style Strongly
   Left/Left/Middle/Right/Strongly Right scales. But Quadruple width
   AKAs lack a true middle, making them harder to visually convert
   from on-screen image to a keyboard equivalent.

5. If exceeding a width of five, you may need to mark your icons, or
   split the AKA.

   Supposing your interface consists of a 10×1 AKA that pulls down
   from each number(1 -> 0) a 3×3 QWE Analogous Key Array. The 3×3
   can remain unmarked(leave it to the tooltips to document their
   behavior), but it´s going to be quite difficult for a user to
   immediately pick which of, say, ten entries a random one near the
   middle is. Splitting the 10×1 into two 5×1´s is an alternative,
   for instance.

6. Page, don´t scroll.

   Scrolls went out of fashion a few thousand years ago for a reason.
   AKA´s that scroll lose consistency–at one moment, Up(Q) might be
   a given command, at the next, Middle(S) could be. Scrolling does
   prevent Page Orphans(A situation that occurs when just one or two
   objects overflows onto the next page), but this is far superior to
   the alternate scenario.

7. 
   AKA´s encourage modality in interface design

   Since multiple usage contexts share the same hotkeys, these contexts
   must be caused not to collide somehow. It is difficult to predict
   what commands users may wish to execute in the same context, and
   requiring constant context switches gets tiring. A couple notes on
   this:

8. Most multicontext apps require modality anyway

   Even a swiss army knife requires the desired tool to be pulled
   out.
   Many of the situations in which the AKA will be used will already
   have established modality anyway. More research is definitely
   required to learn just how to switch context appropriately.

9. AKA´s improve the quality of modal interfaces

   In Starcraft, build units have a command that opens up another
   command array of units to build. As soon as the build units
   command is triggered, a new, automatically hotkey-documented
   command array replaces it. No new learning is necessary.

10. AKA´s use up much more screen real estate than LPC´s

    One advantage of the Loose Prime Character system is that the user
    only needs to remember the name of the command being attempted. In
    order for the user to remember the position, the user must actually be
    able to see the position. This means that AKA´s don´t fit well with
    linear menus(File, Edit, etc.), and also require onscreen real estate
    to establish the relative/directional positions. A few observations:

11. The Rule of Sides severely affects AKA´s.

    Kaminsky´s Rule of Side Pollution basically says that anything
    placed along a side automatically pollutes the rest of that side
    for objects larger in the dimension being polluted. (I shall
    withdraw this rule if somebody else has already stated it in
    similar language.) Objects at a corner pollute one of the two
    sides they contact.. It may be unclear what this means. Suppose
    in a 1024×768 screen, a 100×100 clock exists in the lower right
    hand corner. Now suppose we have our “main window”, a web
    browser, that we´re trying to make as large as possible. We have
    three options:

    1. Make the Netscape window 1024×668
    2. Make the Netscape window 924×768
    3. Make the Netscape window 1024×768, but accept that the lower
       100×100 corner of the window will remain occluded.
       This is what I refer to as Side Pollution, and is a significant
       problem in many GUI´s. The reason this bites AKA´s so severely is
       that, because AKA´s operate by associating position, not name,
       there is an additional demand for screen space since position of a
       command must be established. It´s still worth it, since most
       keyboard shortcuts will never, ever be used, but it´s still not
       that simple. For one thing, the 3×3 array that AKA´s work best
       with pollutes more space than a pulldown menu or a 10×1 taskbar.
       More research is needed, but most applications should find that
       two 5×1 taskbars split across the main number area provides the
       best use of screen real estate. The reason the 10×1 or the two
       5×1 taskbars work whereas various 3×3 arrays don´t is because a
       corrolary of the Rule of Sides shows that Side Pollution isn´t
       cumulative; two 100 pixel polluters side-by-side along the bottom
       of the screen will still only pollute 100 pixels on the bottom.
       This is of course the justification behind the Win95 Taskbar–as
       long as all of the small boxes are organized along the bottom,
       their collective value outweighs the amount of space they take up.
       Of course, games have much more leeway since they have much more
       real estate to play around with.

12. AKA´s can open up other, non identical AKA´si

    This has been alluded to in earlier sections, but just to make it
    explicit–just as clicking on a certain item can create a
    “pulldown/popup” window, so can pressing the associated key bring
    up a pulldown/popup AKA, replete with totally different keyboard
    shortcuts. Just make sure your documentation method(tooltips in
    DoxSTAR) explains what´s going on.

Keyspace is a serious issue, especially for applications
Back when I was part of the GNOME project, I made a call for a
definition of the GNOME keyspace. The keyspace is, essentially, the
breakdown of which keys do what functions in which contexts. As the
mouse has to deal with screen real estate, the keyboard has to cope
with a limited keyspace. Issues arise quite easily–while Starcraft
can be modified quite easily to have C trigger Cancel, users of a word
processing application are going to be quite peeved to find that C no
longer types the letter. In the application keyspace, normal keys
just type out their counterparts on screen–it´s when Control and
Control-Alt is added that keystrokes become commands, at least in the
application keyspace. Worse, there are certain keystrokes in the app
keyspace that seriously conflict with the QWE AKA–Control-C in
Windows must always equal Copy. Windows has also appropriated the
entire Alt keyspace to menu shortcuts–arguable for reducing
confusion, but painful when a new class of hotkeys shows up. A couple
observations on how to deal with this:

1. Applications should use the Control-# and the Control #Pad
   Keyspace
   There are some issues with this–namely, if additional contexts
   are called via the two 5×1 arrays that Control 1-5 and Control 6-0
   provide, it´s going to be harder for the user to trigger the #789
   set than to trigger the QWE set. Also, using the #Pad keyspace
   could lead to some interesting non-uniform(but self-documenting!)
   shortcut sets. It´s much easier, by the way, for most
   applications to justify using the number pad since users are more
   used to shifting between the mouse and the keyboard while typing.
   While it is true that the whole idea of using keyboard shortcuts
   is to avoid having to move one´s hand to the mouse, it should be
   noted that the amount of mental processing, let alone time
   necessary to execute a command via a mouse far outweighs the
   amount of time necessary to hit a “far away” key and return. Apps
   where speed is critical or in which this many keyboard commands
   could not exist can rely on the Control-# keyspace anyway.

2. Mouse-Intensive Programs should never use the #Pad as their
   primary AKA. Rather, they should use the QWE Analogous Key Array.
   Most applications will not fall into this category. Games are a
   different story–pretty much any game where a mouse is used
   moderately heavily should not be programmed with a #pad AKA.
   Here´s why–if the program is designed to have the user leave his
   right hand on the mouse, his left hand is the one at the controls
   of the AKA. The #Pad, however, is at the right side of the
   keyboard. To use this setup, either the user moves his or her
   keyboard a foot to the left, allowing both hands to be placed in
   the center right in front of the monitor, or the user shifts his
   left hand all the way to to the right side of the keyboard, which
   isn´t exactly the most ergonomic position. It is much better to
   have the right hand stay on the right side and the left hand stay
   on the left–plus, Control, Alt, and at least half of the 1-0
   number row are within easy reach of the left hand in the QWE
   layout.

3. The Operating/Windowing System should use Control-Alt for
   launching other software
   Windows allows shortcuts to have arbitrary keyboard hotkeys.
   (Windows is most probably the most keyboard enabled GUI in
   existence–this coming from an ardent Linux fan) Unfortunately
   they don´t always work perfectly or universally. This is a
   shame–for applications that are constantly run, keyboard
   shortcuts are a wonderful way to boot. Perhaps the items in the
   Windows Quick Launch bar should automatically be bound to
   Control-Alt-#? The only issue with the Control-Alt keyspace is
   that Photoshop uses it to reasonably good effect, but then only
   with mouse commands.

4. Customization can be good.
   For applications or games with large or expanding command options,
   an AKA that can be easily customized by the user should be quite
   useful to users who are otherwise overburdened.

Multiple AKA´s pose issues
If there is only one AKA, and it´s on the right of the screen but the
left of the keyboard, it´s somewhat bothersome but not that big of a
deal. If there are two AKA´s in simultaneous use, and they´re
sideswapped in the same manner, the hotkeys are unusable–the user
will repetitively choose the wrong hotkey. Due to the increased
horizontal range of the keyboard, horizontal conflicts are more
common, but the point holds in the vertical dimension as well–if
hotkeys are misaligned vertically, the user may have difficulties.
However, it´s probably not too troublesome if one AKA is at the top
left of the screen and the other is at the lower right, yet both are
on the same horizontal plane.

Watch out for custom keyboards!
AKA´s operate on position–what if the user´s key position isn´t the
same as the developer´s? Uh oh is right. A good portion of the
population has Microsoft Natural Keyboards or a knockoff thereof.
Using a custom AKA that spans the split in the middle of these boards
is not only foolhardy(since even normal boards lack a hard, vertical
line for the hand to align itself against) but also completely
unusable for these users. Furthermore, if you expect any large number
of users to use your layout, ship with a Dvorak configuration–there
aren´t many Dvorak users out there, but they´re not worth
ignoring–they´re arguably using a better system, and they´re quite
capable of arguing it publically 🙂 Finally, if at all possible(and
this holds true even if you aren´t writing a program that uses AKAs),
let your keyboard configuration be configurable. Please.

Don´t ignore left handed people.
Left handers have been obscenely ignored by joystick manufacturers for
the past few years–it´s probably not a nice thing to embed this
subtle dis in your code. Most left handers will work fine with the
right-handed layout, but a number of them won´t, so you may want to
ship either with a method to reconfigure the AKA hotkeys or just with
a swapper to move QWE to #789.

Miscellaneous Notes

I think I basically covered most of the issues you will have to
address when choosing if and how to implement Analogous Key Arrays.
If you feel there is anything I missed, please email me.