This. Is. AWESOME. Let me tell you what this is useful for by telling you my story:
I'm a pretty fast typist (80-100WPM on TypeRacer, usually) and I really never put much thought into my typing, since it was good enough. But I recently started paying attention to the kinds of mistake I make on Typeracer, and realized that I have certain combinations of keys which I don't make using the "home row" of the keyboard, but rather, move my hands to make. Every time I hit one of these, I have a 50/50 chance of not getting back to the home row correctly, meaning I have a 50/50 chance of throwing off my typing.
And I am a heavy VIM user, by the way, which means I am very used to doing everything from the home row, including every navigation you can think of. I even have AutoHotKey scripts to give me vim-style navigation everywhere in windows, so I never have to move my hands.
Now with this program, I finished running an example and noticed 2 shocking things:
1. There are a lot of keys which I'm not used to typing from the homerow, which happen to show up a lot in regular Python code. For example, periods (.). And underscores. I was used to shifting my hand to type these characters. I don't notice this during every day work, since I'm actually programming, but I did notice this while playing a program specifically designed for typing.
2. At the end of the program, it gives you statistics, and I found out that I was only about 48% effective, meaning 52% of the keystrokes I made were accidents that had to be backspaced out. This is a lot. Part of it is "first time with this program" bias, but it still means I have a long way to go.
Anyway, I recommend running through this program, it will probably teach you a lot.
P.S. Just one bit of constructive criticism: the way the program presents mis-types is a little annoying, and hard to follow. I recommend doing the same as TypeRacer, that is, have the "mistaken" keystrokes be visible somewhere, so the typist is very clear on how many keys he needs to backspace out. This is much closer to how people type in the real world.
Thanks, I'm glad you found the stats useful. In my initial version, I wasn't requiring the user to correct errors. I was personally getting errors rates around 3~5% , which appear good but seemed too low for the amount of errors I feel I make. Adding the need to backspace and correct keys revealed the true cost of mistyping a key, namely the wasted keys typed before correcting and all the backspaces.
Thanks for pointing out typeracer. I will take a look at it and try to incorporate its error handling.
Just in case I wasn't clear, I absolutely agree that you should force users to correct errors. It's just that the interface right now makes it harder to see how to correct the error, since you don't get visual feedback on the "wrong" characters that you've typed.
Hey, I agree this is awesome. I have noticed as I've optimized my workflow that I actually make a huge number of typing errors when I'm programming. Other typing programs don't test the whole set of symbols we use, so they're not as useful (and I type English considerably faster than code.)
One thing I would say is that it would be nice if it showed stats while I was typing, instead of just at the end.
I was taught in typing class that its better to skip errors and then come back and correct them when you are done. Not that I follow that advice especially often, but I wonder if it would be more helpful to do that. I didn't like during the demo that I was forced to correct the problem before continuing.
Take it from someone who averages 140 WPM and peaks at 160-170 WPM. Don't skip errors and return to them later. Do delete whole words (alt-backspace) and re-type them from the beginning. When you get really fast, almost all typing errors are transposition errors. By the time they register you are already several characters, even words, ahead. Trying to correct them character by character will throw you off.
If you use emacs, what do you think about `flyspell-auto-correct-previous-word`? It's like autocorrect, but it only happens when you invoke it and it always happens on the last misspelled word rather than the word under point.
I agree. I believe the most typing classes are focused on the word processing end of things rather than programming. While waiting to correct errors afterwards can be faster for regular documents, I would absolutely never do that when programming.
Actually, I doubt it's even better for regular documents.
In the writing discipline, people will often tell you to write a first draft without correcting errors, then go back and error-correct on the second draft. But that's not about typing errors, but rather grammatic/narrative errors in your writing.
I had the same problem with not getting enough feedback on the errors I made. For example, I mistyped ")" a few times. But to correct it I need to know whether I hit the key to the left or to the right of ")" so I can move my finger accordingly. (I often type US-Dvorak on a spanish layout keyboard, so looking at the physical keys on the keyboard is pointless).
Supporting KILL and especially WERASE would be nice; I usually use one of those rather when I've made a string of errors, rather than watching and counting backspaces. And I agree with previous comments that it's hard to follow just how many backspaces are needed.
FYI I did the Symfony demo, then signed in with Google and got a 404 error. It did save my progress, but I had to re-authorize before I could get back to the list of languages.
Fantastic product, though. I see myself using this a lot. Any chance of a C# version coming along?
Exactly, and I'm a java programmer. For the record Sublime Text also inserts these for me. When I had to type '}' in the training program I actually had to look down at my keyboard!
They're completely valid brackets to use in writing. You don't tend to see them much but using different forms of brackets can add clarity to nested brackets (i.e. when you feel the urge to expand on your text in brackets [which I frequently do {and according to Wikipedia, others do too}])
Thanks so much for this bit of knowledge, I was not aware this was the grammatically accepted means of doing this. I always tried to reformulate sentences to avoid nested "expressions" due to the confusing nesting of parenthesis.
Yeah, that makes sense. I could foresee some cases where I was writing something documentation-y, such that it made sense to do in Word, but aimed at developers, such that I'd want to include code samples or the like.
I'm a pretty fast typist (80-100WPM on TypeRacer, usually) and I really never put much thought into my typing, since it was good enough. But I recently started paying attention to the kinds of mistake I make on Typeracer, and realized that I have certain combinations of keys which I don't make using the "home row" of the keyboard, but rather, move my hands to make. Every time I hit one of these, I have a 50/50 chance of not getting back to the home row correctly, meaning I have a 50/50 chance of throwing off my typing.
And I am a heavy VIM user, by the way, which means I am very used to doing everything from the home row, including every navigation you can think of. I even have AutoHotKey scripts to give me vim-style navigation everywhere in windows, so I never have to move my hands.
Now with this program, I finished running an example and noticed 2 shocking things:
1. There are a lot of keys which I'm not used to typing from the homerow, which happen to show up a lot in regular Python code. For example, periods (.). And underscores. I was used to shifting my hand to type these characters. I don't notice this during every day work, since I'm actually programming, but I did notice this while playing a program specifically designed for typing.
2. At the end of the program, it gives you statistics, and I found out that I was only about 48% effective, meaning 52% of the keystrokes I made were accidents that had to be backspaced out. This is a lot. Part of it is "first time with this program" bias, but it still means I have a long way to go.
Anyway, I recommend running through this program, it will probably teach you a lot.
P.S. Just one bit of constructive criticism: the way the program presents mis-types is a little annoying, and hard to follow. I recommend doing the same as TypeRacer, that is, have the "mistaken" keystrokes be visible somewhere, so the typist is very clear on how many keys he needs to backspace out. This is much closer to how people type in the real world.