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.
I really enjoyed watching the talk and the demos. I think there's huge opportunity in a Kickstarter here, both for the gamification aspect as well as the hardware. If I could get a kit with hardware and training it could be compelling. I imagine a setup with both qwerty and steno co-existing, instead of trying to force steno to cover all text input. I think I want to use each for what it's best at.
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've started to see these fully split keyboards, and it makes me think, could people handle a keyboard which had two different home positions with two different keysets?
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.
I'm not trying to be negative in any way, because this is awesome. I really believe there are so many ways to interact with machines that we haven't figured out yet.
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[0] and neosnippet[1] for textmate compatible snippet completion.
It would be cool to see a video demonstrating this using the same snippet of code! If you decide to make one, let me know, and I'll link it on the Plover blog.
Fascinating talk, thank you. I was curious, I saw it mentioned that stenographers have their own styles around the edges of the language.
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.
I've thought about having a sort of collaborative dictionary, updated in realtime with entries weighted by how frequently people use them over a certain period of time. I'm not sure how practical it would actually turn out to be, but it's an interesting idea.
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.
Most people have no business using a pneumatic nail gun. No business at all. You won't hang pictures any faster, and your doghouse will probably look the same. Technically, everything done with a nail gun could be done with a hammer.
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.
Great analogy, but i'm not sure it's accurate. Any kind of abstraction (functions, interfaces, objects, macros, DSLs, frameworks) could be considered a pneumatic nail gun.
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++).
Amazing that Mirabai is able to think in terms of semantic words, most of which can be entered in a single keystroke. If you're a programmer and you don't want to watch the whole video, at least jump to 32:50 and to hear what Mirabai's brain is thinking while coding. Very intriguing.
As someone who has always been fascinated with alternative typing systems and shorthand, I took a look at Plover and Steno a couple of months ago. I bought myself an NKRO Keyboard - haven't turned it into a permanent STENO keyboard yet although I think that's the next step I should take if I want to be serious.
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.
My impression from reading about steno is that a lot of the complexity in steno systems comes from disambiguating similar-sounding words. Have you found this to be the case?
If so I'm thinking predictive techniques could help.
While predictive techniques can help, you really want something that is accurate 100% of the time so you don't have to keep an eye on your output. I'd rather memorize two different chords to get 100% correctness on the I or eye problem rather than 99% correctness on it with a predictive engine - the fact that you have to keep track of what you're typing to catch its mistakes really makes predictive techniques not so good for speed.
Yeah, one of the things I love about steno (as opposed to predictive systems like voice recognition or autocorrect) is its 100% determinism. That tiny pause of hesitation to wait and see whether a word has come out properly is so completely disruptive of flow for me. In the most recent video, I basically did the whole thing just keeping my eyes on the text I was transcribing from, rather than watching my output. You can see me correcting a few errors, but that's because my fingers told me that I'd made one, which prompted me to look over and figure out what I'd screwed up. Otherwise I could trust that whenever I hit a stroke, it translated as the exact same thing every time, so I never have to keep hovering over my text watching for errors. It makes the whole process way more pleasurable.
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?
The qwerty keyboard isn't going anywhere because of its prime advantage. It can be used when first encountered (albeit slowly) by someone who has never used one before.
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...
I'm in talks with a small NYC private school to possibly start some middle schoolers on an informal course in steno. We'll see if they take to it. I'm hoping it'll be like ducks to water. Stay tuned!
Very nice! She is a very good speaker. I want to add two things:
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 used Dvorak fulltime for about a decade and I'm much worse at qwerty than I used to be. I can get back up to speed, but it feels like reciting a poem I used to know and I can't actually think about what I'm doing.
I think it's about how often you switch keyboards. I switch between Windows and Mac keyboards daily (work/home) and now I rarely make a mistake when trying to use a shortcut. Same thing happened when I was learning russian keyboard layout, at first I wouldn't be able to switch despite knowing both layouts. Now I talk with two people simultanously, switching between russian and english (qwerty) every sentence
Here is my experience with Dvorak and AZERTY (the French variant of QWERTY). I learnt AZERTY as a kid, then learnt a French dvorak layout, and then learnt the US dvorak layout, which I now use.
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.
I'll second that on Dvorak. I have very little trouble moving back to QWERTY. I typically make a few mistakes only for the first 1 to 5 minutes after the switch, but other than that I can type in both layouts without even thinking about it.
Same. But if I am going to be at a computer for longer than a couple minutes, usually dvorak is in the keyboard layout options so I can just change it to that.
For anyone who has taken the time to learn Dvorak: From the point you began to learn it, how long did it take to become more proficient at Dvorak than QWERTY? How much more proficient do you consider yourself to be at typing as a result?
Took about a year to work most of the mistakes out. Lots of typos. An unimaginable amount of typos. I don't consider myself any more proficient. Typing dvorak is a bit different: I type word by word, instead of letter by letter. I still type on qwerty (who doesn't, at work?) but that feels more like stringing together an infinite sequence of letters. Dvorak tends to make words a bit easier to type in single fluid motions. So when I actually start typing fast in dvorak it gets crazy fast pretty quickly. Hence the typos.
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.
It took me a week to get to 70wpm or so. I can do 100+ sustained now with not much fatigue. I had been getting hand pains in qwerty, so I switched completely during a paper in high school and haven't looked back.
I can type nearly as fast in qwerty as I used to, but it is uncomfortable, awkward, and I do make errors often.
While cool and useful if you have to write a lot quickly, I don't think it is very helpful for programming - typing speed is just not the limiting factor except in some rare cases.
My feeling is that the "tax" of typing slows down the flow of new ideas in the same way round-trip latency places an upper limit on bandwidth. By this reasoning I switched to Colemak on a Kinesis keyboard about a year ago and have been happy with my choice despite the initial learning costs. Ergonomics and a stable home row position are worthwhile benefits. I would like to try Steno if it means I can spend less time typing or thinking about typing so I can spend more time building stuff.
@danbruc, to supplement and extend pgt's response:
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.
What does it typically look like? One hour thinking, five minutes typing? Yes, sometimes you have a sudden idea or insight and can't type it out as quickly as you want, but that is not the common case.
Yeah, people's strange fetish with programming really fast (e.g. "I use Vi because I can type faster in it, a mouse slows me down!") is completely out of touch with how I program professionally day to day.
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 Vi because I can type faster in it, a mouse slows me down!"
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.
I thought the same thing until I learned Vim. It's not about typing faster, it's about being able to make changes almost as fast as you think them up, and staying in flow instead of getting bored and frustrated.
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.
I thought people bought mechanical keyboards because they were easier on the fingers? The keys often require less activation and you can prevent the bottoming out you get with the cheap keyboards.
On the other hand you can say that coding is a complex task, so having any kind of barrier between you and your code is important.
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.
In my experience, there's much more to 'programming' than typing out new code. Where typing speed becomes an issue is in communicating with people, not machines: trying to have an IM conversation with a non-touch-typist is painful, and when you have emails or documentation to write, it's much more reasonable for typing speed to be the limiting factor.
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 :).
> ...when you have emails or documentation to write...
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.
yes, this is something I have been thinking about recently, coping with RSI. It's one thing I like about vim, is the semantic text entry concepts. "Change Word, Delete Inside 's. ", "Select inside this function", etc.
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.
That's an arse backwards way of trying to counter RSI. It is a series of physical problems that you should address in the physical world (i.e. adjust your damn environment). Rebinding your keyboard is like moving the deck chairs on the Titanic.
What kind of doctor? I think if you read what people have written on the Internet, it's not as simple as just going to a doctor. 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:
A friend of mine has significant wrist issues as a result and had to have surgery. They ignored the issues for a long time before it got to that point.
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>
My goal is to get more information than simply "go to a doctor". RSI is not well understood. Most doctors can't tell you more than "if it hurts then stop doing that". So, that tidbit doesn't go far. I've been to a doctor and didn't find it helpful. I've also been checked for carpel tunnel and I don't have it.
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.
Yep, I think that's a testament to the fact no one has good answers. You'll see this sort of stuff appearing in other blogs, along with testimonials. The one guy is from Princeton.
The speed of steno is mostly due to having a huge number of macros, which chorded keyboards let you have a lot of. You could have a bunch of one-stroke macros for full sentences, for instance. There's no way someone spelling out words one letter at a time is going to be able to keep up with someone who can type a one-stroke macro to type a long word or even a sentence.
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.
Something which was particularly striking to me about this presentation was how the steno input system seems very similar to the Korean alphabet and writing system, Hangul [1], a phonetic writing system in which each syllable is composed of a beginning consonant, a middle vowel, and an ending consonant. Steno seems to have a very, very steep learning curve, but Hangul has been around since the 15th century and is already used by over 50 million people. While the steno 'chords' seem to have as many as 5-6+ keys pressed at the same time, Hangul blocks are typically 2-3 characters. I've been learning Korean for about a month and though I only know a handful of words, I find the writing system easy to learn and use. While it doesn't allow for all combinations of consonants and vowel sounds that exist in western languages like English, with some modifications a hybrid writing/input system could be made which may not be as powerful as steno, but is easier to use and learn like Hangul, allows for all of the consonant and vowel sounds used by most languages, and gets you most of the efficiency gains of stenotype.
great! i read your keys per stroke statistics overview. does this mean the velotype is a superior system compared to plover as it appears to be just as fast, easier to learn and without dictionary dependency?
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.
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.
Weird. You're right; it doesn't work. Must have something to do with the layer Plover's using for keyboard output. That's frustrating. I'll bring it up with the developers.
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.
Typing source code with Plover is possible, but so far there have been lots of reports of unexpected whitespace. I think the ultimate test for plover is to beat something like the 23 minutes 28 seconds qwerty record on http://www.ioccc.org/2013/cable3/cable3.c with less keystrokes overall. IOCCC can be seen as an absolute worst case scenario for the sorts of code that might be encountered in day-to-day programming. So if a somewhat experienced Plover user can handle IOCCC without a problem, then programmers are in the clear.
I think its great that this might be used to help people with disabilities. It doesn't seem great for programmers. There have been very few times where the bottleneck in my productivity was how fast I can type text. I spend a lot more time thinking.
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 am not sure it would be a fair test. I type a lot faster on my phone with a predictive keyboard for normal day to day typing, but it wouldn't work very well with just semi random letters.
With my knuckles getting stiffer, this is a really attractive idea - I just wish there were more obvious ways to get the stick on keys (cannot seem to find the links)
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
Did you try the advice on the page? Hold WASD and try every other key. On my 2014 macbook pro, even WASD by itself fails, so I'd be surprised if the Air is any different.
My MacBook Air can do 6 keys, but not any 6. They have to be horizontally disbursed. In particular tight triangles are impossible (AWS, WSE, etc.) and cannot be pressed at the same time. A fun site to use to see this for yourself is http://benzguo.com/bayan/ .
I have a mid-2013 mba and it seems to work just fine for me. Just tried the hello world example! (It took me about 3 minutes to really get it under my fingers.)
Wow, this is going to be even a bigger learning curve than Dvorak which I already use daily...
You really need a minimum of 16-key rollover to do steno properly. Otherwise you're just really constrained in the number of chords you're able to write.
Each finger can press up to two keys at a time (top row, bottom row, or both rows together). Right pinky can press up to four at a time (two rows plus two columns), and right index can press up to three at a time (two rows plus asterisk column).
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?
I'm teaching myself Gregg shorthand. I tried (briefly) Pitman once, but the idea of discerning two characters only by their thickness never sounded too good to me (plus, it ruled out using a pen). The books for Gregg shorthand are now in the public domain, so you can download them for free, as they are hard to find. I'll probably print and bind my copy one of these days.
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.
Having tried Gregg and Pittman, I strongly prefer Gregg, in part because of the ease of finding instructional and reading material in the public domain, all the way to a complete transcription of Alice in Wonderland[1]. More importantly, though, is that Gregg is--in the terms used by the marketers of the system in the early 1900s--written and not drawn. It flows left-to-right at least as easily as the Latin alphabet, and can be adapted to suit whatever slant and curvature you typically write with in longhand. There was simply less of a barrier for entry as far as getting the shape down on paper for me.
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.
[1] 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.
Great talk! I am excited by the possibility of seeing Mirabai Knight launch a Kickstarter campaign for a steno keyboard for programmers and other users. Given the promise of typing 200 WPM comfortably I think many of us would pay a premium for a new device and training software.
I'm wondering about the user specific dictionaries and whether or not adoption would be aided by the communities trying to define sets of standard dictionaries that seem to be particularly efficient and effective at different tasks, like coding in brackets languages, or just general coding dictionaries.
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.
At work, in Lync (worst IM ever), email, and so forth, I just switched OSs and I'm getting alot of irritation from the spell checker.
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.
Ya, would be interesting to rethink it. Seems cool, but like the question about using it on your phone. Since steno you need two hands you can't use it on your phone (keyboards on your pockets? lol :) )
The Android app is actually pretty decent; you use it Swype-style, but rather than employing Swype's predictive method, it's 100% deterministic, so you know what you're going to get every time.
Ya. The way I pictured it working would be something like your vimrc file or whatever. People post those online all the time as a 'good' starting point. Then eventually you want to add your own and what not.
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:
http://www.intermediair.nl/carriere/een-baan-vinden/beroepen...
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?
http://code.google.com/p/autokey/https://github.com/shaaniqbal/T9-QWERTY/
I hear you, for a lot of writing I'm thinking more than typing. but it's useful for transcription, also communication as you usually communicate quite fluently and without too much thought, so I could benefit there.
And for those of us that regularly type in more than one language, it seems like we would need to learn one typing system per language， rather than using a common system (qwerty) for all languages that use the Latin alphabet. This appears to be a big drawback of steno.
It occurs to me that blind people who are proficient at writing braille would likely be able to learn steno with relative ease, because they're already used to routinely pressing several keys in one stroke (up to 8 at a time in 8-dot computer braille). Also, braille has several contractions, including dot combinations that don't map to single letters but to common two-letter sequences like 'th' and 'st'. Steno, being syllabic, requires fewer keystrokes per word than braille, but at least proficient braille users would already have the dexterity and some of the concepts.
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.
I had the same thought. For reference, an initiative to assemble companies who reject that and other similar myths is undergoing at http://opencompany.org
This is very cool, I've been thinking for a while of learning chorded keyboards, and this stops me having to spend a fortune to do so.
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.
The really great idea is the portable low cost steno keyboard, maybe backed by a Raspberry Pi. Just plug it in and you'd get your own customised input system with all your personal configurations and dictionaries and what not.
Also since it's phonetic, I'd imagine it'd work great with Chinese in Pinyin mode.
http://youtu.be/jRFKZGWrmrM
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