Sunday, December 19, 2010
Plover Speaks!
I finally uploaded a video of what Plover looks like when plugged into a text-to-speech engine. If you remember, the first part of my What Is Steno Good For series was called How to Speak with Your Fingers, and was about how steno can be used as a conversational tool for people who don't use their voices to speak. Plover's now at a point where that's not only possible, but ludicrously easy. All I did was to launch Plover, open a terminal window in Ubuntu, type eSpeak, press enter, and start writing. Whenever I wanted to send a line, I pressed R-R on my steno machine, which my steno dictionary has defined as "press return". That's all there was to it.
Recently, I was quite moved by Roger Ebert's blog post Trying to Get a Word in Edgewise, about the frustration he's experienced since he lost the use of his voice, and by my friend (and early Plover supporter) Mel's response to it. I was already in the middle of planning this video before the blog post went up, but after it was posted, one of Mr. Ebert's fans randomly came upon Plover and recommended it to him. The next morning I was thrilled to discover that Mr. Ebert had actually commented on the relevant article. I panicked a bit, because I didn't yet have anything to show him and no time to make the video until the weekend. Now it's finally up, though, and I can prove that Plover isn't just a pipe dream; it actually works. I know that Mr. Ebert uses a Mac, and that Plover is currently only working on Linux, but cross-platform support is high on our to-do list. I think this video speaks for me better than any blog post ever could, so I'll just leave it there.
(One more minor thing: YouTube lists the running time at 5 minutes, but the actual video is only about 2 minutes long. No idea why those extra three minutes of frozen screen were tacked on there, but just ignore them.)
Sunday, December 5, 2010
Plover 2.1 is Live!
Download Plover 2.1 here.
Incredibly exciting news! The new version of Plover has been released, and it now supports command strokes. This means you can use your steno machine to do anything you can do from your qwerty keyboard -- alt-tab, navigation, formatting, you name it. I'm going to try to make a screencast this week showing me using Plover with Vim, which has been a dream of mine since I first started thinking about Plover. Unfortunately Vim commands don't currently work with the SideWinder X4 (though we'll hopefully be fixing that soon), but the Gemini PR version works flawlessly with every program I could think to throw at it. The SideWinder should work fine with most other programs; it only has trouble with one-key alphanumeric command strokes. Next on the development list: Adding and editing dictionary definitions from the steno machine while using Plover.
Many thanks as always to Josh, our dauntless programmer. I've also updated the Donate button both here on the blog and on the FAQ page. For some reason it stopped working, but it's fixed now. Sorry for anyone who tried to donate and wasn't able to. If you'd like to give it another try, it shouldn't give you any more trouble. Please feel free to send questions, comments, bug reports, and feature requests to plover@stenoknight.com. I'm also hard at work on the next installment of Steno 101, so this blog should be seeing quite a bit more activity than it did over November, which was mostly consumed by NatCapVidMo.
I can hardly believe that my desire for a free, open source steno keyboard emulator that works on affordable hardware has actually come true. There's more to come, but this is a huge milestone, and I'm completely ecstatic.
Incredibly exciting news! The new version of Plover has been released, and it now supports command strokes. This means you can use your steno machine to do anything you can do from your qwerty keyboard -- alt-tab, navigation, formatting, you name it. I'm going to try to make a screencast this week showing me using Plover with Vim, which has been a dream of mine since I first started thinking about Plover. Unfortunately Vim commands don't currently work with the SideWinder X4 (though we'll hopefully be fixing that soon), but the Gemini PR version works flawlessly with every program I could think to throw at it. The SideWinder should work fine with most other programs; it only has trouble with one-key alphanumeric command strokes. Next on the development list: Adding and editing dictionary definitions from the steno machine while using Plover.
Many thanks as always to Josh, our dauntless programmer. I've also updated the Donate button both here on the blog and on the FAQ page. For some reason it stopped working, but it's fixed now. Sorry for anyone who tried to donate and wasn't able to. If you'd like to give it another try, it shouldn't give you any more trouble. Please feel free to send questions, comments, bug reports, and feature requests to plover@stenoknight.com. I'm also hard at work on the next installment of Steno 101, so this blog should be seeing quite a bit more activity than it did over November, which was mostly consumed by NatCapVidMo.
I can hardly believe that my desire for a free, open source steno keyboard emulator that works on affordable hardware has actually come true. There's more to come, but this is a huge milestone, and I'm completely ecstatic.
Monday, October 18, 2010
New experimental version with improved GUI
Good news from Joshua, Plover's programmer. The newest update from the experimental series of Plover has been released. He says:
"The latest experimental release of Plover (version 2.0.0.4) includes a graphical user interface for viewing and editing all Plover configuration parameters. This will hopefully make Plover configuration much easier and less error prone. Aside from the known-to-be-buggy support for the Gemini TX stenotype, everything in this experimental release should work as advertised. If it doesn't, please let me know or, better yet, file a bug report directly in Launchpad."
Download it here.
"The latest experimental release of Plover (version 2.0.0.4) includes a graphical user interface for viewing and editing all Plover configuration parameters. This will hopefully make Plover configuration much easier and less error prone. Aside from the known-to-be-buggy support for the Gemini TX stenotype, everything in this experimental release should work as advertised. If it doesn't, please let me know or, better yet, file a bug report directly in Launchpad."
Download it here.
New logo!
The logo I commissioned for Plover is done! Steno mavens will please note the eponymous feather pattern on the left wing. Logo design by Laura Lake, freelance illustrator. Font is ButterBrotPapier by Anke Art.
Now, I know it's generally traditional to name little animal logos that represent FLOSS projects. I'm not sure what, though. I was thinking of holding a competition for the longest (in terms of letters and/or syllables) common name that can be reasonably represented in one stroke on the steno keyboard. So something like KHREUFRD for Clifford or KHRAEURPBS for Clarence will do, but your invented SKWRO*EPBT brief for Jonathan doesn't count. Or we could leave the little guy nameless; I'm not particular. The main thing is we've got a logo. Now to print up some business cards for the next hacker/steno/accessibility conference I go to...
Friday, October 15, 2010
Qwerty to Steno Key Map
File this one under painfully obvious. In all the excitement of the Plover release, I had forgotten that the actual description of the qwerty-to-steno layout that Plover uses was buried way back in the archives, and that new people trying to figure out how to position their fingers would most likely be totally lost. Sorry about that! By way of apology, I whipped up a new image that should be a little more helpful, and after I finish posting this I'm going to put it on the Plover FAQ Page as well.
The dark blue letters correspond to the letters of the qwerty keyboard. The light blue letters correspond to the letters on the steno keyboard that they produce when Plover is connected. Basically you move your hands half an inch up so that your left thumb is resting between the C and V keys and your right thumb is resting between the N and M keys. The rest should fall into place. a good test sentence to write when you first start up Plover (not least because even keyboards without n-key rollover often type it correctly) is:
AV A WR DVL RU
in qwerty, which corresponds to
SO S TH WOG HF
in steno, which translates to
So is this working?
in English. Now that you know where to put your fingers, try it out and let me know how it goes!
The dark blue letters correspond to the letters of the qwerty keyboard. The light blue letters correspond to the letters on the steno keyboard that they produce when Plover is connected. Basically you move your hands half an inch up so that your left thumb is resting between the C and V keys and your right thumb is resting between the N and M keys. The rest should fall into place. a good test sentence to write when you first start up Plover (not least because even keyboards without n-key rollover often type it correctly) is:
AV A WR DVL RU
in qwerty, which corresponds to
SO S TH WOG HF
in steno, which translates to
So is this working?
in English. Now that you know where to put your fingers, try it out and let me know how it goes!
Wednesday, October 13, 2010
Blog Interview and TX Support
Two exciting things today. First of all, over at Plover's Launchpad Site there's now a User Guide and experimental support for the Gemini TX Protocol. We're still looking for testing with that one, so if you have a TX machine, give it a shot.
Also, there's an interview on Plover at the Geek Feminism Blog, where I talk about some of my reasons for kicking off the project and some things I hope for Plover's future.
There's been a huge amount of excitement since the Plover 2.0 release, and there's also a hackathon scheduled this Saturday, both onsite in Toronto at HackLabTO and online via IRC on the #plover freenode channel. Thanks to everyone (especially to Josh, Plover's tireless coder, for writing the manual and releasing new code daily and to Leigh Honeywell, who's behind both the Geek Feminism interview and the hackathon) for your enthusiasm, linkage, and donations. Plover is picking up steam, and it can only get better from here.
Also, there's an interview on Plover at the Geek Feminism Blog, where I talk about some of my reasons for kicking off the project and some things I hope for Plover's future.
There's been a huge amount of excitement since the Plover 2.0 release, and there's also a hackathon scheduled this Saturday, both onsite in Toronto at HackLabTO and online via IRC on the #plover freenode channel. Thanks to everyone (especially to Josh, Plover's tireless coder, for writing the manual and releasing new code daily and to Leigh Honeywell, who's behind both the Geek Feminism interview and the hackathon) for your enthusiasm, linkage, and donations. Plover is picking up steam, and it can only get better from here.
Thursday, October 7, 2010
Plover 2.0 Is Released!
Yes, kids, the moment you've all been waiting for...
Download Plover 2.0 Here!
You might also want to visit the new Plover landing page:
http://stenoknight.com/plover/
It answers some common questions about the project and the new release, and also features this video showing me using Plover to demolish the competition in an online typing game called TypeRacer.
This video was made using the Gemini PR option. I'll probably make another one with the SideWinder later, showing all the other amazing things Plover can do. You can blog with it, chat with it, write a novel -- you name it! In future releases, we'll also implement the ability to control every aspect of your computer using steno, plus superior dictionary management and support for additional steno protocols. But for now, bask in the glory that is a fully functional and completely free high speed stenographic text entry system. Remember, if you have Windows but not Linux, you can give yourself a stress-free dual boot option in less than 20 minutes using Wubi. Then just extract the .gz file to your chosen directory and follow the two-line installation instructions in the README. Feel free to email me at plover@stenoknight.com if you need any guidance or if you have comments, bugs, or feature requests. A million thanks to Joshua Harlan Lifton, Plover's programmer, for devoting so much time and passion to the project in the past month. And please spread the word. I think Plover has the potential to transform the way people input text and interact with their computers, but the first priority is to make everyone aware of its existence. Now go, play around with it, and see what happens when you triple your speed and quarter your effort.
Download Plover 2.0 Here!
You might also want to visit the new Plover landing page:
http://stenoknight.com/plover/
It answers some common questions about the project and the new release, and also features this video showing me using Plover to demolish the competition in an online typing game called TypeRacer.
This video was made using the Gemini PR option. I'll probably make another one with the SideWinder later, showing all the other amazing things Plover can do. You can blog with it, chat with it, write a novel -- you name it! In future releases, we'll also implement the ability to control every aspect of your computer using steno, plus superior dictionary management and support for additional steno protocols. But for now, bask in the glory that is a fully functional and completely free high speed stenographic text entry system. Remember, if you have Windows but not Linux, you can give yourself a stress-free dual boot option in less than 20 minutes using Wubi. Then just extract the .gz file to your chosen directory and follow the two-line installation instructions in the README. Feel free to email me at plover@stenoknight.com if you need any guidance or if you have comments, bugs, or feature requests. A million thanks to Joshua Harlan Lifton, Plover's programmer, for devoting so much time and passion to the project in the past month. And please spread the word. I think Plover has the potential to transform the way people input text and interact with their computers, but the first priority is to make everyone aware of its existence. Now go, play around with it, and see what happens when you triple your speed and quarter your effort.
Thursday, September 30, 2010
Calm Before the Storm
Just so none of you are alarmed, I've temporarily switched Plover's Github repository to private, at the request of Josh, the programmer. He's putting the finishing touches on the big release version and doesn't want old messy code lying around all over the internet. I've tested the version he's currently polishing, and it's absolutely glorious. Installation is dead easy, the interface is simple and intuitive, and the actual translation (now with formatting and orthographic suffix rules!) is like butter. Like butter, I tell you. You're gonna love it. He says it'll probably be about a week before the big reveal, so I hope you can all hold out 'til then. If I get a chance, I'll try to put together that screencast I've been promising. It's gonna knock your stenoloving socks off.
Tuesday, September 21, 2010
Plover takes control
So Josh, the person responsible for 99% of Plover's code, came by my coworking space today and showed me the newest version of Plover. It's wonderful beyond description. The dream I had when I first came up with the concept and started this blog back in 2008 is finally realized: Plover now writes instant English translations from a steno machine or SideWinder to the active window. Yes, we have achieved keyboard emulation. It blew my mind to see it, and I did a jig of giddy glee.
Now, for the time being this only works on Ubuntu. Windows development, when it comes, will be a fair distance down the road (possibly after development for Android, though we're still thinking about how best to work out that one.) Still, with Wubi available, there's no reason that anyone with a Windows machine can't install Ubuntu as a dual boot option on their system in about 20 minutes, without affecting their existing configuration at all. It's remarkably seamless. There are also a few other kinks to work out before I upload the new code to the Github. We discovered a bug or two today, so Josh is going to tackle them over the next few weeks and hopefully after some testing we'll have a good stable release to show you. Then there's the polishing that needs to be done, adding some linguistic and orthographic rules, and putting all the formatting syntax back under the hood where it belongs. But this is a huge step, and I'm thrilled to bits. In the next day or two I might try to do a sneak preview video to show you guys, if I can get a screencast put together. But for now, you're gonna have to take my word for it. It works! It works! Yeehaw!
Now, for the time being this only works on Ubuntu. Windows development, when it comes, will be a fair distance down the road (possibly after development for Android, though we're still thinking about how best to work out that one.) Still, with Wubi available, there's no reason that anyone with a Windows machine can't install Ubuntu as a dual boot option on their system in about 20 minutes, without affecting their existing configuration at all. It's remarkably seamless. There are also a few other kinks to work out before I upload the new code to the Github. We discovered a bug or two today, so Josh is going to tackle them over the next few weeks and hopefully after some testing we'll have a good stable release to show you. Then there's the polishing that needs to be done, adding some linguistic and orthographic rules, and putting all the formatting syntax back under the hood where it belongs. But this is a huge step, and I'm thrilled to bits. In the next day or two I might try to do a sneak preview video to show you guys, if I can get a screencast put together. But for now, you're gonna have to take my word for it. It works! It works! Yeehaw!
Saturday, September 4, 2010
New readme file!
So the illustrious Stan, longtime Plover user and supporter, has turned the ugly-as-sin Github readme file into a gorgeously formatted PDF. He also assigned it a version number, which I'd been extremely neglectful in not attending to up 'til now. Behold!
Plover Readme 1.3
Thanks, Stan! You're the best. Hopefully in the not too distant future we'll be writing a whole new extensive readme to incorporate the keyboard emulation features that Josh, Plover's lead programmer, is currently working on.
Edited to add Stan's reply in the comments, just because it's too good to be overlooked by people who might not click through:
Well, it ain't open source for no'n ;).
I definitely had fun doing it -- even though it distracted me from actually practicing steno along with the fact that I stayed up until nearly five in the morning to do it. But I figured this would be easier than the old readme file which I for some reason I had a hard time following (maybe I was the dummy toward which the dummy series are directed).
But I'm glad I could contribute. I hope the version number makes sense. My reasoning was as follows:
1.0 - Plover that worked in command line.
1.1 - Plover that opened the small window (for which you made the 'it really works!' video)
1.2 - Addition of Eclipse and DC dictionary support
1.3 - Current one with the text output and GUI.
On a final note, I want to let everyone know that everything in that readme is subject to change and revision. I threw that logo together because it was the first idea that popped in my mind but again, I can design something a lot sleeker if I spend a little more time thinking about it. But I do love the designs from the design prototypes post so I will do my best to try to somehow integrate them if I decide to change it up.
And of course with any major changes with Plover will hopefully be documented in the readme.
I'll put up a url for the original InDesign file once I get my FTP server working again (home ISP services tend to look down on mass file sharing I have found) to uphold the opensource spirit.
Go Plover and opensource software! I'm pretty much done shoveling through my backpack for the hardware key every time I have to open CaseCATalyst or having to spend $5k on Eclipse once I go pro. Many people at my school and around Seattle have even expressed interest in learning steno after observing me practice at coffee shops or libraries. They say, "How is it that you're 'typing' THAT fast?" Or, "My fingers and wrists would kill me if I even attempted half of that pace on a regular keyboard." Then I begin to explain how it works, show them my theory notes, and tell them that I was doing a 200wpm drill and they become captivated further. Once I tell them how much machines and software cost however...
Makes me wonder how many people we could get to at least give steno a chance if the equipment were more accessible.
Steno machines and software are really not complicated things. It's only because of its esotericism that companies are able to reap in as much as they do and bully their users around with excessive and cumbersome anti-piracy measures for technology far exceeded in complexity by things as common as the iPhone or a netbook PC.
With everyone's small contribution I think Plover's really got a chance to rise up to become an equal competitor along side DC, Eclipse, CaseCAT, etc.
Linux did. It even runs on mobile phones. Who's to say we can't steno on an iPad or on a tablet PC?
Plover Readme 1.3
Thanks, Stan! You're the best. Hopefully in the not too distant future we'll be writing a whole new extensive readme to incorporate the keyboard emulation features that Josh, Plover's lead programmer, is currently working on.
Edited to add Stan's reply in the comments, just because it's too good to be overlooked by people who might not click through:
Well, it ain't open source for no'n ;).
I definitely had fun doing it -- even though it distracted me from actually practicing steno along with the fact that I stayed up until nearly five in the morning to do it. But I figured this would be easier than the old readme file which I for some reason I had a hard time following (maybe I was the dummy toward which the dummy series are directed).
But I'm glad I could contribute. I hope the version number makes sense. My reasoning was as follows:
1.0 - Plover that worked in command line.
1.1 - Plover that opened the small window (for which you made the 'it really works!' video)
1.2 - Addition of Eclipse and DC dictionary support
1.3 - Current one with the text output and GUI.
On a final note, I want to let everyone know that everything in that readme is subject to change and revision. I threw that logo together because it was the first idea that popped in my mind but again, I can design something a lot sleeker if I spend a little more time thinking about it. But I do love the designs from the design prototypes post so I will do my best to try to somehow integrate them if I decide to change it up.
And of course with any major changes with Plover will hopefully be documented in the readme.
I'll put up a url for the original InDesign file once I get my FTP server working again (home ISP services tend to look down on mass file sharing I have found) to uphold the opensource spirit.
Go Plover and opensource software! I'm pretty much done shoveling through my backpack for the hardware key every time I have to open CaseCATalyst or having to spend $5k on Eclipse once I go pro. Many people at my school and around Seattle have even expressed interest in learning steno after observing me practice at coffee shops or libraries. They say, "How is it that you're 'typing' THAT fast?" Or, "My fingers and wrists would kill me if I even attempted half of that pace on a regular keyboard." Then I begin to explain how it works, show them my theory notes, and tell them that I was doing a 200wpm drill and they become captivated further. Once I tell them how much machines and software cost however...
Makes me wonder how many people we could get to at least give steno a chance if the equipment were more accessible.
Steno machines and software are really not complicated things. It's only because of its esotericism that companies are able to reap in as much as they do and bully their users around with excessive and cumbersome anti-piracy measures for technology far exceeded in complexity by things as common as the iPhone or a netbook PC.
With everyone's small contribution I think Plover's really got a chance to rise up to become an equal competitor along side DC, Eclipse, CaseCAT, etc.
Linux did. It even runs on mobile phones. Who's to say we can't steno on an iPad or on a tablet PC?
Monday, August 30, 2010
Steno 101, Lesson Two
Steno 101: How to Do It
Steno 101: Lesson Zero
Steno 101: Lesson One
Steno 101: Lesson Two
Steno 101: Lesson Three
Steno 101: Lesson Four
It's been a while since the last installment, but here without further ado is Steno 101, Lesson Two. Now is probably a good time to review Lesson Zero and Lesson One.
Before we get started, I have to address an issue I inexcusably neglected in the previous two segments. If you look at the steno keyboard, you'll notice that the left hand side has four columns of keys before it hits the asterisk, but the right hand side has five columns after the asterisk.
So unless you're Count Rugen from the Princess Bride, you might be wondering how you're supposed to handle that extra column of keys. The answer is that the right hand pinky finger operates both of the two rightmost columns, even though it rests on the left TS column rather than the right DZ column when it's not in use. I prefer to use steno machines with wide keys that let me hit all four keys with one pinky, if I want to, but different stenographers have different preferences. The main thing to remember is that the pointer fingers should always be on the columns adjacent to the asterisks, and the rest of the fingers should follow naturally from there. I've recently started tutoring a beginner in steno, and her fingers kept wanting to drift over to the right, which meant that she had to either stretch or shift her hand left whenever she wanted to press the FR keys, which is really inefficient, considering how often "FR" is used in steno, versus "DZ".
So you've learned S, T, P, and R on both sides of the keyboard, and you've memorized all the various vowel combinations and diphthongs you can get out of the four vowel keys, A, O, E, and U. What's left? First, the other consonants just represented by individual keys:
You can see there are more on the right hand than on the left, but they should all be pretty easy to remember, since they're just straight-up letters rather than chords. The tricky part comes in here:
These are all the letters represented by chords. This time there are more on the left hand side than on the right. In fact, in most steno theories, including mine, only the left hand side has a complete alphabet, and it's the only side used to spell words out letter by letter when they aren't defined strokewise in the steno dictionary.
All this is a lot to memorize, but I hope that breaking it down in this way will make the process easier. Feel free to print out these charts and have them on hand for reference. You might first try memorizing the individual keys on both sides, then try to memorize the complete alphabet on the left hand side incorporating both chords and individual keys, and finally incorporating the four chords on the right hand side. Then try putting the letter keys and letter chords together with the vowel chart from the previous lesson. Once you've got all that under your belt, you'll be able to write almost any English word phonetically, and you'll be able to use the left-hand spelling alphabet (which I write using the letter or chord plus the asterisk key for lowercase letters; I'll get to uppercase letters and other alphabets in subsequent lessons) to spell out words that aren't in the dictionary. Next lesson we'll learn what to do when a word isn't possible to write strictly phonetically, then work on a few principles for briefing prefixes, suffixes, and other common word components.
Steno 101: Lesson Zero
Steno 101: Lesson One
Steno 101: Lesson Two
Steno 101: Lesson Three
Steno 101: Lesson Four
It's been a while since the last installment, but here without further ado is Steno 101, Lesson Two. Now is probably a good time to review Lesson Zero and Lesson One.
Before we get started, I have to address an issue I inexcusably neglected in the previous two segments. If you look at the steno keyboard, you'll notice that the left hand side has four columns of keys before it hits the asterisk, but the right hand side has five columns after the asterisk.
So unless you're Count Rugen from the Princess Bride, you might be wondering how you're supposed to handle that extra column of keys. The answer is that the right hand pinky finger operates both of the two rightmost columns, even though it rests on the left TS column rather than the right DZ column when it's not in use. I prefer to use steno machines with wide keys that let me hit all four keys with one pinky, if I want to, but different stenographers have different preferences. The main thing to remember is that the pointer fingers should always be on the columns adjacent to the asterisks, and the rest of the fingers should follow naturally from there. I've recently started tutoring a beginner in steno, and her fingers kept wanting to drift over to the right, which meant that she had to either stretch or shift her hand left whenever she wanted to press the FR keys, which is really inefficient, considering how often "FR" is used in steno, versus "DZ".
So you've learned S, T, P, and R on both sides of the keyboard, and you've memorized all the various vowel combinations and diphthongs you can get out of the four vowel keys, A, O, E, and U. What's left? First, the other consonants just represented by individual keys:
You can see there are more on the right hand than on the left, but they should all be pretty easy to remember, since they're just straight-up letters rather than chords. The tricky part comes in here:
These are all the letters represented by chords. This time there are more on the left hand side than on the right. In fact, in most steno theories, including mine, only the left hand side has a complete alphabet, and it's the only side used to spell words out letter by letter when they aren't defined strokewise in the steno dictionary.
All this is a lot to memorize, but I hope that breaking it down in this way will make the process easier. Feel free to print out these charts and have them on hand for reference. You might first try memorizing the individual keys on both sides, then try to memorize the complete alphabet on the left hand side incorporating both chords and individual keys, and finally incorporating the four chords on the right hand side. Then try putting the letter keys and letter chords together with the vowel chart from the previous lesson. Once you've got all that under your belt, you'll be able to write almost any English word phonetically, and you'll be able to use the left-hand spelling alphabet (which I write using the letter or chord plus the asterisk key for lowercase letters; I'll get to uppercase letters and other alphabets in subsequent lessons) to spell out words that aren't in the dictionary. Next lesson we'll learn what to do when a word isn't possible to write strictly phonetically, then work on a few principles for briefing prefixes, suffixes, and other common word components.
Wednesday, August 18, 2010
Funding
So I just had a good session with my Python tutor, and it seems that Plover has reached a turning point. The essential steno-to-English structure of the program is working well. The next biggest priority is getting it to work as a keyboard emulator, and it looks like the most efficient and robust way to do that is to plug Plover into a program with flexible, relatively low-level control over the OS: namely, Autokey in Linux and AutoHotKey in Windows. We're starting with Autokey first, because it's written in Python (AutoHotKey is written in C++, though fortunately it's also open source) and my Python tutor runs Ubuntu, so it's the most convenient one to try first. We dug through the program a bit today, and it looks like it's going to involve a fair amount of intricate rerouting and testing and kludging. The other issue is that Plover is written in Python 3 and Autokey is written in Python 2.6, so we'll have to negotiate how to work that in as well. What it comes down to is that an hour a week or every other week is not going to be enough to get this moving along in the near future. Plover development so far has been funded entirely out of my pocket, to the tune of nearly $2,000 so far. I can only afford to pay about $300 a month, which has been keeping development at a relative snail's pace. My tutor is excited about the project and would like to put more time into it, but he's got a business to run just like I do, and can't afford to work at a loss. It looks like our options are:
* Keep developing Plover at the same rate we've been moving, about three hours per month.
* Find more funding from an external source, either from individual donations, a FLOSS grant, or some kind of seed money from a person or organization interested in contributing to the project. The trouble there is that Plover is not something that can be monetized directly. The whole point is that it's free for anyone to download and/or modify. Donations might help a little, but its user base is currently pretty small, and not likely to get much bigger until it's capable of being used as a fully functioning keyboard emulator.
* Figure out a way to make money in ways adjacent to Plover.
- My Python tutor is also a hardware hacker, so he's interested in trying to put together some kind of wearable steno keyboard with Plover built in, so it can just be plugged into a computer and work without any software configuration or Autokey-style workarounds. The only way that can be profitable is if it's sufficiently cheap to make and there's sufficient demand from wearable geeks willing to pay $100 - $200 to triple their typing speed. Whether either of those conditions are possible is difficult to calculate.
- Alternately, we could work on making a standalone AAC device, using Plover and Open Source Text-to-Speech Software. The advantage there is that AAC devices are often funded by health insurance or governmental agencies, and can cost thousands of dollars for non-realtime speech synthesis. If we could act as a vendor to people with good fine motor control but the inability to speak, as outlined in my How To Speak With Your Fingers article, there might well be a bigger pool of money available and more motivated users willing to pay for and learn how to use such a thing.
- On the other hand, I could try to make money on the pedagogical side of things, offering Plover and the Steno 101 series (next installment coming soon!) for free, but charging for personal steno tutoring or classes or something of that sort, either remotely or online. I'm certainly willing to put in the time, but I wonder how easy it will be to find people who want to take steno classes on software that's still in development, and how much they'll be willing to pay for the privilege.
- The third way to pay for development would be to keep funding Plover out of my own pocket up until the point that it hits keyboard emulation, then try to build it into a video game hosted on the web. If that takes off, we can fund development via ads and donation requests on the website. (A Tetris/Guitar Hero hybrid has been proposed, and its skeleton is already sketched out here, just waiting for code and graphics to bring it to life) Again, lots of uncertainty, but I feel like the video game route is both the best way to learn steno and the best way to bring it to the attention of the general public. If we could get it working on a mobile/wearable system, all the better. But we can't even start on the video game until Plover is emulating qwerty output, and that's looking to be a considerable distance away.
* And, of course, I want to improve my own Python skills so that I can start contributing code rather than just money, enthusiasm, and steno expertise to the project. That's easier said than done, but I'm going to try to keep making headway in that direction. Currently Plover isn't in the best shape for collaboration, but it's definitely a future priority to structure and document it so that people can contribute code as well as or instead of money to help get it off the ground.
Any thoughts and suggestions are very welcome. As long as I have money to spare, Plover development will continue to go forward. For now, I think I'm going to keep spending that $300 a month; I'm going to work on making a dedicated Plover page with a FAQ, donation button, and links to relevant posts from the blog; I'm going to do a bit of outreach in the mobile/wearable and open source communities to see if I can figure out a hypothetical price for functioning plug-and-play steno hardware; and I'm going to keep blogging the Steno 101 series so that anyone who wants to teach themselves steno can do so, using the current not-quite-a-word-processor version of Plover. It's definitely a start, and we'll just have to see where it goes.
* Keep developing Plover at the same rate we've been moving, about three hours per month.
* Find more funding from an external source, either from individual donations, a FLOSS grant, or some kind of seed money from a person or organization interested in contributing to the project. The trouble there is that Plover is not something that can be monetized directly. The whole point is that it's free for anyone to download and/or modify. Donations might help a little, but its user base is currently pretty small, and not likely to get much bigger until it's capable of being used as a fully functioning keyboard emulator.
* Figure out a way to make money in ways adjacent to Plover.
- My Python tutor is also a hardware hacker, so he's interested in trying to put together some kind of wearable steno keyboard with Plover built in, so it can just be plugged into a computer and work without any software configuration or Autokey-style workarounds. The only way that can be profitable is if it's sufficiently cheap to make and there's sufficient demand from wearable geeks willing to pay $100 - $200 to triple their typing speed. Whether either of those conditions are possible is difficult to calculate.
- Alternately, we could work on making a standalone AAC device, using Plover and Open Source Text-to-Speech Software. The advantage there is that AAC devices are often funded by health insurance or governmental agencies, and can cost thousands of dollars for non-realtime speech synthesis. If we could act as a vendor to people with good fine motor control but the inability to speak, as outlined in my How To Speak With Your Fingers article, there might well be a bigger pool of money available and more motivated users willing to pay for and learn how to use such a thing.
- On the other hand, I could try to make money on the pedagogical side of things, offering Plover and the Steno 101 series (next installment coming soon!) for free, but charging for personal steno tutoring or classes or something of that sort, either remotely or online. I'm certainly willing to put in the time, but I wonder how easy it will be to find people who want to take steno classes on software that's still in development, and how much they'll be willing to pay for the privilege.
- The third way to pay for development would be to keep funding Plover out of my own pocket up until the point that it hits keyboard emulation, then try to build it into a video game hosted on the web. If that takes off, we can fund development via ads and donation requests on the website. (A Tetris/Guitar Hero hybrid has been proposed, and its skeleton is already sketched out here, just waiting for code and graphics to bring it to life) Again, lots of uncertainty, but I feel like the video game route is both the best way to learn steno and the best way to bring it to the attention of the general public. If we could get it working on a mobile/wearable system, all the better. But we can't even start on the video game until Plover is emulating qwerty output, and that's looking to be a considerable distance away.
* And, of course, I want to improve my own Python skills so that I can start contributing code rather than just money, enthusiasm, and steno expertise to the project. That's easier said than done, but I'm going to try to keep making headway in that direction. Currently Plover isn't in the best shape for collaboration, but it's definitely a future priority to structure and document it so that people can contribute code as well as or instead of money to help get it off the ground.
Any thoughts and suggestions are very welcome. As long as I have money to spare, Plover development will continue to go forward. For now, I think I'm going to keep spending that $300 a month; I'm going to work on making a dedicated Plover page with a FAQ, donation button, and links to relevant posts from the blog; I'm going to do a bit of outreach in the mobile/wearable and open source communities to see if I can figure out a hypothetical price for functioning plug-and-play steno hardware; and I'm going to keep blogging the Steno 101 series so that anyone who wants to teach themselves steno can do so, using the current not-quite-a-word-processor version of Plover. It's definitely a start, and we'll just have to see where it goes.
Monday, August 16, 2010
Update
I gave my first beginning steno lesson to the auction winner last week, using a new SideWinder and the latest version of Plover. She did remarkably well, for only an hour worth of steno training! I taught her how to write "the stoat sat at the top step" (old steno school habits die hard) and gave her some exercises on memorizing the vowels and diphthongs with S, T, P, and R. Hopefully this week we'll move on to some of the other consonants, and she'll be off and running. I'm also supposed to be having another Python lesson tomorrow, in which we're hoping to get qwerty emulation operational in the Linux version of Plover using Autokey. I'll keep y'all posted.
Thursday, August 5, 2010
StenoKnight Blog?
Lately I feel like I'm bubbling over with things to say about my business, StenoKnight CART Services. I get some of my thoughts out on Twitter, but the character restriction is starting to feel really limiting. I have an articles page, which contains both things that I wrote for the Plover Blog and things that I wrote on various other forums over the last few years. But I kind of want to have a space for blog posts on my daily CART work, freelancing, promoting a business, time management, Deaf/HoH issues, and all that sort of thing. The Plover blog doesn't seem to be an appropriate place for it, so I'm toying with the idea of creating a StenoKnight-specific Blog. But, on the other hand, I've had the StenoKnight Facebook page for a while now and it's been largely neglected. Maybe that's just because I don't really enjoy the Facebook interface, but I'm worried that starting another blog will quickly feel like a burden and dilute my professional web presence even more. So maybe I should just write the things I want to write offline, polish them up, and post them on my articles page rather than having a dedicated top-of-the-head blogging space. I don't know. I know this isn't Plover-related, but since a fair number of this blog's readers are aspiring court reporters or CART providers, I guess I'm wondering which you guys would rather read: Polished articles on various topics that are published pretty infrequently on my website, or a new space for less carefully edited but more frequent posts on running a CART business in New York City?
Monday, August 2, 2010
Steno Versus Qwerty Versus Automatic SR
First of all, have some lovely Egyptian Plovers from the Bronx Zoo, taken by Abigail on a recent photo jaunt.
Thanks, Abigail!
Second, a low-cost wearable computer rig that'll make you look significantly less dorky than your average gargoyle.
I'm a little concerned about overheating brought on by lack of ventilation, but even so it's a good start. This guy uses a foldable qwerty keyboard. You'll remember from my article on mobile and wearable computing that I think steno is just dying to be turned into an efficient wearable text input system. I think that two flat multitouch panels with keypads for haptic feedback tied snugly around each thigh and connected to the rest of the rig via Bluetooth would be ideal. Still not sure how feasible it would be to manufacture, but as Plover inches ever closer to full keyboard emulation (we're a session or two away from getting it working in Linux, and then hopefully we'll be able to port that bit into the Windows version without much trouble), I'd love to try it out in a mobile context, even if that means sawing open a SideWinder, cutting off the steno-irrelevant sections, snapping the circuitboard in half, and rewiring everything so that it can be attached to a wearable substrate like jeans, a hoodie, or a small bag.
Third, I'm going to check out the exhibit hall of SpeechTek2010 tomorrow. I'll let you know what I think, but I doubt I'll be out of a job just yet. And, anyway, even positing true AI and human-equivalent automated speech recognition, there are many contexts in which text input via fingers is more private and more convenient than dictating, which means that steno will always have a place in the game -- assuming I can get enough people aware of its many benefits.
Speaking of automated speech recognition, I made a short video the other day, and YouTube's autocaption transcript just kicked in today, so I decided to post it.
I stitched together several snippets of timed audio, dictated at speeds between 40 and 185 words per minute, and made screencasts of myself transcribing them first using the qwerty keyboard (top portion) and then the steno keyboard (bottom portion). First notice how much more work I was doing on the qwerty keyboard than on the steno keyboard. In What Is Steno Good For: Raw Speed, I discuss all the wasted energy and effort required to type out each individual letter, backspacing and retyping if I inadvertently type them in the wrong order, and the inherent limitations on speed imposed by this method. My fingers are moving much more quickly and working much harder in the qwerty window than in the steno window. As you can see by the end of the video, I was losing huge chunks of the audio, my accuracy was dismal, and I was positively sweating bullets between 160 and 185 WPM in the qwerty window. When I got to use my steno machine, 185 felt like a stroll in the daisies. I usually don't start feeling like my fingers are really going full blast until I get up to 240 or more on my steno machine, which this video doesn't show; I chose to stop at the point where my qwerty typing completely broke down. The difference in terms of ease, comfort, and ergonomics is hard to miss.
If you want to see how YouTube's automated speech recognition did at the same task, turn the captions on, then select "transcribe audio". You'll notice that even though the audio is crystal clear and each word is perfectly enunciated, it makes so many mistakes that it's almost impossible to understand what's being said by reading the autocaptions alone. Later on the quality improves a bit, though there are still significant errors, because the 185 WPM section of the transcript is a judge's jury charge, which contains lots of boilerplate big words such as "testimony" and "circumstances". Speech recognition has a much easier time with multisyllabic words, especially in dictation where there's a clear space inserted between each word (as in these samples, since they're intended for dictation, though they sounds quite unnatural to most ears) because there are comparatively fewer possibilities to rule out than in words of one or two syllables, which automated SR always has a great deal of trouble with. The problem is that small words are often the most important words in the sentence (especially if they're negatory words such as "no" or "not"), and you can see if you look at the auto captions that even making an error in 1 word out of 20 (a 95% accuracy rate) can cause great confusion.
The most successful and least error-ridden passage in the transcription was the phrase "the convergence of resources and bolstering of partnerships to support a coherent program for science and mathematics for all students". Because there were so many multisyllabic words in that passage, the autocaptioning system got them all right except for the phrase "for all", which it translated as "football". This is an error that a human transcriber would never make, because "football" and "for all" are stressed entirely differently in English, and syntactically it makes no sense to insert the word "football" between "mathematics" and "students". But you can see how that one tiny error brings the rest of the sentence into doubt, and can steer a Deaf or hard of hearing person off on entirely the wrong train of thought. It's this complete lack of ability to understand speech in context and to correct errors semantically that makes automatic speech recognition ultimately unreliable without extensive babysitting by human editors.
Thanks, Abigail!
Second, a low-cost wearable computer rig that'll make you look significantly less dorky than your average gargoyle.
I'm a little concerned about overheating brought on by lack of ventilation, but even so it's a good start. This guy uses a foldable qwerty keyboard. You'll remember from my article on mobile and wearable computing that I think steno is just dying to be turned into an efficient wearable text input system. I think that two flat multitouch panels with keypads for haptic feedback tied snugly around each thigh and connected to the rest of the rig via Bluetooth would be ideal. Still not sure how feasible it would be to manufacture, but as Plover inches ever closer to full keyboard emulation (we're a session or two away from getting it working in Linux, and then hopefully we'll be able to port that bit into the Windows version without much trouble), I'd love to try it out in a mobile context, even if that means sawing open a SideWinder, cutting off the steno-irrelevant sections, snapping the circuitboard in half, and rewiring everything so that it can be attached to a wearable substrate like jeans, a hoodie, or a small bag.
Third, I'm going to check out the exhibit hall of SpeechTek2010 tomorrow. I'll let you know what I think, but I doubt I'll be out of a job just yet. And, anyway, even positing true AI and human-equivalent automated speech recognition, there are many contexts in which text input via fingers is more private and more convenient than dictating, which means that steno will always have a place in the game -- assuming I can get enough people aware of its many benefits.
Speaking of automated speech recognition, I made a short video the other day, and YouTube's autocaption transcript just kicked in today, so I decided to post it.
I stitched together several snippets of timed audio, dictated at speeds between 40 and 185 words per minute, and made screencasts of myself transcribing them first using the qwerty keyboard (top portion) and then the steno keyboard (bottom portion). First notice how much more work I was doing on the qwerty keyboard than on the steno keyboard. In What Is Steno Good For: Raw Speed, I discuss all the wasted energy and effort required to type out each individual letter, backspacing and retyping if I inadvertently type them in the wrong order, and the inherent limitations on speed imposed by this method. My fingers are moving much more quickly and working much harder in the qwerty window than in the steno window. As you can see by the end of the video, I was losing huge chunks of the audio, my accuracy was dismal, and I was positively sweating bullets between 160 and 185 WPM in the qwerty window. When I got to use my steno machine, 185 felt like a stroll in the daisies. I usually don't start feeling like my fingers are really going full blast until I get up to 240 or more on my steno machine, which this video doesn't show; I chose to stop at the point where my qwerty typing completely broke down. The difference in terms of ease, comfort, and ergonomics is hard to miss.
If you want to see how YouTube's automated speech recognition did at the same task, turn the captions on, then select "transcribe audio". You'll notice that even though the audio is crystal clear and each word is perfectly enunciated, it makes so many mistakes that it's almost impossible to understand what's being said by reading the autocaptions alone. Later on the quality improves a bit, though there are still significant errors, because the 185 WPM section of the transcript is a judge's jury charge, which contains lots of boilerplate big words such as "testimony" and "circumstances". Speech recognition has a much easier time with multisyllabic words, especially in dictation where there's a clear space inserted between each word (as in these samples, since they're intended for dictation, though they sounds quite unnatural to most ears) because there are comparatively fewer possibilities to rule out than in words of one or two syllables, which automated SR always has a great deal of trouble with. The problem is that small words are often the most important words in the sentence (especially if they're negatory words such as "no" or "not"), and you can see if you look at the auto captions that even making an error in 1 word out of 20 (a 95% accuracy rate) can cause great confusion.
The most successful and least error-ridden passage in the transcription was the phrase "the convergence of resources and bolstering of partnerships to support a coherent program for science and mathematics for all students". Because there were so many multisyllabic words in that passage, the autocaptioning system got them all right except for the phrase "for all", which it translated as "football". This is an error that a human transcriber would never make, because "football" and "for all" are stressed entirely differently in English, and syntactically it makes no sense to insert the word "football" between "mathematics" and "students". But you can see how that one tiny error brings the rest of the sentence into doubt, and can steer a Deaf or hard of hearing person off on entirely the wrong train of thought. It's this complete lack of ability to understand speech in context and to correct errors semantically that makes automatic speech recognition ultimately unreliable without extensive babysitting by human editors.
Tuesday, July 20, 2010
Two bug fixes in SideWinder version of Plover
If you go over to the Github, you'll see changes in tktest.py and sidewinder.py. I recently took a trip to Seattle and Missoula and didn't have enough room in my luggage for my steno machine, so instead I took along the new SideWinder X4 I bought for my brother William. I had four transcription files to finish before the end of the trip, and I discovered that the freezing bug which had intermittently affected Plover completely prevented me from using my rewind foot pedal with Winamp, so my brother and I sat down together and fixed it, by gum. I also put in a line of code that made it so if you accidentally hit the space bar (like I found myself doing constantly, since it's so close to the vowel keys) it doesn't throw out the stroke the way it does if you hit other keys besides the ones mapped to be steno keys; it just ignores the space and translates the stroke as usual. These two tiny little changes has made Plover drastically more useful as-is, and tomorrow I'm meeting my Python tutor to work on keyboard emulation. I know it's been a bit of a hiatus, but Plover is back in active development again.
Saturday, July 17, 2010
Sidewinder + Steno Lessons for Auction
Hey, all. A friend of mine is trying to pay for her last semester of college, and her friends are having an auction to help raise funds. For my part, I'm offering a SideWinder X4, all decked out steno-style, plus six hours of steno lessons, either offered in New York City or over the internet. The current bid is $65, so if this sounds like a good deal to you, get in while the getting's good!
Auction for Maria: Steno Machine and Lessons
Auction for Maria: Steno Machine and Lessons
Monday, July 5, 2010
Steno 101, Lesson One
Steno 101: How to Do It
Steno 101: Lesson Zero
Steno 101: Lesson One
Steno 101: Lesson Two
Steno 101: Lesson Three
Steno 101: Lesson Four
So you've read Lesson Zero, which taught you some basic principles using pseudosteno, and now you're ready to start learning real steno. In order to keep it at a manageable level, I'm going to focus this lesson on two main groups of letters: The vowels, including chorded vowel combinations, and the consonants which appear as single letters on both sides of the steno keyboard.
First, the vowels:
A - as in bat, ant, father, or allow
O - as in got or knoll
E - as in let, pert, or defy
U - as in grump, bull, or purr
EU - as in grip, dirt, or tryst
AO - spelling differentiator, oa or oo
AE - spelling differentiator, ea or ae
AEU - as in grape or saint
AOE - as in seen or breech
AOU - as in glue or pew
AOEU - as in guise or spite
OEU - as in toil or ploy
AU - as in bought, tawny, or faun
OU - as in down or mound
OE - as in boat or grown
Let's look at the single vowels first: A, O, E, and U. They're all single-key vowels. (EU, even though it's a chord and not a letter, should also be grouped with them rather than with the vowel chords below, because it corresponds to the letter "I" and works like a single-key vowel). You'll see from the examples that a single vowel can stand for a few different vowel sounds. That's because, even though English has a fairly large number of actual vowel sounds, English spelling breaks vowels up into two rough categories: "short", which consists of a single vowel on its own, and "long", which consists of a doubled vowel, a diphthong (two different vowels together), or a vowel whose sound is modified by another vowel elsewhere in the word.
The steno theory I learned, while mostly phonetic, sometimes uses spelling to inform how to write a word. So if a word is written with a single "short" vowel, it will usually be written with the same vowel on the steno machine, regardless of what it actually sounds like. "Pert" and "Purr" have the same sound, but "pert" is written with the E key, and "purr" with the U key.
The theory also uses spelling cues to differentiate between long-vowel soundalike words. I spoke a little about this in Lesson Zero, but now that you see the whole vowel chart, it should make more sense.
Let's go back to pseudosteno again for some examples:
Pair: PAEUR
Pear: PAER
Bare: BAEUR
Bear: BAER
Grate: GRAEUT
Great: GRAET
You can see that words containing "ea" together are written with "AE", while the words with the same long A sound that don't contain "ea" together are written phonetically, with "AEU". (Or, in the case of a word pair like "breech" and "breach", with the long E sound, "AOE", for breech, while breach would be written "BRAECH" in pseudosteno.) This is the main use for the "AE" key combination, so you can see that it's really a conflict differentiator, rather than a vowel sound per se.
The AO key combination is similar. It can be used as a spelling differentiator for word pairs like "soar" (SAOR) and "sore" (SOR), but more often than that, it's used to represent the "OO" vowel pair, irrespective of what it sounds like. Pseudosteno again:
Book: BAOK
Floor: FLAOR
Zoo: ZAO
That covers the second group of steno vowels. The last group covers so-called "long" vowel sounds and diphthongs, and it's going to involve the most straight-up memorization. The good news is that these operate almost entirely phonetically, so you don't have to concern yourself with spelling. Eventually I'm going to make a steno tutorial video game that will teach you these sounds and drill you on them, but for now you're going to have to memorize them on your own, with whatever method that works.
AEU - "long-A" sound
AOE - "long-E" sound
AOU - "long-U" sound
AOEU - "long-I" sound
OE - "long-O" sound
AU - "aw" or "au" diphthong
OU - "ow" or "ou" diphthong
OEU - "oy" or "oi" diphthong
Let's ditch the pseudosteno and move into some actual steno. In this lesson we're only going to deal with the top section of the complete steno layout chart that I posted several weeks ago.
These are the single-key letters that appear on both sides of the steno keyboard: S, T, P, and R. Try using them with your new vowel combinations. I've made a chart that shows what you get when you try just one left-hand letter, a vowel or vowel chord, and just one right-hand letter, but remember that steno can work with an unlimited number of letters in a chord. (Purple-highlighted cells in the chart represent chord combinations that aren't English words and can therefore be assigned to phonetic word parts or briefs. If I've highlighted a few that actually are words, let me know; I'm not the world's best Scrabble player.) First try a few from the chart:
Practice going through the vowel sounds to reinforce them in your muscle memory. Then try plugging in additional consonants. A few starter chords to get you going, using the "short a" sound:
STRAP: Strap
STARS: Stars
START: Start
PARTS: Parts
PRATS: Prats
SPRAT: Sprat
RAPT: Rapt
SAS: Sass
Now try making some more chords, using different vowel sounds and different combinations of letters. Let me know what you come up with in the comments. Feedback is always welcome. In the next lesson, we'll start learning chorded consonants. Stay tuned!
Steno 101: Lesson Zero
Steno 101: Lesson One
Steno 101: Lesson Two
Steno 101: Lesson Three
Steno 101: Lesson Four
So you've read Lesson Zero, which taught you some basic principles using pseudosteno, and now you're ready to start learning real steno. In order to keep it at a manageable level, I'm going to focus this lesson on two main groups of letters: The vowels, including chorded vowel combinations, and the consonants which appear as single letters on both sides of the steno keyboard.
First, the vowels:
A - as in bat, ant, father, or allow
O - as in got or knoll
E - as in let, pert, or defy
U - as in grump, bull, or purr
EU - as in grip, dirt, or tryst
AO - spelling differentiator, oa or oo
AE - spelling differentiator, ea or ae
AEU - as in grape or saint
AOE - as in seen or breech
AOU - as in glue or pew
AOEU - as in guise or spite
OEU - as in toil or ploy
AU - as in bought, tawny, or faun
OU - as in down or mound
OE - as in boat or grown
Let's look at the single vowels first: A, O, E, and U. They're all single-key vowels. (EU, even though it's a chord and not a letter, should also be grouped with them rather than with the vowel chords below, because it corresponds to the letter "I" and works like a single-key vowel). You'll see from the examples that a single vowel can stand for a few different vowel sounds. That's because, even though English has a fairly large number of actual vowel sounds, English spelling breaks vowels up into two rough categories: "short", which consists of a single vowel on its own, and "long", which consists of a doubled vowel, a diphthong (two different vowels together), or a vowel whose sound is modified by another vowel elsewhere in the word.
The steno theory I learned, while mostly phonetic, sometimes uses spelling to inform how to write a word. So if a word is written with a single "short" vowel, it will usually be written with the same vowel on the steno machine, regardless of what it actually sounds like. "Pert" and "Purr" have the same sound, but "pert" is written with the E key, and "purr" with the U key.
The theory also uses spelling cues to differentiate between long-vowel soundalike words. I spoke a little about this in Lesson Zero, but now that you see the whole vowel chart, it should make more sense.
Let's go back to pseudosteno again for some examples:
Pair: PAEUR
Pear: PAER
Bare: BAEUR
Bear: BAER
Grate: GRAEUT
Great: GRAET
You can see that words containing "ea" together are written with "AE", while the words with the same long A sound that don't contain "ea" together are written phonetically, with "AEU". (Or, in the case of a word pair like "breech" and "breach", with the long E sound, "AOE", for breech, while breach would be written "BRAECH" in pseudosteno.) This is the main use for the "AE" key combination, so you can see that it's really a conflict differentiator, rather than a vowel sound per se.
The AO key combination is similar. It can be used as a spelling differentiator for word pairs like "soar" (SAOR) and "sore" (SOR), but more often than that, it's used to represent the "OO" vowel pair, irrespective of what it sounds like. Pseudosteno again:
Book: BAOK
Floor: FLAOR
Zoo: ZAO
That covers the second group of steno vowels. The last group covers so-called "long" vowel sounds and diphthongs, and it's going to involve the most straight-up memorization. The good news is that these operate almost entirely phonetically, so you don't have to concern yourself with spelling. Eventually I'm going to make a steno tutorial video game that will teach you these sounds and drill you on them, but for now you're going to have to memorize them on your own, with whatever method that works.
AEU - "long-A" sound
AOE - "long-E" sound
AOU - "long-U" sound
AOEU - "long-I" sound
OE - "long-O" sound
AU - "aw" or "au" diphthong
OU - "ow" or "ou" diphthong
OEU - "oy" or "oi" diphthong
Let's ditch the pseudosteno and move into some actual steno. In this lesson we're only going to deal with the top section of the complete steno layout chart that I posted several weeks ago.
These are the single-key letters that appear on both sides of the steno keyboard: S, T, P, and R. Try using them with your new vowel combinations. I've made a chart that shows what you get when you try just one left-hand letter, a vowel or vowel chord, and just one right-hand letter, but remember that steno can work with an unlimited number of letters in a chord. (Purple-highlighted cells in the chart represent chord combinations that aren't English words and can therefore be assigned to phonetic word parts or briefs. If I've highlighted a few that actually are words, let me know; I'm not the world's best Scrabble player.) First try a few from the chart:
Practice going through the vowel sounds to reinforce them in your muscle memory. Then try plugging in additional consonants. A few starter chords to get you going, using the "short a" sound:
STRAP: Strap
STARS: Stars
START: Start
PARTS: Parts
PRATS: Prats
SPRAT: Sprat
RAPT: Rapt
SAS: Sass
Now try making some more chords, using different vowel sounds and different combinations of letters. Let me know what you come up with in the comments. Feedback is always welcome. In the next lesson, we'll start learning chorded consonants. Stay tuned!
Saturday, July 3, 2010
Plover's Got a Discussion Group
At Tony's suggestion, I've made a Google Group for Plover. I know a lot of you found out about this blog via Depoman, and feel free to keep talking about it there, but for sustained conversation I thought the Google Group was a better idea than the slapdash blog comment discussions we've been having up 'til now. If you know anyone else who might be interested, please send them along. I'm hoping to get more Steno 101 lessons up in the next week or so here at the blog (mirrored on my website's articles page), and a drastically more useful version of Plover (hopefully with Linux keyboard emulation, and maybe even Windows as well) should be uploaded to the Github by some time in August. Meanwhile, please feel free to use the group to talk about what you'd like to see in the software, steno-customizations of your SideWinder, your experience of learning steno, and anything else that takes your fancy.
Saturday, June 26, 2010
A Request
Hey, all. I don't actually know how many people subscribe to this blog (because I just activated Google Webmaster Tools today and they haven't kicked in yet), but it's had a good half a dozen commenters, and I have a feeling there's a lurker or two hanging around as well. I've got a favor to ask you guys. When I tell people about the Plover Project, the most common response I get is, "Sure, steno is impressive. But who's actually going to take the trouble to learn it?" I know that a number of you are looking to become court reporters, captioners, or CART providers, but I know there are others who intend to use steno to write fiction, avoid RSIs, or any number of other reasons. I'd love to get a bunch of blurbs from people who are either starting steno via Plover or are choosing to use Plover alongside their more traditional steno studies. Why do you think it's worthwhile? What's your motivation in learning steno? What sorts of things do you want to do with it? Just a couple of sentences from a few different people would be enough to fill a post that I could link to whenever the doubters raised their eyebrows at the whole idea of a steno program for amateurs. I'll kick it off with a comment from my friend Martin, who works as a draftsman:
"Here's how I look at it: Right now, I type at about 40-50 WPM. If I ever made a change to how I typed, I'd spend at least a month or so writing at like 20ish WPM. If I learned to write qwerty properly, I'd eventually get up to 60-80 WPM -- clearly not worth it. Dvorak, maybe 75-90 -- meh. That Dutch thingie* , realistically I'd probably max out around 100-150ish. Steno, probably about the same. That's worth the time, but it's not worth the money. Plover takes the fastest option and makes it one of the cheapest."
Anyone else have a story to tell? You can write 'em in the comments or email me (plover@stenoknight.com), and then I'll collect them and put them together as a post on the blog. I'm hoping to show that there are plenty of reasons to learn steno, and plenty of demand for Plover that will only increase as it develops. After a month-long hiatus, my next Python session is on Monday, and we're gonna work on keyboard emulation in both Windows and Linux. We've got some pretty good leads on how to do it, so if all goes well, Plover will be able to write properly formatted text into any program you like after the next several weeks.
*Velotype, which I showed him this morning after a Plover commenter sent it to me. Thanks, Nicolay!
"Here's how I look at it: Right now, I type at about 40-50 WPM. If I ever made a change to how I typed, I'd spend at least a month or so writing at like 20ish WPM. If I learned to write qwerty properly, I'd eventually get up to 60-80 WPM -- clearly not worth it. Dvorak, maybe 75-90 -- meh. That Dutch thingie* , realistically I'd probably max out around 100-150ish. Steno, probably about the same. That's worth the time, but it's not worth the money. Plover takes the fastest option and makes it one of the cheapest."
Anyone else have a story to tell? You can write 'em in the comments or email me (plover@stenoknight.com), and then I'll collect them and put them together as a post on the blog. I'm hoping to show that there are plenty of reasons to learn steno, and plenty of demand for Plover that will only increase as it develops. After a month-long hiatus, my next Python session is on Monday, and we're gonna work on keyboard emulation in both Windows and Linux. We've got some pretty good leads on how to do it, so if all goes well, Plover will be able to write properly formatted text into any program you like after the next several weeks.
*Velotype, which I showed him this morning after a Plover commenter sent it to me. Thanks, Nicolay!
Friday, June 25, 2010
CART, Court, and Captioning
What Is Steno Good For?
Part One: How to Speak With Your Fingers
Part Two: Writing and Coding
Part Three: The Ergonomic Argument
Part Four: Mobile and Wearable Computing
Part Five: Raw Speed
Part Six: CART, Court, and Captioning
Finally, the sixth and last installment of my What Is Steno Good For? series. The first five sections dealt with using steno in daily life, for conversation, prose composition and coding, injury prevention, typing while walking, and inputting text as efficiently as possible. Plover is being developed primarily with those five spheres in mind.
This section is different. It focuses on people who actually want to make a living as court reporters, CART providers, or captioners. It's also the category that the majority of the Plover Project's current testers, readers, and commenters belong to. In order for Plover to succeed, that proportion needs to change.
Steno as a career is skyrocketing. Official reporters (the ones who work in actual courtrooms) are facing layoffs, but in every other field -- deposition work, captioning, and CART -- there's far more demand than supply. Rates are relatively high (though down considerably from their peak in the '90s, and gradually continuing to decline) and work is plentiful. Certified realtime stenographers can make six figures a year, while setting their own schedules and maintaining autonomy as independent contractors. It's pretty much a dream job.
Steno as an academic-vocational discipline is dying. Steno schools continue to shut down across the country. The national dropout rate is 85%. Student machines cost over $1,000, and DRM-riddled student software runs about $500, so without even considering tuition, students are forced to pay a largely non-refundable $1,500 right out of the gate. Considering the 15% graduation rate and the variable length of study (which ranges from 1 to 6 years, but averages around 4 years of intensive daily practice to reach graduation speeds of 225 WPM), steno school is a fool's gamble for the vast majority of new students. Most schools are for-profit, so it's in their interest to accept large numbers of theory students, selling them their steno machines when the semester starts and buying them back at a steep markdown from the dropouts, who tend to leave around 120 WPM, just in time for the next crop of theory students to arrive. There's no incentive for schools to screen for English aptitude, physical dexterity, or self-discipline, because the students that are all but doomed to fail are potentially even more lucrative than the successful ones, due to the revolving steno machine sale-and-buyback scheme. This means plenty of profit in the short term, but in the long term it spells the death not only of these short-sighted schools, but of the steno professions themselves.
A market in which demand exceeds supply will hold out only so long. Eventually the vaccuum caused by the shortage of stenographers will collapse, and inferior but readily available substitutes such as electronic recording, undertrained voice writers, and non-verbatim notetaking systems will move in to claim the territory. Compounding the problem is that many people think that the career is less than a decade away from obsolescence; 30 years of Star Trek has put the idea into their heads that artificial intelligence is a nut we're close to cracking, and that a computer that can understand and transcribe everything we say to it is just around the corner. I've got lots and lots to say on this one, but let me just lay out the short and sweet version, and you can either take my word for it now or wait for the long argument to come later. (You might also want to read this article for some of the technical details.)
Without true artificial intelligence, there is no reliable speech recognition. Current speech recognition software works relatively well with good audio, clear speakers, and a somewhat restricted vocabulary. Dictation at 160 WPM or less can give good results, especially if the speaker puts in the effort to train themselves and their software, and providing that they have the luxury to stop the dictation and correct any errors made by the software before continuing on. In real-life situations, where the speaker being transcribed can't be induced to slow down, correct errors, or enunciate perfectly in American-accented English -- even with an intermediary "respeaker" repeating the dictation directly into a microphone, inserting punctuation, and correcting errors on the fly -- the software's verbatim realtime accuracy is significantly below that of a trained stenographer. The only respeakers that even approach the accuracy of realtime steno are true voice writers, who spend thousands of hours training their voices, figuring out ways to differentiate the pronunciation of homophones, and creating macros to resolve mistranscriptions. It is not easy to do. I compare true voice writing to beatboxing and steno to playing a drumset in my article Voice Captioning Versus CART. You can read it if you're interested in that sort of thing.
The trouble is that everyone keeps saying "Voice recognition software is constantly improving. It gets better with every new release. Soon it'll be perfect." The first two statements are correct. The third is a fallacy. The software is improving, but asymptotically. Its theoretical ceiling of improvement is far below what's required for consistent, reliable transcription. Speech recognition software doesn't parse language the way humans do. It has no ability to use context or meaning to change sounds into words. It records audio waveforms, breaks them up into little bits, and compares them to a database of other audio waveforms. It never finds a perfect match, because no two humans say the same word in exactly the same way each time. Instead, it tries to choose the closest match in its database of thousands of other tiny fragments of audio. All speech recognition software relies on probability-based algorithms to guess at what's being said. This means that the more common the phrase, the more variants of it will be found in the database, and the more likely it will be to be correctly transcribed.
But the converse is also true. In the architecture class I provide CART for, the phrase "sum of the forces" comes up several dozen times a week. But because the phrase "some of the" is so much more common in normal speech than "sum of the", the VR software would mistranscribe it unless the voice writer figured out a way to say "sum" that sounded completely different from the word "some" and defined it as a custom waveform. There are scads of these soundalike words and phrases in the English language, and the voice writer is at a disadvantage when trying to distinguish them. The steno writer has a number of options to resolve homophone conflicts or to compress a wordy phrase into a single stroke. They can add the asterisk, they can alter the vowels, or they can take a cue from the way the word is spelled. It's much harder for a voice writer to find an alternative way to pronounce a word or syllable, because not only must they pronounce it consistently so that the computer can recognize it each time, but it also can't sound like any other words or syllables that they might be called upon to speak. It's much easier to write a memorable nonsense syllable on the steno keyboard than it ever would be to speak it.
There's also the inherent uncertainty involved in decoding analog speech with a digital algorithm. Even with good amplification, the signal is always lossy to some extent, and the speech processing algorithms are essentially a black box that weigh relative probabilities and then just spit out the most likely one, without being able to incorporate any semantic or contextual calculations. The voice writer is never quite sure what the machine is going to make out of what they said, and no matter how cleanly they speak, they're forced to build in a lot more error correction time into their transcription process. Steno writers can write a word in half a second that took the speaker three seconds to say, and they know with certainty what will come up on the screen when they hit a particular chord. That's an advantage a voice writer will never have. Add in that a voice writer has to speak at the same time that they're trying to listen, and you see some of the difficulties they labor under.
There are some excellent voice writers out there, and I don't want to devalue their talent or the enormous amount of training that goes into the process of achieving accurate verbatim realtime using VR software. On the contrary; I think if people realized how much work it takes to do the job properly with the voice, they might balk a lot less at the idea of learning to do it with their fingers. Unfortunately, the shortage of CART providers, captioners, and court reporters has led to a widespread practice of companies hiring untrained voice writers, deciding that their output is good enough, and dropping both standards and wages accordingly. It's a sad situation.
Because voice recognition is perceived to be so much easier than it really is, and because learning it only requires about $200, a microphone, and a computer, it's much easier to find people willing to give it a chance. After all, if it doesn't live up to their expectations, they're only out $200, rather than the $1,500 albatross steno school dropouts find themselves trying to unload. Imagine if computer programming required a special computer that couldn't connect to the internet or run games or do anything else except write computer software, and that it sold for $1,500. What do you think the state of software development would look like? Maybe some rich kids' parents would buy them the machine, but they'd probably prefer that they become doctors or lawyers than programmers, which is a lot of work for not much prestige. Poor kids would be completely out of luck. Middle class kids might think that programming sounded fun, but they'd probably decide it wasn't worth the restrictive entry cost. Some few people might decide that programming was their best shot at making a good living, so they'd scrimp and save and take out loans to buy the special programming computer plus the lessons to go with it. And after all that, what if they didn't like programming? What if they didn't have an aptitude for it? They were out $1,500 and a lot of wasted effort. What kind of smart, inquisitive, curious kid would make that kind of gamble? What would the field of computer programming look like if this were the only way to write software?
It's the state of steno today, and I'm worried that if it goes on for much longer, the discipline will die out altogether. The only way we can build the next generation of realtime reporters, captioners, and CART providers is if we get people using steno for all sorts of purposes -- not just the ones that will make them an immediate profit. Once there's a pool of amateurs and enthusiasts all using steno in their daily lives, it will be evident how useful it can be and how outdated the qwerty interface has become. Kids will start learning it in their typing classes. Companies will start selling steno machines (hopefully ultra-portable ones!) at consumer prices. People who would feel awkward talking to themselves in public via VR software will embrace steno as the most efficient way to put their thoughts into words.
All of this holds true even if they're only writing at 120 words per minute. It took me a year and a half to graduate from steno school. In that time, I noticed that most of my fellow students dropped out when they were writing between 120 and 225 words per minute. Relatively few of them dropped out before their third semester. They would make fairly steady progress through theory and up to 120 WPM, then plateau. It seems that nearly anyone can get up to 100 WPM or so in less than six months, but that closing the gap between 100 and 200 seems to take much more work. You don't need to write at 225 WPM to reap the advantages of steno. Even 120 WPM is double the average qwerty typing speed, and steno has significant ergonomic benefits as well. Users can overtake their qwerty speed within the first few months of use, then gradually work their way up to higher speeds while using steno to perform their daily tasks, rather than spending 10 hours a week in grueling, boring dictation classes.
Inevitably, some of these people will find they have both a passion and a talent for steno. They'll push themselves to go faster and faster, and eventually they'll arrive at court/CART/captioning speeds. Much like programmers do today, they'll start out tinkering around with the free software, discover a passion and an aptitude for the system, possibly spend some time in a formal program polishing their technique, and discover one day that they're skilled enough to take paying work. These people are the future of our profession, and right now they hardly know it exists. The only way people will bother to learn steno is if the software is free, the steno machine costs less than $100, and the lessons are available online. The Plover Project is an attempt to meet those goals, and to secure the future of the work that I love.
Part One: How to Speak With Your Fingers
Part Two: Writing and Coding
Part Three: The Ergonomic Argument
Part Four: Mobile and Wearable Computing
Part Five: Raw Speed
Part Six: CART, Court, and Captioning
Finally, the sixth and last installment of my What Is Steno Good For? series. The first five sections dealt with using steno in daily life, for conversation, prose composition and coding, injury prevention, typing while walking, and inputting text as efficiently as possible. Plover is being developed primarily with those five spheres in mind.
This section is different. It focuses on people who actually want to make a living as court reporters, CART providers, or captioners. It's also the category that the majority of the Plover Project's current testers, readers, and commenters belong to. In order for Plover to succeed, that proportion needs to change.
Steno as a career is skyrocketing. Official reporters (the ones who work in actual courtrooms) are facing layoffs, but in every other field -- deposition work, captioning, and CART -- there's far more demand than supply. Rates are relatively high (though down considerably from their peak in the '90s, and gradually continuing to decline) and work is plentiful. Certified realtime stenographers can make six figures a year, while setting their own schedules and maintaining autonomy as independent contractors. It's pretty much a dream job.
Steno as an academic-vocational discipline is dying. Steno schools continue to shut down across the country. The national dropout rate is 85%. Student machines cost over $1,000, and DRM-riddled student software runs about $500, so without even considering tuition, students are forced to pay a largely non-refundable $1,500 right out of the gate. Considering the 15% graduation rate and the variable length of study (which ranges from 1 to 6 years, but averages around 4 years of intensive daily practice to reach graduation speeds of 225 WPM), steno school is a fool's gamble for the vast majority of new students. Most schools are for-profit, so it's in their interest to accept large numbers of theory students, selling them their steno machines when the semester starts and buying them back at a steep markdown from the dropouts, who tend to leave around 120 WPM, just in time for the next crop of theory students to arrive. There's no incentive for schools to screen for English aptitude, physical dexterity, or self-discipline, because the students that are all but doomed to fail are potentially even more lucrative than the successful ones, due to the revolving steno machine sale-and-buyback scheme. This means plenty of profit in the short term, but in the long term it spells the death not only of these short-sighted schools, but of the steno professions themselves.
A market in which demand exceeds supply will hold out only so long. Eventually the vaccuum caused by the shortage of stenographers will collapse, and inferior but readily available substitutes such as electronic recording, undertrained voice writers, and non-verbatim notetaking systems will move in to claim the territory. Compounding the problem is that many people think that the career is less than a decade away from obsolescence; 30 years of Star Trek has put the idea into their heads that artificial intelligence is a nut we're close to cracking, and that a computer that can understand and transcribe everything we say to it is just around the corner. I've got lots and lots to say on this one, but let me just lay out the short and sweet version, and you can either take my word for it now or wait for the long argument to come later. (You might also want to read this article for some of the technical details.)
Without true artificial intelligence, there is no reliable speech recognition. Current speech recognition software works relatively well with good audio, clear speakers, and a somewhat restricted vocabulary. Dictation at 160 WPM or less can give good results, especially if the speaker puts in the effort to train themselves and their software, and providing that they have the luxury to stop the dictation and correct any errors made by the software before continuing on. In real-life situations, where the speaker being transcribed can't be induced to slow down, correct errors, or enunciate perfectly in American-accented English -- even with an intermediary "respeaker" repeating the dictation directly into a microphone, inserting punctuation, and correcting errors on the fly -- the software's verbatim realtime accuracy is significantly below that of a trained stenographer. The only respeakers that even approach the accuracy of realtime steno are true voice writers, who spend thousands of hours training their voices, figuring out ways to differentiate the pronunciation of homophones, and creating macros to resolve mistranscriptions. It is not easy to do. I compare true voice writing to beatboxing and steno to playing a drumset in my article Voice Captioning Versus CART. You can read it if you're interested in that sort of thing.
The trouble is that everyone keeps saying "Voice recognition software is constantly improving. It gets better with every new release. Soon it'll be perfect." The first two statements are correct. The third is a fallacy. The software is improving, but asymptotically. Its theoretical ceiling of improvement is far below what's required for consistent, reliable transcription. Speech recognition software doesn't parse language the way humans do. It has no ability to use context or meaning to change sounds into words. It records audio waveforms, breaks them up into little bits, and compares them to a database of other audio waveforms. It never finds a perfect match, because no two humans say the same word in exactly the same way each time. Instead, it tries to choose the closest match in its database of thousands of other tiny fragments of audio. All speech recognition software relies on probability-based algorithms to guess at what's being said. This means that the more common the phrase, the more variants of it will be found in the database, and the more likely it will be to be correctly transcribed.
But the converse is also true. In the architecture class I provide CART for, the phrase "sum of the forces" comes up several dozen times a week. But because the phrase "some of the" is so much more common in normal speech than "sum of the", the VR software would mistranscribe it unless the voice writer figured out a way to say "sum" that sounded completely different from the word "some" and defined it as a custom waveform. There are scads of these soundalike words and phrases in the English language, and the voice writer is at a disadvantage when trying to distinguish them. The steno writer has a number of options to resolve homophone conflicts or to compress a wordy phrase into a single stroke. They can add the asterisk, they can alter the vowels, or they can take a cue from the way the word is spelled. It's much harder for a voice writer to find an alternative way to pronounce a word or syllable, because not only must they pronounce it consistently so that the computer can recognize it each time, but it also can't sound like any other words or syllables that they might be called upon to speak. It's much easier to write a memorable nonsense syllable on the steno keyboard than it ever would be to speak it.
There's also the inherent uncertainty involved in decoding analog speech with a digital algorithm. Even with good amplification, the signal is always lossy to some extent, and the speech processing algorithms are essentially a black box that weigh relative probabilities and then just spit out the most likely one, without being able to incorporate any semantic or contextual calculations. The voice writer is never quite sure what the machine is going to make out of what they said, and no matter how cleanly they speak, they're forced to build in a lot more error correction time into their transcription process. Steno writers can write a word in half a second that took the speaker three seconds to say, and they know with certainty what will come up on the screen when they hit a particular chord. That's an advantage a voice writer will never have. Add in that a voice writer has to speak at the same time that they're trying to listen, and you see some of the difficulties they labor under.
There are some excellent voice writers out there, and I don't want to devalue their talent or the enormous amount of training that goes into the process of achieving accurate verbatim realtime using VR software. On the contrary; I think if people realized how much work it takes to do the job properly with the voice, they might balk a lot less at the idea of learning to do it with their fingers. Unfortunately, the shortage of CART providers, captioners, and court reporters has led to a widespread practice of companies hiring untrained voice writers, deciding that their output is good enough, and dropping both standards and wages accordingly. It's a sad situation.
Because voice recognition is perceived to be so much easier than it really is, and because learning it only requires about $200, a microphone, and a computer, it's much easier to find people willing to give it a chance. After all, if it doesn't live up to their expectations, they're only out $200, rather than the $1,500 albatross steno school dropouts find themselves trying to unload. Imagine if computer programming required a special computer that couldn't connect to the internet or run games or do anything else except write computer software, and that it sold for $1,500. What do you think the state of software development would look like? Maybe some rich kids' parents would buy them the machine, but they'd probably prefer that they become doctors or lawyers than programmers, which is a lot of work for not much prestige. Poor kids would be completely out of luck. Middle class kids might think that programming sounded fun, but they'd probably decide it wasn't worth the restrictive entry cost. Some few people might decide that programming was their best shot at making a good living, so they'd scrimp and save and take out loans to buy the special programming computer plus the lessons to go with it. And after all that, what if they didn't like programming? What if they didn't have an aptitude for it? They were out $1,500 and a lot of wasted effort. What kind of smart, inquisitive, curious kid would make that kind of gamble? What would the field of computer programming look like if this were the only way to write software?
It's the state of steno today, and I'm worried that if it goes on for much longer, the discipline will die out altogether. The only way we can build the next generation of realtime reporters, captioners, and CART providers is if we get people using steno for all sorts of purposes -- not just the ones that will make them an immediate profit. Once there's a pool of amateurs and enthusiasts all using steno in their daily lives, it will be evident how useful it can be and how outdated the qwerty interface has become. Kids will start learning it in their typing classes. Companies will start selling steno machines (hopefully ultra-portable ones!) at consumer prices. People who would feel awkward talking to themselves in public via VR software will embrace steno as the most efficient way to put their thoughts into words.
All of this holds true even if they're only writing at 120 words per minute. It took me a year and a half to graduate from steno school. In that time, I noticed that most of my fellow students dropped out when they were writing between 120 and 225 words per minute. Relatively few of them dropped out before their third semester. They would make fairly steady progress through theory and up to 120 WPM, then plateau. It seems that nearly anyone can get up to 100 WPM or so in less than six months, but that closing the gap between 100 and 200 seems to take much more work. You don't need to write at 225 WPM to reap the advantages of steno. Even 120 WPM is double the average qwerty typing speed, and steno has significant ergonomic benefits as well. Users can overtake their qwerty speed within the first few months of use, then gradually work their way up to higher speeds while using steno to perform their daily tasks, rather than spending 10 hours a week in grueling, boring dictation classes.
Inevitably, some of these people will find they have both a passion and a talent for steno. They'll push themselves to go faster and faster, and eventually they'll arrive at court/CART/captioning speeds. Much like programmers do today, they'll start out tinkering around with the free software, discover a passion and an aptitude for the system, possibly spend some time in a formal program polishing their technique, and discover one day that they're skilled enough to take paying work. These people are the future of our profession, and right now they hardly know it exists. The only way people will bother to learn steno is if the software is free, the steno machine costs less than $100, and the lessons are available online. The Plover Project is an attempt to meet those goals, and to secure the future of the work that I love.
Monday, June 21, 2010
Raw Speed
What is Steno Good For?
Part One: How to Speak With Your Fingers
Part Two: Writing and Coding
Part Three: The Ergonomic Argument
Part Four: Mobile and Wearable Computing
Part Five: Raw Speed
Part Six: CART, Court, and Captioning
In the introduction to the What Is Steno Good For? series I said, more or less facetiously, that this section would be devoted to "break onto the high score tables of online typing games." Speed for the sake of bragging rights is great and all, but I think there's more than that to be gained from being able to write three times faster than a qwerty typist.
When I tell people about Plover, they often say, "Well, I guess it's cool that you can type 240 WPM, but your job is to write down what other people are saying. I work alone, on my own time. Why would I go to the trouble of learning this whole new system? I type 60 WPM on a qwerty keyboard, and it's never been a problem for me." That's a fair question. Does the ability to type faster actually offer real-world advantages to people who aren't working as stenographers or transcriptionists? Which is the limiting factor: The input speed of the fingers or the output speed of the brain? And if there is a difference, is it only a quantitative one, or can it be qualitative as well?
I've talked about using steno to converse without speaking, the ease and fluency it lends to prose composition, its ergonomic benefits, and its potential in mobile applications. But speed is the most obvious and immediate benefit of steno over qwerty. It lets you get rid of the boring stuff quickly, leaving you more time for the interesting stuff. Whether that means being so blindingly fast at your dull data entry job that you get promoted to something requiring actual intelligence, or whether it means solidifying your ideas in text before they snarl up and blow away, it's a worthwhile thing to do. The counterargument to that, which I hear a lot, is that words just don't come that quickly; it takes longer to think of them than it does to write them, even at glacial typing speeds. That doesn't match up with my experience, and I don't think I'm the only one.
I'm willing to bet that the act of qwerty typing slows down the thoughts of many people. When I type on a qwerty keyboard, I feel my mind splitting along four consecutive but overlapping tracks: One, the word I want to write. Two, the way it's spelled. I'm a pretty good speller, but English is weird enough that the process is never completely automatic. Three, the series of five to ten finger motions it takes to type it. Four, the error checking mechanism that iterates over the first three and confirms that the correct word choice, orthography, and letter position have appeared onscreen. Usually I'll have already started typing the next word when I spot a spelling or typing error in the previous one, and by the time I've pressed backspace ten times to correct two transposed letters, my train of thought will have gotten all tangled up and I'll have to pause for a second to remember what I was writing. Even when I try to pace myself and type more slowly than usual, I'll make an error like this every few sentences, and my flow of composition will have been interrupted half a dozen times by end of the paragraph.
I know this sounds less like an argument for speed and more like the argument for fluency that I made in part two, but I don't think people realize how closely they're connected. Your mind won't let itself leap too far ahead of the words on the screen, so the rate of the words effectively throttles the rate of your thoughts. Add in the constant backspacing and rewriting, and three quarters of your mind is devoted to busywork, while the quarter devoted to producing actual words is forced to wait its turn.
How does steno consolidate those channels of word selection, spelling, typing, and error correction? Well, with word selection you're on your own; the steno machine can't help you there. But then you only have to conjure the sound of the word and stroke out its corresponding syllables. The spelling takes care of itself. No more pausing to remember where the double l goes in "parallel"; just write PA/RA/LEL and the computer will find the proper spelling for you. This is very useful when producing work for clients with divergent specifications. If you're copywriting for one company that prefers the spelling "Web site" (shudder) and another that favors "website", you don't have to spend any thought cycles retraining your fingers each time you switch; just define WEBT differently in your two client dictionaries and forget about it. Same with international spellings. Get both an American dictionary and a Canadian/British dictionary, and your writing can stay the same while your spelling toggles across borders. That also goes for diacritical marks, brand names, trademark symbols, and everything else it's a pain in the butt to write out each time; define it once, and you can just keep writing phonetically without worrying about the extra fiddly bits. Of course, you can do this to a certain extent with autocorrect and autoexpand settings in word processors, but they still require three to five keystrokes per word, and they don't easily accommodate several client or task-specific dictionaries.
That's spelling taken care of. What about typing accuracy? Qwerty requires your fingers to be constantly in motion, and their timing has to be split-second accurate if you want to avoid writing letters in the wrong order. Most people have a few fingers that are quicker than the rest, leading to persistent letter inversion and spacing errors. In steno, there is no space bar, so that's 1/5 of your errors obviated straight off. It's also far harder to make letter inversion errors, because the steno machine registers strokes not when each finger hits the key, but after all the keys have been released. You can compensate for a lazy or overactive finger merely by lifting your hands decisively from the keyboard at the end of each stroke. In steno, the wrist and forearm muscles get to set the pace, rather than the scattershot fast-twitch muscles of the fingers.
Pay attention to how many times you hit the backspace key when writing qwerty, even while typing slowly and evenly. The longer it takes to discover an error, the more backspaces you need to return to the spot and fix it, which means that you're forced either to be hypervigilant as you type or to spend nearly as much time backspacing as typing. In steno, the asterisk key deletes the last translation, not the last letter. Misstroke a six-letter word? Fix the error with a single stroke rather than six. No more leaning on the backspace key, waiting for the cursor to catch up. One stroke to write a word, one stroke to delete it. All of these shortcuts simplify the mental and physical bookkeeping you have to do during the writing process, which speeds up not just your typing, but your thoughts as well.
And what do you do with the time you save from that increased typing and thinking speed? The stuff that isn't typing. Typing is boring. It's not profitable. It's also not scalable. You might think that part of my scheme to hook people on steno would be to tell them how to make money off of it, but to be honest, unless you're really good, really fast, and really dedicated, you're not gonna be able to earn much from it. Realtime stenographers (I'm one myself) make a good living. Offline (i.e., non-realtime) transcription jobs, like gold farming, are only sustainably profitable these days in countries with pretty low costs of living. If there's a transcriptionist in the Philippines reading this who's thinking about using Plover to make their work more efficient, I'd be thrilled to bits to hear from 'em. But in the United States, Canada, and Europe, even stenographic speeds aren't likely to make you enough transcription money to live on. There are too many people working at far slower speeds who can afford to charge much less. So speed alone isn't the answer to everything.
On the other hand, there are a lot of jobs out there that involve plenty of typing. In most of them, the typing is usually the grunt work you have to get out of the way in order to do the fun part of the job: Emails, spreadsheets, reports, text chats, work logs, and assorted administrative chaff. There's also tons of nonprofit and volunteer accessibility work out there that's in desperate need of accurate human transcription. It's not just for altruistic purposes, either. Transcribe your YouTube videos, and it's now accessible not only to the Deaf and hard of hearing, but also to the people who found your video via a keyword in your transcript, people who watch muted videos on the sly at work, and people who are too impatient to watch something to the end if there isn't a transcript to give them the gist first. Add those four groups together, and you've got a pretty good chunk of the internet. At qwerty speeds, it can take almost an hour to transcribe and caption a five-minute video. With steno, you can do it in less than ten.
If I haven't convinced you by now that increasing your typing speed is worth your while, it's probably not gonna happen. I'll turn to the people who are already convinced. The people who play Typestriker and Typing Maniac and The Typing of the Dead, just to feel the flow of words through their fingers. The people who spend their leisure time making speed runs in video games and yearn for that same rush of screaming sweetness in their boring data entry jobs. The people who, bless their hearts, spend months retraining their fingers to use Dvorak for, at the most, a 20% increase in speed. These are the people who should welcome steno with a gleaming eye and a jackrabbit heart. They already know they want to be the fastest thing going. Now, with $60 and a bit of practice, 240 WPM is theirs for the taking. If this sounds like anyone you know, send 'em along to the Plover Project.
Part One: How to Speak With Your Fingers
Part Two: Writing and Coding
Part Three: The Ergonomic Argument
Part Four: Mobile and Wearable Computing
Part Five: Raw Speed
Part Six: CART, Court, and Captioning
In the introduction to the What Is Steno Good For? series I said, more or less facetiously, that this section would be devoted to "break onto the high score tables of online typing games." Speed for the sake of bragging rights is great and all, but I think there's more than that to be gained from being able to write three times faster than a qwerty typist.
When I tell people about Plover, they often say, "Well, I guess it's cool that you can type 240 WPM, but your job is to write down what other people are saying. I work alone, on my own time. Why would I go to the trouble of learning this whole new system? I type 60 WPM on a qwerty keyboard, and it's never been a problem for me." That's a fair question. Does the ability to type faster actually offer real-world advantages to people who aren't working as stenographers or transcriptionists? Which is the limiting factor: The input speed of the fingers or the output speed of the brain? And if there is a difference, is it only a quantitative one, or can it be qualitative as well?
I've talked about using steno to converse without speaking, the ease and fluency it lends to prose composition, its ergonomic benefits, and its potential in mobile applications. But speed is the most obvious and immediate benefit of steno over qwerty. It lets you get rid of the boring stuff quickly, leaving you more time for the interesting stuff. Whether that means being so blindingly fast at your dull data entry job that you get promoted to something requiring actual intelligence, or whether it means solidifying your ideas in text before they snarl up and blow away, it's a worthwhile thing to do. The counterargument to that, which I hear a lot, is that words just don't come that quickly; it takes longer to think of them than it does to write them, even at glacial typing speeds. That doesn't match up with my experience, and I don't think I'm the only one.
I'm willing to bet that the act of qwerty typing slows down the thoughts of many people. When I type on a qwerty keyboard, I feel my mind splitting along four consecutive but overlapping tracks: One, the word I want to write. Two, the way it's spelled. I'm a pretty good speller, but English is weird enough that the process is never completely automatic. Three, the series of five to ten finger motions it takes to type it. Four, the error checking mechanism that iterates over the first three and confirms that the correct word choice, orthography, and letter position have appeared onscreen. Usually I'll have already started typing the next word when I spot a spelling or typing error in the previous one, and by the time I've pressed backspace ten times to correct two transposed letters, my train of thought will have gotten all tangled up and I'll have to pause for a second to remember what I was writing. Even when I try to pace myself and type more slowly than usual, I'll make an error like this every few sentences, and my flow of composition will have been interrupted half a dozen times by end of the paragraph.
I know this sounds less like an argument for speed and more like the argument for fluency that I made in part two, but I don't think people realize how closely they're connected. Your mind won't let itself leap too far ahead of the words on the screen, so the rate of the words effectively throttles the rate of your thoughts. Add in the constant backspacing and rewriting, and three quarters of your mind is devoted to busywork, while the quarter devoted to producing actual words is forced to wait its turn.
How does steno consolidate those channels of word selection, spelling, typing, and error correction? Well, with word selection you're on your own; the steno machine can't help you there. But then you only have to conjure the sound of the word and stroke out its corresponding syllables. The spelling takes care of itself. No more pausing to remember where the double l goes in "parallel"; just write PA/RA/LEL and the computer will find the proper spelling for you. This is very useful when producing work for clients with divergent specifications. If you're copywriting for one company that prefers the spelling "Web site" (shudder) and another that favors "website", you don't have to spend any thought cycles retraining your fingers each time you switch; just define WEBT differently in your two client dictionaries and forget about it. Same with international spellings. Get both an American dictionary and a Canadian/British dictionary, and your writing can stay the same while your spelling toggles across borders. That also goes for diacritical marks, brand names, trademark symbols, and everything else it's a pain in the butt to write out each time; define it once, and you can just keep writing phonetically without worrying about the extra fiddly bits. Of course, you can do this to a certain extent with autocorrect and autoexpand settings in word processors, but they still require three to five keystrokes per word, and they don't easily accommodate several client or task-specific dictionaries.
That's spelling taken care of. What about typing accuracy? Qwerty requires your fingers to be constantly in motion, and their timing has to be split-second accurate if you want to avoid writing letters in the wrong order. Most people have a few fingers that are quicker than the rest, leading to persistent letter inversion and spacing errors. In steno, there is no space bar, so that's 1/5 of your errors obviated straight off. It's also far harder to make letter inversion errors, because the steno machine registers strokes not when each finger hits the key, but after all the keys have been released. You can compensate for a lazy or overactive finger merely by lifting your hands decisively from the keyboard at the end of each stroke. In steno, the wrist and forearm muscles get to set the pace, rather than the scattershot fast-twitch muscles of the fingers.
Pay attention to how many times you hit the backspace key when writing qwerty, even while typing slowly and evenly. The longer it takes to discover an error, the more backspaces you need to return to the spot and fix it, which means that you're forced either to be hypervigilant as you type or to spend nearly as much time backspacing as typing. In steno, the asterisk key deletes the last translation, not the last letter. Misstroke a six-letter word? Fix the error with a single stroke rather than six. No more leaning on the backspace key, waiting for the cursor to catch up. One stroke to write a word, one stroke to delete it. All of these shortcuts simplify the mental and physical bookkeeping you have to do during the writing process, which speeds up not just your typing, but your thoughts as well.
And what do you do with the time you save from that increased typing and thinking speed? The stuff that isn't typing. Typing is boring. It's not profitable. It's also not scalable. You might think that part of my scheme to hook people on steno would be to tell them how to make money off of it, but to be honest, unless you're really good, really fast, and really dedicated, you're not gonna be able to earn much from it. Realtime stenographers (I'm one myself) make a good living. Offline (i.e., non-realtime) transcription jobs, like gold farming, are only sustainably profitable these days in countries with pretty low costs of living. If there's a transcriptionist in the Philippines reading this who's thinking about using Plover to make their work more efficient, I'd be thrilled to bits to hear from 'em. But in the United States, Canada, and Europe, even stenographic speeds aren't likely to make you enough transcription money to live on. There are too many people working at far slower speeds who can afford to charge much less. So speed alone isn't the answer to everything.
On the other hand, there are a lot of jobs out there that involve plenty of typing. In most of them, the typing is usually the grunt work you have to get out of the way in order to do the fun part of the job: Emails, spreadsheets, reports, text chats, work logs, and assorted administrative chaff. There's also tons of nonprofit and volunteer accessibility work out there that's in desperate need of accurate human transcription. It's not just for altruistic purposes, either. Transcribe your YouTube videos, and it's now accessible not only to the Deaf and hard of hearing, but also to the people who found your video via a keyword in your transcript, people who watch muted videos on the sly at work, and people who are too impatient to watch something to the end if there isn't a transcript to give them the gist first. Add those four groups together, and you've got a pretty good chunk of the internet. At qwerty speeds, it can take almost an hour to transcribe and caption a five-minute video. With steno, you can do it in less than ten.
If I haven't convinced you by now that increasing your typing speed is worth your while, it's probably not gonna happen. I'll turn to the people who are already convinced. The people who play Typestriker and Typing Maniac and The Typing of the Dead, just to feel the flow of words through their fingers. The people who spend their leisure time making speed runs in video games and yearn for that same rush of screaming sweetness in their boring data entry jobs. The people who, bless their hearts, spend months retraining their fingers to use Dvorak for, at the most, a 20% increase in speed. These are the people who should welcome steno with a gleaming eye and a jackrabbit heart. They already know they want to be the fastest thing going. Now, with $60 and a bit of practice, 240 WPM is theirs for the taking. If this sounds like anyone you know, send 'em along to the Plover Project.
Friday, June 18, 2010
Steno 101, Lesson Zero
Steno 101: How to Do It
Steno 101: Lesson Zero
Steno 101: Lesson One
Steno 101: Lesson Two
Steno 101: Lesson Three
Steno 101: Lesson Four
Audio version
Before I start teaching you how to use that nice colorful chart I posted a while back, I'm going to talk about some of the fundamental principles of machine shorthand. Later I'll get into the nitty gritty, but for a first introduction, I just want to give a quick overview on what it takes to turn words into a code that a computer can turn back into words.
The Steno Machine
Today's steno machine is descended from a machine first invented by Ward Stone Ireland in 1910. A steno machine has anywhere between 24 and 37 keys: 22 capital letter keys, 1 to 4 asterisk keys, 1 to 9 number keys, and sometimes 2 optional accessory keys. The asterisk and number keys are all identical to one another; their numbers only vary for ergonomic reasons.
A chord made up of one or more of those keys (also known as a "steno outline") can represent a single letter, a syllable, or an entire word. The letters on the left hand side represent the beginning consonants of words, the keys operated by the thumbs represent vowels, and the letters on the right hand side represent the ending consonants. The asterisk key, struck by itself, represents a command to delete the last stroke from the record. When struck with other letters, it's a sort of wild card, and can be employed for several different purposes, all of which I'll get into later.
Each letter appears in a strictly defined order within a chord, and chords are always read from left to right. When writing down steno outlines for the benefit of colleagues or students, stenographers often employ a sort of pseudosteno, writing the English letters they mean to represent, rather than the actual keys they would press on the machine to write the chord. So the word "braving", which would properly be written "PWRAEUFPBG", would be written "BRAIFNG" in pseudosteno. The stenographer would know to translate the "B" to "PW", the "I" to "EU", and the "N" to "PB" when writing the outline on the machine. Because pseudosteno is much easier for beginners to read, I'm using it to write all the examples in this first lesson. Then in the second lesson I'll start teaching you those "B" to "PW" and "I" to "EU" mappings using the chart.
Principles of Steno
Audio version
Steno is commonly considered a phonetic writing system, though I would really call it more of a phonetic-mnemonic system. Each stenographer has a wide degree of latitude in determining how to write each word, and the criteria they use are fairly arbitrary, as long as the outlines are memorable and easy to write. Most one-syllable words are written phonetically, unless they contain letters out of steno order (STKPWHRAO*EUFRPBLGTSDZ -- more on that in the next lesson) or if they conflict with soundalike words or phrases. Soundalike words are usually differentiated by altering vowels, taking advantage of spelling differences, or inserting the asterisk key in the less common outline.
Resolving homophone conflicts -
Bear: BAER
Bare: BAIR
So: SO
Sew: SWE
Gram: GRAM
Graham: GRA*M
Multisyllabic words will sometimes be written phonetically, syllable by syllable (often with schwa sounds omitted) but will sometimes be truncated, inverted, or mashed together. When you see a slash between two steno outlines, it means that the word or phrase is made up of multiple strokes. A steno machine registers a stroke as complete when all the previously pressed keys have been released, so the slash indicates that the stenographer should lift all their fingers from the keyboard and then write the next chord in the outline.
Syllabic -
Harmonica: HAR/MON/KA
Bungle: BUNG/*L
Dreadful: DRED/FL
Phonetic, shwahs ommitted -
Committed: KMITD
Leverage: LEFRJ
As much as: SMUCHS
Inverted -
Greater: GRAERT
Destroy: SDROI
Really: LAOERL
Truncated -
Prejudice: PREJ
Superintendant: SUPT
Accident: SDENT
Briefs
Audio version
So far most of the outlines I've shown you fall under the category of "more or less phonetic". Another important tool in steno is the brief, also known as the "abbreviation", "short form", or "arbitrary". Briefs are simply non-phonetic mappings of steno outlines to English words or phrases. For instance, the phrase "from time to time" could be written out:
FROM/TAOIM/TO/TAOIM
(Four strokes)
Or it could be briefed:
FRIMT
(One stroke)
Either one will translate as "from time to time" if they're defined that way in the steno dictionary, but the second one is shorter and easier to write. The trade-off, of course, is that "FRIMT" doesn't really sound much like "from time to time", though it's got a hint of mnemonic resonance to hang your hat on. Briefs are counter-intuitive and sometimes hard to remember, but very useful. I'll be saying a lot more about how to invent and use them in subsequent lessons.
The Hyphen
Audio version
In the steno outlines I've shown you so far, you've seen capital letters, slashes, and asterisks. The only other character used in writing steno is the hyphen. Like the slash (and unlike the capital letters or the asterisk), the hyphen is a guideline to writing, and does not actually appear on the steno machine. It represents the middle of the keyboard and is used to differentiate keys written with the left hand from those written with the right hand. A letter with a hyphen after it, such as "T-", is written with the left hand; a letter with a hyphen in front of it, such as "-T", is written with the right hand. Some letters appear only on one or the other side of the keyboard, so it's not always necessary to use a hyphen when writing steno outlines. In this lesson I only use it when it's required for clarity.
Common Short Words
Audio version
Very common short words are usually briefed rather than written out, because the fewer keys a stenographer presses at a time, the less energy they expend and the less likely they are to make a misstroke. English uses words like "it", "the", "is", and "will" so often, it makes sense to write them with only one letter.
Outlines and briefs for common short words:
Can: KAN
Can: K-
Will: WIL
Will: L-
It: IT
It: T-
The: TH*E
The: -T
Is: IS
Is: S-
With: WI*T
With: W-
Be: B*E
Be: -B or B-
If: IF
If: F-
Steno Theories
Audio version
All English language steno theories are derived from the original Stenotype theory devised by Ireland when he invented the machine. Some modern theories depart radically from that first theory. Some differ very little. Theories tend to differ most in their treatment of briefs and how explicitly they write suffixes and vowel sounds. The controversy is often stated as "brief-heavy" versus "stroke-heavy", though it gets a bit more complicated than that. I'll probably write an article summarizing the main points of prevailing theories at some point, but in the Steno 101 series, I'm going to teach you the theory I use, which I adapted from NYCI theory, in turn descended from StenEd, one of the most popular and mainstream modern steno theories. Because I believe that steno dictionaries must be constructed by their stenographers to be truly useful, and that rote memorization of other people's systems is of limited utility, I'll try to leave plenty of jumping-off points where people can adapt the theory to their own purposes. In subsequent lessons, I'll also explain some of the inconsistencies in my dictionary, how they originated, and possible ways to improve them.
This is getting to be pretty lengthy for an introductory lesson, so I'll just mention one more element of stenographic writing, and then we'll try to put everything together.
Word Boundaries
Audio version
The steno machine saves an enormous number of keystrokes by eliminating the space bar. Word boundaries in steno are implicit rather than explicit, but the steno software is able to insert appropriate spaces remarkably well without needing to be told where to put them. In certain cases, however, the stenographer needs to be careful about word boundaries and work around possible overlaps. Misplaced spaces are known as "boundary errors", and they're usually resolved by dictionary tweaking, theory modification, or, in rare cases, brute force. If worse comes to worst, a stenographer can manually insert a space between strokes, though there are usually better ways to work around the problem.
Some examples of boundary errors with and without homophone conflicts:
We're going to the play right now.
He almost makes the play write itself.
The playwright is coming to the rehearsal.
In order to resolve a potential word boundary issue, the stenographer needs to weigh the likeliness of a boundary error against the trouble of figuring out how to avoid one.
"Play right", "play write" and "playwright" from the sentences above occur commonly enough in English that a means must be found to differentiate them. But what about the word "catalogues"? Ordinarily it would be written in pseudosteno:
KAT/LOGS
A smart stenographer would recognize that the components of that word are words in their own right -- "cat" and "logs" -- and try to construct hypothetical sentences in which they'd appear next to each other. For instance, you could say:
"That cat logs 12 hours a day down at the Post Office, catching mice."
It's possible to do, but it seems like a bit of a stretch, doesn't it? The stenographer will probably conclude that the phrase "cat logs" is not common enough to worry about, and put "catalogues" in their dictionary as KAT/LOGS.
Another example:
PAOI/NAOERNG
"From across the banquet hall, he could see the enormous pie nearing the dessert table as its six muscular bearers staggered beneath its bulk."
"This is a pioneering development in the field of pastry transportation technology."
Based on your knowledge of English, is the phrase "pie nearing" likely to come up in conversation as often as the word "pioneering"? No? Then setting the outline "PAOI/NAOERNG" to "pioneering" is probably safe. Still, this kind of probability check needs to be done whenever defining a multisyllabic word in a steno dictionary, and the decisions are not always as clearcut as "catalogues" and "pioneering".
Wrap-up
Audio version
You've learned about pseudosteno, differentiating soundalikes, syllabic and non-syllabic outline construction, using single letters for common words, and avoiding boundary errors. Let's put it all together. I'll write a paragraph in English and then show you how I'd render it into pseudosteno.
778 Keystrokes
171 Keystrokes
Legend:
BLUE = Briefed Short Words
GREEN = Punctuation
PURPLE = Multisyllabic Words With Schwas Omitted
Steno 101: Lesson Zero
Steno 101: Lesson One
Steno 101: Lesson Two
Steno 101: Lesson Three
Steno 101: Lesson Four
Audio version
Before I start teaching you how to use that nice colorful chart I posted a while back, I'm going to talk about some of the fundamental principles of machine shorthand. Later I'll get into the nitty gritty, but for a first introduction, I just want to give a quick overview on what it takes to turn words into a code that a computer can turn back into words.
The Steno Machine
Today's steno machine is descended from a machine first invented by Ward Stone Ireland in 1910. A steno machine has anywhere between 24 and 37 keys: 22 capital letter keys, 1 to 4 asterisk keys, 1 to 9 number keys, and sometimes 2 optional accessory keys. The asterisk and number keys are all identical to one another; their numbers only vary for ergonomic reasons.
A chord made up of one or more of those keys (also known as a "steno outline") can represent a single letter, a syllable, or an entire word. The letters on the left hand side represent the beginning consonants of words, the keys operated by the thumbs represent vowels, and the letters on the right hand side represent the ending consonants. The asterisk key, struck by itself, represents a command to delete the last stroke from the record. When struck with other letters, it's a sort of wild card, and can be employed for several different purposes, all of which I'll get into later.
Each letter appears in a strictly defined order within a chord, and chords are always read from left to right. When writing down steno outlines for the benefit of colleagues or students, stenographers often employ a sort of pseudosteno, writing the English letters they mean to represent, rather than the actual keys they would press on the machine to write the chord. So the word "braving", which would properly be written "PWRAEUFPBG", would be written "BRAIFNG" in pseudosteno. The stenographer would know to translate the "B" to "PW", the "I" to "EU", and the "N" to "PB" when writing the outline on the machine. Because pseudosteno is much easier for beginners to read, I'm using it to write all the examples in this first lesson. Then in the second lesson I'll start teaching you those "B" to "PW" and "I" to "EU" mappings using the chart.
Principles of Steno
Audio version
Steno is commonly considered a phonetic writing system, though I would really call it more of a phonetic-mnemonic system. Each stenographer has a wide degree of latitude in determining how to write each word, and the criteria they use are fairly arbitrary, as long as the outlines are memorable and easy to write. Most one-syllable words are written phonetically, unless they contain letters out of steno order (STKPWHRAO*EUFRPBLGTSDZ -- more on that in the next lesson) or if they conflict with soundalike words or phrases. Soundalike words are usually differentiated by altering vowels, taking advantage of spelling differences, or inserting the asterisk key in the less common outline.
Resolving homophone conflicts -
Bear: BAER
Bare: BAIR
So: SO
Sew: SWE
Gram: GRAM
Graham: GRA*M
Multisyllabic words will sometimes be written phonetically, syllable by syllable (often with schwa sounds omitted) but will sometimes be truncated, inverted, or mashed together. When you see a slash between two steno outlines, it means that the word or phrase is made up of multiple strokes. A steno machine registers a stroke as complete when all the previously pressed keys have been released, so the slash indicates that the stenographer should lift all their fingers from the keyboard and then write the next chord in the outline.
Syllabic -
Harmonica: HAR/MON/KA
Bungle: BUNG/*L
Dreadful: DRED/FL
Phonetic, shwahs ommitted -
Committed: KMITD
Leverage: LEFRJ
As much as: SMUCHS
Inverted -
Greater: GRAERT
Destroy: SDROI
Really: LAOERL
Truncated -
Prejudice: PREJ
Superintendant: SUPT
Accident: SDENT
Briefs
Audio version
So far most of the outlines I've shown you fall under the category of "more or less phonetic". Another important tool in steno is the brief, also known as the "abbreviation", "short form", or "arbitrary". Briefs are simply non-phonetic mappings of steno outlines to English words or phrases. For instance, the phrase "from time to time" could be written out:
FROM/TAOIM/TO/TAOIM
(Four strokes)
Or it could be briefed:
FRIMT
(One stroke)
Either one will translate as "from time to time" if they're defined that way in the steno dictionary, but the second one is shorter and easier to write. The trade-off, of course, is that "FRIMT" doesn't really sound much like "from time to time", though it's got a hint of mnemonic resonance to hang your hat on. Briefs are counter-intuitive and sometimes hard to remember, but very useful. I'll be saying a lot more about how to invent and use them in subsequent lessons.
The Hyphen
Audio version
In the steno outlines I've shown you so far, you've seen capital letters, slashes, and asterisks. The only other character used in writing steno is the hyphen. Like the slash (and unlike the capital letters or the asterisk), the hyphen is a guideline to writing, and does not actually appear on the steno machine. It represents the middle of the keyboard and is used to differentiate keys written with the left hand from those written with the right hand. A letter with a hyphen after it, such as "T-", is written with the left hand; a letter with a hyphen in front of it, such as "-T", is written with the right hand. Some letters appear only on one or the other side of the keyboard, so it's not always necessary to use a hyphen when writing steno outlines. In this lesson I only use it when it's required for clarity.
Common Short Words
Audio version
Very common short words are usually briefed rather than written out, because the fewer keys a stenographer presses at a time, the less energy they expend and the less likely they are to make a misstroke. English uses words like "it", "the", "is", and "will" so often, it makes sense to write them with only one letter.
Outlines and briefs for common short words:
Can: KAN
Can: K-
Will: WIL
Will: L-
It: IT
It: T-
The: TH*E
The: -T
Is: IS
Is: S-
With: WI*T
With: W-
Be: B*E
Be: -B or B-
If: IF
If: F-
Steno Theories
Audio version
All English language steno theories are derived from the original Stenotype theory devised by Ireland when he invented the machine. Some modern theories depart radically from that first theory. Some differ very little. Theories tend to differ most in their treatment of briefs and how explicitly they write suffixes and vowel sounds. The controversy is often stated as "brief-heavy" versus "stroke-heavy", though it gets a bit more complicated than that. I'll probably write an article summarizing the main points of prevailing theories at some point, but in the Steno 101 series, I'm going to teach you the theory I use, which I adapted from NYCI theory, in turn descended from StenEd, one of the most popular and mainstream modern steno theories. Because I believe that steno dictionaries must be constructed by their stenographers to be truly useful, and that rote memorization of other people's systems is of limited utility, I'll try to leave plenty of jumping-off points where people can adapt the theory to their own purposes. In subsequent lessons, I'll also explain some of the inconsistencies in my dictionary, how they originated, and possible ways to improve them.
This is getting to be pretty lengthy for an introductory lesson, so I'll just mention one more element of stenographic writing, and then we'll try to put everything together.
Word Boundaries
Audio version
The steno machine saves an enormous number of keystrokes by eliminating the space bar. Word boundaries in steno are implicit rather than explicit, but the steno software is able to insert appropriate spaces remarkably well without needing to be told where to put them. In certain cases, however, the stenographer needs to be careful about word boundaries and work around possible overlaps. Misplaced spaces are known as "boundary errors", and they're usually resolved by dictionary tweaking, theory modification, or, in rare cases, brute force. If worse comes to worst, a stenographer can manually insert a space between strokes, though there are usually better ways to work around the problem.
Some examples of boundary errors with and without homophone conflicts:
We're going to the play right now.
He almost makes the play write itself.
The playwright is coming to the rehearsal.
In order to resolve a potential word boundary issue, the stenographer needs to weigh the likeliness of a boundary error against the trouble of figuring out how to avoid one.
"Play right", "play write" and "playwright" from the sentences above occur commonly enough in English that a means must be found to differentiate them. But what about the word "catalogues"? Ordinarily it would be written in pseudosteno:
KAT/LOGS
A smart stenographer would recognize that the components of that word are words in their own right -- "cat" and "logs" -- and try to construct hypothetical sentences in which they'd appear next to each other. For instance, you could say:
"That cat logs 12 hours a day down at the Post Office, catching mice."
It's possible to do, but it seems like a bit of a stretch, doesn't it? The stenographer will probably conclude that the phrase "cat logs" is not common enough to worry about, and put "catalogues" in their dictionary as KAT/LOGS.
Another example:
PAOI/NAOERNG
"From across the banquet hall, he could see the enormous pie nearing the dessert table as its six muscular bearers staggered beneath its bulk."
"This is a pioneering development in the field of pastry transportation technology."
Based on your knowledge of English, is the phrase "pie nearing" likely to come up in conversation as often as the word "pioneering"? No? Then setting the outline "PAOI/NAOERNG" to "pioneering" is probably safe. Still, this kind of probability check needs to be done whenever defining a multisyllabic word in a steno dictionary, and the decisions are not always as clearcut as "catalogues" and "pioneering".
Wrap-up
Audio version
You've learned about pseudosteno, differentiating soundalikes, syllabic and non-syllabic outline construction, using single letters for common words, and avoiding boundary errors. Let's put it all together. I'll write a paragraph in English and then show you how I'd render it into pseudosteno.
Clifford held his breath as he waited to hear the hiss of the elevator. He checked his pockets for the fifth time. Still empty. He might belong to the dorkiest echelon of the Intelligence Squad, but he was determined to do his duty. There it went. He tiptoed rapidly out into the hall and dove through the doors as they opened. He let his breath out with a slow and shaking whoosh as his MagnaShoes engaged. Carefully, gingerly, he clomped up the wall and onto the high steel ceiling. Blood rushed to his head. The elevator's doors closed and he felt himself ascending. When they opened again, he would be ready. His fingers twitched above the cloth keypads mounted on his thighs, ready to write down everything they heard over the next 8 hours. He'd do Steno Batallion proud.
778 Keystrokes
KLIFRD HELD HIS BRE*T AZ E WAITD TO HAER -T H*IS FT LFR TP-PL E KHEKD HIS POKTS FOR -T FI*FT TAOIM TP-PL STIL EM/TI TP-PL E MAOIT BLONG TO*T DORK/YEFT ERB/LON FT INT/JENS SKWAD KW-BG BUT E WAS DERMD TO DO HIS DAOUT TP-PL THR T- WENT TP-PL E TIP/TOED RAEPLD OUT NAO -T HAUL SKP DOEF THRU -T DAORS AZ THE OEPD TP-PL E LET HIS BR*ET OUT NAI SLOE SKP SHAIK/G WHAORB AZ HIS MAG/NA/SHAOS EN/GAIJD TP-PL KAIFL/LI KW-BG JING/ERL KW-BG E KLO*MD UP -T WAUL SKP OENT -T HAOI STEEL KRAOENLG TP-PL BLAOD RURBD TO HIS HED TP-PL -T LFR AES DAORS KLOEFD SKP E FELT HIM/SEFL A/SEND/G TP-PL WHEN THE OEPD SGEN KW-BG E WO B DRAE TP-PL HIS FIRNGS TWIFPD BOF -T KLO*T KAOE/PADZ MOUNTD ON HIS THAOIS KW-BG DRAE TO WRAOIT DOUN EFRG THE HERD OEFR -T NEGT AET HOURS TP-PL *ED DO STO*IN BA/TAL/YON PROUD TP-PL
171 Keystrokes
Legend:
BLUE = Briefed Short Words
GREEN = Punctuation
PURPLE = Multisyllabic Words With Schwas Omitted
Monday, June 7, 2010
Mobile and Wearable Computing
What is Steno Good For?
Part One: How to Speak With Your Fingers
Part Two: Writing and Coding
Part Three: The Ergonomic Argument
Part Four: Mobile and Wearable Computing
Part Five: Raw Speed
Part Six: CART, Court, and Captioning
When I was 10 years old, my big brother William came to visit from California. He was 29, had a mohawk and mirrored sunglasses, worked as an electronic engineer for a tech company in Silicon Valley, and lived in a drainage tunnel because he didn't believe in rent.
My brother William, just after graduating from Cal Poly
He was, needless to say, the coolest human being on the planet. One day he came to talk to my 6th grade class about careers in computer science. He walked into the school wearing a head mounted display that projected green glowing lines of ASCII onto his eyeballs, controlled by a clunky beige laptop strapped to his chest (this was 1991), with a numeric keypad peripheral tied around his right leg, which he controlled using a chording system he'd invented himself. Actually, he'd built all of it himself, putting it together out of spare parts on a whim, and the instant I saw it, I wanted one just like it. It was my first exposure to the idea of writing via chording and my first taste of the dorktastic awesomeness that is wearable computing.
It shouldn't be too surprising that my brother abandoned his wearable rig shortly after he got it all working. It was too heavy and too hot, the display gave him eye strain, and the chording thigh pad was hopelessly slow and uncomfortable.
Not my brother. A guy named Steve Mann.
I've railed often enough against the inefficiencies of qwerty and its tedious one letter per keystroke input ratio, but the one letter per chord ratio of nearly all one-handed keypad systems (Twiddler, Frogpad, Chordite, et al.) is even slower, less accurate, and less ergonomic. The jacked-in cyberfuture of the '90s failed to materialize, and while computers continued to get faster and smaller, they remained external objects, migrating from our desks to our backpacks to our pockets, but refusing to become part of our wardrobes.
Fast forward 19 years. I'm now the age my brother was when he blew my mind by walking into Washington Middle School like an awesome apocalyptic cyborg. Every day I carry a 26-pound bag from my apartment in Upper Manhattan to the subway and settle in for an hour long commute to my office in downtown Brooklyn.
This is actually an old picture. I've gotten a new steno machine and a new laptop since then, and I don't carry the wireless router anymore, since I now use Bluetooth instead. But you get the general idea.
The bag contains one laptop (a Lenovo SL400) and one tablet PC (a Samsung Q1), both running Windows XP; two tripods; a Revolution Grand steno machine; a USB foot pedal for audio transcription; and a bunch of wires and cables. Sometimes I want to get my transcription work done on the train during my commute, so I set up the steno machine on its tripod, press the Samsung Q1 onto its heavy-duty velcro holder, plug in the USB foot pedal and my Sennheiser HD 280 Pro headphones, and start writing. It sounds less awkward than it is. When the train is crowded, that maneuver is all but impossible, and I'm forced to leave all my fancy transcription gear in my bag. Instead, I reach for my phone. I can't do transcription work on it, but it keeps me entertained.
Part three of What is Steno Good For? was composed entirely on my phone (a Blackberry Curve 8330) with two thumbs and a lot of patience. This is what mobile computing means in 2010: Hunting and pecking on a teeny-tiny qwerty keyboard at 20 WPM. Oh, my 10-year-old cyberpunk self would be weeping. But why are these pocket-sized systems currently the most convenient form of mobile text input? Is this as good as it's going to get? Will we be stuck tip-tapping on our phones with our thumbs forever? I sure hope not. The basic problem is this: If it's small enough to fit in a pocket, it's too small to type on efficiently. If it's too big to fit in a pocket, it's too inaccessible to be available on the spur of the moment. There are two potential solutions to the problem. One, clothing-integrated or clothing-mounted text input. Two, virtual space text input. The first one is easy enough to visualize. The second one is pretty far out there, so I won't be addressing it at any length, especially since I'm concerned that its usefulness will be limited without at least a minimal amount of haptic feedback.
As you've probably guessed, this is the least reality-based article in the What is Steno Good For? series. None of my ideas for wearable steno systems are anywhere close to currently available. My scheme is to get people hooked on free software, free steno training, and $60 steno machines first. Then maybe once there's a critical mass of steno-savvy consumers, some company will recognize the demand for efficient mobile computing and manufacture the wearable computing technology I've always dreamed of. My first job is to convince you that steno is actually an ideal solution to the finger size versus pocket size paradox I referred to before. But first, a quick detour on the subject of head-mounted displays. It's a problem that still hasn't been solved to anyone's satisfaction, even after several decades of trying. They're too heavy, too fragile, too stupid-looking, too headache-inducing. But let's posit that someday soon the problem will be solved, and we'll be able to go out and buy lightweight, stylish augmented reality overlay monitors that look just like ordinary pairs of eyeglasses.
So you're walking down the street wearing your AR specs, watching text hover gracefully over all of the local landmarks. What if you want to interact with that text? What if you want to work on your novel while doing your grocery shopping? Text chat with your friend in Belize while walking your dog? Or, you know, write a blog post on a crowded subway? If you're reading this on a desktop computer, put your qwerty keyboard in your lap. If you're not, pretend. Imagine the keyboard split in half and made flexible, melding with the fabric of your jeans and wrapping around each leg. Then imagine trying to type on it while walking. Do you see how many buttons that is? Even if you leave out some of the metakeys, you've got 33 keys plus enter, shift, and space. Make them big enough to fit your fingers, and they wrap clean around to the back of your thigh. Make them small enough to fit completely in the region where your fingers rest naturally, and it's impossible to type on them accurately. The human hand, the human leg, and the English alphabet seem to have irreconcilable differences.
See? Just... No.
But instead of 36 tiny little squares, what about two panels of ten nested rectangles, plus two more resting under each thumb? Compared to the qwerty layout it's both narrower and shorter, and those 24 panels (22 letters plus two asterisks) can be used to produce every letter of the alphabet plus punctuation, commands, and special characters to boot. At 260 words per minute, I might add -- but this article isn't about speed; I'll get to that in the next one. This is about walking and writing or sitting and writing or lying down and writing or doing the cha-cha or riding bumper cars or running a marathon and writing. Unlike on the qwerty keyboard, where you're constantly moving your hands up or down, left or right, leaving and returning to the home row, in steno the only fingers that ever leave their fixed positions are the right pointer for the asterisk and the right pinky for the D and Z keys. All the others stay put, making touch typing much easier, even under bumpy conditions.
Okay, this is really not doing it justice, but I don't have Photoshop, so it's the best you're gonna get.
Don't want to type on the tops of your thighs? Wear a hoodie and type on your abs with your hands in the pockets. Cross your arms and type on your biceps. The limited surface area required by the steno layout means that you could hypothetically write in steno more or less anywhere you can rest your fingers. Now, because it's a two-handed system it's still going to be inconvenient in some situations, but it's got a good shot at succeeding where the qwerty keyboard was inevitably doomed to fail.
I know this clothing-integrated stuff is still many years away, but even on the slightly less mobile front, I'm excited about the dual screen multi-touch laptops I've posted about recently. Putting steno on those seems like a good compromise between my bulky three-part transcription system and all these full-on wearable pipe dreams, and I know they'd be a big help to me in my daily commute. We take our technology with us almost everywhere we go these days, and we desperately need a more elegant way of interacting with it. I think steno could fit the bill.
PS: Just for laughs, here's my current most successful attempt at mobile steno computing. It is not a practical everyday solution. I use it to CART meetings and other events with Deaf or hard of hearing clients who need to walk around a lot; it worked quite well for a meet-and-greet tour of a client's potential grad department, for instance. But this sort of thing is way too bulky and weird-looking for anything but special occasions. It uses my Samsung Q1, my Revolution Grand, some gaffer's tape, and a Connect-a-Desk. Far from perfect, but all I've got for now.
Part One: How to Speak With Your Fingers
Part Two: Writing and Coding
Part Three: The Ergonomic Argument
Part Four: Mobile and Wearable Computing
Part Five: Raw Speed
Part Six: CART, Court, and Captioning
When I was 10 years old, my big brother William came to visit from California. He was 29, had a mohawk and mirrored sunglasses, worked as an electronic engineer for a tech company in Silicon Valley, and lived in a drainage tunnel because he didn't believe in rent.
My brother William, just after graduating from Cal Poly
He was, needless to say, the coolest human being on the planet. One day he came to talk to my 6th grade class about careers in computer science. He walked into the school wearing a head mounted display that projected green glowing lines of ASCII onto his eyeballs, controlled by a clunky beige laptop strapped to his chest (this was 1991), with a numeric keypad peripheral tied around his right leg, which he controlled using a chording system he'd invented himself. Actually, he'd built all of it himself, putting it together out of spare parts on a whim, and the instant I saw it, I wanted one just like it. It was my first exposure to the idea of writing via chording and my first taste of the dorktastic awesomeness that is wearable computing.
It shouldn't be too surprising that my brother abandoned his wearable rig shortly after he got it all working. It was too heavy and too hot, the display gave him eye strain, and the chording thigh pad was hopelessly slow and uncomfortable.
Not my brother. A guy named Steve Mann.
I've railed often enough against the inefficiencies of qwerty and its tedious one letter per keystroke input ratio, but the one letter per chord ratio of nearly all one-handed keypad systems (Twiddler, Frogpad, Chordite, et al.) is even slower, less accurate, and less ergonomic. The jacked-in cyberfuture of the '90s failed to materialize, and while computers continued to get faster and smaller, they remained external objects, migrating from our desks to our backpacks to our pockets, but refusing to become part of our wardrobes.
Fast forward 19 years. I'm now the age my brother was when he blew my mind by walking into Washington Middle School like an awesome apocalyptic cyborg. Every day I carry a 26-pound bag from my apartment in Upper Manhattan to the subway and settle in for an hour long commute to my office in downtown Brooklyn.
This is actually an old picture. I've gotten a new steno machine and a new laptop since then, and I don't carry the wireless router anymore, since I now use Bluetooth instead. But you get the general idea.
The bag contains one laptop (a Lenovo SL400) and one tablet PC (a Samsung Q1), both running Windows XP; two tripods; a Revolution Grand steno machine; a USB foot pedal for audio transcription; and a bunch of wires and cables. Sometimes I want to get my transcription work done on the train during my commute, so I set up the steno machine on its tripod, press the Samsung Q1 onto its heavy-duty velcro holder, plug in the USB foot pedal and my Sennheiser HD 280 Pro headphones, and start writing. It sounds less awkward than it is. When the train is crowded, that maneuver is all but impossible, and I'm forced to leave all my fancy transcription gear in my bag. Instead, I reach for my phone. I can't do transcription work on it, but it keeps me entertained.
Part three of What is Steno Good For? was composed entirely on my phone (a Blackberry Curve 8330) with two thumbs and a lot of patience. This is what mobile computing means in 2010: Hunting and pecking on a teeny-tiny qwerty keyboard at 20 WPM. Oh, my 10-year-old cyberpunk self would be weeping. But why are these pocket-sized systems currently the most convenient form of mobile text input? Is this as good as it's going to get? Will we be stuck tip-tapping on our phones with our thumbs forever? I sure hope not. The basic problem is this: If it's small enough to fit in a pocket, it's too small to type on efficiently. If it's too big to fit in a pocket, it's too inaccessible to be available on the spur of the moment. There are two potential solutions to the problem. One, clothing-integrated or clothing-mounted text input. Two, virtual space text input. The first one is easy enough to visualize. The second one is pretty far out there, so I won't be addressing it at any length, especially since I'm concerned that its usefulness will be limited without at least a minimal amount of haptic feedback.
As you've probably guessed, this is the least reality-based article in the What is Steno Good For? series. None of my ideas for wearable steno systems are anywhere close to currently available. My scheme is to get people hooked on free software, free steno training, and $60 steno machines first. Then maybe once there's a critical mass of steno-savvy consumers, some company will recognize the demand for efficient mobile computing and manufacture the wearable computing technology I've always dreamed of. My first job is to convince you that steno is actually an ideal solution to the finger size versus pocket size paradox I referred to before. But first, a quick detour on the subject of head-mounted displays. It's a problem that still hasn't been solved to anyone's satisfaction, even after several decades of trying. They're too heavy, too fragile, too stupid-looking, too headache-inducing. But let's posit that someday soon the problem will be solved, and we'll be able to go out and buy lightweight, stylish augmented reality overlay monitors that look just like ordinary pairs of eyeglasses.
So you're walking down the street wearing your AR specs, watching text hover gracefully over all of the local landmarks. What if you want to interact with that text? What if you want to work on your novel while doing your grocery shopping? Text chat with your friend in Belize while walking your dog? Or, you know, write a blog post on a crowded subway? If you're reading this on a desktop computer, put your qwerty keyboard in your lap. If you're not, pretend. Imagine the keyboard split in half and made flexible, melding with the fabric of your jeans and wrapping around each leg. Then imagine trying to type on it while walking. Do you see how many buttons that is? Even if you leave out some of the metakeys, you've got 33 keys plus enter, shift, and space. Make them big enough to fit your fingers, and they wrap clean around to the back of your thigh. Make them small enough to fit completely in the region where your fingers rest naturally, and it's impossible to type on them accurately. The human hand, the human leg, and the English alphabet seem to have irreconcilable differences.
See? Just... No.
But instead of 36 tiny little squares, what about two panels of ten nested rectangles, plus two more resting under each thumb? Compared to the qwerty layout it's both narrower and shorter, and those 24 panels (22 letters plus two asterisks) can be used to produce every letter of the alphabet plus punctuation, commands, and special characters to boot. At 260 words per minute, I might add -- but this article isn't about speed; I'll get to that in the next one. This is about walking and writing or sitting and writing or lying down and writing or doing the cha-cha or riding bumper cars or running a marathon and writing. Unlike on the qwerty keyboard, where you're constantly moving your hands up or down, left or right, leaving and returning to the home row, in steno the only fingers that ever leave their fixed positions are the right pointer for the asterisk and the right pinky for the D and Z keys. All the others stay put, making touch typing much easier, even under bumpy conditions.
Okay, this is really not doing it justice, but I don't have Photoshop, so it's the best you're gonna get.
Don't want to type on the tops of your thighs? Wear a hoodie and type on your abs with your hands in the pockets. Cross your arms and type on your biceps. The limited surface area required by the steno layout means that you could hypothetically write in steno more or less anywhere you can rest your fingers. Now, because it's a two-handed system it's still going to be inconvenient in some situations, but it's got a good shot at succeeding where the qwerty keyboard was inevitably doomed to fail.
I know this clothing-integrated stuff is still many years away, but even on the slightly less mobile front, I'm excited about the dual screen multi-touch laptops I've posted about recently. Putting steno on those seems like a good compromise between my bulky three-part transcription system and all these full-on wearable pipe dreams, and I know they'd be a big help to me in my daily commute. We take our technology with us almost everywhere we go these days, and we desperately need a more elegant way of interacting with it. I think steno could fit the bill.
PS: Just for laughs, here's my current most successful attempt at mobile steno computing. It is not a practical everyday solution. I use it to CART meetings and other events with Deaf or hard of hearing clients who need to walk around a lot; it worked quite well for a meet-and-greet tour of a client's potential grad department, for instance. But this sort of thing is way too bulky and weird-looking for anything but special occasions. It uses my Samsung Q1, my Revolution Grand, some gaffer's tape, and a Connect-a-Desk. Far from perfect, but all I've got for now.