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 3x3 array(the standard size for an AKA) of commands on screen, a 3x3 array on the keyboard should be chosen. Consider the following illustration, created from the DoxSTAR modification to the popular game Starcraft by Blizzard Entertainment.

3x3 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 3x3 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 3x3 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 3x3 arrays with 8 or 9 options.

   3x3 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 10x1 AKA that pulls down from each number(1 -> 0) a 3x3 QWE Analogous Key Array. The 3x3 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 10x1 into two 5x1´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 1024x768 screen, a 100x100 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 1024x668
    2. Make the Netscape window 924x768
    3. Make the Netscape window 1024x768, but accept that the lower 100x100 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 3x3 array that AKA´s work best with pollutes more space than a pulldown menu or a 10x1 taskbar. More research is needed, but most applications should find that two 5x1 taskbars split across the main number area provides the best use of screen real estate. The reason the 10x1 or the two 5x1 taskbars work whereas various 3x3 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 5x1 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.