I'm still just a Python novice, so obviously I didn't write this code originally; I'm just transcribing it from a text file into Vim to demonstrate how easily and fluently code can be written with steno. It's not primarily about speed, but about chunking commands and words into single strokes, as opposed to breaking them down into individual letters and typing each letter out one by one as in qwerty. Also notice how simple error correction is; an incorrect word is deleted with a single stroke.
For more information, visit: http://openstenoproject.org
I think there's also an activism we could have about NKRO. I had never even heard of it before watching this. If it was a feature I knew actually helped people, I would expect it to be present. At the very least, it's not too much to ask to get this feature in cheaper boards.
But seriously, as a gift at the end of the year, I can see engineers getting this. It would actually be a pretty badass gift...
I'm imagining a left hand / right hand split qwerty, but nestled in the middle is the smaller steno board. Maybe that's crazy, but whatever the right design, there have got to be hobbyists out there who would build the prototype which you could feature.
Is that the right path? Building some kind of uber keyboard and a cute training game and trying to do it all at once? That's endorsing an almost YC approach, but it would certainly be fun if you're into that pace.
Good luck with the project! I think captioning is important, but will ultimately be replaced by software; giving the world a better way to input text universally is a very big idea. I don't think it's necessarily great for programming in today's languages, but I guess you have to think about this sort of thing on a wider time scale.
But ... can't you achieve this level of efficiency, maybe even better with a combination of auto completion and snippets?
With python and vim, I use jedi-vim and neosnippet for textmate compatible snippet completion.
0 : https://github.com/davidhalter/jedi-vim
1 : https://github.com/Shougo/neosnippet.vim
Would it be possible to capture each users' idiosyncrasies, and work them in to the core to keep it expanding? (Perhaps using statistical analysis of shared chords?)
A goal could be to have the best of both worlds: flexibility to customize as one sees fit. Yet, also have the idiomatic ways bundled in. That way a user could minimize the amount of time spent tinkering, if they so wished.
Thank you so much for working on this. Recently I've been experiencing significant repetitive stress. I am using a kinesis advantage keyboard and recently worked with a few physical therapists. I still feel pain.
I really like that by learning Plover, I may not only be reducing pain, but actually become a faster typer and coder. I just ordered a sidewinder keyboard, and I look forward to trying out this soon. I am prepared for a long learning curve, but by this point I am used to it and it seems like it will be worth the cost.
But if you didn't know what a nail gun was, never imagined the thing, could you imagine framing a 2-story house by hand? A large house might need teams of arms & hammers. Dozens. You wouldn't even see construction as the same kind of thing: more of a coordinated work of labor, like aisles of rowers on a trireme.
If I can type so fast I can think out loud into the machine, the flow changes. It's likewise hard to argue how a REPL changes much anything, since saving & recompiling is fast, but I think flow is rather important.
Software development is built on layers of abstraction that directly allow one human to frame a 2-story house, while typing very little. The amount of actual machine code generated by a simple CRUD application can be massive. Optimizing the raw typing is only useful when you have no control over the deeper abstractions (like if you are stuck with C++).
It seems difficult, but after about a week, you can write a lot of things without having to look them up in the STENO dictionary. The syllabic way of spelling words is systematic enough that you can derive most words, and there are multiple ways to spell something so most of your guesses are right.
Unfortunately, I think it will take (as said in the video) 3-6 months before I can go at a normal pace, and words not in STENO are not so easy to deal with. For any word not in the STENO dictionary, you either spell them out or generate a new set of chords for that word. So the system grows on you as you use it more and becomes more optimized and comfortable the longer you use it; it just takes a long time for you to become comfortable.
Steno keyboards also don't have arrow keys or modifier keys so you have to chord them out or remap all your shortcuts to things that make steno sense to you - that's even more of a learning curve.
I still really want to learn it; it is something that I think pays dividends after around 5 years or so. I would love to use it for stream of consciousness writing or note taking/transcription. Not sure about programming since there are so many tools (autocompletion, you can just write your own macros if you really want to save keystrokes) to help speed you up.
If so I'm thinking predictive techniques could help.
BAIR --> Bare (phonetic)
BAER --> Bear (spelling)
You do have a point, though, that predictive software could help. I just don't don't know how I'd feel when it gets it wrong.
If Plover can effectively make Steno keyboards understandable by our OS of choice... Should we start teaching our kids this thing before they ever get hooked into qwerty?
That said, I wish for a time machine so I could go back and give a Plover to 8yo me so that I could internalize it like only a child can. Then I could pull it out, jam it into a USB port and type like a Jedi to the amazement of all in the present day while spouting platitudes about an elegant keyboard from a more civilized age...
1. A gentleman at the end says he's learning Colemak and that he's forgotten QWERTY as a cost. I type Dvorak every day, and I have to refute that claim! Sure, Colemak is a lot closer to QWERTY but I have a hard time believing he actually forgot QWERTY. So don't worry about that, I encourage you to try a different layout (and recommend Dvorak for its prevalence in the wild.)
2. There is a second gentleman asking if this could be done for iPhone. Such efforts are underway, I know there is some project at KTH doing this. It doesn't really work all too well but it is a nice concept. Perhaps if you could also properly see the screen while typing...
I have totally forgotten the French dvorak, but not AZERTY, because I feel I haven't learned those in the same fashion. AZERTY I learnt by hunt-and-peck (I was around 50-60 WPM when I switched), the dvorak variants as touch-typing (as the key labels don't match what's written on the keyboard, so you have to do it this way). So my feeling is that if you used to hunt and peck with QWERTY, dvorak will not overwrite this; otherwise, there's a risk.
This is also what I think is the main benefit of learning an alternate keyboard layout: force you to touch-type properly. Some people manage to move on to proper touch-type on a keyboard layout they learnt by hunt-and-peck, but others don't, and the level of comfort achieved by not looking at the keyboard at all is really, really worth it. Glancing alternatively at the keyboard and screen is stressful and causes typos.
By contrast, if you can already touch-type proficiently in QWERTY (but really touch-type), then I think the benefits of learning an alternate keyboard layout are less clear. My impression is that it saves you maybe some muscle strain because your hands move a lot less, but I'm not sure of how beneficial that is.
It took at least a few years before I could type dvorak with just my right hand, which is tricky seeing the other letters when I'm staring at a qwerty keyboard.
I regret nothing. (:
I can type nearly as fast in qwerty as I used to, but it is uncomfortable, awkward, and I do make errors often.
I'm a touch-typist, and when on some rare occasions I have to hunt-and-peck while programming (e.g. a fingercut or something), I'm absolutely and totally frustrated on how horribly slooooooow it is; kinda like being handicapped; imagine e.g. being able to use only your one hand to type; or, even better - having to type with your nose! (yes, nose, really!). Now, knowing that, I imagine that being able to type with this amazing steno speed, one feels a similar level of improvement vs. touch-typing.
So, that wasn't a straight answer to your concern, but given that I do feel like described above, I believe it shows that it somehow proves important to me as a programmer. Ah, also, now I remembered, there's the "classical" article on this by Jeff Atwood, which is worth a read: http://blog.codinghorror.com/we-are-typists-first-programmer...
edit: Also, now that I thought of it somewhat more, there are two additional benefits: One is, that typing faster leaves me with more time to do the actual thinking. Second one is, that makes my code more "lightweight" for me, in that it's somewhat easier to delete/iterate/refactor stuff, knowing subconsciously that I can quite easily type something similar ("other variant") fairly quickly.
For most code that I write there is a modicum of research (e.g. online docs, requirements, etc), some time spent thinking about how it should be laid out, and a whole lot of frameworking (e.g. putting the code into the agreed upon structures or interacting with the structures, which is often an internal research stage also).
The only thing I can imagine trying to write really really fast, is someone reproducing from memory various Computer Science 101 algorithms for funzies (you'd always use standard libraries in prod' anyway). Aside from that programming speed seems the opposite of how programming works.
Yet it is constantly talked out (e.g. "I purchased a $150 mechanical keyboard to type code better," "I use Vi/emacs because a mouse/IDE slows me down," "I code on the terminal because it has less distractions," etc).
I use vim (or emacs) because the regex search/replace and macros mean that when I need to edit the same thing 5,000 times in a data file I don't need to fire someone in India for a week to hunt them down.
Typing speed has very little to do with it, but avoiding the mind numbing tedium of going from underscore variable names to CamelCase or vise versa is a godsend.
>I code on the terminal because it has less distractions,
I code on the terminal because when I use tmux I can have the equivalent of 30 IDE windows open each looking at a snippet of code I need. Until I have have a monitor wall I can carry around with me that can display a few dozen different windows there really is no comparison.
It's not about speed, it's about keeping in your head what you're doing. For example, there is a function call in a source file to fn_ive_never_seen(), in an IDE the best you can hope for is for it to dig up where it was defined, and maybe the header file if it's some C type language.
I can open a new window on the terminal, grep the whole source base for this function, see where it is used, where it is defined and with sed edit all those definition to take an extra variable I need by just stringing together a few commands in yet another window.
Again, it's not about speed, it's about getting a computer, which is very good at being pedantic, to make sure that every last mention of something is changed the way you want it to be changed.
Writing raw code makes up a TINY proportion of what I do professionally day to day. Writing long code in a single stretch (e.g. without researching, checking other parts of the codebase) almost never ever happens (because code isn't created in a vacuum).
Also I am well versed on Vi's functionality. I choose to use an IDE.
It's like, say, editing in a window which is, say, 8 lines high. Sure, most of the time you are only looking at 8 lines at a time, and the time spent switching back and forth when you need more is not the limiting factor. Still, I think this would make you a lot less efficient.
The point of competent typing, and good text editors, is that they reduce the gap between your mind and the code. It's not just about speed. The latency analogy of pgt is a pretty good one.
I don't want such things to be a big chunk of my day, and being able to type quickly helps keep the amount of time I spend doing that to a minimum and lets me get back to coding :).
I totally agree. Every editor or typing speed article is accompanied by posters claiming that it's not important for programming, and I just have to think that they haven't spent a lot of time working in a team.
Typing and thinking about code is never more than 2/3 of my job. Writing emails, commenting code, creating procedures (e.g., for releasing), documenting our infrastructure... These activities require a bit less thought and are always limited by my typing speed, even with vim and 100+ WPM.
Getting through them slower would mean spending less than half of my time programming, or worse: a pile of undocumented code and systems, and increasing irrelevance in team discussions.
I was wondering about making a custom keyboard for vim actions, and programming it even more with extra macros a la surround.vim
Buttons / actions could also include switching windows, switching to the browser and refreshing, etc.
Also, go see a doctor!
As for doctors, I would go see a specialist like a physiatrist. They can give you a treatment plan and help you adjust your environment and habits to combat the problems.
RSI isn't manifested as one specific problem, it can cause a whole host of issues. So the specific type of doctor you'll need somewhat depends on what it has manifested itself as.
> it's not as simple as just going to a doctor
What exactly is your point? That people should ignore it because it isn't "simple" or that rebinding your keyboard is better than going to a freaking specialist?
Honestly why did you make that post? What are you goals here, to discourage people from seeking treatment? I am really trying to figure it out.
edit: Above post was edited after I posted to add:
> My understanding is that it could be a problem with your shoulders or back, for example. Here some of the stuff I've been reading: <links>
Btw, everyone agrees not to ignore the problem. I would think that there are enough people who read hacker news, we might be able to get a little more concrete information.
But you don't have to use a steno keyboard or a pre-defined steno system to type words phonetically nor to create macros. Both can be done on regular keyboards (or any other kind of keyboard). However, it is nice to get a keyboard that can chord more than 2 or 3 keys which most cheap keyboards are limited to. The more keys a keyboard lets you chord, the more one-stroke macros you can create.
Velotype also works on a start-vowels-end system, just with letters instead of sounds.
I liked the discussion of unicode/multilingual stuff (brief and inconclusive though it was). Basically it sounded like if a language has a steno solution then this could work for it.
I liked the demos and the going over of the chords that were typed in to make the various outputs.
I liked the accessibility and efficiency side of things.
I really liked the conversational speech engine thing.
At first, I was a bit uncomfortable with how fast she was talking (it was very rapid fire), but she even addressed that (in giving the same presentation previously, she'd run out of time).
I liked the low cost aspect of it.
I thought her idea of a game (RPG or MUD) to learn how to type steno was interesting. I looked at the project website (http://plover.stenoknight.com/) and didn't see the game yet, so I am guessing nobody has taken up that torch yet.
I am skeptical about the keyboard as a long term input device, but I've been using it for 25+ years now, and it doesn't seem to be going away just yet.
Here's a site with an n-key rollover test, which should tell you if your keyboard will support this sort of stuff natively: http://www.gigahype.com/nkey-rollover-test-page/
I noticed that my keyboard supported, in some cases, up to 8 characters are a time -- but if I tried to hold WASD all down at the same time, it failed. So I guess it's not an n-key rollover supporting keyboard. (I vaguely remember reading something about this and how the key switches are laid out in a grid last year.)
I rarely seem to get problems with my fingers from typing, but one culprit is Tetris (which I play for hours every week, not sure why I'm not sick of it after so many years). It does cause some pain for me to play. I don't know if this sort of thing would ever help with that, but I am not sure.
Edit: Forgot to mention, the description of the logo was pretty neat.
But yeah, making a comprehensive steno tutorial video game is pretty much at the top of our list right now. We've even got some funding set aside for art assets and stuff; it's just about finding the right developers at this point.
Meanwhile I have been working on reverse engineering the proprietary USB protocol for the Elan Cybra steno machine... http://cdn2.bigcommerce.com/server1400/803d4/products/3527/i...
The keyboard shortcut thing in vim is cool though.
Well, what would it take to make it great for programmers? My primary concern at the moment is the excess whitespace it often adds after every keypress. Exact typing is very important to me when I am writing code. Are there other issues you're concerned about?
I think that ultimately everyone spends more time thinking than literally anything else in the world, including qwerty typing, so "I spend more time thinking" doesn't seem like a meaningful observation to make. Even a 1% improvement in typing rate applied globally, across all forms of work that might even trivially involve typing, can save millions of hours per year of labor.
Wait, let's check. Assume 500 million qwerty typists. Assume an average of 10 minutes per day spent typing every day for a year by everyone. So a 1% improvement would be 34,700 years of labor saved over a single year? Pretty cool.
Edit: yeah so it occurs to me that I shouldn't estimate 500 million qwerty users. Hmm. Maybe it would be better to estimate based on "75% of cellphone users worldwide send text messages" multiplied by maybe uh 1.5 billion users. So anyway, at least 1 billion typists (although not qwerty-specifically, cellphone typing is dramatically slower, so is safe to use here).
(I'm not implying that I could do faster, only that it seems slow compared to other typing speed records)
Although.... I'm not the slowest: http://www.seanwrona.com/typeracer/profile.php?username=kanz... (so this might distort the results either positively or negatively) (also my background as a programmer might make IOCCC code look nearly legible)
I wanted to give a baseline so that when someone tried using Plover to type it, there would be at least one number to compare against.
Edit: did not mean to sound so miserable. I think this is a great project and my plan before Xmas is to install it on a raspberry pi, buy or make the stick on keyboard and use the RPi as a pass through keyboard at work - so I am less dependant on each local hard disk
I tried this link and it seems like I can press multiple keys at once: http://www.gigahype.com/nkey-rollover-test-page/
It looks like I get 6 keys so maybe that is not enough?
Wow, this is going to be even a bigger learning curve than Dvorak which I already use daily...
Does anyone have a preferred system of shorthand? I've always wanted to learn shorthand because my thoughts sometimes escape me when I am writing. I haven't taken the step beyond choosing a shorthand system, so if anyone has a preference would you mind sharing?
If you are learning a language other than English, you might want to look into localized shorthand systems. I know that German has its own and that Pitman has been adapted to Spanish, but there are other alternatives.
Be advised, however, that learning shorthand can take a tremendous amount of time--at least to get "up to speed" at it. The system of strokes, hooks, and loops is not in and of itself difficult to master; it's the profusion of brief forms, detached endings, and so on that take a great deal of time to become fluent at. Having used Gregg every day for the past six months, I can say that I write and read with comfort, more or less--but I'm certainly not reading mine or others' shorthand at the speed at which I can read longhand. And I'm definitely not able to take dictation yet (not that I have need to), any more than I could do so typing on a QWERTY keyboard.
(As quick but hopefully instructive examples, the form "AL" can mean "I will," "allow," "ail," or "ale"; an attached "F" at the end of a form can mean "-ful", "-ify", or simply the sound "f"; there is nothing to distinguish the prefixes "es-" and "ex-" except by what follows them; "pend," "pent," "gend," and "gent" all look precisely the same; and so do "nt" and "nd," "det" and "ted," and "mem," "men," "min," "mim", and a handful of others.)
I've tried out Plover, and my experience with Gregg definitely made it more approachable than I think it would have been otherwise. One of the advantages it has over written shorthand, however, is that it is purely a writing, not a written, system. There is no need to learn to read it.
That said, I find shorthand a joy--and it is vastly more portable than a full QWERTY keyboard.
 http://gregg.angelfishy.net/ is a good compendium for English-language Gregg. The "Anniversary Edition" has the most texts. The "Simplified Edition" is a little more manageable in size, but is much more recent and still under copyright in most markets.
If I tried to use it for something somewhat non standard and had to start defining a lot of my own chords, I'd pretty quickly wonder if I was handicapping myself by making bad choices in defining things. Might be that I'd quickly realize it doesn't matter for whatever reason.
Looks really rad, either way.
The sheer amount of jargon that it thinks are misspellings and tries to fix is staggering. Dozens per day, at minimum.
I'm assuming all of those would require custom definition. I can't seem myself going through the hassle. And even if the job is done collectively, our department has less than 50 people in it (maybe 70 if you include the data center). It's not a big enough community for it to spread thin.
Steno seems like last century's solution to the problem, not this century's.
I wonder any of the Pycon 2013 participants try to learn plover and what their experiences were, perhaps they even read this topic on HN?
I'm already very proficient at dvorak typing (with the regular vim bindings), so I'm not sure if the 30% speed increase would justify taking 3 to 6 months of learning this, it'd be cool for substituting your speech with a text to speech engine, and with openeeg recognition one step closer to cyborghood. It's also nice to just have the skill to transcribe human speech real time and being able to apply for jobs in politics, justice or television. For example, here's an interview with the dutch transcriber in Dutch parliament:
I wonder if the steno chording could be optimized significantly by rearranging the keys and layout in a similar way as dvorak did with qwerty.
Perhaps T9/autoexpand with Linux can be just as fast, but it cannot be used blind, can it?
I mean being able to type 240 wpm would be some bragging rights, but how would it be useful?
Edit: On a more software-related topic, the interaction between Plover and a screen reader (assistive technology used by blind people) would be... interesting, particularly if the user is using text-to-speech output rather than a braille display. Plover simulates individual QWERTY keystrokes, and a screen reader often speaks in response to keystrokes. So to take the example of entering "Python", the screen reader would notice the backspaces produced by the second steno keystroke and would try to speak the backspaced characters, interrupting itself all along the way, before speaking the newly constructed word (assuming the user has word echo enabled). The response to the asterisk key would also be suboptimal. I don't know how best to solve that. On Windows, the best solution would probably be an add-on module for the open-source NVDA screen reader (http://www.nvaccess.org/), which is in Python.
Edit 2: I belatedly remembered the correct answer to the above problem for Windows. On Windows, Plover should be using the Text Services Framework as an alternative to simulating keystrokes, where the TSF is available, which includes Microsoft Word and standard edit controls. I guess I should implement that.
One (unrelated) part of the Q&A saddens me, the fallacy that an open source project cannot be commercially successful: https://www.youtube.com/watch?v=Wpv-Qb-dB6g#t=1200
From the title I must admit I was wondering if it was going to be something like NASA's actual thought-to-text project - http://www.nasa.gov/home/hqnews/2004/mar/HQ_04093_subvocal_s... - It would be really cool if someone could make an open source version of that in python.
Also since it's phonetic, I'd imagine it'd work great with Chinese in Pinyin mode.
Does anyone know if this project supports other dictionaries/layouts?