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.
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])
>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.
Earlier post: http://news.ycombinator.com/item?id=4007096
I don't know enough about Emacs to compare there, though.
1. Identify a problem
2. Think what I need to do to fix it
3. Decide what keys I need to press
4. Direct fingers to press keys
1. Identify a problem
2. Direct fingers to press keys
Perhaps if I could try more complex things (that I don't have current muscle memory for), I would find it incredibly useful.
Either way, getting better at using your tools is always a good thing.
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.
To elaborate a little, I'd like to see a "you are here":
you want to be here:
type thing. Not sure if this would work for other editors.
I don't want to need muscle memory for editing!
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.
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.
Hood news, everyone!_ [Ctrl-A]
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!
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.
One for Emacs would be fun
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.
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 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
> Move the cursor to the beginning of this line|
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.
ps. I'll get eclipse added as well :)
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.
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.
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.
# ps axo ucomm | grep -q SecurityAgent && osascript -e 'tell application "SecurityAgent" to activate'
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.
map <up> <nop>
map <down> <nop>
map <left> <nop>
map <right> <nop>
imap <up> <nop>
imap <down> <nop>
imap <left> <nop>
imap <right> <nop>
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.
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.
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.
There goes a large chunk of users. You'd think this would be one of the first editors to have made the short list.
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.
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.
Then, say for Sublime to cut a line it's ctrl+shift+k. It shows K.
So I try hitting ctrl then shift - nothing.
I try typing ctrl then shift - wrong.
I try entering a caret (^) for ctrl - wrong.
Just what are you supposed to do?
That said, the site can be pretty confusing. What's the difference between practice and drill (other than slight interface difference?)
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
Add a shortcut key for Start Drill!
Perhaps the game should be to transform one block of code into something different in as few keystrokes as possible.
I would love to see videos of people using commands that are not a part of my current vocabulary.
Related, http://vimgolf.com/ but vim-specific..
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.
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.
求 -> ball -> O (actual ball)
求 -> O (actual ball)
Classic study vs immersion.
The implementation will be much harder, but for this to be effective show the manipulation, not the description.