Rethinking the Stenotype (very long)
765 views
Skip to first unread message
Peter DeBiase
Nov 27, 2015, 9:54:31 AM11/27/15
to Plover
Dear Fellow Plover Lovers,
I got here the way most of us probably got here - I just wanna go fast. I am a Japanese to English patent translator by profession (and an enterprising Python/Autohotkey hacker by hobby/side-profession). Like many independent writers, I get paid by the word, so more words and more words faster = more money. And let's just be honest, who wouldn't want to type at 200+ WPM, even if only for purposes of correspondence?
Subsequent research made it very clear that this is not a new idea. Not even close. The idea of wanting to write stuff really really fast is almost as old as language itself. Over the years this has produced a wide variety of written shorthands (some of the notable "modern" ones being Pitman, Gregg, and Teeline (1800s-early/mid 1900s)), which in more recent times seem to have been superseded by machine-based shorthand systems (StenEd, Phoenix, Stenomaster, Magnum Steno (mid/late 1900s-2000s?)).
Now we are bringing steno into the 21st century with Plover. As I read through the Learn Plover! guide, I am concerned that Plover may be being fit to what is perhaps an outdated technology - the stenotype. I am hoping that those of you who are more familiar in the world of steno and Plover might be willing to address a few questions I have.
1. Is there any reason we still need to have only 22 keys available for chording?
QWERTY keyboards, in all their inadequacy, have dedicated keys for each of the 26 letters of the alphabet, plus 10 dedicated keys for the numbers. Furthermore, it is only moderately difficult to become quite proficient at actuating all 36 of these little villains. This being the case, is there any reason we should still have to simultaneously press 6 keys (or 3 intersections between keys) to get a left-hand Z on the steno keyboard, or 4 keys (2 intersections between keys) for a left-hand G? Couldn't we just press a Z or a G switch? My early experimentation with Plover has given me a true awe for professional stenographers - chords that require more than three or so keys to be pressed are hard. Very hard. Prohibitively hard...
What are some possible solutions? I'm sure many of you are familiar with the ErgoDox keyboard. The ErgoDox has 20 "base" letter/number keys on each half of the keyboard, plus five keys for each thumb, and that's before we start considering layers added by modifiers like Control, Alt, and Shift and before we start considering the programmable layers baked into the ErgoDox design itself.
With something like that, we could realistically put each consonant on its very own key on both sides of the keyboard, use one thumb cluster for short vowels, and use the other thumb cluster for long vowels and thereby essentially have a full system of "tokens" for representing the phonemes (sounds) of the English language (also removing the need to use double or triple vowel key chords to access the various vowel sounds). In other words, this would make it possible to produce virtually every phoneme/syllable with a chord of no more than approximately three keys in total (initial left hand consonant, middle vowel sound, and ending right hand consonant - note that this is not counting the blended consonant sounds like "st" and "pr", which hopefully wouldn't be too hard to handle).
And this is all before we start applying various the clever optimizations such as double-purposing consonants (such as Q and K) and folding in common endings (-ed, -ing) that are already implemented in modern machine-based steno theories. Such optimizations could reduce the total number of consonant/vowel keys needed while still keeping a single dedicated key for each phonetic sound.
Here are some examples of words which currently make me cry to try to chord in Plover but might potentially become more accessible given a scheme with additional keys such as that described above. Also, attached is a rough example of what an ErgoDox-based steno keyboard layout with additional chording switches might look like. Note that this layout is not optimized for relative syllable frequency or ease of pressing common syllabic combinations - this is just me throwing an idea out there. It is partially based on the existing steno keyboard with the extra consonants thrown in where there's room (note also that we keep the ZXCV keys in their current location on the QWERTY keyboard to facilitate commonly used keyboard shortcuts).
"tolerate"
TOL/RAEUT - easy 3-key chord/hard 5-key chord
=>
TOL/RāT - easy 3-key chord/easy 3-key chord
"please"
PHRAOES - very hard 7-key chord
=>
PLēZ - manageable 4-key chord (or just PLZ if we wanted to do some briefing trickery because we have so many consonant keys available)
This also makes it possible to retain the left-to-right spelling order of a word in almost all cases. Of course there are still bound to be collisions and word boundary resolutions to consider, but no more so than in existing steno theories.
How do we handle numbers, you might wonder. Flick one of the switches on the left or right half of the keyboard to access one of the other keyboard layers and turn the other half into a 10-key numpad. 10-key numpads are pretty good for entering numbers.
2. Is it currently possible to make Plover "listen" for keys other than the standard 22 Steno keys (STKPWHRAO*EUFRPBLGTSDZ)?
This would make it possible to take advantage of additional keys/keycodes for chording purposes in order to achieve something like the layout described above. If not, how much work would be involved in making this possible? (I am willing to volunteer my time and coding experience.)
3. Is it possible to make Plover actively differentiate between single-key presses and chords?
This would make it possible to do two very cool things. First, it would allow people to continue to use and type on their QWERTY (or alternative "conventional" keyboard layout - DVORAK, Colemak, Workman, etc.) keyboards with Plover in the background on the lookout for chords, potentially easing the transition into full-on chording. Using a text expansion scheme such as that in Autohotkey would make it possible to still take advantage of one and two letter briefs already present in Plover (K for "can", left-hand S for "as", FT for "of the", etc.), which could also be input sequentially (Press F, Press T, press Space => auto-expand to "of the", or chord FT => Plover catches chord and translates to "of the").
Next, and equally important, this would remove some of the need for a dedicated steno keyboard. It seems to me that you just cannot achieve your maximum Plover potential on a non-steno specialized keyboard. The vanilla Microsoft Sidewinder or any conventional keyboard just doesn't cut it as a stenotype without serious modifications. Stenosaurus and other hardware solutions seem eminently on the horizon, but no (reasonably priced) de facto hardware solution has yet emerged. And the ErgoDox has problems of its own (not everyone wants to solder together their own keyboard, although the upcoming ErgoDox EZ solves that problem) and may not even be well-suited to use with Plover. I won't know until I get my hands on one, but how cool would it be if you could use a single keyboard for all of your text input tasks, both sequential (QWERTY-esque input) or chorded (Plover-esque) input (to say nothing of entertainment/gaming).
Conclusion
I'm not trying to reinvent the wheel. A lot of very smart people have already done a lot of work on written and machine-based shorthand systems, and many of you similarly very smart people have done a lot of amazing work getting Plover to where it is today. But as long we are bringing steno into the 21st century, might not it be prudent to stop and consider optimizations we could make to steno theory itself as well? Is there a way we can take the strengths and brevity of historic shorthand systems like Pitman and Gregg and combine them with the strengths of contemporary machine-based theories to produce the cleanest, fastest, fully deterministic method of stenographic writing to date?
Here's to wondering. Please be so kind as to share any information or thoughts you may have.
Pete
I got here the way most of us probably got here - I just wanna go fast. I am a Japanese to English patent translator by profession (and an enterprising Python/Autohotkey hacker by hobby/side-profession). Like many independent writers, I get paid by the word, so more words and more words faster = more money. And let's just be honest, who wouldn't want to type at 200+ WPM, even if only for purposes of correspondence?
Subsequent research made it very clear that this is not a new idea. Not even close. The idea of wanting to write stuff really really fast is almost as old as language itself. Over the years this has produced a wide variety of written shorthands (some of the notable "modern" ones being Pitman, Gregg, and Teeline (1800s-early/mid 1900s)), which in more recent times seem to have been superseded by machine-based shorthand systems (StenEd, Phoenix, Stenomaster, Magnum Steno (mid/late 1900s-2000s?)).
Now we are bringing steno into the 21st century with Plover. As I read through the Learn Plover! guide, I am concerned that Plover may be being fit to what is perhaps an outdated technology - the stenotype. I am hoping that those of you who are more familiar in the world of steno and Plover might be willing to address a few questions I have.
1. Is there any reason we still need to have only 22 keys available for chording?
QWERTY keyboards, in all their inadequacy, have dedicated keys for each of the 26 letters of the alphabet, plus 10 dedicated keys for the numbers. Furthermore, it is only moderately difficult to become quite proficient at actuating all 36 of these little villains. This being the case, is there any reason we should still have to simultaneously press 6 keys (or 3 intersections between keys) to get a left-hand Z on the steno keyboard, or 4 keys (2 intersections between keys) for a left-hand G? Couldn't we just press a Z or a G switch? My early experimentation with Plover has given me a true awe for professional stenographers - chords that require more than three or so keys to be pressed are hard. Very hard. Prohibitively hard...
What are some possible solutions? I'm sure many of you are familiar with the ErgoDox keyboard. The ErgoDox has 20 "base" letter/number keys on each half of the keyboard, plus five keys for each thumb, and that's before we start considering layers added by modifiers like Control, Alt, and Shift and before we start considering the programmable layers baked into the ErgoDox design itself.
With something like that, we could realistically put each consonant on its very own key on both sides of the keyboard, use one thumb cluster for short vowels, and use the other thumb cluster for long vowels and thereby essentially have a full system of "tokens" for representing the phonemes (sounds) of the English language (also removing the need to use double or triple vowel key chords to access the various vowel sounds). In other words, this would make it possible to produce virtually every phoneme/syllable with a chord of no more than approximately three keys in total (initial left hand consonant, middle vowel sound, and ending right hand consonant - note that this is not counting the blended consonant sounds like "st" and "pr", which hopefully wouldn't be too hard to handle).
And this is all before we start applying various the clever optimizations such as double-purposing consonants (such as Q and K) and folding in common endings (-ed, -ing) that are already implemented in modern machine-based steno theories. Such optimizations could reduce the total number of consonant/vowel keys needed while still keeping a single dedicated key for each phonetic sound.
Here are some examples of words which currently make me cry to try to chord in Plover but might potentially become more accessible given a scheme with additional keys such as that described above. Also, attached is a rough example of what an ErgoDox-based steno keyboard layout with additional chording switches might look like. Note that this layout is not optimized for relative syllable frequency or ease of pressing common syllabic combinations - this is just me throwing an idea out there. It is partially based on the existing steno keyboard with the extra consonants thrown in where there's room (note also that we keep the ZXCV keys in their current location on the QWERTY keyboard to facilitate commonly used keyboard shortcuts).
"tolerate"
TOL/RAEUT - easy 3-key chord/hard 5-key chord
=>
TOL/RāT - easy 3-key chord/easy 3-key chord
"please"
PHRAOES - very hard 7-key chord
=>
PLēZ - manageable 4-key chord (or just PLZ if we wanted to do some briefing trickery because we have so many consonant keys available)
This also makes it possible to retain the left-to-right spelling order of a word in almost all cases. Of course there are still bound to be collisions and word boundary resolutions to consider, but no more so than in existing steno theories.
How do we handle numbers, you might wonder. Flick one of the switches on the left or right half of the keyboard to access one of the other keyboard layers and turn the other half into a 10-key numpad. 10-key numpads are pretty good for entering numbers.
2. Is it currently possible to make Plover "listen" for keys other than the standard 22 Steno keys (STKPWHRAO*EUFRPBLGTSDZ)?
This would make it possible to take advantage of additional keys/keycodes for chording purposes in order to achieve something like the layout described above. If not, how much work would be involved in making this possible? (I am willing to volunteer my time and coding experience.)
3. Is it possible to make Plover actively differentiate between single-key presses and chords?
This would make it possible to do two very cool things. First, it would allow people to continue to use and type on their QWERTY (or alternative "conventional" keyboard layout - DVORAK, Colemak, Workman, etc.) keyboards with Plover in the background on the lookout for chords, potentially easing the transition into full-on chording. Using a text expansion scheme such as that in Autohotkey would make it possible to still take advantage of one and two letter briefs already present in Plover (K for "can", left-hand S for "as", FT for "of the", etc.), which could also be input sequentially (Press F, Press T, press Space => auto-expand to "of the", or chord FT => Plover catches chord and translates to "of the").
Next, and equally important, this would remove some of the need for a dedicated steno keyboard. It seems to me that you just cannot achieve your maximum Plover potential on a non-steno specialized keyboard. The vanilla Microsoft Sidewinder or any conventional keyboard just doesn't cut it as a stenotype without serious modifications. Stenosaurus and other hardware solutions seem eminently on the horizon, but no (reasonably priced) de facto hardware solution has yet emerged. And the ErgoDox has problems of its own (not everyone wants to solder together their own keyboard, although the upcoming ErgoDox EZ solves that problem) and may not even be well-suited to use with Plover. I won't know until I get my hands on one, but how cool would it be if you could use a single keyboard for all of your text input tasks, both sequential (QWERTY-esque input) or chorded (Plover-esque) input (to say nothing of entertainment/gaming).
Conclusion
I'm not trying to reinvent the wheel. A lot of very smart people have already done a lot of work on written and machine-based shorthand systems, and many of you similarly very smart people have done a lot of amazing work getting Plover to where it is today. But as long we are bringing steno into the 21st century, might not it be prudent to stop and consider optimizations we could make to steno theory itself as well? Is there a way we can take the strengths and brevity of historic shorthand systems like Pitman and Gregg and combine them with the strengths of contemporary machine-based theories to produce the cleanest, fastest, fully deterministic method of stenographic writing to date?
Here's to wondering. Please be so kind as to share any information or thoughts you may have.
Pete
Tony Wright
Nov 27, 2015, 10:37:59 AM11/27/15
to plove...@googlegroups.com
I've been interested in how the steno keyboard could be different, but from reading your e-mail, I see our concerns are rather different. For me, a complex chord in itself is not difficult. I think that may depend on the kind of keyboard you are using. Chords may be difficult on n-key rollover qwerty keyboards as you get into the higher numbers of key depressions, but I have two electronic stenotype machines, and as long as the sensitivity of the keys is adjusted right, striking several keys at once is no problem for me.
What is a problem for me personally is leaving home row. I hate leaving home row. I hate the asterisk for that reason. Many times, when I make a mistake, it's because I had to leave home row.
I have thought about a three-row steno keyboard that would still involve chording, but would obviate the need to ever leave home row. That would be a dream for me.
--Tony
--
You received this message because you are subscribed to the Google Groups "Plover" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ploversteno...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Joshua Taylor
Nov 27, 2015, 10:44:20 AM11/27/15
to plove...@googlegroups.com
I haven't learned Plover (or any steno theory) yet, but I expect
that more keys would slow one down too much by forcing one to have
deadweight time where one was moving one's fingers over the next
keys.
Also, your setup has the apple, egg, igloo, ominous, under sounds as well as the aim, ego, I, oats, universe sounds as far as I can tell. These are the sounds that are taught to preschoolers (and never to my knowledge corrected if they don't research it themselves) in English. But they do not represent the phonological inventory of English vowels. I think that if a steno theory was to be created on the idea of one switch for one sound, it would be based on phones, not phonemes as your's seems to be.
-- Joshua Taylor
Also, your setup has the apple, egg, igloo, ominous, under sounds as well as the aim, ego, I, oats, universe sounds as far as I can tell. These are the sounds that are taught to preschoolers (and never to my knowledge corrected if they don't research it themselves) in English. But they do not represent the phonological inventory of English vowels. I think that if a steno theory was to be created on the idea of one switch for one sound, it would be based on phones, not phonemes as your's seems to be.
-- Joshua Taylor
Joshua Taylor
Nov 27, 2015, 10:46:12 AM11/27/15
to plove...@googlegroups.com
I agree with Wright insomuch as someone who has yet to learn steno
can agree or disagree with any opinion on this topic.
-- Joshua Taylor
-- Joshua Taylor
Peter DeBiase
Nov 27, 2015, 11:25:53 AM11/27/15
to plove...@googlegroups.com
@Tony
I uncovered something during my research that may be of interest to you. Check this out. The caption reads "A 104-key USB keyboard adapted into a chording keyboard. All phonetic
keystrokes may be accomplished by one and two-key chords of the home
keys on the top row."
This looks very much like your imagined home row-only steno keyboard. It's simplicity was intriguing to me as well; however, I was unable to uncover any further information on it. Furthermore, you would need to develop a steno theory to support that particular key layout or re-purpose an existing steno theory. I believe the ErgoDox would be suitable for such an application, although it would involve considerable tinkering.
You may also be interested in having a look at this Japanese steno keyboard for inspiration (at around 2:00). Japanese has 52 total phonetic sounds, and the steno keyboard depicted seems to have a single home row for consonants and one (thumb row) for vowels, along with some other helpful keys (10-key numpad etc.).
@Joshua
The layout I posted was only a very rough example of what might be possible. I am also personally sailing in mostly uncharted waters.
I agree that "long" and "short" vowels do not tell the whole story. The Pitman shorthand system defines 25 single consonant sounds, 24 double consonant sounds, and 16 vowel sounds. The Gregg shorthand system defines 20 consonants and 14 vowel sounds and covers consonant blends by blending the appropriate strokes.
In comparison, my (admittedly shallow) understanding of the theory upon which Plover is built (StenEd?) is that 5 short vowels, 5 long vowels, 3 diphthongs, and 2 vowel "disambiguators" are defined, for a total of 15 vowel "things".
All of the above notwithstanding, I'm mainly curious whether it is possible to have Plover listen for additional keys for use in chords and whether Plover can differentiate between single-key input and chords so that a sequential input scheme (like QWERTY) could be used simultaneously in conjunction with a chording scheme (like Plover).
-Pete
--
You received this message because you are subscribed to a topic in the Google Groups "Plover" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ploversteno/GhMcoSh6qmA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ploversteno...@googlegroups.com.
Theodore Morin
Nov 27, 2015, 11:32:28 AM11/27/15
to Plover
I'll address your concerns, I've had similar thoughts.
1. The number of keys.
Your concern is based off of the fact that multi-key combinations are hard, or "very hard". I'll lay down some numbers to bring this down to reality. In stenography, when you reach high speeds, you are no longer hitting or thinking about keys. It's much more the shape of your hand. You move your fingers to the needed shape and then lower your arm to strike.
This movement is difficult on a traditional NKRO keyboard. I learned on my ErgoDox with cherry clears—that's 60 grams of force to actuation, plus a big bump. Then, I got another ErgoDox with red switches, which brought the force of each key down to 45 grams for actuation. It was much better!
Right now, I'm using a Tréal—this brings the actuation point for each key down to *15 grams*. Full bottoming out is 30 grams, not even enough to start travel on the Cherry MX switch. It's so much insanely easier to stroke, I can't even describe it.
I was messaging Mirabai on Twitter, I asked her how much force she had to give her Infinity Ergonomic in order to actuate. She couldn't tell me—because even a dime would depress the key, and she could blow her breath to activate the switch between 3 and 6 inches away. Clearly, at this point, there's no barrier for comfort! You just shape the hand and the force makes every chord much easier.
With stenography, a large portion of the effort is learning how to properly block your hand, making sure that you don't drift away from the correct hand position and accurately hit the keys you want to hit. It shouldn't be hard (even though cheap hardware makes it seem that way).
2. Making Plover listen to more than 22 keys
Plover is currently quite hard coded in terms of how many keys it can listen to. Some have made different builds where they change the hard coding to their needed layout. Currently, Plover doesn't support different layouts. However, I'd like it to. It's a largish development issue, but I'm totally welcome to others trying their hand at it. Basically, what we need is a way to store keyboard layouts and then use them in the program. The steno layout is a set of keys, you have left hand keys, right hand keys, and center keys. You have "modifier" keys (like the number bar) and then a map of the modifier keys (you want S- when modified with # to be 1). Then you basically define the order of the keys. Left: 0: S, 1: T, 2: K… Center: 0: A, 1: O, 2: *, 3: E, 4: U, and right: 0: F…
Then you have to also consider that some locales may read right to left, and I'm not totally sure how I'd handle that. I might keep the logic inside Plover going left to right, but just switch the reading of the layout and translations. So, no, Plover can't do this now, but I really want it to because it's an often request feature and would allow users to create their own layouts and implement new languages.
3. Plover uses single key presses for words already…and any qwerty typist will definitely be hitting chords accidentally all the time if they are writing with any semblance of speed. I've thought about this problem before, and I really don't see a way around it. I think the systems are not easily melded together. Otherwise, you're down to arbitrary shortcuts anyways, which the computer already does/can do with the help of AutoHotkey or similar. Again, if someone can make something viable, Plover's GitHub is very open to pull requests.
All that being said, I really appreciate your enthusiasm. I think that stenography could definitely be improved as nothing is perfect, but it requires a rare mind, motivation, talent, and luck to make it happen. The current system has a lot of thought and experience put into it. It's a great system and should not be discarded because it was invented before computers existed. It's still very good and I find it quite adequate for programming and extremely useful for any other writing.
Thanks for posting to the group and striking these fascinating conversations 😁
--
Marc Weber
Nov 27, 2015, 11:59:47 AM11/27/15
to ploversteno
I've had the same "question" - is plover still up to date?
If you get a "current tablet' you have 10 touch typing fingers
and "pressure" detection eventually. You can even have 'hit and move"
gestures. Eg when coding you often have different kind of spellings
take_that or takeThat .. also "apps" would be a way to refinance
investments.
Also such tablets are very cheap - and using synergy like connections
you can type to computers easily.
I haven't had time to think about this all.
Marc Weber
If you get a "current tablet' you have 10 touch typing fingers
and "pressure" detection eventually. You can even have 'hit and move"
gestures. Eg when coding you often have different kind of spellings
take_that or takeThat .. also "apps" would be a way to refinance
investments.
Also such tablets are very cheap - and using synergy like connections
you can type to computers easily.
I haven't had time to think about this all.
Marc Weber
Drew Neil
Nov 27, 2015, 3:57:03 PM11/27/15
to plove...@googlegroups.com
In a recent episode of The Allusionist podcast, Leslie Scott had this to say about the game of Scrabble:
Not many people realise the success of Scrabble is based on a statistician figuring out the scoring system - it's the first time someone had a word game where the score of the word game was based on him researching very thoroughly the number of times a particular letter was used. He scoured the New York Times for years counting how many times an E comes up, a Z, etc. Hence the numbers of those letters in the stack to start with was based on this, as is the scoring. And it works, whether or not you like the game. We have a mathematician to thank.
(Here’s the transcript: http://www.theallusionist.org/transcripts/word-play)
That made me think of stenography. The letters that appear most frequently can be stroked with fewer keys, while the rarer letters require more keys to be pressed simultaneously. That’s no accident. Whoever designed the steno keyboard layout must have taken a similar approach to the person who designed the game of scrabble.
Then there’s the matter of Steno Order, which is deviously well thought out. Scrabble players know that the letter ’S’ is easy to place on the board, because it can be appended to most singular nouns to form the plural. And Steno Order reflects this by having ’S’ (and sound-alike ‘Z’) towards the end of the sequence. Similarly, many verbs can take ‘-ed’ as a suffix, so the ‘-D’ key (which produces ‘-ed’) also appears towards the end of the steno order sequence.
If you study the steno keyboard layout and steno order, you’ll find loads of places where clever trade-offs have been made. Consider the ‘R’ key on the left side, which is the last consonant (before the vowels) in terms of steno order. Some of the consonants that precede it are frequently combined with ‘R’ in that order, e.g. TR (train, trade, etc.), KR (crawl, crane, etc.), PR (prowl, print, etc.) By contrast, it’s very rare in English to see RT at the start of a word, same for RK and RP. Now consider HR, and try to think of any English words that start with those sounds. There aren’t any! And that’s why the steno keyboard layout uses those two keys as a chord to stand for the letter ‘L’: it’s never ambiguous (did you mean ‘L’ or did you mean ‘HR’?)! Again, the placement of ‘L’ in steno order is well thought out, with some of the consonants that precede it being frequently combined in sequence with ‘L’, e.g. SL (slow, sleigh, etc.), KL (clever, clown, etc.) PL (plover, plough, etc.).
The steno keyboard layout is wonderfully well thought out. The more I study Plover, the more appreciation I have for it.
Drew
--
Peter DeBiase
Nov 27, 2015, 8:25:58 PM11/27/15
to Plover
Dear all,
Thank you for your excellent and thoughtful replies. It would appear that much of my concern about the stenotype design stems from my trying to use a Microsoft Sidewinder as a stenotype. In other words, maybe the stenotype itself isn't so bad (several of you have stated that quite to the contrary, it is a magnificently designed machine), but I think we can probably agree that a standard nkro keyboard is a poor stenotype.
Because it is unlikely that I will ever buy one of the high-priced existing stenotype models, and because the Stenosaurus and other hardware solutions are still on the horizon, I think there's value to continuing to explore this idea of an updated stenotype layout optimized for use on an ErgoDox. The information you all have kindly shared has allowed me to refine my ideas and given me a few new ones. I will be back with more later this evening.
Cheers,
Pete
PS - I cross-posted my OP to this board on the Plover Aviary as well.
Thank you for your excellent and thoughtful replies. It would appear that much of my concern about the stenotype design stems from my trying to use a Microsoft Sidewinder as a stenotype. In other words, maybe the stenotype itself isn't so bad (several of you have stated that quite to the contrary, it is a magnificently designed machine), but I think we can probably agree that a standard nkro keyboard is a poor stenotype.
Because it is unlikely that I will ever buy one of the high-priced existing stenotype models, and because the Stenosaurus and other hardware solutions are still on the horizon, I think there's value to continuing to explore this idea of an updated stenotype layout optimized for use on an ErgoDox. The information you all have kindly shared has allowed me to refine my ideas and given me a few new ones. I will be back with more later this evening.
Cheers,
Pete
PS - I cross-posted my OP to this board on the Plover Aviary as well.
...
Achim Siebert
Nov 27, 2015, 8:59:29 PM11/27/15
to Plover
Don't let us keep you from finding better ways! One of the originators of machine steno took 20 years to develop the machine and layout we still use today (don't take that as granted, I read it somewhere and forgot who it was). But rest assured that steno is working quite well as it is, so you can learn a lot by studying it before trying something new.
I for one would love a theory that takes phones as its foundation, so it would be possible to use it for many languages (at least the "western" ones like English, German, Spanish, French, Italian etc., maybe also including slavic languages or even arabic ones). But I'm not sure if that would be possible with the meager 22 keys available on a steno machine. Plover might be on its way to allow for different key layouts - if those where switchable by a defined stroke steno could work with layers like those usually triggered by holding down ctrl, shift and/or alt keys. So I'd suggest to take rather small steps deviating from "standard" American English steno which is definitely a good foundation to build upon.
Peter DeBiase
Nov 28, 2015, 9:14:21 AM11/28/15
to Plover
Hello all,
Thank you again for your replies. I am back with some additional ideas and questions. Again, it's very long, but I tried to reply to everybody.
@Ted
1. The number of keys
Have you ever tried to do Plover on a Sidewinder or another standard QWERTY keyboard? If so, how would you compare the Sidewinder, the ErgoDox, and the Treal in terms of relative ease of chording? Is there any appreciable difference between the Sidewinder and the ErgoDox?
Thank you again for your replies. I am back with some additional ideas and questions. Again, it's very long, but I tried to reply to everybody.
@Ted
1. The number of keys
Have you ever tried to do Plover on a Sidewinder or another standard QWERTY keyboard? If so, how would you compare the Sidewinder, the ErgoDox, and the Treal in terms of relative ease of chording? Is there any appreciable difference between the Sidewinder and the ErgoDox?
2. Making Plover listen to more than 22 keys
I see. If Plover was designed from the ground up for use with the 22-key steno keyboard, it might be difficult indeed to change that.
Late last night I had what I thought was an awesome (read: disgusting and very hacky) idea where I would just have an Autohotkey script convert a single keypress like "Z", for example, into a chord like "asdf" that Plover would catch as SKWR and then translate accordingly. From there, I would have "Z" create a truly bizarre chord like KPR-RPGD that no one would ever use in real steno to spoof a "new" Z key in addition to the standard 22 stenokeys for use in chords. However, it seems like Autohotkey is not capable of sending truly simultaneous keystrokes. There is some super small interval between the keypresses (like on the order of milliseconds) that Plover catches and therefore doesn't count as a chord. In fact, I can't get Plover to catch any virtual keystrokes sent by Autohotkey at all.
Programmers like them an elegant, general-purpose solution to a problem something fierce. I think it would be really cool to generalize Plover from a "stenotype" program (based on the 22 key stenotype) to an all-purpose chording program that can take any keyboard and a map of keys on that keyboard to "tokens" (the STKPWHRAO*EUFRPBLGTSDZ on the stenotype machine) for use in steno chords. I'm looking through the codebase right now (and wow, you guys really have done a good job with this, I must say :) ), and it seems to me that the main hard-coding of the 22-key steno layout takes place in the following three files:
Particularly in the DEFAULT nested list structure. It looks like you are actually working with letters sent by the keyboard, not native keyboard scancodes, is that right? Definitely the right choice to make Plover work with all nkro keyboards as scancodes probably vary from manufacturer to manufacturer.
If this is indeed the case, I see no reason why we couldn't have a simple text file "map" that Plover loads on launch. This text file would map keys on a keyboard to tokens for use in chords, and then in the dictionary file we would define how we want Plover to translate chords of those tokens into full words (like we already do now). Then, users could create new systems of tokens for use in chords, which would also facilitate creating steno layouts for other languages as a side effect. I mean, maybe STKPWHRAO*EUFRPBLGTSDZ just doesn't get the job done in Arabic or Spanish or something. STKPWHRAO*EUFRPBLGTSDZ was developed specifically for use with the English language, right?
Am I fooling myself into thinking it won't be monumentally difficult to generalize Plover for any keyboard layout? Is the 22-key layout assumed in any of the other data structures? Is there any developer documentation for Plover available that maps out how all the modules and classes and whatnot fit together? Anything that could get me up to speed quicker would be amazing.
Late last night I had what I thought was an awesome (read: disgusting and very hacky) idea where I would just have an Autohotkey script convert a single keypress like "Z", for example, into a chord like "asdf" that Plover would catch as SKWR and then translate accordingly. From there, I would have "Z" create a truly bizarre chord like KPR-RPGD that no one would ever use in real steno to spoof a "new" Z key in addition to the standard 22 stenokeys for use in chords. However, it seems like Autohotkey is not capable of sending truly simultaneous keystrokes. There is some super small interval between the keypresses (like on the order of milliseconds) that Plover catches and therefore doesn't count as a chord. In fact, I can't get Plover to catch any virtual keystrokes sent by Autohotkey at all.
Programmers like them an elegant, general-purpose solution to a problem something fierce. I think it would be really cool to generalize Plover from a "stenotype" program (based on the 22 key stenotype) to an all-purpose chording program that can take any keyboard and a map of keys on that keyboard to "tokens" (the STKPWHRAO*EUFRPBLGTSDZ on the stenotype machine) for use in steno chords. I'm looking through the codebase right now (and wow, you guys really have done a good job with this, I must say :) ), and it seems to me that the main hard-coding of the 22-key steno layout takes place in the following three files:
plover/plover/machine/keymap.py
plover/plover/steno.py
plover/plover/translation.py
Particularly in the DEFAULT nested list structure. It looks like you are actually working with letters sent by the keyboard, not native keyboard scancodes, is that right? Definitely the right choice to make Plover work with all nkro keyboards as scancodes probably vary from manufacturer to manufacturer.
If this is indeed the case, I see no reason why we couldn't have a simple text file "map" that Plover loads on launch. This text file would map keys on a keyboard to tokens for use in chords, and then in the dictionary file we would define how we want Plover to translate chords of those tokens into full words (like we already do now). Then, users could create new systems of tokens for use in chords, which would also facilitate creating steno layouts for other languages as a side effect. I mean, maybe STKPWHRAO*EUFRPBLGTSDZ just doesn't get the job done in Arabic or Spanish or something. STKPWHRAO*EUFRPBLGTSDZ was developed specifically for use with the English language, right?
Am I fooling myself into thinking it won't be monumentally difficult to generalize Plover for any keyboard layout? Is the 22-key layout assumed in any of the other data structures? Is there any developer documentation for Plover available that maps out how all the modules and classes and whatnot fit together? Anything that could get me up to speed quicker would be amazing.
>>>Some have made different builds where they change the hard coding to their needed layout.
Do you know where I could get in touch with these people to get a better idea of what changing the hard-coded layout might entail?
Also, would it be best to start a new thread for this effort here on the Google Group or contact you off-list or what? I'm a newcomer here so I don't know what the customs are for doing such things around here.
Oh, one last thing:
Also, would it be best to start a new thread for this effort here on the Google Group or contact you off-list or what? I'm a newcomer here so I don't know what the customs are for doing such things around here.
Oh, one last thing:
>>>Then you have to also consider that some locales may read right to left, and I'm not totally sure how I'd handle that. I might keep the logic inside Plover going left to right, but just switch the reading of the layout and translations.
I'm not sure I understand the problem. Send me a PM and we can dig further into it? Like I said, I am totally willing to volunteer time and experience, especially now that I'm pumped that the codebase is so manageable.
3. Differentiating between single-key presses and chords
Having played around with implementing a chording scheme in Autohotkey, I can confirm you are exactly right on this. I defined a chord like "th" (I mean "th" in QWERTY) which should expand to "this", for example. And I found that my "chord" was firing ALL the time, even when I didn't want it to, like when I would type "the" normally, for example. Furthermore, AHK doesn't seem to support any reasonable way to define chords longer than two characters.
Changing the question slightly...fingerspelling is another thorn in my side with existing steno theory that just doesn't make sense to me. Why should I press multiple keys to get a single key output? Plover does, however, support the {PLOVER:TOGGLE} command. Back when you were doing Plover on your ErgoDox, would you ever just come across a proper noun and (instead of fingerspelling it in steno) kick the clutch into QWERTY, type it normally, and then drop back into stenoland as usual in Plover? Is having your fingers rapidly switch from one input "language", if you will, to another too much of a mental load to be feasible?
>>>It's [the current stenotype layout] still very good and I find it quite adequate for programming and extremely useful for any other writing.
Last question: Does this mean that you have freed yourself from a standard keyboard and now interact with your computer solely using the Treal? (If so, that's quite a feat of pushing the boundaries of human-computer interaction).
I apologize to pepper you with questions Ted. Thanks so much in advance for any further advice/info you could give!
@Drew
The idea of assigning key positions based on frequency and ease of access has become even more popular in recent years. Are you familiar with the Maltron? (It's sort of like the ErgoDox's grandpa.) They created their layout based on a letter frequency (also bigram and trigram frequency) analysis, and from what I've heard the Maltron layout is quite well-regarded. This guy (who is a court reporter) claims to be able to type at 180 wpm using just the Maltron and text expansion.
The "modern" alternate layouts for the standard keyboard are based on the same type of frequency analysis. Most of us have heard of Dvorak, Colemak, and Workman, for example, but who here has heard of QGMWLY, which is purported to reduce typing effort by some 44% over QWERTY? (As a side note, having personally tried some of these alternate layouts, I think they are definitely onto something - the more time you can spend on the home row, the better.) QGMWLY was developed very recently by Martin Krzywinski as part of a project called CarpalX. Here's the idea: we quantify the effort it takes to press each key and combinations of keys (using fancy maths). Then, we download some ENORMOUS corpus of English language text and analyze how frequently each letter and letter combination is used. Finally, we put the two pieces together and put the most frequently used letters/letter combinations on the easiest keys/key combinations, and Bob's your uncle.
I'm personally of the opinion that alternate keyboard layouts get a bad rap because people try to sell them based on the idea of increased typing speed rather than what they're actually built to do: reduce typing effort. There really is an upper limit on how quickly the human fingers can actuate keyboard switches (also it varies from person to person). Any increase in speed from an alternate keyboard layout is due mostly comes as a side effect of the reduction in effort.
Martin also developed another keyboard layout (the "worst possible layout") called TNWMLC to prove this. Think QWERTY is bad? Try this: it is truly horrifying to try to type in :) .
One final note on typing speed. Mark Kislingbury, the mind behind Magnum Steno, has an excellent video where he breaks down the concept of typing speed very well. Whether you are typing in QWERTY or steno or any other scheme, there are really only two inputs that determine the speed of text input: switch actuations/unit time and words/switch actuation. To maximize speed, we need to maximize both parameters.
3. Differentiating between single-key presses and chords
Having played around with implementing a chording scheme in Autohotkey, I can confirm you are exactly right on this. I defined a chord like "th" (I mean "th" in QWERTY) which should expand to "this", for example. And I found that my "chord" was firing ALL the time, even when I didn't want it to, like when I would type "the" normally, for example. Furthermore, AHK doesn't seem to support any reasonable way to define chords longer than two characters.
Changing the question slightly...fingerspelling is another thorn in my side with existing steno theory that just doesn't make sense to me. Why should I press multiple keys to get a single key output? Plover does, however, support the {PLOVER:TOGGLE} command. Back when you were doing Plover on your ErgoDox, would you ever just come across a proper noun and (instead of fingerspelling it in steno) kick the clutch into QWERTY, type it normally, and then drop back into stenoland as usual in Plover? Is having your fingers rapidly switch from one input "language", if you will, to another too much of a mental load to be feasible?
>>>It's [the current stenotype layout] still very good and I find it quite adequate for programming and extremely useful for any other writing.
Last question: Does this mean that you have freed yourself from a standard keyboard and now interact with your computer solely using the Treal? (If so, that's quite a feat of pushing the boundaries of human-computer interaction).
I apologize to pepper you with questions Ted. Thanks so much in advance for any further advice/info you could give!
@Drew
The idea of assigning key positions based on frequency and ease of access has become even more popular in recent years. Are you familiar with the Maltron? (It's sort of like the ErgoDox's grandpa.) They created their layout based on a letter frequency (also bigram and trigram frequency) analysis, and from what I've heard the Maltron layout is quite well-regarded. This guy (who is a court reporter) claims to be able to type at 180 wpm using just the Maltron and text expansion.
The "modern" alternate layouts for the standard keyboard are based on the same type of frequency analysis. Most of us have heard of Dvorak, Colemak, and Workman, for example, but who here has heard of QGMWLY, which is purported to reduce typing effort by some 44% over QWERTY? (As a side note, having personally tried some of these alternate layouts, I think they are definitely onto something - the more time you can spend on the home row, the better.) QGMWLY was developed very recently by Martin Krzywinski as part of a project called CarpalX. Here's the idea: we quantify the effort it takes to press each key and combinations of keys (using fancy maths). Then, we download some ENORMOUS corpus of English language text and analyze how frequently each letter and letter combination is used. Finally, we put the two pieces together and put the most frequently used letters/letter combinations on the easiest keys/key combinations, and Bob's your uncle.
I'm personally of the opinion that alternate keyboard layouts get a bad rap because people try to sell them based on the idea of increased typing speed rather than what they're actually built to do: reduce typing effort. There really is an upper limit on how quickly the human fingers can actuate keyboard switches (also it varies from person to person). Any increase in speed from an alternate keyboard layout is due mostly comes as a side effect of the reduction in effort.
Martin also developed another keyboard layout (the "worst possible layout") called TNWMLC to prove this. Think QWERTY is bad? Try this: it is truly horrifying to try to type in :) .
One final note on typing speed. Mark Kislingbury, the mind behind Magnum Steno, has an excellent video where he breaks down the concept of typing speed very well. Whether you are typing in QWERTY or steno or any other scheme, there are really only two inputs that determine the speed of text input: switch actuations/unit time and words/switch actuation. To maximize speed, we need to maximize both parameters.
>>>The steno keyboard layout is wonderfully well thought out. The more I study Plover, the more appreciation I have for it.
I will continue my study of Plover and see what more I can take away. I'm not necessarily saying it's bad, I just think we can do better.
@Achim
I sure don't have 20 years :) . Maybe 2, tops. I'm not sure where I came up with this link (did one of you post it?), but it's another letter frequency analysis. It talks about how the people that first did these analyses had to manually gather text sources and do arcane things with punch cards to perform their studies. Drew also mentioned how the Scrabble guy designed Scrabble - by manually counting letters in the New York Times. The horror!
Today, we can do insane things like download Wikipedia in its entirety and analyze it in ways these OGs of text analysis cold never have imagined. And we can do it in an afternoon. As I mentioned before, I'm not trying to reinvent the wheel. If I get an alternate stenotype layout working on an ErgoDox, I'm still sort of planning on using StenEd as my base steno theory. They've already done all of the hard work of classifying the English language in terms of consonant and vowel sounds and how to put those sounds together to make words. I am absolutely going to repurpose that work - I'm just going to use different keys for each consonant/vowel because I don't want to buy a stenotype.
In regards to making steno more accessible for other languages, what do you think of the following idea?
The International Phonetic Alphabet (IPA) defines 107 letters, 52 diacritics, and four prosodic marks that, as far as I know, are capable of representing all sounds in all human languages. Not all human languages use all sounds (thank goodness). English uses about 50ish? So, while I don't think it's possible to develop the One True Steno Layout that is fully optimized for all languages, what I do think we could do is give people an accessible method for developing their own steno layouts for their own languages utilizing the IPA. Here's how (using basically the same methodology as the CarpalX project)
-Quantify the ease of pressing keys on the target hardware (QWERTY keyboard, ErgoDox, stenotype-like thing, whatever).
-Take a large corpus of the target language text, and convert it to IPA representation using IPA dictionaries.
-Analyze the converted IPA corpus for relative frequency of each sound used.
-Put the most frequent sounds and sound combinations on the easiest to press keys.
-???
-Profit
I'm sure there would be some trial and error involved to refine the layout after the initial mapping, but we could literally make an open source package that does the heaviest lifting involved for any language in a matter of hours. No 20 years required. That would be pretty cool.
Conclusion
Alrighty, I think that's it for me for today. Look forward to hearing back from y'all!
Cheers,
Pete
PS - I'm also going to get in touch with some of the folks who practice shorthand systems like Pitman and Gregg and see what ideas they might have. The main problem with shorthand systems is that they are not deterministic - a given shorthand "outline", as they are called, can mean more than one word. Context is usually enough to narrow it down, but programming contextual clues of human language is really hard. Perhaps with more symbols it would be possible to represent a fully deterministic shorthand system.
@Achim
I sure don't have 20 years :) . Maybe 2, tops. I'm not sure where I came up with this link (did one of you post it?), but it's another letter frequency analysis. It talks about how the people that first did these analyses had to manually gather text sources and do arcane things with punch cards to perform their studies. Drew also mentioned how the Scrabble guy designed Scrabble - by manually counting letters in the New York Times. The horror!
Today, we can do insane things like download Wikipedia in its entirety and analyze it in ways these OGs of text analysis cold never have imagined. And we can do it in an afternoon. As I mentioned before, I'm not trying to reinvent the wheel. If I get an alternate stenotype layout working on an ErgoDox, I'm still sort of planning on using StenEd as my base steno theory. They've already done all of the hard work of classifying the English language in terms of consonant and vowel sounds and how to put those sounds together to make words. I am absolutely going to repurpose that work - I'm just going to use different keys for each consonant/vowel because I don't want to buy a stenotype.
In regards to making steno more accessible for other languages, what do you think of the following idea?
The International Phonetic Alphabet (IPA) defines 107 letters, 52 diacritics, and four prosodic marks that, as far as I know, are capable of representing all sounds in all human languages. Not all human languages use all sounds (thank goodness). English uses about 50ish? So, while I don't think it's possible to develop the One True Steno Layout that is fully optimized for all languages, what I do think we could do is give people an accessible method for developing their own steno layouts for their own languages utilizing the IPA. Here's how (using basically the same methodology as the CarpalX project)
-Quantify the ease of pressing keys on the target hardware (QWERTY keyboard, ErgoDox, stenotype-like thing, whatever).
-Take a large corpus of the target language text, and convert it to IPA representation using IPA dictionaries.
-Analyze the converted IPA corpus for relative frequency of each sound used.
-Put the most frequent sounds and sound combinations on the easiest to press keys.
-???
-Profit
I'm sure there would be some trial and error involved to refine the layout after the initial mapping, but we could literally make an open source package that does the heaviest lifting involved for any language in a matter of hours. No 20 years required. That would be pretty cool.
Conclusion
Alrighty, I think that's it for me for today. Look forward to hearing back from y'all!
Cheers,
Pete
PS - I'm also going to get in touch with some of the folks who practice shorthand systems like Pitman and Gregg and see what ideas they might have. The main problem with shorthand systems is that they are not deterministic - a given shorthand "outline", as they are called, can mean more than one word. Context is usually enough to narrow it down, but programming contextual clues of human language is really hard. Perhaps with more symbols it would be possible to represent a fully deterministic shorthand system.
On Friday, November 27, 2015 at 6:54:31 AM UTC-8, Peter DeBiase wrote:
...
Benoit Pierre
Nov 28, 2015, 10:03:44 AM11/28/15
to plove...@googlegroups.com
>>>Some have made different builds where they change the hard coding to their needed layout.
Do you know where I could get in touch with these people to get a better idea of what changing the hard-coded layout might entail?
You could look at this branch: https://github.com/benoit-pierre/plover/compare/bpierre...benoit-pierre:mecatipia
As part of the changes include changing the hard-coded layout.
Cheers,
--
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
Q: Why is top posting dumb?
Ted Morin
Nov 28, 2015, 1:11:44 PM11/28/15
to Plover
Peter, I can say that for me the biggest change was the light actuation force, though I imagine that a staggered layout is not ideal (I personally haven't had to do it for any appreciable amount of time). I'd believe the key toppers help get over the layout. It might be worth weighing the actuation force on the Sidewinder using nickels (5g each). I'd be curious to see what the actuation and the bottoming out forces are.
To continue discussion on customizing the steno layout, I'd most prefer if we can keep it in a GitHub issue: https://github.com/openstenoproject/plover/issues/134 While it may not be technically difficult to theoretically support any steno layout… I'm worried more about what configuration looks like, if layouts are dictionary-specific, can users switch between steno theories live (if I have a French and an English dictionary, I'd like to have the theory change but still be able to switch between them on the go, so that suggests per-dictionary layouts, but how do you store that?). Not that these can't be overcome, but I'm wary of making any promise or estimations because I believe this task will only grow in scope as we realize it. You are welcome to start contributing though and once someone starts I'm certain that others will hop in and lend a hand.
As for me using steno… Why yes, I do use it all the time. Most of the time on here I'm writing with steno (like right now) and the only exceptions are couch-laptop-lounging time and on the go with my phone. I used the ErgoDox with Cherry MX reds and now I use the Tréal at my day job in order to program in JavaScript and Java. Often at home I'll also work on Plover while stenoing, though this can be difficult when I have to close down Plover to build it, and so maybe a little less than when I'm not working on Plover.
I've been learning steno since August 2014 and it wasn't always easy, but the end result is super amazing. I don't know, there's nothing else like this and I can see why Mirabai thought that she had to free this to the world. It's hard to convince people, obviously, because it's so far from what we are used to, but if only we could share with them the feeling of the comfort and speed of steno, people would flock to it. It's truly fantastic once you are beyond that initial difficult learning curve. Sorry, I know I don't need to convince you 😉 you are already here and thinking about theories.
Anyways, yes, just to say that after learning steno, it's a pleasant experience all around for me. I use it at university, on the job, and at home. My steno machine travels with me at the moment. I look forward to when I get a Stenosaurus or maybe multiple different steno machines so that I can one dedicated to travel and one set in a comfortable place at home, et cetera. Please feel free to ask any further questions and critique the layout. There's always room for more contributions.
Peter DeBiase
Nov 29, 2015, 8:03:06 AM11/29/15
to Plover
@Benoit
Thank you very much!
The Github issue Ted posted also has a user doing an alternate steno layout for French, so now I have two examples of how to approach the problem of steno layout customization!
@Ted
Thank you so much for your followup!
Sidewinder switches (rubber dome switches) are 45g to actuation and 55g to bottom out. I cannot recommend steno on the stock Sidewinder though, as the staggered layout really does make chording awkward.
Understood on moving further discussion on layout customization to the Github issue you listed. It looks like there are already a few other users there who have started making some early headway on this. I have some ideas about how we might solve the concerns you mentioned. I agree that it is of the utmost importance to avoid scope creep in implementing support for layout customization. Here is my plan for moving forward:
1. Spend a few more days familiarizing myself with the codebase.
2. Draft an informal design spec for layout customization (within the next week).
3. Post design spec, get feedback/buyin from yourself and the other stakeholders.
4. Create a new fork and go to town!
It's really cool to hear about your experience learning and using steno. I'm also pretty amazed that you achieved a functional working speed in just a year. That's super impressive.
I am in full agreement with you that there are currently serious limitations in the way we interact with computers (looking at you QWERTY ಠ_ಠ). I am really fired up about redefining the human-computer interaction status quo and really pushing the boundaries, as you seem to be as well.
I think one key to popularizing steno is going to be making it more approachable. "Spend a year of intensive study and maybe you'll probably be able to type okay, but until then you are essentially dead in the water" can be a hard pill to swallow. Supporting custom layouts could definitely be one step forward in making it more approachable. For example, think about if we made a 26-key steno layout that was just a regular QWERTY keyboard, and had each key do exactly what they do now (input one letter at a time). We talked before about the difficulty of distinguishing between single-key presses and chords in a useful way, but maybe if we had some "appetizer" chords like "ZJ" = "and the" on a QWERTY keyboard that aren't likely to fire during normal typing, it would be easier to get people to invest.
I know for me personally, it was when I came across a brief of -FT being "of the " (two full words) that the lightbulb really went off in my head. I was like "Dang, I just did one action to do what would have otherwise taken seven actions" (including the spaces). We really just need to make those first steps easier for people to take so they can experience their own lightbulb moments. We need to make it easier for them to get that first taste of steno.
It will also take people championing Plover across the web and in real life, accessible hardware, and a rock-solid pedagogy, and it looks like there are already a lot of people working on that side of the equation too. Steno Hero is a genius idea for a learning method. Check out SUBS2SRS one day when you have a sec, and let me know what you think of the idea of turning movies and TV shows into video/audio flashcards for people to practice their steno.
Okay, enough talk, I'm ready to get down to business!
Thank you to everyone for your feedback and ideas!
-Pete
Thank you very much!
The Github issue Ted posted also has a user doing an alternate steno layout for French, so now I have two examples of how to approach the problem of steno layout customization!
@Ted
Thank you so much for your followup!
Sidewinder switches (rubber dome switches) are 45g to actuation and 55g to bottom out. I cannot recommend steno on the stock Sidewinder though, as the staggered layout really does make chording awkward.
Understood on moving further discussion on layout customization to the Github issue you listed. It looks like there are already a few other users there who have started making some early headway on this. I have some ideas about how we might solve the concerns you mentioned. I agree that it is of the utmost importance to avoid scope creep in implementing support for layout customization. Here is my plan for moving forward:
1. Spend a few more days familiarizing myself with the codebase.
2. Draft an informal design spec for layout customization (within the next week).
3. Post design spec, get feedback/buyin from yourself and the other stakeholders.
4. Create a new fork and go to town!
It's really cool to hear about your experience learning and using steno. I'm also pretty amazed that you achieved a functional working speed in just a year. That's super impressive.
I am in full agreement with you that there are currently serious limitations in the way we interact with computers (looking at you QWERTY ಠ_ಠ). I am really fired up about redefining the human-computer interaction status quo and really pushing the boundaries, as you seem to be as well.
I think one key to popularizing steno is going to be making it more approachable. "Spend a year of intensive study and maybe you'll probably be able to type okay, but until then you are essentially dead in the water" can be a hard pill to swallow. Supporting custom layouts could definitely be one step forward in making it more approachable. For example, think about if we made a 26-key steno layout that was just a regular QWERTY keyboard, and had each key do exactly what they do now (input one letter at a time). We talked before about the difficulty of distinguishing between single-key presses and chords in a useful way, but maybe if we had some "appetizer" chords like "ZJ" = "and the" on a QWERTY keyboard that aren't likely to fire during normal typing, it would be easier to get people to invest.
I know for me personally, it was when I came across a brief of -FT being "of the " (two full words) that the lightbulb really went off in my head. I was like "Dang, I just did one action to do what would have otherwise taken seven actions" (including the spaces). We really just need to make those first steps easier for people to take so they can experience their own lightbulb moments. We need to make it easier for them to get that first taste of steno.
It will also take people championing Plover across the web and in real life, accessible hardware, and a rock-solid pedagogy, and it looks like there are already a lot of people working on that side of the equation too. Steno Hero is a genius idea for a learning method. Check out SUBS2SRS one day when you have a sec, and let me know what you think of the idea of turning movies and TV shows into video/audio flashcards for people to practice their steno.
Okay, enough talk, I'm ready to get down to business!
Thank you to everyone for your feedback and ideas!
-Pete
On Friday, November 27, 2015 at 6:54:31 AM UTC-8, Peter DeBiase wrote:
...
Joshua Taylor
Nov 29, 2015, 9:23:01 AM11/29/15
to plove...@googlegroups.com
Would this be as simple as just creating a dictionary for plover
with "q" defined as a chord that outputted "q", "w" defined as a
chord that outputted "w", etc. and then adding in the short forms we
wanted with care taken to make them easy to remember, easy to
stroke, and most importantly, hard to accidently type if typing
qwerty in English?
-- Joshua Taylor
-- Joshua Taylor
--
Peter DeBiase
Nov 29, 2015, 9:32:00 AM11/29/15
to plove...@googlegroups.com
(Somebody please correct me if I'm wrong, but...)
I think you would be able to get most (but not all of the way there) using that method. My understanding is that (the master branch of) Plover is currently built from the ground up around the idea of the 22-key stenotype, so you wouldn't be able to implement a full QWERTY scheme in Plover which gave you to access to all 26 letters of the alphabet with a single keypress for each letter (you would have to chord some of the letters, as they already do with fingerspelling in modern machine-based steno theories).
-Pete
--
You received this message because you are subscribed to a topic in the Google Groups "Plover" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ploversteno/GhMcoSh6qmA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ploversteno...@googlegroups.com.
Joshua Taylor
Nov 29, 2015, 9:39:11 AM11/29/15
to plove...@googlegroups.com
oh. :( I'm not sure I want to even know how much work it would be to
change that.
Does anyone know more or less off the top of their head how many lines of code plover has and what language it's written in?
-- Joshua Taylor
Does anyone know more or less off the top of their head how many lines of code plover has and what language it's written in?
-- Joshua Taylor
Benoit Pierre
Nov 29, 2015, 9:44:57 AM11/29/15
to plove...@googlegroups.com
On Sun, Nov 29, 2015 at 3:39 PM, Joshua Taylor <jt...@mail.com> wrote:
oh. :( I'm not sure I want to even know how much work it would be to change that.
Does anyone know more or less off the top of their head how many lines of code plover has and what language it's written in?
8692 lines of Python according to sloccount on the latest code.
Peter DeBiase
Nov 29, 2015, 9:45:24 AM11/29/15
to plove...@googlegroups.com
Well, adding support for custom layouts is sort of what we've been talking all about in this thread...so stay tuned?
Don't know how many lines of code in total, but I know it's written in Python (aka the best programming language ever). I spent some time looking through the codebase over the past two days, and it seems very manageable.
Here is the master branch of Plover on Github. Here is the Github issue where we'll be tackling adding support for layout customization. Stay tuned!
Best,
Pete
Jennifer Brien
Nov 29, 2015, 5:02:43 PM11/29/15
to Plover
On Sunday, 29 November 2015 13:03:06 UTC, Peter DeBiase wrote:
Sidewinder switches (rubber dome switches) are 45g to actuation and 55g to bottom out. I cannot recommend steno on the stock Sidewinder though, as the staggered layout really does make chording awkward.
I've been wondering about the possibility of a detachable frame of piano-like lever keys that you could place over the keyboard for steon and remove when you didn't. That might solve the key weight and placement problems.
I think one key to popularizing steno is going to be making it more approachable. "Spend a year of intensive study and maybe you'll probably be able to type okay, but until then you are essentially dead in the water" can be a hard pill to swallow. Supporting custom layouts could definitely be one step forward in making it more approachable. For example, think about if we made a 26-key steno layout that was just a regular QWERTY keyboard, and had each key do exactly what they do now (input one letter at a time). We talked before about the difficulty of distinguishing between single-key presses and chords in a useful way, but maybe if we had some "appetizer" chords like "ZJ" = "and the" on a QWERTY keyboard that aren't likely to fire during normal typing, it would be easier to get people to invest.
I know for me personally, it was when I came across a brief of -FT being "of the " (two full words) that the lightbulb really went off in my head. I was like "Dang, I just did one action to do what would have otherwise taken seven actions" (including the spaces). We really just need to make those first steps easier for people to take so they can experience their own lightbulb moments. We need to make it easier for them to get that first taste of steno.
There a autotyping programs such as PhraseExpress which do that better. If you want a gateway to steno I wouldn't start with Qwerty at all, but something else easy to learn that can quickly get you to a useful speed (say 70 wpm). For that you need an orthographic system, on that will output words as they are spelled not as they are sounded, so that you don't need to remember how to distinguish words that sound alike, or a dictionary to convert it back into English, or whatever language you are using. All you need is the ability to write the most common syllables in a single stroke. Then, when you get used to the system, you can add a dictionary for your briefs. English is complex, but not really as irregular as it sometimes seems, and it doesn't take many rules to define the most common opening consonant sequences. Closing sequences are trickier, but if the last letter doesn't fit you can always key it in separately before the next syllable/chord.
For the past couple of months I've been experimenting with a mapping of the Velotype keyboard onto a Planck Grid (paper mockups only so far) working from the patent spec available at
So far, I've found:
There is a fine balance of complexity between number of keys and number of rules. The standard set of rules for English is not hard to learn, but it needs some study. By adding dedicated keys for W, M and H, I got a layout where all the missing consonants could appear on keycaps as shifts with either Z or J. That left a few very simple simple rules like "that key doubles the vowel" "this key changes the order of the vowel pair, or if there is only one vowel, it double the consonant that follows it."
"Right hand F and Z are respectively E and S if there are other consonants." So, for example, FE is JF and FT is FZ.
This is very easy to learn and delightful to use, but it does make for some awkward hand positions, so I suspect more rules and fewer keys would be better for speed.
Anyway, download the PDF of the patent and have a look at the logic flowcharts. Maybe they will give you some inspiration. :)
Peter DeBiase
Nov 29, 2015, 7:33:22 PM11/29/15
to Plover
@Jennifer
This is all amazing stuff!
This is all amazing stuff!
I've been wondering about the possibility of a detachable frame of piano-like lever keys that you could place over the keyboard for steon and remove when you didn't. That might solve the key weight and placement problems.
Are you familiar with the keycap set on the Plover store?
There a autotyping programs such as PhraseExpress which do that better. If you want a gateway to steno I wouldn't start with Qwerty at all, but something else easy to learn that can quickly get you to a useful speed (say 70 wpm). For that you need an orthographic system, on that will output words as they are spelled not as they are sounded, so that you don't need to remember how to distinguish words that sound alike, or a dictionary to convert it back into English, or whatever language you are using. All you need is the ability to write the most common syllables in a single stroke. Then, when you get used to the system, you can add a dictionary for your briefs.
The idea behind being able to type QWERTY through Plover is mainly that it would be a proof of concept for the customizable layout feature. The scheme you are talking about with PhraseExpress is sometimes called "text expansion" - I am currently also working on some text expansion-related stuff in Autohotkey (same thing as PhraseExpress, just lets you do stuff other than text expansion too). This is related to the symbol-based written shorthand systems like Pitman and Gregg as well as the more recent alphabetical shorthand systems like Speedwriting and Keyscript, which take a little bit of a different approach to writing fast than the machine-based methods (which employ chording).
For example, here are some lines of Autohotkey code that define "hotstrings" that expand to simple words. I also put in some cheeky hotstrings that fire when you type out the full word you are supposed to be using shorthand for - reminding you that there is indeed a shorthand "outline" available and deleting the word you typed out to force you to type it in again using the shorthand form.
So basically, 'h' = 'the' and '7' = 'and' (7='and' because of the ampersand on the 7 key). The stuff like 'c0o0' is just options that tell Autohotkey to expand these phrases in a specific way (here, whether to be case-sensitive and whether to insert a space after the expanded text).
The problem with these types of shorthand systems, in my (very brief) experience with them, is that they are inevitably non-deterministic and require you to use context clues to decipher non-unique outlines. For example, in one of the shorthand systems I'm studying (Keyscript, which is based on the much older Pitman shorthand), the letter 't' by itself can mean any of 'to', 'at', 'tea', 'tee', 'eat', 'out', etc. depending on context. This makes it difficult to code up everything in Autohotkey, for example, because how do you deal with the duplicates for certain outlines? Implement pattern-based statistical resolution of duplicates? Now that sounds hard (could absolutely be done, it's just harder than I can personally solve).
One idea would be to use additional symbols to reduce ambiguity. For example, maybe use the capital letters to do extra things, and we add a rule like capital 'C' is the 'ch' sound. This is about as far as I've gotten down this path though. A few days ago I tried to see if there were any experts at the r/shorthand sub on reddit that would be willing to discuss the idea of a fully deterministic keyboard-based shorthand writing system, and as of last night the discussion was dead in the water. It looks like we have some contributors now though!
I am interested in hearing if you have more ideas on how to implement an orthographic shorthand system to be implemented as text expansion. I had an idea for a "lazy" shorthand in which we would leave all of the hard-to-abbreviate nouns and verbs alone and just turn "glue" words (mainly prepositions, conjunctions, and combinations thereof) into a deterministic shorthand system. Somewhere I read that 25% of all English text is like the same 25 short "glue" words.
Re: The Velotype
Now this is really amazing. The orthographic chording system employed by the Velotype is actually what got me started down the path of developing alternate chording schemes in the first place. I was looking at the (newer?) Velotype rather than the (older?) Veyboard though, which seems to be the device specified in the patent specification you mentioned.
But in any case, oh my god this patent specification already has pseudo-code for implementing this type of orthographic chording scheme! As someone who works with patents for a living, it is completely embarrassing that I did not know this patent existed or even think to look for it!
For example, here are some lines of Autohotkey code that define "hotstrings" that expand to simple words. I also put in some cheeky hotstrings that fire when you type out the full word you are supposed to be using shorthand for - reminding you that there is indeed a shorthand "outline" available and deleting the word you typed out to force you to type it in again using the shorthand form.
:c0o0:h::the
:o0:7::and
::the::
MsgBox, ,Use shorthand!, 'the' is 'h', 1.5
Return
:z:and::
MsgBox, ,Use shorthand!, 'and' is '7' (&), 1.5
ReturnSo basically, 'h' = 'the' and '7' = 'and' (7='and' because of the ampersand on the 7 key). The stuff like 'c0o0' is just options that tell Autohotkey to expand these phrases in a specific way (here, whether to be case-sensitive and whether to insert a space after the expanded text).
The problem with these types of shorthand systems, in my (very brief) experience with them, is that they are inevitably non-deterministic and require you to use context clues to decipher non-unique outlines. For example, in one of the shorthand systems I'm studying (Keyscript, which is based on the much older Pitman shorthand), the letter 't' by itself can mean any of 'to', 'at', 'tea', 'tee', 'eat', 'out', etc. depending on context. This makes it difficult to code up everything in Autohotkey, for example, because how do you deal with the duplicates for certain outlines? Implement pattern-based statistical resolution of duplicates? Now that sounds hard (could absolutely be done, it's just harder than I can personally solve).
One idea would be to use additional symbols to reduce ambiguity. For example, maybe use the capital letters to do extra things, and we add a rule like capital 'C' is the 'ch' sound. This is about as far as I've gotten down this path though. A few days ago I tried to see if there were any experts at the r/shorthand sub on reddit that would be willing to discuss the idea of a fully deterministic keyboard-based shorthand writing system, and as of last night the discussion was dead in the water. It looks like we have some contributors now though!
I am interested in hearing if you have more ideas on how to implement an orthographic shorthand system to be implemented as text expansion. I had an idea for a "lazy" shorthand in which we would leave all of the hard-to-abbreviate nouns and verbs alone and just turn "glue" words (mainly prepositions, conjunctions, and combinations thereof) into a deterministic shorthand system. Somewhere I read that 25% of all English text is like the same 25 short "glue" words.
Re: The Velotype
Now this is really amazing. The orthographic chording system employed by the Velotype is actually what got me started down the path of developing alternate chording schemes in the first place. I was looking at the (newer?) Velotype rather than the (older?) Veyboard though, which seems to be the device specified in the patent specification you mentioned.
But in any case, oh my god this patent specification already has pseudo-code for implementing this type of orthographic chording scheme! As someone who works with patents for a living, it is completely embarrassing that I did not know this patent existed or even think to look for it!
There is a fine balance of complexity between number of keys and number of rules. The standard set of rules for English is not hard to learn, but it needs some study. By adding dedicated keys for W, M and H, I got a layout where all the missing consonants could appear on keycaps as shifts with either Z or J. That left a few very simple simple rules like "that key doubles the vowel" "this key changes the order of the vowel pair, or if there is only one vowel, it double the consonant that follows it."
"Right hand F and Z are respectively E and S if there are other consonants." So, for example, FE is JF and FT is FZ.
This is very easy to learn and delightful to use, but it does make for some awkward hand positions, so I suspect more rules and fewer keys would be better for speed.
Avoiding awkward hand positions is what I want to do most! If you have already put some thought into developing an orthographic chording system, maybe I could help by doing some frequency analysis to determine which keys and key combinations are used most frequently, and then we could put the most frequent keys/key combinations on the easiest keys. Will send you a PM, or we can start a new thread here so other people can see what's going on/add their own ideas if that doesn't bother you. If you want to keep your work private for now, that's also totally cool.
As I see it, there are three main tasks in implementing a new chording scheme:
1. Add support for custom chording layouts in Plover (people are working on it).
2. Develop alternate chording method (people are working on it).
3. Refine to maximize speed and minimize number of awkward hand positions. (to be done later)
-Pete
As I see it, there are three main tasks in implementing a new chording scheme:
1. Add support for custom chording layouts in Plover (people are working on it).
2. Develop alternate chording method (people are working on it).
3. Refine to maximize speed and minimize number of awkward hand positions. (to be done later)
-Pete
Paul Beaudet
Nov 30, 2015, 12:03:16 AM11/30/15
to Plover
Jennifer,
The idea of clip on type weighted actuator array, like what you mentioned is a great idea! I think I'm going to do that before doing anything electromechanical. Going to be better off finding out what is comfortable first. ( Peter, The toppers would debilitate my main keyboard so they are a no go for me )
Peter,
This thread is long, but interesting, the passion around learnability is exciting to me. I have to admit I had a similar idea about utilizing more keys to simplify the shorthand when I started learning. Now that I've got to a grand 17 WPM with Plover, I'll say that I'm now more apt to want to find a better way to -DZ, eliminating those two keys to save my pinky. Of course one would have to come up with a new theory to do that, but my point is ergonomics seems to be more at odds with learnability in the long game. Right now finger stretching is slowing me down (maybe... actually it probably has more to do with building muscle memory, which is related).
If you carefully look at how people type you will see fast people knocking out 7-13 actuations per second with a full keyboard. Pro stenographers seem to only be doing about 4-7 actuations. From my observation this is basically the "Top out" speed for chording because of either ergonomic or mental effort involved. This is why a fast speed for a char by char chorder is 60 WPM ( 5 actuations/sec times 60 divided by 5 chars) . What I'm getting at is that a best of both worlds situation is kinda dealing with two concepts that are probably fundamentally at odds with each other. You'll probably find that a 'more complete or verbose' steno order is directly at odds with long term speed because of the "ergonomic friction" ( if you might indulge a made up term).
Ultimately, we (royale) will build something that is easy to learn and fast (probably not steno, it just weighs heavy on being fast). Being cognisant of the difficulty in conflating the two features is notable. Probably going to take trying something everyone thinks is weird at this point and putting an exceptional amount of effort into it. You could be onto something keep on exploring!
Mark Crossley
Oct 29, 2018, 5:16:30 PM10/29/18
to Plover
What I love about Plover users is that we are an "out of the box" kind of folk anyways, it is great to see inspirational ideas from other folks. I have been using Plover for a number of years providing CART (realtime captioning onsite and remotely) and love the software. Has been something amazing, a truly great adventure. I wish Stenosaurus were available, but realize the immensity in work and research it takes to get that off the ground.
Reply all
Reply to author
Forward
0 new messages