The mouse, when chosen as the primary user interface (for something other than a fundamentally-spatial task, like CAD) is a soul-destroyer.
This is because operating a mouse-based user interface is a conscious process - one which cannot be fully relegated to "muscle memory." Unlike the keyboard, the mouse scarcely rewards learning at all.
Erik Naggum, in a Usenet post (circa 1997) explains this far better than I could:
"The clumsiness of people who have to engage their brain at every step is unbearably painful to watch, at least to me, and that's what the novice-friendly software makes people do, because there's no elegance in them, it's just a mass of features to be learned by rote... it's sadly obvious that we are moving into a way of working that is predominantly _conscious_, for which I believe the human brain was never prepared. we no longer have the time to let skills sink into the autonomous nervous system, as it were, and even if we try, the criminal in Redmond, WA, has a new, incompatible version out by the time we learned the last version... One of the joys of learning to ride a bicycle is to stop thinking about it -- the feeling that I had successfully programmed my body to master a bicycle at least thrilled me as a kid (except I didn't know the verb "to program")... we need to communicate to users that learning to use Emacs is like learning to ride a bicycle -- it does take some time and effort, it's a worth-while skill to have, and then you never forget. I firmly believe that the novice-friendly software is like giving people several sets of supporting wheels so they won't tilt, but could get moving right away, and then never taking them off, preferring that they keep using them and moving so slowly that they always need them. of course, if you argue that they should remove the supporting wheels to such users, they will, admittedly correctly, argue that they will fall _splat_ on the ground and ruin their three-piece suits. clearly a no-go."
I've found validation in this point of view in an unexpected source, World of Warcraft (WoW).
WoW has the ability to redefine the user interface through keyboard short-cuts, LUA code, and UX changes. There is an active community providing different takes on the UX.
WoW has a built in 'time test' which consists of 'boss' encounters in what the game calls a 'raid'. [1]
In polling characters who were better able to perform during an encounter, there was a strong correlation between "keyboard" users and better performace. Better was defined as able to respond faster and more consistently to changing conditions.
It would be interesting to have Tog have a look.
[1] For anyone not familiar with WoW and its gameplay, a group of 10 or 25 people, of different specialties (game specific; damage doers, healers, and damage takers (tanks)) who coordinate during an encounter with a powerful game character (a boss) by fighting it. Healers are focussed on applying various skills to keep the players alive (they take damage due to various game mechanics), damage doers (dps) use different skills to maximize their damage, and tanks use their skills to keep the game characters focussed on attacking them rather than the other players. After a set amount of time, the game character 'enrages' which basically makes it impossible to kill and it does 10x the amount of damage it normally does. This results in a 'wipe' (all player characters in the group dying).
If you suggested to a Starcraft 2 pro that they should stop using the keyboard shortcuts because they are slower, you would be laughed out of the building. Erik Naggum was on the ball with that one - it is impossible to acquire muscle memory for mouse movements because there is no base position from which all movement actions are performed.
I'm replying to the specific points about Starcraft 2 here, but really this is off topic considering that nobody is actually saying Professional Gamers in the year 2011 should be compared to word processor "power users" in the year 1989.
Professional Starcraft 2 players need to use hotkeys because they have to be able to do multiple tasks at once - they're macroing with their left hand while clicking around the mini-map and performing other tasks with their mouse hand. You couldn't play SC2 (well) with just the keyboard or just the mouse.
As for the muscle memory for mouse movements, there's no question that Pro SC2 players have exactly that. If you watch a pro give his opening workers commands, it looks like what he's doing should be impossible. You or I couldn't sit down at a computer and do it. But they can precisely because of muscle memory: they know how far a mineral node is from the starting base and exactly what mouse movements are needed to select a worker and send him to a specific mineral patch, then select the next and so on. It's true that in Starcraft 1 this muscle memory was even more necessary as SC2 has automated (to a high degree) many tasks that once required precisely practiced mouse movements, but you still see SC2 players using those skills that they learned from Brood War.
In most non-casual games it's all about maximizing how many commands you can issue. WoW (and SC2) have interfaces for which a large part of the interaction is only efficient at all with the mouse. If you then depend on the mouse for other things, you've created a bottleneck.
All good WoW players bind all their skills to keys rather than clicking them because if they didn't do that they couldn't use that skill while running, or while selecting a new target. It's not about the cost (or lack thereof) of mode-switching between keyboard/mouse, or the cost (or lack thereof) of consciously manipulating the UI -- it's purely about being able to walk and chew gum at the same time.
Keybinds are important in WoW but no less so then the mouse. The primary benefit of keybinding is to keep your mouse for faster turning and target changing (turning with the keyboard is slow). High end healing is based around click casting mods. The mouse is so vital to WoW that MMO mice have progressively added more and more buttons because it's essential to have your hand on the mouse when in combat.
The mouse is so vital to WoW that MMO mice have progressively added more and more buttons because it's essential to have your hand on the mouse when in combat.
That's not the 'mouse being vital', that's 'missing out on keystrokes' and putting a keyboard on the mouse.
Actually it is the 'mouse being vital'. It's so vital that you don't "use it sometimes" and float back and forth ala classic mac interface the article discusses. Your hand is always on the mouse during combat.
Semantic games are fun but unless you're actually contesting that the mouse is vital you're just tilting at straw men.
Actually, it's "mouse being required". As in there are functions that Blizzard will not allow you to keybind like turning your camera or character. In games where this restriction is not in play, players have keys to face an enemy or do a 180.
Good point. It suggests that a keyboard that was a mouse might capture both qualities. I can't imagine how you might accomplish that (attach your keyboard to your wrists somehow?) but it sounds like an interesting (if cutting edge) experiment.
For the record I own one of the weird things Microsoft built the 'Strategic Commander' [1] which, if one could have two of them, and the protocol was documented, my make for an interesting test platform.
The Strategic Commander looks like an awesome beast. And I like your idea of keyboards that were mice. If there were some way to move beyond the obvious ergonomic issues, that is. It would definitely be for the power user. Or power gamer. I mean, these guys already learn some pretty insane (to me) mice[1][2] to get an edge.
I spend most of my computing hours using the keyboard 99% of the time. I can completely agree keyboard interfaces are very rewarding.
However, I believe there is "muscle memory" that can be learned using the mouse. For example, playing a lot of first person shooter games in my day, one can learn and memorize the nuances of moving the mouse. Correlating the amount and direction of movement of the mouse with the response of the screen is, I believe, a skill that can be learned and is quite rewarding.
The way you move the mouse has less to do with how you interact with the interface - yes, you may be able to optimize mouse moves, but that's not enough.
What happens is that a mouse-friendly interface is organized in such a way that finding the right action to click on involves traversing a tree of choices. Even if you memorize the exact location of the action you want in that tree, for many actions you still need several clicks to perform something instead of just one.
And that's not the end of it - you clearly need keyboard input too, in many cases. For example in WYSIWYG editors, you type-type-type, then you need a new header, move your hand on the mouse, select the right header in the select-box (during which your eyes also move from the current line), then get back your hand in typing position and start typing again, until you need another mouse action.
This is the reason I wrote my last resume in HTML and didn't even bother opening office, even though HTML sucks for typography (I'll probably switch to Latex next time).
That said, the mouse is better for browsing around, exploring stuff or for interfaces such as Photoshop. I also don't mind the mouse for interfaces where I don't need to be productive. Someone mentioned CAD in this thread - I disagree as AutoCAD is more productive with keyboard input.
In an FPS, it's the relative motion of the mouse the matters. That's what the mouse excels at: motion from where it currently is to the DIRECTION you need to go.
Elsewhere, you actually have to click on things. Personally, I find that that takes up a huge amount of cognitive space.
Unrelated, but one of the things with FPS's and such that annoy me the most is that you are required to use the mouse to achieve top efficiency. It would be great if someone made a game or extended the options to allow for better keyboard navigation / aiming. Like key combinations to tweak the interval size for a directional key (speed). I.e. shift+w, alt+w, ctrl/cmmd + w, maybe vim-like w20, etc. Also for increasing turn intervals like 45, 90, 180, and custom degree immediate turns.
You used to use the keyboard for all actions in FPS's. The first Quake is an example of this. And it was goddamn terrible, which is why everyone started playing shooters with mice as soon as possible.
Wasn't it back around that same time period that some people also tried playing FPS games with a joystick? Probably would have worked ok for Doom, but I can't see it working as well with anything that allows vertical aiming.
The controls from the original Quake is not what I'm suggesting. Controlling your movement and aim via keybaord right now IS terrible and I'm not disputing that.
What I'd like to see as an experiment is having a much finer grained control over your keyboard sensitivity.
As an example, let's say you have "a" mapped as your left turn (not strafe) key. So pressing and holding "a" gives you the standard movement speed you've come to expect. Pretty terrible.
Now let's say holding shift and pressing "a" gives you a turn speed that's twice as fast. Already this is a pretty significant improvement and offers you some control over you turn speed using only the keyboard.
Now let's add a couple more modifiers; crtl/cmd for 3x speed, alt/opt for 4x speed. Let's also add some new keys for turn 90 degrees, turn 180 degrees, turn 270 degrees, and these are all instant, just like a fast mouse turn.
A mouse still allows for much more granular control when it comes to aiming etc. but for someone who spends to time to really adapt these keys it would close the gap significantly and may even make keyboard aiming / turning a viable option.
I could be completely wrong though and it might just feel terrible, but I'd love to test it out to see.
I'm pretty sure that Quake 3 is basically unplayable on my phone because I don't have a mouse. Your suggestion might work fine if you were just shooting stationary targets, but for moving objects, no way.
The difference between FPS mousing and other kinds is that in an FPS the goal is actually to use the mouse as accurately as possible. In most other tasks using the mouse is not actually part of what you're trying to achieve.
Typical point-and-click interaction is conscious, yes, but mouse gestures generally aren't, since you don't have to know where the cursor is in order to use them.
That's one of the reasons I used to like Opera. Now I like it because shift+arrowkeys basically mean that I never have to even touch a mouse to browse the internet. It's completely keyboard-accessible.
Similarly, there's Pentadactyl and Vimperator for Firefox.
It's also an incredibly powerful addon when you dig down into what you can do with it. Last I checked (which was quite a while ago, to be fair), Vimium sadly didn't have the more technical aspects, but it's pretty much equal for keyboard browsing.
This is a great point - when I was trying to articulate (to myself) why I prefer the keyboard it wasn't necessarily any speed advantage, it was more like the "flow" advantage. Your point speaks to that.
I think there's also a big difference in the amount of physical effort needed when using the mouse. With the keyboard it's easier to keep most of my arms relaxed, and when I need to switch to the mouse everything from the shoulder down has to contract into action.
An interesting perspective (even if, I think, hopelessly wrong-headed).
Maybe that's why I hate Windows so much -- the position of the menu bar, for example, means I have to stop and think to pull menu items in a way that I never have to on the Mac (thanks to Fitt's law). Similarly, the over-reliance on toolbars and ribbons.
> Unlike the keyboard, the mouse scarcely rewards learning at all
I find it hilarious watching experienced vi and emacs folks furiously typing macros to perform text operations that are trivial with a mouse or graphical editor. The problem isn't that the mouse doesn't reward learning, but that what you learn is harder to define.
I use emacs. I don't really feel the need to defend it however. But honestly furiously typing is just not correct. Most of it is just muscle memory, not a lot of conscience thought. It takes a lot longer to switch to the mouse and click a position than to just use the built in commands.
There is also the aspect that the only time my hands hurt, or I experience carpal tunnel symptoms is when using the mouse extensively (especially when gaming). I have never had pain when using the keyboard.
You can only build a muscle memory for keyboard commands, if there are uniform shortcuts across different programs. Which is the case with commands such as ctrl-c, ctrl-v, ctrl-w etc.
However creating such uniform shortcuts won't fit the variety and complexity of today's applications - shortcuts are easy if you're dealing with trivial tasks like text editing in vim and emacs. However especially on the web (where many users probably spend most of their time) building an intuitive and usable interface for keyboards would be nearly impossible, given the variety of web applications.
Related anecdote: in Vim, ^W is the fairly useful 'delete previous word'. Pretty much everywhere else, it is 'destroy window'. This had led to many an issue.
Also related: In Emacs C-n is next line, which I would use to scroll through a small portion of the document. Most everywhere else it spawns a new window, so in Firefox I would want to scroll down 5 or 6 lines and end up with a bunch more windows open.
Although, if you learn Vim, there are Vim extensions for just about every program you might use - Firefox, Chrome, Eclipse, etc. I love being able control many programs with Vim's or Vim-like keybindings.
Vim navigation (j/k, etc) seems to be fairly standard for "move through items in a list". It's in Gmail, DuckDuckGo, and some others I can't remember offhand.
A couple of terminal applications that aren't vim that also use j/k are screen and w3m. Screen on its ctrl-a " selection screen and in ctrl-a esc mode, w3m on just every webpage (though it also uses emacs ctrl-v to scroll down a page).
This is only true for mouse based interfaces that require hand-eye coordination (click this, drag it there) -- gesture based interfaces (click and drag left/up/etc) don't suffer from this problem at all.
I believe I perform Opera mouse gestures using just muscle memory, I really don't have to think at all.
Before mouse gestures, yes, I would have agreed with that text, but not now. I genuinely browse faster with just the mouse and the gestures than with only keyboard, or with mouse+keyboard without gestures.
Note: the Chrome gestures plug-in is not up to the quality of the Opera native implementation. There's no comparison.
> one which cannot be fully relegated to "muscle memory."
I find mouse clicking as much "muscle memory" as using the keyboard; changing the position of buttons and items causes issues. For example, when I upgraded to Firefox 4, accessing bookmarks was moved, and for a few days I didn't automatically bring up HN without thinking.
I find that I unconsciously make the cursor track my eyes. I don't know if this falls into the realm of muscle memory but it makes using the mouse a lot less effort because the I am usually looking at where I am about to click.
The first rule of interface testing: Test the actual interface, on the actual problem, with the actual userbase.
This classic article is from 1989. You wouldn't believe what a state-of-the-art interface looked like in 1989. My awesome shiny new Mac SE/30 -- an excellent machine -- had a 512 by 342 black and white display (and I do mean black and white, not greyscale) and a 16MHz processor, which was considered fairly powerful.
My point is: We lived in a totally different universe back then. So, admire the methodology, but don't waste time debating the relevance of the results. Do some new measurements on your interface with your tasks. This is especially important now that touch interfaces have finally escaped from the lab: We are only starting to develop experience with such things, and everything is up for debate again.
> You wouldn't believe what a state-of-the-art interface looked like in 1989. My awesome shiny new Mac SE/30 -- an excellent machine -- had a 512 by 342 black and white display...
You wouldn't believe what a state-of-the-art interface looked like... in 1981:
If MMORPGs existed back then, this would not have been written. I don't know if anyone here is/used to be a gamer, but ever tried using your mouse to click skills/gear swaps? It takes forever, and completely distracts you from the flow of the game.
I used to play RO, and in /bm mode, I had access to 24 hotkeys (qaz rows). Enough? Hell naw. Even after they gave us access to another 8 keys (total 32), I still had macros set up for playing. On 31ms average ping to the server, I could dodge .3s casts - absolutely impossible by clicking.
While the mouse is more intuitive in the beginning, for anyone who actually uses their computer a lot, the keyboard becomes increasingly faster. Having to find the developer tab on excel and then hit export, save, and yes is much slower than Alt->L->E->Enter->Left->Enter for example. The idea of hotkeys, is just like ctrl+z, ctrl+c, and ctrl+v, they become intuitive.
A funny anecdote: I used to use ctrl+z (undo) hundreds of time a day when I was designing Worms Armageddon maps in paint. There came a time, where when I made a mistake in class on paper, my left hand would automatically go into the ctrl+z position, and move down even when there was no keyboard.
I don't think that anyone argues that mousing to small, arbitrary targets is more reliable or faster than keyboarding. Menus are a special case in this study because they abut the top of the screen (at least, if your OS's UX is reasonable), so you only have to care about x-axis accuracy.
Try mousing to the reply button on a HN page vs mousing to the Edit menu, it's easy to see why one might be faster even if your pointer is closer to the reply target.
Every other year when this article hits the latest aggregator the same conversation erupts.
People need to remember:
1.) This was the result of an actual user interface study. Responding with anecdotal evidence makes you seem less than intelligent.
2.) This only applies to the specific type of software studied (perhaps even within the time frame) and should not be taken out of context. Bringing up Emacs or Vi is completely out of scope with the discussion and if I had the power to; I'd down vote each comment that does.
Their whole argument seems to be about the use of simple hotkeys (cmd-p) vs menu items (File->Print).
Text editors are a completely different application of the same input devices. I also think that studying the efficiency and speed of typing complex text is much harder than measuring the speed at which a user can activate a simple command.
I'd like to see a breakdown of exactly what's faster and what isn't. Obviously, typing text by clicking on an onscreen qwerty keyboard (or better yet, a menu) would not be faster than typing via a regular keyboard, so the mouse isn't always faster than the keyboard. Is typing text some magical special case where the mouse becomes much slower? I find that hard to believe.
Tog's article makes it sound like mousing is always faster, but that's clearly and incontrovertibly wrong. I know nuance doesn't make for an eye-catching headline, but it would be nice to see somewhere in the essay.
Using arrow keys to manipulate a virtual mouse to move an arrow cursor across the screen is even more hopeless than typing with a mouse on a virtual keyboard. Any device emulating another will probably not show its best face.
(Edited for clarity since people seemed to misunderstand my meaning.)
But using `(` in vim to move the cursor backwards by a sentence is probably better than using a mouse--which involves locating the previous sentence, locating the mouse, locating the mouse cursor, moving it to the spot, and clicking.
You're manipulating words to make the mouse operation sound more arduous than it is. Similarly, I could say "when using the keyboard, you have to recognize that you wish to move the cursor backwards by what vi arbitrarily calls a sentence, then remember what the command you want is, then hold down the shift key, then hit the '9' key, then locate where the cursor has jumped to".
The user knows where the mouse is, and as soon has he grabs the mouse and starts to move it, the location of the cursor becomes evident. Moving to the spot and clicking is then an exercise in the kind of hand-eye coordination most people master by the age of 3.
I think part of it is that there's a (much dreaded) context switch from keyboard to mouse. Even if I can click a spot in text quicker with a mouse, I'll often just stick to the keyboard to retain my "flow state". I might trade off some time, but it keeps me slightly more focused.
Getting around in text with a mouse in Vim is probably unbelievably tedious, because you're using an editor designed in the 70s to be used with the ADM-3 terminal, from which a mouse was definitely absent (I have one in the closet, it's nice but doesn't even have a microprocessor, just TTL :)
I mean, sure, in Word, I can hit the "Home" key, if I want to make things harder for myself than Vim but easier than mousing around. But that's about all.
That's an interface created for a keyboard manipulating text, not the keyboard directly simulating the movements of a virtual mouse — remember, this is supposed to be the equivalent of a mouse pressing buttons on a virtual keyboard. Trying to use the keyboard to simulate mouse movements is simply frustrating, and I say that from experience.
Actually, for a while in an effort to learn more keyboard shortcuts for Excel I took out my mouse. The problem was I needed a way to play youtube videos but the focus was never set on the flash frame. So I wrote a Autohotkey script that would go one half the distance to the edge of the screen on each successive press of a key. In most cases it was very fast. I could click on any pixel with a theoretical max of 26 keyboard presses, but I also wrote in a "nevermind" key, so I could engage the key again for certain cases. For example, say the cursor was in the middle of the screen and I wanted to go 15% towards the left. I would activate keyboard movement, go right, deactivate it (now at 75% towards right) reactivate the keys and go back left bringing me to roughly where I wanted to go.
Regardless of the original claims on keyboard versus mouse (there is more recent work on that subject), there are some really nice gems in the article and comments, that are still relevant for current interfaces:
"
Guideline: The keyboard interface must not dictate the design of the visual interface.
Guideline: The work to design and build the keyboard interface should not sap resources that are needed for the creation of the visual interface.
"
Nolan Larsen from WordPerfect Corp. puts it nicely:
"
... When scrolling the text horizontally in a window we would refresh the text by redisplaying each line starting at the top. This resulted in a wave of text rippling down the screen, and many complaints that the screen refresh was too slow. The remedy was to scroll the bits already on screen and then redisplay each line from the top. The second implementation was actually slower than the first because we incurred the overhead of scrolling the bits before we even started to display the new text on the screen. However, the perception was that there was an immense increase in speed. We stuck with the second implementation because it increased the overall satisfaction of the user even though it actually decreased the throughput of the product.
In my mind, perception is stronger than reality. A user’s perception of a product is what causes him to purchase it and influences his satisfaction with the product...
"
Translating to modern technology, Nolan would express surprise that his irrational users that preferred web pages that displayed text before downloading media, or displayed above-the-fold content before rendering the rest, or liked being able to see welcome message instead of a full-screen loading animation at game startup, because the less-user-friendly version has the optimal "reality" of taking less time to finish an return to idle.
The lessons Nolan got tanalizingly close to discovering were that overall user experience matters more than whatever metric is easiest to measure mechanically, and that sometimes empirical data can disprove a theory. (Ironically, this second lesson was part of the message of Tog's article.).
The keyboard interface must not dictate the design of the visual interface.
I'm writing this on a borrowed Mac and hating the damn thing (damn mouse-base dreck seriously slows me down).
I would say that because of its keyboard use, the Windows interface is far more effective than the Macintosh interface but that the Mac interface is designed to seem usable. I would suppose something that seems great is exactly what companies should sell for their own benefit. I'm happy that Mac is not yet universal...
You're conflating speed with usability. I'm insanely fast on Windows, to the point where coworkers would make a sort of spectacle out of how fast I can open windows and explore the filesystem and such, but it's just because I know the shortcuts while they fumbled with a mouse.
Windows' keyboard accessibility combined with its responsiveness blows all other OSes out of the water, Gnome is accessible but less responsive, OS X is not accessible but responsive.
OS X is not keyboard-accessible at all, but it's more usable for novice users, as it doesn't confuse them with many options, the UI is cleaner, everything is laid out better, etc. I don't think anyone claims that using OS X is faster per se...
OSX is not keyboard accessible by default, its is not however "not keyboard-accessible". Go into system preferences and turn on keyboard navigation and adjust the keymaps to your hearts content. Heck add scripts to execute on certain key combinations if you want. And if you like you can remap what its defaults are to whatever you like.
OSX is setup to be transparent to novice users. That doesn't mean it cannot be setup to be used with a keyboard. Just that the default, which for 99% of users doesn't allow they keyboard to interfere with a novice user.
I can get OSX to do quite literally everything from the keyboard, I'm not sure how one can argue it isn't keyboard accessible when it is trivial to turn on. And being the 1% of the population that cares about it, power users shouldn't be afraid of learning how to turn it on.
Hopefully this didn't come across as harsh, but I just get annoyed at people that equate OSX = mouse only interface. When you can tell the whole idea behind the interface is to make default things simple to use with a single mouse button and make the rest possible. Despite what we think the actual idea of more than one mouse button is about as foreign as trying to understand Russian to an Englishman. Its more cognitive load than most care about.
I turned it on the moment I ran OS X for the first time. There were still many instances where I actually couldn't tab-navigate to some controls. Not to mention that there are no keyboard accelerators for anything in sight. That aspect alone makes it many times less accessible than Windows/Gnome/KDE.
I haven't used OS X in a few years, so I don't know if things have changed now, but I don't think they have keyboard accelerators nowadays either.
I'll admit I haven't found an application that doesn't let me tab to controls. Sounds like the developer messed up when creating his app or isn't setting the controls properly on the fly.
Can you remember what application it was? I'm curious now and like dumb challenges like this.
> I can get OSX to do quite literally everything from the keyboard,
I call foul on that one.
Perhaps if you said "I can get OSX to eventually do everything from the keyboard". I say that because of the 9 menu items showing for Chrome right now (if one includes the Apple), I can get to exactly one of them using Ctrl-F2. If I wanted to jump to the History menu, it is Ctrl-F2 followed by five right-arrow presses. If I were on Windows, I bet a Euro it would be alt-H or some such.
I just get annoyed at people who think that an option to turn on tabbing onto controls and to hotkey onto the Apple menu (or the dock) somehow equates with the incredible keyboard-friendliness of some other OSes.
So history is Command+Y in chrome by default, though yes if you activated the apple menu and key over I agree thats annoying. Command+H is universally hide window, but you could change it if you were annoyed enough.
Its not just "turn on tabbing onto controls and to hotkey onto the Apple menu". Though I admit, I don't use the menubar from the keyboard as most of the time I just use the shortcuts that activate the menu item.
Don't believe me? You are partially right with the eventually remark however, not all applications allow or even try to have shortcuts for every menu option. Lets add a shortcut to something that doesn't have it in Chrome. I'll choose the extensions menu under Window in Chrome just to be fair as you mentioned the app.
System Preferences->Keyboard & Mouse->Keyboard Shortcuts tab, then Clicky the + button. Choose your Google Chrome.app dir. Then "Extensions" and since I'm trying to not collide with things, I'm using Commmand+Shift+E, and click back and then voila, command shift e gives me the ability to activate what I couldn't before. Works for me and now I never have to click on a menubar either. Or am I just missing a use case in windows where normally the first letter allows you to activate the menu? I admit i've never used that even in windows.
More work than windows by default? Sure. But I'd call that good. As for apps that don't allow tab navigation or other such things, the only one's that seem to be the biggest offenders are browsers. Firefox need a few about:config changes to adjust its retarded on osx default focus behavior and everything is peachy. I've not hit anything I can't do in chrome, Ctrl+tab/etc... cycles tabs etc... Is there something specific you can't do in chrome? Are you referring to the wrench menu perhaps?
On OS X, I can get directly to any menu item by pressing cmd+? and then using the search. This is better if you have a vague idea of what you want, although admittedly, Windows has a better implementation for keyboard browsing of menu items. I vastly prefer the former, though.
The former is preferable for complex applications such as photoshop, but the latter is absolutely indispensable for frequently-used applications, as it's much faster.
Actually in Windows the application specific shortcuts often start with Ctrl. In this case Ctrl+H takes you to the history tab. Doesn't something like that work on OS X?
No, and that was my complaint. The post by pdhborges below enlightened me that one can use letters after pressing Ctrl-F2, but it is still quite awkward and I believe it is disruptive to flow.
Three keystrokes, the first of which is awkward and the rest of which are menu-dependent. In other OSes it's just alt+accelerator, for anything you want.
OS X/Cocoa includes some Emacs-style key bindings by default (see http://www.hcs.harvard.edu/~jrus/Site/system-bindings.html), so I don't think leaving other key shortcuts out makes the keyboard "interfere with a novice user" as you say. Dialog boxes don't support keyboard accelerators other than Esc and Enter, and the Finder doesn't support things like cut-and-paste or opening folders with the Enter key, and I find these things incredibly frustrating having used Windows in the past. Try doing something simple like moving a file from a directory to its parent in Finder versus Explorer.
Oh man, moving a file to its parent. You'd basically have to copy it, go up (I'm not sure if backspace goes up, does it?), paste it, find the folder again, go back down (or just back, i guess), find the file and delete it.
A clusterfuck, I can't fathom how some people can actually argue at length that OS X is fantastically keyboard-accessible.
I've used unix os's for longer than I have windows, I consider the terminal to be "keyboard-accessible". You can argue that point if you like, but the terminal is always a command tab away. That with osascript and the open command means i don't have much use for Finder. If I could keep Finder from restarting it wouldn't even be running on my system.
I use WindowMaker with tons of custom keyboards shortcuts using the windows key : win+x to open an xterm, win+n to open a text editor, etc. I also use a lot alt+Functions keys to minimize, maximize, switch windows to back or to front... I can do about anything without ever touching the mouse. BTW a massive pain I have with Firefox 4 is that the F6 key doesn't select the URL bar anymore, this is a huge usability drawback.
I use Gnome and have set the same shortcuts, it's great but it takes a while for the file manager to open and respond, for example. Windows Explorer (especially under XP) just flies in comparison.
By the way, why are you using F6? The standard shortcut is ctrl+l, as far as I know, and it's much closer than F6.
Gnome is slow... I use Rox as a file manager. I'm used to F6 because it worked on all platforms. Ctrl+I doesn't work on a Mac. Strangely, F6 still work on the Mac, but not on Linux.
Reading comprehension, folks, seriously -_-' All your arguments is either `but keyboard feels faster', or `there are some actions slow to do with mouse'. The former is addressed in the article:
> While the keyboard users in this case feels as though they have gained two seconds over the mouse users, the opposite is really the case. Because while the keyboard users have been engaged in a process so fascinating that they have experienced amnesia, the mouse users have been so disengaged that they have been able to continue thinking about the task they are trying to accomplish.
It's there, plain and simple: keyboarding around switches off (or busy-waits) a part of our brain, while providing nice tactile and quantized visual (every character stop) stimuli in regular interval. It feels faster, because that's how our brain is wired to measure time.
On the other hand, mousing around doesn't provide any cool stimuli until you actually activate the target widget. It feels long-ish, because the brain has to constantly work on adjusting cursor trajectory and nothing serious happens till you actually activate the widget.
The later argument is the case of rarely used commands. Of course ^S or ^P is faster than hunting the `Save...' or `Print...' through modern long menus, but that's an exception; an action to be taken once every few minutes. Manipulating text tokens and blocks (that's what we do most often, right?) is inherently faster with mouse than with Vim-ish or EMACS-ish regexps. Same for browsing hyper-text documentation or 'net forums.
Tell me you can select and move around a word, line or block of code faster with regexps than with mouse, and I'll gladly do it faster with mouse. On the average, anyway, which is what matters in the longer run.
Addendum: When you watch somebody working with Vim, and he looks so fast... consider that it's probably you hearing and seeing the massive stream of ^D^D^Djjjjjj3yykkkkkkkkp he has to type to find a chunk of text, yank it, and move it a few lines up. And that was me being generous, assuming he needs to cut 3 entire lines, not parts of a line. Working with the mouse looks slow because it's just a few clicks and maybe a keystroke or two.
…with thinking pauses a) figuring out what to search for: /fo or /foo or even /foo\. and b) for checking that your idea about the search term was correct. Repeat for the search for 'bar'
I am not claiming that this isn't faster for you or in general, but Tog has/had data to defend his claims, and data that that introspection can be unreliable in judging task duration. All you (and I) give are anecdotes.
There's a nice post by Jeff Atwood from 2008 that says this is crap for modern systems, but he does a nice job of putting it in historical context. There's just no way going to the File menu, scrolling down to Print and then clicking is faster than "Ctrl-P" (or Cmd-P) with your left hand.
Possibly for print, but then again I don't press print very often.
For scrolling down a couple of pages, copying 3 lines of code, moving back up, pasting, and then changing a couple of characters, I actually believe I am faster with a mouse than keyboard, after quite a bit of trying to master vim.
2 years ago I had a class where the lecturer was working in a visual ide. I'm not that good with vim, but it was painful to follow along. Half my time was spent waiting and watching him click around.
1 year ago I was teaching a class and had to give up vim. It was too quick for people to follow.
Vim doesn't give many cues as to what commands are being issued. If (using the previous example) you yank three lines then passive observer has no idea that anything has happened. That would be confusing for anyone.
I'm in my fourth week of vim after using Netbeans for years. I'm still waiting for these magical performance improvements. I think that good, consistent keyboard shortcuts are useful but completely ignoring the existence of modern GUIs and the mouse is just stubborn.
Scrolling and selecting with the mouse I can see, but do you actually copy and paste with the mouse too (i.e. through the context menu, or with the copy/paste buttons on the toolbar, if there is one)?
When I work with the mouse, I use my right hand (on the mouse) to select and my left hand (on the keyboard) to cut, copy and paste.
A more reasonable example than using Ctrl-P to Print is Ctrl-S to Save, I think. It's so much easier to hit Ctrl-S when you already have your left hand on the keyboard than using the mouse, and frankly I see no reason to ever remove my left hand from the keyboard.
Acme uses three-button mouse for copy/cut/paste, selecting text, searching, following hyperlinks and executing commands. It has `steep learning curve', steeper than VIM anyway to become comfortable, but pays off handsomly in the end.
CTRL-B and j several times (vs. scrollbar/scroll wheel)
"copying 3 lines of code,"
3yy (vs. select block, right-click -> 'Copy')
"moving back up,"
'' (vs. scrolling)
"pasting,"
p (vs. right-click > 'Paste')
"and then changing a couple of characters,"
(depends on the text)
"I actually believe I am faster with a mouse than keyboard, after quite a bit of trying to master vim."
I would humbly suggest the sum of the parts is greater than the whole, especially the use of marks and (unmentioned here) macros or the '.' repeat command.
Yeah, but then you're stuck counting lines. Whereas with a mouse, you just click and drag exactly what you want.
"p (vs. right-click > 'Paste')"
This is more difficult if you've copied whole lines but want to paste inside a line or replace text with your paste.
I love me some vim, but I do think it's easy to think we're faster than we are. I wonder if I recorded myself and then watched it if I'd think I was as fast as I feel that I am.
> This is more difficult if you've copied whole lines but want to paste inside a line
I agree, but the case where I want to copy multiple lines and have the first line start in the middle of a line is very rare in the languages I use.
> or replace text with your paste
That's what Visual mode is for. Personally, I find pressing Shift-V then j a few times is usually easier for line selection than acquiring the left line-selection margin or finding the end of the text.
In these cases I wouldn't say it's faster as much as I would consistent and easier. I do find myself having to clean up slight mistakes more often with mousing than I do vim commands.
Then you just get stuck holding down shift and the arrow key while auto-repeat ticks out the desired region... when you could have clicked at the start, held the button down, and immediately moved the mouse cursor to the end of the block you want to select.
If executing `Print' command is your top priority, you're a Federal Reserve employee, not an enterpreneur/programmer/tech enthusiast.</sarcasm>
Thinking, reading & browsing, writting -- those should take the most time in front of the computer, in that order. If you write more than think, you're either Don Knuth (hi there, Professor!) or using some VisualBasic 1.0 Verbose Edition. If you write more than read, you're working on a three-file project that only calls a few stdlib functions.
My point? That's not where the money is.
What you want is to make software for an pre-existing ecosystem of other software. Re-use code, build upon ready-made libraries and services. You get to think of how to interact with them, you get to browse the docs, jump around code a bit, pinpoint the right place and then type. Just a little, because you're using a high-level language.
Thinking? No idea how that interacts with the mouse. Except that being able to hold a snack or mug in the other hand helps sometimes ;-)
Browsing? Sure there is Vimperator [1], but most of the time you want mouse to browse docs and code efficiently. You want to use it profficiently, and you want an editor that treats your code (and possibly data, like Adminer [2] does for SQL DBs) as hypertext. Occasional ^F, sure, but that doesn't dominate. You can search with mouse, it's faster.
Programming? You work on various chunks of code or data. A block, a line, a word, a tag (if you are an XML person). All that's fast to indicate, search, select, copy, move etc. with mouse and proper editor [3] that doesn't force you to go through menus or toolbars. You want to click on the right FILE:LINE in compiler's error output and see it in editor, not keyboard through the output or manually input FILE:LINE it into editor when it's right there on your screen.
Of course keyboarding feels like it's doing that faster, but see the original article about why appearances are misleading here.
And yes, I've seen folks still using the old right-click, pop-up-menu, going all the way to `Cut' and then right-click, pop-up-menu, all the way to `Paste'. That's kind of backward and bloody sad, but not by itself a counter-argument against fast work with mouse.
Many of you have claimed that a keyboard is faster/'superior' but it really depends on your form of mouse and the application at hand. I recently got a new Macbook and have happily replaced some of my previous keyboard shortcuts with multitouch gestures. With the aid of Jitouch and hotkeys I can easily navigate web history (and go back and forth in folders and other programs), switch spaces, maximize/minimize windows, show all applications, hide all applications, show all spaces+applications, snap windows to the left or right half of the screen, zoom in on pictures or web pages, and other less-used actions.
I am not trying to say that multitouch+jitouch+hotcorners is the best solution for all interactions. Surely for activities like coding it's probably not. But over the past few weeks I've grown to prefer it for web browsing and general navigating the OS.
This argument is flawed in several ways:
1. Repetitive tasks get progressively faster with the keyboard as the motion gets smoother as your practise it.
2. He allows two-handed using editing Ctrl+X/C/V as a special case but there are other similar situations.
I'd like to see the exact methodology. 2 seconds to decide which key press to use sounds fishy to me.
Isn't your first point also true of mouse movements under certain circumstances? I am specifically thinking of the Apple style of fixing the menu at the top of the screen given the display resolutions at the time, and of "pie menus" on today's hardware:
A friend works on high-end image editing software (Maya). Their research is that pie menus are faster than keyboard commands and both Apple and Windows style menus because the user is learning write flicking gestures and their hand is already on the mouse for drawing activities.
> 2. He allows two-handed using editing Ctrl+X/C/V as a special case but there are other similar situations.
Like "all of them." The only command shortcuts I actually use one hand for are Ctrl-(Z|X|C|V), Alt-Tab, and Ctrl-Tab - everything else, I hold Ctrl with one hand and press the key with the other hand. It feels more natural that way.
I think context matters here. The article was discussing GUi word processor usage.
When using an app like Pages or Word, the mouse will be faster because keyboard navigation in those apps is terrible. You may be able to save some mousing with command-p, but for general editing tasks like highlighting and moving text, the mouse will always beat the keyboard.
In vim, however, editing via keyboard is well designed and always faster than mousing.
The true test would be to compare editing LaTex with vim versus a rich text document with TextEdit.
Ok, so what ? You can write faster with keyboard or move faster with mouse, but do you really need to be so fast ?
I'm really curious ( and not trolling ) : Don't you guys need to think "before" and "while" coding ? Or you just type as faster as you can ? I need to design and "try" code on my mind and then write it, i can make some last moment corrections while writing. Most of time, my code works as i designed and i'm spending much of my time with designing not writing. So what's the matter ?
Agree 100%. I've never gotten really proficient at any single text editor, but I've also never really felt like typing/editing was a significant part of the time I spend programming. Hearing other people talk about their amazing productivity gains from time to time makes me think I should master a particular text editor, but I don't expect I ever will because it just doesn't seem like a limiting factor to me. Could be wrong.
I made a switch from PC to Apple 4 years ago. The lack of meaningful keyboard shortcuts drives me mad. Consider a simple task of switching applications with the Cmd-Tab key: Minimize the only window of your application. Switch to another program, then cmd-tab back to your original program. Where did the window go? Oh, it's still sitting in the dock. So, grab the mouse, go get your window - and if you have 3 monitors (like I do), your mouse can be in a different zip code and it takes a long time just to find the cursor.
In fact, I think if we did this study today, we would find that due to bigger screen sizes, it's harder to spot the cursor, which would probably increase "mousing" time. However, Apple has 6 modifier keys on a laptop: Shift, Fn, Control, alt, option, and cmd, so trying to remember these keys can be a challenge too (and drives me crazy as well). What is the full screenshot shortcut? Control-Cmd-Shift-3 (aka finger-gymnastics)
There's your problem right there. Don't minimize windows in OS X just because that's what you are used to from decades of training on Windows. Hide the window instead (CMD+h). This way when you get back to it with CMD+Tab it magically appears again.
On the original topic. The whole idea makes me laugh. There is no way anyone driving with a mouse is going to be faster than I am with a keyboard. Navigating the filesystem, manipulating the filesystem, editing text esp. is laughable (I love VIM and nothing can come close to the speed I can edit in VIM, esp. not anything you have to drive with a mouse). Very few applications are better done with a mouse/pad (like Photo editing in Photoshop, but even there various keyboard shortcuts are faster than navigating submenus).
Your advice on hiding and switching applies to applications rather than windows. Consider this: you have four terminal windows open. You want to get toggle between two of them. Mac only has rotate (CMD+`), not toggle. There's no equivalent of the alt+tab combination in win32+gnome.
> I love VIM and nothing can come close to the speed I can edit in VIM, esp. not anything you have to drive with a mouse
A contrived example, but I'd like to see someone edit a Java project faster in VIM than I do in Eclipse.
Look, I know how to use VIM better than the next guy (you'll just have to trust me on this), but when it comes to writing code for large projects I can't stand using VIM. It makes me feel like I'm looking through this tiny window to my code. Give me a mouse and a powerful IDE, and it's like I suddenly have a 10,000ft view of the world.
I prefer Eclipse with VI plugin. You get the best of both worlds. And if I'm not happy with the vi plugin implementation, I can always continue editing in actual VIM by typing :vi in Eclipse.
All, that being said, I have heavily customized VIM with ctags, cscope, Command+T plugin and taglist.
Command+T alone is really worth it, you can open any file in the entire project structure by just typing a few letters (just like Eclipse's CTRL+SHIFT+t, but works on any file type).
With all these I can navigate code, and edit pretty much like I am in Eclipse, but unlike Eclipse this combo works for C,C++, Ruby, Python, Perl, Javascript etc. as well.
In that case, I think it would depend on the task at hand. For refactoring code and moving massive swaths of text around, stock Eclipse would win. For making small patches and writing new code from scratch, VIM would probably win.
I am referring to software such as viplugin. You're still in eclipse, so anything you do in eclipse without the plugin still works, but you also get Vi-style editing.
The point here is that the discussion is about input styles, not "IDE vs Classical Editor".
Not sure what is the practical and/or logical purpose of differentiating "hiding" applications and "minimizing" windows. They do one and the same, with the exception that "hiding" hides the entire app (with exception of Photoshop), and minimizing moves a window to the dock. IMO, two different behaviors for essentially the same thing - I can't think of a strong enough use case where you would want to hide instead of minimize (or minimize vs hide).
Back on topic, here's another thought (which I alluded to in my original post, but could not articulate well): could it be that their study included shortcuts that were too complicated? Could their results be skewed because in some instances it was easier to grab the mouse than to perform finger-gymnastics or to even remember the complex key combinations? I think the results of their study were glaringly obvious: the answer isn't "Move everything to the mouse" but "Improve keyboard shortcuts"
I think a lot of the difference ends up being more a matter of expressiveness than speed of simple operations. I'm pretty good in vim, but if I wanted to highlight some arbitrary region of text I'm pretty sure I'd be faster at using the mouse than I would with normal vim navigation.
However, I almost never want to highlight an arbitrary region, but instead a sentence, a paragraph, a line, the text in some quotes, the text until the next semi-colon, or something similar. And vi gives me easily expressed intrinsics to do all of those very quickly.
On the other hand, I can use a mouse just fine with a soda or cup of tea in my other hand, something I can't do with a keyboard. :)
Many people here are creating a false dilemma out of mousing and keyboarding. The argument isn't even necessarily about mousing vs. keyboarding, it could be about GUI vs. command line/hotkey. GUIs provide a discoverable profile of all actions (with the most common tasks optimized visually, hopefully). Hotkeys package the common actions to save time.
In any interface, there is a learning curve. Some users never progress beyond the most basic stages, and each time they interact with the software it's as if they are starting over. Other users develop further along the learning curve to the point that using a hotkey becomes cheaper. Many users bring overlap from other interfaces (which is what makes an interface intuitive — it fits the user's expectations). As more hotkeys are defined they will be for less and less common actions, which fewer users will learn, remember, and use. People will also move up and down the curve depending on their frequency of use with the software.
A useful product should have both. The more complex a product gets, the more the user skill stratifies (from newbs to pros), the more necessary both a GUI and hotkey interface is. The GUI provides a scheme for organizing the myriad features and functions as a fallback interaction layer, while hotkeys allow the user to leap ahead.
HN users are overwhelmingly savvy, which is shown by the support of keyboard interactions.
I am not saying that the title given here is true (certainly not in general, with arbitrary small targets at arbitrary large distances. There also is quite a bit of follow-up research on this), but I do find it sort-of funny/interesting/sad (frankly, I do not know what to call this) to see many reactions "I do not believe it" without evidence, while one of the claims of this paper is that users do not believe the first result.
Oh, and IIRC, the original research was on a dual-monitor setup, moving the pointer over two screens. And yet, Tog measured that the mouse was faster. I do assume he had a Macintosh mouse on a Mac, though. Compared to PC mice of the era, those were good (especially software-wise. There were PC mice were it was (as good as?) impossible to move the mouse by a single pixel.)
I've been a Vim user for 4 years now. I enjoy Vim and I'm definitely more productive using all those household keystroke shortcuts without having to move my fingers too much around. Really, everyone should try Vim once in their lives.
But there's something weird that happens to me whenever I adventure myself into a longer or smarter key combination that does a lot for little (ie. a macro). My mind will actually figure out the correct sequence quickly (< 1s) and fire it up... but then, after accomplishing my goal, I freeze during ~5s with a strange, contemplative doze in my face. That's when all the productivity it gave me goes down the drain.
So maybe too much keyboard shortcutting ends up overloading the brain at some point or another, in an effort to learn, rinse, repeat or out of sheer ecstasy.
It's not entirely clear if the test he relates (as "the test I did several years ago") in Part 3 is the same test he is referencing in Part 1. Part 1 does mention $50M worth of testing, after all.
But the test in Part 3 is to replace all instances of '|' with instances of 'e', in a chunk of English text. Keyboard users take 99 seconds, mouse users take 50 seconds.
He also implies that his experiment does not involve a cursor scheme that allows word-wise or sentence-wise movement (something present in friggin' Notepad, much less a real editor).
I'm not even gonna _start_ singing vim's praises at this point, because aside from preaching to the choir, it's like shooting fish in a barrel.
I think this study is too old to be applicable. I'm sure "ctrl+w, ctrl+t, ctrl+l" is much faster than "click the little X on the tab, click new tab, click on the address bar".
I have two words why i prefer keyboard over mouse: carpal tunnel. My wrist tightens up quickly when using mouse excessively. Typing is so much more relaxing.
(USS Saratoga was our code name during development of the extended keyboard because of its eerie resemblance to the popular aircraft carrier. Not so much the shape as the size.)
Nice bit of trivia there. I remember the Apple Extended Keyboard being big, but not that big. IBM Model Ms are pretty much the biggest keyboard I can think of.
The equivalence of actions isn't the same, so this wreaks a bit havoc on the argument. Yes, if you e.g. select text in visual mode and the "cursor" keys, then you'd probably be faster switching to the mouse. If you use the semantic movement commands, things are a bit different. Never mind keyboard macros...
It's pretty hard to generalize activity, and you really have to take notice of the tasks and user groups selected for comparisons like this.
It makes me feel old that I remember reading the original article when it first came out. When the first Mac came out in 1984, my roommate (an aerospace engineering student) was down on it until he came rushing home one day and excitedly informed me that, "I found out that I don't HAVE to use the mouse! They have keyboard equivalents for everything!" He ended up buying the Mac, but then went to work at IBM and was lost to the dark side.
>It takes two seconds to decide upon which special-function key to press. Deciding among abstract symbols is a high-level cognitive function. Not only is this decision not boring, the user actually experiences amnesia! Real amnesia! The time-slice spent making the decision simply ceases to exist.
I wonder if mussel memory ever catches up to make the time benefit break the other way. I want something closed, hitting f3 is the same as typing any other letter. I had to look down to see what F-button it actually is.
I think their claim is trivially disproven just by watching someone who's been using computers long enough. I don't think about the overwhelming majority of special-key presses, I just do them. Same with vim wizards and their tool of choice.
But, then, this was written in Ye Olde Days, where people hadn't really grown up with computers and may not have had that instinctual comfort with keyboard commands.
This is because operating a mouse-based user interface is a conscious process - one which cannot be fully relegated to "muscle memory." Unlike the keyboard, the mouse scarcely rewards learning at all.
Erik Naggum, in a Usenet post (circa 1997) explains this far better than I could:
"The clumsiness of people who have to engage their brain at every step is unbearably painful to watch, at least to me, and that's what the novice-friendly software makes people do, because there's no elegance in them, it's just a mass of features to be learned by rote... it's sadly obvious that we are moving into a way of working that is predominantly _conscious_, for which I believe the human brain was never prepared. we no longer have the time to let skills sink into the autonomous nervous system, as it were, and even if we try, the criminal in Redmond, WA, has a new, incompatible version out by the time we learned the last version... One of the joys of learning to ride a bicycle is to stop thinking about it -- the feeling that I had successfully programmed my body to master a bicycle at least thrilled me as a kid (except I didn't know the verb "to program")... we need to communicate to users that learning to use Emacs is like learning to ride a bicycle -- it does take some time and effort, it's a worth-while skill to have, and then you never forget. I firmly believe that the novice-friendly software is like giving people several sets of supporting wheels so they won't tilt, but could get moving right away, and then never taking them off, preferring that they keep using them and moving so slowly that they always need them. of course, if you argue that they should remove the supporting wheels to such users, they will, admittedly correctly, argue that they will fall _splat_ on the ground and ruin their three-piece suits. clearly a no-go."
(http://groups.google.com/group/comp.emacs/msg/821a0f04bab918...)