CART Problem Solving Series
Sitting Apart
Handling Slides
Classroom Videos
Latin
Superscript and Subscript
Schlepping Gear
Late Hours
Expensive Machines
Communicating Sans Steno
Cash Flow
Lag
Summer
Test Nerves
Ergonomics
Speech Recognition, Part I
Speech Recognition, Part II
Speech Recognition, Part III
Speech Recognition, Part IV
CART PROBLEM: There's too much delay between when a word is written and when it appears onscreen.
If you read The Plover Blog, you'll have seen today's post about the updated Windows version. This means, among many other exciting things, that I can use Plover as a monitoring system for my steno output when my clients are sitting too far away to read comfortably from their screens. Unlike systems like StreamText (which charge per minute) and Bridge (which, in my experience, are unreliable and prone to freezing the entire connection -- client computer and monitoring computer alike), Plover runs on a completely separate connection that has no effect on my client's connection. I can turn it off and on with impunity and never affect what my client views on their screen. This is a big deal. Plover's still not quite at the stage where it can completely take over from Eclipse, my proprietary steno software, but it's definitely advanced enough to be very useful as a monitoring system. One of its best features is that unlike all the other steno software on the market, it has a length-based stroke buffer rather than a time-based stroke buffer, so there's absolutely no lag between when I write a word and when it appears in its active window.
Proprietary steno software is always written with court reporters in mind, and CART functionality tends to be put in as an afterthought. Lawyers don't care if there's a 1.5 second delay between when something is said and when it appears on the screen, and sometimes court reporters are grateful for the time difference between what they see on their screen with pending translation display turned on (though they still have to read through lots of ugly metacharacters) and what the lawyers see on their realtime screens, since it allows them to correct any errors they might have made before the lawyers can spot them. But CART is a very different business. In order for CART to be truly useful to our clients, the text output has to be as smooth and instantaneous as possible. There's inevitably going to be some delay built in; it takes time for the provider to hear and write the words at one end, and it takes time for the client to read and comprehend the words on the other end. But even a small additional delay added on can mean unnecessary frustration and embarrassment. When a professor asks one of my clients a question and they pause to let the words appear on the screen, each tiny fraction of a second can diminish the professor's estimation of my client's intelligence, competence, or attentiveness. It's not rational and it's not fair, but it's a fact, and I think it's important to minimize it as much as humanly possible.
Since I can't yet use Plover in all my daily work, what do I do? I certainly don't want to make them read through the metacharacters. So I turn pending translation display off, and at every pause in speech, no matter how tiny, I invoke the {FLUSH} command, which I write "TPHR-RB". This manually dumps the buffer and avoids the 1.5 second delay. I just looked at my dictionary statistics, and it tells me that I've written {FLUSH} over 1.1 million times and counting. 1.1 million wasted keystrokes. (Sometimes instead of {FLUSH} I'll write STPH-B instead, which roughly translates to "press the right arrow key" and accomplishes the same thing. I've written that about 105,000 times.) It's so annoying that I've got to slam on the flush stroke pretty much every sentence I write, but it's the only way to give my clients truly instant text output. I've asked the developers of Eclipse if they can include a pending translation display without the messy markup and line jumping, but they've told me it's impossible. I've just got to keep working on making Plover completely functional, and then I'll be able to finally throw away that silly superfluous flush command for good.
I, too have this problem. Especially because the class I'm CARTing right now is a math class where Q&A between the teacher and the students (doing problems on the board) take up most of the class session.
ReplyDeleteSometimes the teacher would ask a question and my student missed all but the last part (the most important usually) and is just staring at my screen waiting for the translation to come out.
Even with flushing it's still slow enough that by the time the student gets the message, is able to process it, and has an answer, someone across the room already blurted it out.
My student actually preferred I turn ON the pending translation display so that even though the ugly metasymbols appear, it is near instantaneous. She said the delay would bother her more.
Can't wait 'til Plover is playing in the big leagues. I love how much cleaner and less "clunky" -- if that's the right word -- the translation looks as compared to Eclipse.
Stan: Yeah, I had one student who preferred to read through the metasymbols too. She wasn't happy about them, but she found them preferable to lag, even with me sending flush strokes at every possible opportunity. Gotta get Plover just a little bit more built up and then I'll switch over forever and never look back.
ReplyDeleteYou and me both :D.
ReplyDeleteWe just need super and subscript support, on-the-fly globalling, and what else? Output to StreamText or some other remote viewing platform?
So currently, does Plover always just match the longest entry for a given string of steno strokes?
On-the-fly globaling is the big one. Multiple dictionary support would be good too. Plover doesn't need to handle superscript or subscript; just use a word processor that supports it and use Plover to send the necessary commands. I guess being able to output to CaseView protocol might be helpful so that people could use Streamtext, but it might be just as effective to use a free web-based text editor with realtime refresh like Etherpad or even Google Docs. So it's basically just the globaling and a few little fixes like better orthography for word endings. Then we'll be set.
ReplyDeleteYep, longest entry, no time-based buffer required. Beautifully simple, isn't it? But because all proprietary software is based on the old time-based legacy system and the companies have no incentive to rewire all their old code to get rid of it, Plover is the only one in the game that offers truly instant translation. Kind of staggering, when you think about it.
I feel like 90% of stenographers and steno-based companies follow the adage, "if it ain't broke, don't fix it."
ReplyDeleteAnd in the case of Bridge and sometimes Eclipse, "it's broke but we can't do anything about it!" like in your experience calling them and asking if you can turn off the metasymbols without the stroke timer.
I had Eclipse completely die and lose the formatting I had applied to the test transcript during the WA CSR!! When I restarted Eclipse and loaded the document while on the user preferences I had created specifically for tests, it did some wacky thing and smooshed all the text together in a giant clump. When I tried to manually expand the line height, it literally sent the text that should have been automatically pushed to the next page as a result of the increased line spacing into like an invisible hole at the bottom of each page so that every page had the last three lines MISSING.
Its failure was literally the cause of my having to print out and turn in an improperly formatted document for which I hope they give me some leeway. I panicked, outputted to ascii, just threw my envelope number at the top, and hit print.
You would think from all the thousands of dollars they make from every copy of the damn thing plus all the people who are paying several hundred every year to maintain support AND all the students purchasing the $500 student version, they would have enough left over to maybe hire a couple of GOOD programmers.
So frustrating.
Eclipse is definitely a step up (in my opinion) from CaseCAT but it'll be great to have like a steno-to-computer direct interface so that I can precisely control how the text is outputted -- instead of this somewhat unpredictable thing that some people actually pay to learn how to use.
Btw, if I were to start donating money to the project, where would it go? Like does it pay programmers? For more Majestouches and Sidewinders? Epoxy? Lol.
As of right now, Plover's raised $4,762. I've contributed $4,000, and 15 generous donors have contributed the $762. All of that money except $100 (which we received yesterday) has so far gone to Josh Lifton, Plover's first programmer, to try to reimburse him in some small degree for the enormous number of programming hours he's donated over the past two years. Hesky made the most recent code contribution, so I offered him yesterday's $100 donation, but he said he was happy to keep contributing code for free, and told me to keep the $100. I'll be using it to buy epoxy and foam mounting squares to stenoize the Sidewinders I'll be buying (most likely out of pocket) for the PyGotham steno class. I'll probably offer the Sidewinders for sale after the class to any students who feel like pursuing steno further, and any money I make from that will go back into the general fund, either to pay for programming or to build up a starter inventory of epoxy key kits to sell, which might go some way toward making Plover somewhat self-sustaining.
ReplyDelete