If you get something wrong, and what you type is longer than the expected answer, you end up failing the next couple of questions too.
muscle memory - if you type eg "uptime" when the answer should be "free", it fails on the first character, but you're still typing, by which time it's on to the next question. which you then fail, because the answer to the next question isn't "ptime"
Yeah, this is a problem. Also, having some nice visual feedback when I get one right or wrong would be great.
That said, this is an awesome service and I'm going to pay for the premium account just to support the effort. I'm in the process of switching from a tricked-out gedit along with nano to just using vim, so this is a wonderful resource. I'd highly recommend it to anyone trying to learn vim. In the course of just 10 minutes, I've already learned another 10 commands. Assuming I practice them another day or two, they'll become permanently part of my vim repertoire.
EDIT: To clarify what exactly I'm using this service to do: I'm using it to eliminate the constant need to refer to a vim reference card. The muscle memory will come only from using these commands in vim, but being able to eliminate the need to constantly refer to a vim reference for new commands is a huge plus. I've already learned 10+ new commands that I no longer have to look up. PS - paid for the premium.
This is neat, but one thing it misses is the "reward." Not a gamification award, but the visual feedback from hitting a keyboard shortcut and seeing it actually happen, which helps reinforce the connection from muscle-action to program-action.
Another important component is seeing the scenario. Seeing the words "Duplicate line" doesn't hit the same neurons as seeing the situation in the text-editor that toggles my brain to think, "I need to duplicate a line here".
Obviously, none of these features are trivial to implement. Great work, though!
I agree that the visual correlation to the shortcuts is important. It's a very nicely designed and implemented idea, but I think I would need that visual component to warrant paying for it (the visual component would also justify a higher price for me as well.)
You misunderstood me. I said a reward, but not gamification. The reward when you complete a successful duplicate line shortcut is that you see a duplicate line. This helps associate result with muscle action. I'm arguing that this cements the memory even more.
This is great, similar to the code drills posted a couple of days ago, pretty good way to get that crucial memory in place. Did drill, would drill again.
I have to enable way too much stuff in NoScript to proceed when I actually click on an editor button. Giving permissions just to shortcutfoo is not enough. NoScript also shows airbrake.io, stripe.com, olark.com. I don't know what any of those are, so I'm not enabling them. So I cannot use your website, as cool as the premise sounds :/
I would argue that #3 would be one I'd like to have blocked. I've never had a situation where those "Hey! Wanna chat with a salesperson!?" boxes isn't annoying.
I wonder if this actually teaches you the right kind of muscle memory.
I have no difficulty with hjkl for navigating in Vim, but I had trouble associating those keys with the string "move <up/down/left/right> one character".
Mapping from the description of the command to the key is not the kind of muscle memory I use all day.
Agreed, this is the strangest way to learn an editor. The whole point of pressing a command is to see what it actually does. Connecting that action to your muscle movements is what you want.
Agreed. Perhaps a block of text/code with lines highlighted along with instructions on how/what to change them? That would give the right visual feedback and should be totally doable.
Agreed. Same problem here. Perhaps a visual display of what needs to be done would be a lot more useful. I have no clue of how this could be done though. At the same time if you want to build muscle memory, just use the damn editor and you get it eventually :)
This is great, I've seen a web game that you can use to practice vim schortcuts. But since this one's about building muscle memory, I don't see how this is going to be better than the actual use of the editor itself. Using the actual editor not only gives you the actual feeling but also challenge you with the real text editing tasks. CMIIW. But this is still useful if you just want to see a cheatsheet or not knowing certain shortcuts in the editor.
I think the point is that when starting out with a new text editor you aren't moving fast enough to use these shortcuts that often, so it's harder to internalize them. With this you just get rapid repetition, so that when it comes time to use them you have the command at the ready in your head. Of course I'm speaking from the point of view of someone just starting out using an editor. For someone that has already used any of these editors for any length of time this sit does seem kind of worthless.
I feel I must ask: do you try this on every website you come across, or do you check the source on every website you come across? Either way: thanks :D
Cool site, but a minor annoyance, is that some editors, like vim, have multiple ways of accomplishing a task. For instance move to line 4 can be done with 4G or 4gg, but only accepts 4G, which is frustrating as I've already internalized 4gg :) I'm sure there are others.
It's nice, but I'm not sure that's how my mind works when I'm working in VIM. I wonder how I'd react if I was put in an actual document and then prompted somehow to do the same exercises.
Not sure about OSX, but in Windows you can. This is a huge miss in Linux I find (all distributions I've tried so far), you need the mouse to get anything done without resorting to a terminal.
To get to System Preferences, you can use CTRL-F2 to get to the Apple menu, CTRL-F3 to get to the Dock, or—if those shortcuts aren't set up (but I think that they are by default)—CMD-TAB to get to Finder, CMD-A to get to the Applications folder, and type a few letters to get to 'System Preferences.app'. :-)
In the System Preferences window, you can start typing to select 'Keyboard' (keyboard focus is in the Spotlight menulet).
You can tab to the 'Keyboard' / 'Keyboard Shortcuts' tab bar, then arrow over to 'Keyboard Shortcuts', then tab to the 'Full Keyboard Access' radio buttons. Sadly, these last few steps require that Full Keyboard Access already be turned on! The text below the radio buttons says that you can toggle the setting with CTRL-F7, but that doesn't work for me; I'm not sure if some other keybinding is interfering.
How do you keyboard navigate the TextEdit save dialog that comes up when you Cmd+w on a window when you don't want to save it? (Can you do better than press tab 5 times then space?)
Working once on a MacBook with a disabled trackpad, I found the only window that I could not focus using the keyboard was the password dialog. I realized later that AppleScript could do the trick:
I'm not trying to be difficult here, just genuinely curious: why disable the arrow keys? Is it simply the speed boost you get from using hjkl on the home row vs moving your hand to the arrows?
I use Colemak, so hjkl is very counter-intuitive for me, whereas the arrow keys make sense and aren't /that/ far away.
EDIT: http://news.ycombinator.com/item?id=3684515 has some good explanations. So does anyone have suggestions for non-QWERTY users? remap the keys that are in the HJKL space, leading to a cascade of keys moved around? Deal with the counter-intuitiveness of actually using HJKL?
Dvorak users can get away with using hjkl with the dvorak layout - it's not that counter-intuitive. Your Colemak layout, however, looks beyond salvageable in terms of using Colemak hjkl. I think a re-binding is in order there.
When I use Vim I barely even use hkjl except to fine-tune larger movement commands. I'll search for a symbol, or move word-by-word, or use f/F/t/T to move to a different character on a line, which gets me in the ballpark.
Even if hjkl is faster, I would be optimising for a case that just doesn't show up that much.
Or, remap the hjkl of vim, a ridiculous legacy of an obsolete keyboard Bill Joy just happened to be using at the time, to the normal inverted-T of cursor movement: ijkl. Then continue using the "arrowkeys" that are now under your right hand on the home row.
You'll then need to move the insert on left side of cursor, which was i, to h, the key on the left side of your index finger. Reach left to insert left. Easy for muscle memory. With that, both sets of arrowkeys on the keyboard work the same, and you won't need to disable one of them. Normal arrowkey muscle memory, and reach left to insert left. So easy.
Bill Joy was working in an era when keyboards didn't have separate arrowkeys and the ESC key was within easy reach. He wanted it to be as easy as possible to remember lots of different command keys. He used what was printed on his key caps, such as a straight line of arrows on hjkl and various English words such as "yank" in his design. It was a good idea at the time. He also realized that keyboards varied, so he made it all remappable to adapt to future keyboard designs--also a good idea.
But the programmers themselves couldn't adapt. The choices Joy made for that obsolete keyboard were frozen in amber by programmers whose habits were frozen in amber. These days, almost all keyboards have real arrowkeys, and people develop the muscle memory to use them long before they ever hear of vim. Also the ESC key, such a fundamental key, is off in Siberia.
For every vim user with vim habits based on an obsolete keyboard they don't use, there are 10,000 potential vim users with keyboarding habits based on the modern keyboards they DO use. Those 10,000 people use inverted-T arrowkeys, x/c/v as cut, copy, paste, they can't reach their ESC key, etc. Vim was designed to adapt, but old vimmers apparently weren't, so the design features that give vim its power are forever stuck behind arbitrary key layouts optimized for the wrong keyboard.
It makes more sense to remain consistent with existing muscle memory and keyboards, using the inverted-T arrangement ijkl, mapping your left-side insert to the left side key ('h'), and mapping ESC to something easy to reach, such as ';;'. Then, if you ever need to use a non-customized vim, just use the real arrowkeys, which will still feel natural. If you ever need to use another app with a serious vi mode, like zsh, it will be remappable to match your vi. (If it's not a serious vi mode but just a couple of vi-like keyboard shortcuts, either use the arrowkeys or do what we always do, given that every app has its own unique set of keyboard shortcuts: just learn a few new shortcuts for that app.)
What's so ridiculous about hjkl? I'm actually an emacs user, and I've gone to great lengths to set up hjkl layouts in my editor and browser.
It seems like the perfect setup to me. An inverted T would cause you to reposition a finger every time you wanted to change direction. I do that often enough that it doesn't seem very efficient to me. I had some doubts as to whether jkl; would be a better option, but it really does seem more convenient to have the "down" key below your index finger.
This is similar to how I learned the DVORAK layout actually. I switched to DVORAK, made sure that I had a couple of essays pushed off til the last minute, and bam! I knew it like the back of my hand by 3AM.
Dvorak was a long process for me. It took me about 3 months to get to 70 wpm (was 120 qwerty). Online gaming had a lot to do with the delay: switching keybindings for every game was annoying, and I needed to quickly communicate with teammates (or smacktalk opponents ;P)
No need to be so drastic! - just put it on the other side of your desk.
I've done this a few times when I've needed the space for taking notes. I'm now pretty good at mousing with either hand - but the key part is not making mousing more annoying, like it was the first time I swapped, but rather just making you realise when you're reaching for it. That gives you a chance to consciously think about what you're about to do. And then you have a chance to decide that you're going to figure out how to do it with the keyboard.
I'm hoping to get there soon. On linux, I use vim, a keyboard centric window manager and I've recently started using uzbl for my web browsing. Not there yet, but getting there - already I find I don't need to reach for the mouse very often at all!
121 comments
[ 5.9 ms ] story [ 265 ms ] threadThat said, the site can be pretty confusing. What's the difference between practice and drill (other than slight interface difference?)
muscle memory - if you type eg "uptime" when the answer should be "free", it fails on the first character, but you're still typing, by which time it's on to the next question. which you then fail, because the answer to the next question isn't "ptime"
That said, this is an awesome service and I'm going to pay for the premium account just to support the effort. I'm in the process of switching from a tricked-out gedit along with nano to just using vim, so this is a wonderful resource. I'd highly recommend it to anyone trying to learn vim. In the course of just 10 minutes, I've already learned another 10 commands. Assuming I practice them another day or two, they'll become permanently part of my vim repertoire.
EDIT: To clarify what exactly I'm using this service to do: I'm using it to eliminate the constant need to refer to a vim reference card. The muscle memory will come only from using these commands in vim, but being able to eliminate the need to constantly refer to a vim reference for new commands is a huge plus. I've already learned 10+ new commands that I no longer have to look up. PS - paid for the premium.
Another important component is seeing the scenario. Seeing the words "Duplicate line" doesn't hit the same neurons as seeing the situation in the text-editor that toggles my brain to think, "I need to duplicate a line here".
Obviously, none of these features are trivial to implement. Great work, though!
1) exception tracking api 2) payment processing api 3) live, on-page chat tool
noscript is cool and all, but those 3 above listed items are perfectly fine to permanently enable on all sites
I have no difficulty with hjkl for navigating in Vim, but I had trouble associating those keys with the string "move <up/down/left/right> one character".
Mapping from the description of the command to the key is not the kind of muscle memory I use all day.
> Duplicate this line
or
> Move the cursor to the beginning of this line|
http://zeroturnaround.com/wp-content/uploads/2010/11/IDEs.pn...
System Preferences -> Keyboard -> Keyboard Shortcuts
And change the radio at the bottom to "All controls" under Full Keyboard Access.
In the System Preferences window, you can start typing to select 'Keyboard' (keyboard focus is in the Spotlight menulet).
You can tab to the 'Keyboard' / 'Keyboard Shortcuts' tab bar, then arrow over to 'Keyboard Shortcuts', then tab to the 'Full Keyboard Access' radio buttons. Sadly, these last few steps require that Full Keyboard Access already be turned on! The text below the radio buttons says that you can toggle the setting with CTRL-F7, but that doesn't work for me; I'm not sure if some other keybinding is interfering.
Or just hit Control-F7.
Command + first letter button title
will activate that option, with a few caveats - Command-C won't work as Cancel, but Command-. will.
I use Colemak, so hjkl is very counter-intuitive for me, whereas the arrow keys make sense and aren't /that/ far away.
EDIT: http://news.ycombinator.com/item?id=3684515 has some good explanations. So does anyone have suggestions for non-QWERTY users? remap the keys that are in the HJKL space, leading to a cascade of keys moved around? Deal with the counter-intuitiveness of actually using HJKL?
Even if hjkl is faster, I would be optimising for a case that just doesn't show up that much.
You'll then need to move the insert on left side of cursor, which was i, to h, the key on the left side of your index finger. Reach left to insert left. Easy for muscle memory. With that, both sets of arrowkeys on the keyboard work the same, and you won't need to disable one of them. Normal arrowkey muscle memory, and reach left to insert left. So easy.
Bill Joy was working in an era when keyboards didn't have separate arrowkeys and the ESC key was within easy reach. He wanted it to be as easy as possible to remember lots of different command keys. He used what was printed on his key caps, such as a straight line of arrows on hjkl and various English words such as "yank" in his design. It was a good idea at the time. He also realized that keyboards varied, so he made it all remappable to adapt to future keyboard designs--also a good idea.
But the programmers themselves couldn't adapt. The choices Joy made for that obsolete keyboard were frozen in amber by programmers whose habits were frozen in amber. These days, almost all keyboards have real arrowkeys, and people develop the muscle memory to use them long before they ever hear of vim. Also the ESC key, such a fundamental key, is off in Siberia.
For every vim user with vim habits based on an obsolete keyboard they don't use, there are 10,000 potential vim users with keyboarding habits based on the modern keyboards they DO use. Those 10,000 people use inverted-T arrowkeys, x/c/v as cut, copy, paste, they can't reach their ESC key, etc. Vim was designed to adapt, but old vimmers apparently weren't, so the design features that give vim its power are forever stuck behind arbitrary key layouts optimized for the wrong keyboard.
It makes more sense to remain consistent with existing muscle memory and keyboards, using the inverted-T arrangement ijkl, mapping your left-side insert to the left side key ('h'), and mapping ESC to something easy to reach, such as ';;'. Then, if you ever need to use a non-customized vim, just use the real arrowkeys, which will still feel natural. If you ever need to use another app with a serious vi mode, like zsh, it will be remappable to match your vi. (If it's not a serious vi mode but just a couple of vi-like keyboard shortcuts, either use the arrowkeys or do what we always do, given that every app has its own unique set of keyboard shortcuts: just learn a few new shortcuts for that app.)
It seems like the perfect setup to me. An inverted T would cause you to reposition a finger every time you wanted to change direction. I do that often enough that it doesn't seem very efficient to me. I had some doubts as to whether jkl; would be a better option, but it really does seem more convenient to have the "down" key below your index finger.
I've done this a few times when I've needed the space for taking notes. I'm now pretty good at mousing with either hand - but the key part is not making mousing more annoying, like it was the first time I swapped, but rather just making you realise when you're reaching for it. That gives you a chance to consciously think about what you're about to do. And then you have a chance to decide that you're going to figure out how to do it with the keyboard.
There goes a large chunk of users. You'd think this would be one of the first editors to have made the short list.
Add a shortcut key for Start Drill!