I'm an unrepentant
vim user, eschewing other text editors which might have less terrible internal scripting languages. I love
vimperator for Firefox, and I'm about to give
Chrome a whirl and the first thing I'm going to do is install
Vrome for it. I prefer
ADoM (at least in UI terms). I passionately hate almost every "webapp" ever written.
I do almost all my work in the console. It's not actually that I prefer doing everything in a cell matrix containing characters in a monospaced font; in fact, for a lot of things, especially reading, I'm increasingly finding that proportional fonts really are advantageous. [Please don't ask me about antialiasing; I still haven't done a good enough side-by-side comparison to determine whether it results in "smooth" or "blurry".] It's just that console applications as a general rule are much more likely to have an input UI which allows a little more expressiveness than pointing with your finger and grunting. (To be fair, some GUIs do allow you to grunt, whine, or whistle while pointing.)
The goal of the input portion of a tool's UI is to effectively transmit information (what you want to do) from your mind to the tool. I think there are a few basic principles that should be kept in mind when designing or evaluating a UI.
The user's intention must be transmitted to the tool as accurately as possible. The only thing that's more infuriating than a tool going off and doing something other than what you intended is when what it goes off and does is deleting your data [or killing your character].
This is why I find "TrackPads" and touchscreens extremely frustrating to use, by the way. I don't know if it's something about my body shape/chemistry, but they tend to register my touches and movements with extremely poor accuracy, often resulting in erroneous commands. While conceptually a touch screen is in many ways far superior to a mouse/trackball/etc., for some reason the accuracy just doesn't seem to be there.
The programs I love which tend to assign unique commands to each key on the keyboard (of which more later) do sometimes suffer in this respect. If you're not a good typist, you may err. If you misremember the mnemonics for commands, you may issue the wrong command (and there's often no way to check, which is a real design flaw). And gods-forbid you should accidentally paste that text you quoted for discussion into your
nethack game; death by mispaste is very real.
Vim's robust undo buffer really helps here.
irssi's paste detection and confirmation is really helpful for avoiding embarrassment, and I think I recall the
crawl folks discussing implementing something similar for that project.
Note that the point-and-click interface is far from exempt from this problem. Misclicks happen all the time, either due to poor pointer control [see again my complaint about TrackPads] or due to interface elements having confusing or misleading boundaries.
A UI should get out of the way as much as possible, allowing the user to transmit a maximal amount of information with a minimum of effort. This should allow the user to get their work done and move on as quickly as possible. It should also minimize the physical exertion required to accomplish tasks, especially tasks which are performed frequently. This is especially important for sufferers of RSI, and to avoid creating new RSI sufferers. Finally, it should minimize the cognitive load necessary to perform tasks.
That last is where most people get lost on keyboard-based interfaces. Their cognitive load to remember which key does what is certainly higher when first learning the program, and most do a piss-poor job of ameliorating that (or even acknowledging it . . . again, really, a basic keyboard help system needs to be accessible with minimal effort in an immediately apparent manner at the very least, e.g. a reminder to press <?> for help at the bottom of the screen which you can turn off when you no longer need it). And even after you've learned it, the mnemonics you don't use all the time can be kind of tricky (do you 'z'ap a spell, 'c'ast a spell, or 'm'anipulate a ritual; do I want to move forward a 'w'ord or to the 'e'nd of the current/next word?). It's a pretty big price to pay for the benefits in other parts of efficiency and other areas; I argue it's worth it, but it's real, and it also inhibits learning the tool.
This is also where I need to insert my quick
emacs rant, because the thing that drives me away from emacs is its terrible stock keybindings. The more often you do a task, the more essential that it be able to be performed with minimal physical effort.
Emacs commands typically require chording (pressing multiple keys at the same time to enter).
vim, in contrast, puts its most common commands on regular keys, ideally in the home row. Moving to the arrow keys is effort. Moving to the mouse is worse. Having to hold one key while pressing another is real physical effort, especially if those keys are on the same hand. (Not that
vim couldn't be improved here: modality means an awful lot of reaching up for that Esc key, and plenty of chording for Shift-: as well, but
vim at least attempts to limit these effects. [Now that I think about it, I wonder how hard it would be to patch
vim to use ; instead of : for command entry...])
The combination of Efficiency and Expressiveness is where I end up selecting most of the tools I prefer. Not only should your tool make it easy to do the simple things that you do all the time, but it should make it easy to do the complex things you do frequently as well.
For instance, what do you have to do to jump to the next occurrence of a word? In
vim, put the cursor anywhere in that word and press
# to search backward. Keep pressing that key to keep skipping to occurrences, or use the non-chording
n to go to the 'n'ext occurrence, or
N to go to the 'N'ext [backward]. (This Shift-something to do that something backward is fairly productive in the UI, applying to a lot of commands for jumping around in text.) If you've never jumped to the matching parenthesis (or bracket, brace, or angle bracket) just by pressing
%, let me tell you, it's amazing.
If users will spend a lot of time in your tool, it should include some kind of macro system as well, so the users can determine tasks they frequently perform and come up with a way to do them with less effort. How complex this needs to be really depends on how powerful the tool is, but I'll note that
crawl will let you macro an oft-repeated key sequence and bind it to a key. Better,
irssi lets you define new commands that can be entered by name, and also lets you bind them to keys. You don't have to be a programmer to say "hey, I use this exact key sequence about once an hour, let me have the computer remember it and let me access it with a short mnemonic".
If your tool does use a lot of keyboard input for more than typing in text, it's essential that the keybindings be user configurable, as well as having a decent set of defaults.
A user might use a nonstandard keyboard, QWERTZ because they're in Europe, Dvorak or Colemak because they're better, a BAT or Frogpad because they have a reason to prefer one-handed typing. If your keymapping relies on key locations (
vim's hjkl movement or most roguelike games'
hjklyubn movement, for an excellent example), your user will want to be able to move things around to support their keyboard layout. Or the user may want to move keys to mnemonics in their native language. Or they might have a split keyboard and what the hell were you thinking putting exactly one of the movement keys on the wrong hand? (Seriously, even without a split keyboard, right-handed b is not the way we teach typing. One of the many reasons I like
crawl is that I was able to edit the configuration file to use
hjklyunm for movement and put the commands that used to be on m over on b.)
As a designer of a tool, it's your job to think about how people will want to interact with that tool and make it as easy as possible for them to do so and get the most out of it. It's not good enough to do what's easiest for you to design, and it's not good enough to stop at only the features that will be easy to learn. For input, the tool should be able to capture relatively complex ideas in a simple way, and grow with the user. Users shouldn't have to ask, "I need to do this simple task about 20 times a day, why does it take 5 minutes to do each time?" At the worst, the answer should be because the user wasn't aware of the simpler way; it should never be because of an unnecessary limitation of the UI. Designers of database-interactive software, I'm looking at you, here.
Originally posted at http://marcmagus.dreamwidth.org/137280.html. ( comment[s]|comment there)