This really didn't work for me. I found needing to parse the command ("Move backward a word") broke the memory that I have built up over 15 years of using Emacs. Instead of naturally moving backwards with a flick of the fingers, I had to concentrate on where each finger was and on the key I was pressing.
I think the goal of this is great, but as it stands, I'm not convinced it is going to help. Given it aborted my natural wiring, I doubt it will be wiring things up correctly for people who don't have the wiring (I could be VERY wrong here!).
Now, take @gruseom's idea of a visual "goal" that you are chasing, and I think this could be intensely valuable.
> Now, take @gruseom's idea of a visual "goal" that you are chasing, and I think this could be intensely valuable.
Yes, they really need to take the words out of the equation. It's just a superfluous modality that gets in between the muscle memory, the goals and the training.
Of course, this method will get you familiar with shortcuts rather quickly (I only tried the Vim ones), but then, so does printing out a cheat sheet, or reading some tutorial and an afternoon of practice. While I do believe ShortcutFoo does manage to teach that more effectively than those methods, that's not where it could really shine.
To become a pro text-editor user, you really need to go beyond that, hence muscle memory, not just "memory". You don't merely need to remember the shortcut for "go one word back" when presented with the written goal "go one word back", no you must intuitively know the shortcut as soon as you identify the goal already on an abstract level.
Even with a simple default editing control like this text box: As I'm typing these words, I'm not thinking of every letter I type, I don't think about whether I need to "move cursor left five times" or "move cursor left one word" or "delete word to the left" etc, I'm thinking about the sentences and ideas I want to put into this post and operate the keyboard to make that happen--and any literal textual description of shortcuts and movement commands would really just get in the way with my thought process.
I haven't seen @gruseom's post yet, so maybe s/he had the same idea but: Something like a phantom cursor that indicates "get the cursor to here" or half-fade a word that you must delete?
But that may become too low level once you get more advanced. What you really need is a sort of visual indication that shows a diff between the original text and the goal text, you get to look at it to take it in while a quick countdown timer goes 3-2-1 and from that point it times how quickly you can edit to the target and how many keystrokes it takes you to do it.
(could even make it a colour-coded actual diff, then people get to train reading diffs as well :) [something I need to practice myself])
>This really didn't work for me. I found needing to parse the command ("Move backward a word") broke the memory that I have built up over 15 years of using Emacs. Instead of naturally moving backwards with a flick of the fingers, I had to concentrate on where each finger was and on the key I was pressing. ...
>Now, take @gruseom's idea of a visual "goal" that you are chasing, and I think this could be intensely valuable.
I made exactly your suggestion to the author a while back, since this site was posted on HN about a month ago. A few days after that, I went to a TrueCar Ruby meetup where the author presented his shortcutfoo app, and when he asked for input, I made exactly your suggestion:
Since, I reasoned, you never go from "verbal description of alteration" to "keyboard input" in actual practice, I said that it would make more sense to give some visual representation of what the desired change looks like, since that is a lot closer to how people use these shortcuts (although not an exact match, of course). Someone else then followed up by suggesting that it display "before and after" pictures (what the text/cursor look like before and after the modification), which would be pretty easy to implement.
I don't know why he didn't take that suggestion, but it's unfortunate that he hasn't.
Just to contrast, as somebody that's a novice-to-intermediate vim user, I really like this so far. The action verb model feels like it mirrors how I think when using vim, so at first blush, for me at least, it feels like a good fit.
I don't know enough about Emacs to compare there, though.
That's actually a very good description of my experience learning vim so far.
It starts off being a very conscious set of actions when first learning a new command -- e.g., "I want to change the word under the cursor... cw" -- before becoming something that happens subconsciously as I become more familiar with a set of commands.
Where this site at least appears to work well is that once I started to understand vim commands as verbs and nouns, I started seeing actions as sentences. The drills here seem to reinforce that sentence structure type approach.
I can see it being less useful for somebody that is familiar enough with their editor thatt it's already become a mostly subconscious process. While I'm comfortable using vim for the most part, I'm very far from a high level of proficiency with it.
I agree. When I use vim, I just know the key to press to move around. I don't think "move to the next word -> w". I know I want to move the cursor and my fingers know where to be but not really what key I am pressing.
Sounds like you are already there then. This gets you back into the cognition of it all which you aren't used to because you don't have to think about it. Its probably more helpful for people with less experience. I too find myself getting confused when reading about VIM because I don't think about it that much.
I would take the hard stand that any repetitive keystroke combinations inherently implies inefficiency - ie, an ideal editor should provide enough shortcuts to give your keystroke stream a fairly high entropy content. Maybe we're not there yet but I don't want to develop habits which would stand in the way of such an ideal.
But that's what the muscle memory is for. If you only ever used the arrow keys to move around and backspace to delete one character at a time, you won't need any special tool for memorizing which key to use!
The whole reason this tool exists is because the best text editors (Emacs ;)) do have a ton of different commands. So now you have to learn that when you wand to delete a word in front you use M-d.
The "muscle memory" is just associating each of the many discrete keystrokes with an action. So instead of thinking "hmm, I need to delete this word, I'll press M-d" your hands just go to M-d as soon as you realize the word needs to be deleted.
This is exactly the sort of memory you need to deal with a high-entropy command stream quickly. The ideal would be to use a ton of different commands without thinking about them at all.
Now, I don't think this site is ideal for this sort of learning, but it's a step in the right direction.
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 neat and promising. I agree with other commenters that the weakness is in telling the user what to do in the form of text like "Move cursor to beginning of line". Routing the muscle signals through text processing in the brain is slow and isn't what goes on when you actually use an editor. i.e., there's no text in a marquee in one's head telling one what one needs to do next. Since keyboard shortcuts are all about habit and speed, you definitely don't want to require any atypical or slow mental processes.
For cursor movement you could show a buffer of text with some kind of target thingy that moves around, and you have to chase it using keyboard commands. That might be fun. It would also be simple to create an efficiency score based on how many commands the user used to get where they wanted to go.
For text manipulation you could provide some auxiliary visual indicator of what needs doing. For example, to practice deletion, have a buffer of text and some visual indicator of a character, word, or line that needs deleting. Say it flashes (probably a bad choice, but whatever). Then the user's job is to use the right shortcut to delete the flashing thing. At first, the software could move the cursor to the right place before each new command. For more advanced users, you could tell them "First move the cursor to the right place and then invoke the right command to delete the flashing thing". As soon as they delete one bit, another bit starts flashing. You could measure how long it takes to delete everything in the buffer this way. That might be fun too.
That looks fun, but also intimidating. It makes me think that maybe tracking efficiency is a bad idea for learning after all. To stop and think about whether one's doing X in the most efficient way stymies flow.
Come to think of it, in Emacs I often do things inefficiently – in the sense of using many more commands than the technical minimum to do a task – because the basic commands are already "compiled" in my head. If I have to stop and grope for a less familiar command that could do the job more directly, that's like switching to interpreter mode, which is much slower. So in the short run, it can be more efficient in time to be less efficient with commands. This is the chicken-and-egg problem where one doesn't invest the effort to acquire new tricks because one's too busy doing one's job with the tricks one already knows.
The goal is to get more tricks into the compiled set (muscle memory) more easily. I suspect this is a "don't make me think" kind of challenge. One has a limited budget of thinking energy and typically needs to spend it on more important things, so one doesn't have anything left to invest in getting better at Emacs or whatever, even though one knows one "should". The challenge is how to move this kind of knowledge into muscle memory using some cheaper pool of energy.
This is probably a solvable problem because the commands we're talking about are so mechanical. They don't need to go through the most expensive cognitive process; our goal is to forget them on that level anyway. But I haven't seen any teaching tool with a low enough cost in this sense. The OP comes the closest, which is already impressive. And if you can learn editor commands this way, there probably are a lot of other useful things you can learn this way.
I took a look and yes, I didn't have to think much about what to do, and nearly all my effort was spent actually toying with h-j-k-l. I don't know vim at all so I'm good for a newbie test there.
Edit: I just realized what bothered me, though: it doesn't look anything like vim. So there's a context loss, which feels like it might degrade the value of the learning.
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 :)
Wow. Nothing like waking up on Monday morning to find your app at the top of Hacker News. Thanks to whoever posted this :)
This is awesome feedback. It looks like the most requested feature right now is moving from reading words to a more visual representation of what's happening. This is definitely something I've thought about - but didn't want to attempt until I received exactly this type of response. Thanks! I'll definitely move this up as a top priority and hopefully have something implemented soon.
Thanks for everyone else's feedback. I'll carefully read each post and email I've received and respond appropriately.
Someone asked about the tech stack: backbone.js + sinatra + mongodb hosted on heroku (2 dynos). I'll try and get a blog post up with more on this plus possibly a HN postmortem if there is interest.
I spent a few minutes trying to figure out how to give you this feedback before I saw your comment here. Maybe you should list an email address or have a contact form somewhere on the site. The only thing I found was a Twitter account, and I'm not on Twitter.
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.
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)
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!
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:
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.
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?
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.
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.
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.
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.
Textmate: ⌘-[ for shifting left is "History > Back" in Safari and happens every time when it's the last shortcut in drill mode, which happened to me both times I tried.
Otherwise nice tool. I agree with the others about visual feedback. For Photoshop: Show the part of the palette you want instead of the name of the tool.
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
Had this idea too, glad someone has executed on it so awesomely. I've been eager to get better at Sublime Text, so will start using this.
Two suggestions which I think would be really awesome.
!. The hard part of exercising though is getting your butt to the gym. What if you could sign up for a daily email that keeps you at it, challenging you to take it to the next level, tracks your progress, sets goals and reminds you to make them, etc.
2. It's really abstract to just hit key commands without seeing them actually do something. What if you made small animated gifs for each action your are emulating, maybe even with a full fake editor background? This way, your brain would be tricked further that you are actually performing the action represented by the keyboard shortcut.
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.
That's really fun. I love the site design, very slick.
Found a "bug". Some of the keyboard shortcuts conflict with my browser shortcuts.
For example, in one of the emacs drills, to move down a line (ctrl + n) it causes chrome to open a new window... so I could never complete the drill because of this.
It would be nice if the prompts at the end of sections could be easily keyboard-activated. (For instance, the "Start Drill" button that I have to take my hands off the keyboard to click.)
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.
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 only use vim, and from using this site for 3 minutes there's clearly plenty of knowledge that I'm missing. I really wish that it would teach me the commands it was drilling me on, and not just expect me to know the key strokes. I know I can pull up the shortcuts reference, but I feel like it should train and hint, then drill.
I feel like this is the equivalent of obsessing too much about going to the gym. What about good old "on the job training"? The shortcuts you need, you will eventually internalize... instead of using up time on an exercise like this. I mean, it might give some benefit, but is it worth the mindlessness?
One thing is you might want to allow people to configure the META key. I have Emacs set up so that the Command key is META, so all my muscle memory is ruined when trying to run through the drills.
But I like the concept and might use it to increase my shortcut kung-fu.
I think a cross between this and vimgolf would be really good. Basically where you just get things you need to do like changing the paragraph formatting and you just implement them to help you get in a state of flow with your editor.
Ctrl-shift-T is the key for repeating duplication in Photoshop, but it's also the shortcut for create the most recent tab in Chrome, so it's impossible to enter it unless you change your browser settings, which I'm not sure I want to do.
I thought this was a great idea. But I simply am an idiot and can't figure out how to use it. They tell you to type these || characters and it always spits back a fail when I try it. They need more user testing feedback.
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.
This is a fun project. But I'm not sure about the 5 bucks. Seems like it's begging to be rich too soon. This app is just revealing information you already have on a cheat-sheet.
I found it confusing because it was using capital letters when shift wasn't implied. So I'd hit shift to capitalize like it displayed and it'd be wrong.
I think the goal of this is great, but as it stands, I'm not convinced it is going to help. Given it aborted my natural wiring, I doubt it will be wiring things up correctly for people who don't have the wiring (I could be VERY wrong here!).
Now, take @gruseom's idea of a visual "goal" that you are chasing, and I think this could be intensely valuable.