Making Tablets Client-Friendly

Most CART providers do the lion's share of their work one-on-one, with a single client reading from their laptop, which is usually mounted a foot or so away on a tripod. There's an unwritten social convention that it's not polite to reach over and fiddle with someone else's laptop, and I've found that virtually all my clients respect that rule without having to be asked. But what about when a CART provider sends their realtime feed to a tablet, which the client holds in their hands, often sitting at some distance away from the provider, or moving around the room while the provider stays in one place? For some reason, that simple act of holding a screen rather than viewing it while mounted on a tripod changes the whole situation. When people hold tablets, they're tempted to play with them; it's practically a law of nature. And if you don't want your client to have free rein over everything accessible via your tablet, what should you do? Fortunately, there's a very simple solution: Lock it up.

I use an app called Friend Lock Pro on my Samsung Galaxy Tab II. It's simple, aesthetically attractive, and only $1.99.



This is what the homescreen of my tablet looks like when it's unlocked. Notice the large dolphin icon. That's a link to the Dolphin Browser, which offers an aesthetically attractive full screen mode for realtime CART streaming. I made the icon nice and big using Giganticon, and set Dolphin Browser's homepage to the URL I use for realtime captioning via Streamtext. To get to the captions, it's only a single button push away. When I'm ready to hand the tablet to the client, I push the lock icon and get this:



Now Dolphin Browser is the only app accessible to the client. They can page through my homescreens and eventually find my personal screen (though I have blank homescreens on either side of the main one as a sort of buffer):



But if they try to access my email, they only get a notification that the app has been blocked. All notifications are also turned off, so the client won't get annoying (and possibly confidential) pop-ups from my email, calendar, or other apps while they're trying to read the captions. To unlock the tablet, I just have to draw a simple design in Friend Lock Pro's unlock screen, and the tablet is mine again. I can use it to access student schedules, display prep material, log my steno practice, or navigate to my next gig, using my own personal apps. Then I can lock it back up again and hand it on to the next client, secure that none of that information is accessible to them. Since installing this app, I haven't had to fret or worry about what the client is doing with my tablet when they're out of my sight. I can't recommend it highly enough.

I'm not a paid endorser for this app or anything; I'm just really, really happy with it! If anyone knows of equivalent apps for iOS devices, feel free to let me know about them in comments, and I'll pass them along to my iPad-loving colleagues.

Lucky Printer Giveaway!

My RMR certificate

So I'm a little late with blogging about it, but if you've checked my resume or FAQ page recently, you'll know that I am now Mirabai Knight, CCP, CBC, CRR, RPR, RMR! Yep, after several false starts, I finally passed that last pesky 260 WPM Testimony exam and got to add "Registered Merit Reporter" to my roster of certifications. I have to say it feels pretty good. While I'm disappointed that there aren't any merit-speed realtime certifications, which would be more directly relevant to showcasing my professional skills, the RMR shows that I've got at least a certain amount of speed, even if it doesn't speak much to my realtime accuracy. I'll be taking the RDR written exam this fall, just to collect the whole set of certifications offered by the NCRA, and then I guess there's nowhere else to go but the annual conference realtime and speed competitions. Still haven't decided about those. I don't tend to do my best under test-taking conditions. If they had a test with guaranteed medical subject matter I think I'd do pretty well, but since most of it is full of legal vocabulary, I'd be starting from a disadvantage. I did promise myself that I'd get to go to the NCRA convention if I passed the RMR, though, which is very exciting. It'll be my first national convention since I was a 120 student back in 2006. I wish I could be there for the world record attempt so I could root for my main man Stan Sakai, but sadly I have to work until Friday afternoon, so I won't be getting in until Friday night. That also probably means that I'll be missing the CART and Captioning dessert reception, though I'm gonna hustle from the airport as fast as I can, in hopes of catching the tail end of it. But if any readers of this blog are there, please feel free to flag me down in the hallway and say hi! I'll also be presenting a very short demo of how to use Google Glass for Captioning at the "CART: The Tech Connection" seminar on Saturday at 10:00. (Oh, and I'll be trying to do small informal demos of Plover throughout the weekend. Have you seen our latest release, complete with a video demonstrating our hot new on-the-fly dictionary update system?)

So anyway, I'm really looking forward to putting that RMR ribbon on my name tag. Lord knows it took long enough to get there; I had to take the thing five times, all told. But that's what steno is all about. You keep failing and failing and failing, and then finally you wake up and realize that not only do you have the speed, but you're so much faster than you need to be, and somehow that fact has made those test nerves just magically melt away.

This is my practice graph for the RMR. As you can see, I stopped practicing while waiting for results, which is not recommended, but I just couldn't bring myself to do yet another take when it might turn out that I'd passed.


My RMR practice graph

And I have to give big props to Ann Plainos Record, for our competition. She won hands down (and I sent her a basket of gourmet New York-made munchies as a prize), but just having that extra push helped hugely with my motivation in those last crucial weeks of practice.

But there's one more component of my success. On my next-to-last attempt at the RMR, my old portable printer (which had seen me through the RPR and both the Jury Charge and Literary portions of the RMR) suddenly gave up the ghost, and I wound up unceremoniously dumping it in a garbage can next to the subway entrance before heading home. So for the attempt in May, I actually bought a printer solely for the purpose of getting this one last take.

It's an HP Deskjet 1000, and it cost me about $40. It's certainly not the best printer you'll ever use; these low-end machines tend to be made of cheap components and sold for rock bottom prices so that people will spend lots of money on ink. It's not a patch on the giant, sleek double-sided printer I keep in my home office, but then again, it's far more portable, and it's totally serviceable for low stakes, low volume printing jobs. I really don't see myself getting much use out of it, now that I've passed all the available NCRA speed tests (yeah, sorry, I just enjoy typing that sentence way too much), so I've decided to give it away. After all, it turned out to be lucky for me. Maybe it'll be lucky for you too! The box is a bit ripped up from when I opened it, but it's otherwise in near mint condition; only about 15 pages have been printed on it.



I'm going to be completely arbitrary and subjective about this give-away. Email me at info@stenoknight.com with the subject header "Printer Giveaway" and give me your most persuasive argument about why I should give it to you. Make it interesting! Tell me your story! The person whose email makes the most compelling case will get the printer shipped to them, and hopefully some of that good old test passing magic will come along with it.

Glass for Captioning: First Field Tests

Glass for Captioning series:

Augmented Reality Captioning
Preliminary Impressions of Google Glass

First Field Tests

Last week I tried Google Glass out in the field for the first time. I've gotten a new pair now; Google was very helpful and accommodating when I told them about the optical flaw in my last pair and happily switched them out for a new one. There's still a little bit of glare underneath the screen, which they told me is pretty much inherent to the design, but it's much less than before, and the glare along the sides is gone, plus the smeary left edge has cleared up and the text overall seems crisper and less diffuse than before. I think my prior set just had a slightly misaligned projector or something. Absolute top scores to Google's customer service team, which was communicative, timely, and quick to move.

There are still some frustrations when it comes to actually using Glass for captioning. Initial tests seemed to offer Hangout Screen Sharing as a good solution; the resolution was clear enough that about 8 lines of captioning were visible, very readable, with all of my carefully tweaked Eclipse display and font options on view, plus it would allow me to use all the realtime editing tricks I rely on every day to clean up misstrokes and define new words from my steno machine. It sounded like a slam dunk. When I was just writing a few experimental words for myself, it seemed perfect. Unfortunately, as I feared, when I started actually transcribing the professor in action, the amount of lag involved in refreshing an entire computer screen several times a second quickly tanked the experiment. This was a particularly slow and steady lecturer, but the display was consistently 10 to 20 lines behind my laptop's display, and sometimes it would skip whole swaths of texts in order to catch up to the present, only to fall immediately behind again. So much for that idea. Incidentally, my laptop was on good quality institutional Wi-Fi, and Glass was tethered via Bluetooth to my phone, using the connection from that same institutional Wi-Fi. Glass can connect to most Wi-Fi networks directly, but this particular one required an authentication type that wasn't supported, so it had to piggyback from the connection on my phone. I've also had some trouble connecting it to my 4G hotspot, but I want to fiddle with it some more before deciding whether it's Glass's fault or user error.

So the next day I gave up the beautiful dream of lagless screen sharing and went to the fallback option: Hangout Chat. I set it up well before the class started, which was good, because currently Glass offers no way to turn off the little blips, bloops, swoops, and blats it makes while connecting to someone via Hangout. I really hope they offer a silent option soon; the bone conducting speaker makes the sound louder to the user than to anyone else in the room, but it's still clearly audible and potentially quite disruptive. By default, Glass displays video from whoever you're hanging out with, but I turned that off to save Glass's battery. So then it displayed my user icon, but that was a distracting background against which to view the text, so I set my user icon to a plain black rectangle. Then I muted Glass's own microphone and camera, also to save on battery life. This is what I wound up with:



The Hangout Chat interface without text.



The Hangout Chat Interface with text.

The two main distractors are the prefix of my username before every line of text that's sent (inescapable in this sort of text chat format) and the two prominent "camera muted" and "microphone muted" icons in the center of the lowest part of the screen. I think this is somewhat poor design, considering that new text starts at the bottom and is pushed upward, and that the very top of the screen isn't used by Hangout Chat at all. So rather than keeping the mute icons down at the bottom, interfering with the newest and presumably most important texts, why not put them at the top and out of the way?

The battery was also a little disappointing. On the previous day, when I was screen sharing, it died completely after less than an hour. That was too bad, but I had higher hopes for Hangout Chat, which presumably required less juice. And indeed, its total life was about an hour and 40 minutes, but the intensely irritating low battery alert came on just about exactly halfway through:




So not only does the alert pop up when the battery's presumably only at 50% of its capacity, but the alert is an entire line of full-sized text smack in the middle of the screen. How does that make sense? What's wrong with a discreet little battery icon tucked away in the corner of the screen? I can only hope that as the UI is updated (which happens on a pretty regular basis, I'm happy to say), this will be fixed to be less disruptive. I'll also probably post a comment to the Glass Explorers' Forum. This is, as I have to keep reminding myself, a prototype device, and a lot can change over the next few months.

But here's the most serious issue, which you can also see in the pictures above: Once an old line of text is pushed up to make room for a new one, it's suddenly severely truncated. So if you didn't manage to read the entirety of the text the first time around, it's going to be all but useless to you as soon as another line comes in. For captioning, where text can come in at a pretty solid clip, that is a big, big problem.




This is the main thing that's keeping me from enthusiastically offering Glass to my clients. If all they've got to work with is one line of text, it won't be good for much except slow-paced one-on-one conversations, and if the battery is really only good for less than two hours (I haven't yet tested it with the microphone active, which would presumably reduce the battery life even more, even though it would potentially allow them to interact and even move around without me and my machine having to sit there at their elbow), that severely restricts the circumstances in which Glass will actually be useful.

What about the future? Will Screen Sharing get less laggy? Will they remove the truncation from previous messages? Will they show the username the first time a message is sent and then allow it to be implied for subsequent messages? Will they condense alerts to icons and move them out of the way? Or will I have to commission special captioning Glassware to solve all these problems for me? I guess we'll have to wait and find out.

Oh, and one last thing. By request, a picture of me actually wearing Glass. Dork Factor: Significant.

Preliminary Impressions of Google Glass

For background, read my first post on augmented reality captioning.

I picked up my Google Glass last Thursday. It's certainly an impressive bit of hardware, and I'm very excited about the possibilities for captioning, but of course it's still a prototype device; the consumer models won't be released until after a year of additional quality testing and user feedback. The first pair they gave me had an unresponsive touchpad, and the second pair (the one I have now) seems to have some kind of optical defect that results in a lot of light scattering and glare, which I didn't notice with the first pair. I think I'm going to have to go back to Google to see if they can either repair the problem or give me another pair. The light scattering is just obnoxious, though. It doesn't actually prevent me from using the device. The voice recognition is about as good as one would expect (which is to say, borderline okay when one speaks slowly and deliberately, but pretty terrible with casual speech); no surprises there. It comes with a nice clear plastic lens insert, which will be good to protect the user's eyes in potentially messy situations. It's more lightweight than I expected, and the interface is pleasantly intuitive.

But the really exciting thing is that it seems to be caption-ready pretty much out of the box. I just started a hangout with myself, using my personal Gmail account on Glass and my professional Gmail account on my computer. My computer got video from Glass's camera (which was pointing over the top of my computer monitor, into my apartment's foyer), and Glass got video from my laptop's camera, which showed my own face wearing the admittedly dorky-looking Glass. I muted my laptop's microphone to test the sound quality of Glass's microphone and was impressed with its clarity, though of course we'll have to see how that alters depending on background noise and how far away the people we're captioning stand from the person wearing Glass. Best of all, though, when I typed into the hangout's chat window, the text came up instantly on Glass, with perfect clarity. So even though I haven't actually tested it with my steno machine yet, I think that as long as I use Plover or Eclipse with the Keyboard Macro setting turned on, I'll be able to send captions to Glass without having to commission any additional software. The Wi-Fi in the place I'll be using it is fairly reliable, but if it isn't I can always use my 4G hotspot as a backup. And if the microphone proves to be as good as it seems to be at first glance, I'll be able to caption remotely instead of having to stand next to my client, cramming myself into tiny spaces and generally making a nuisance of myself. The only downside is that I'll have to press "Enter" on my steno machine (which I've mapped to R-R, because it uses the two strongest fingers of the hands) after everything I write. But that won't be so terrible. I actually had to do that when I captioned a webinar two weeks ago, using Plover with the closed captioning feature built into InstantPresenter.com. It's a little tricky to get into the rhythm of pressing Enter each time, but it's certainly not a dealbreaker. More concerning is that Glass's display is designed to be above and to the right of a typical user's line of sight, forcing the user to glance upwards whenever they want to read anything on it, which might result in some eyestrain after constant use. I also haven't tested the battery life yet, though I'm hoping that Glass's battery will be able to withstand at least an hour or two of constant video chat. It's all very promising. Now I just have to get that optical defect sorted out, and then start testing it out with clients!

Our accessible cyberpunk future is so close, I can practically taste it.

Variables in Wireless Captioning

The end of the semester is looming, and with it I'm taking on more work outside of my ordinary daily academic CART schedule. Last week I did an awards ceremony and a graduation ceremony, and yesterday I captioned one of the monthly Songbook performances at the New York Public Library. All three of those events had one thing in common: Wireless captioning. In each case, I was given a partial script of the event, which I was able to feed line by line to the client's screen. Other parts were CARTed live, so I had my steno machine at the ready to switch off from line feeding when necessary. This necessitated a split screen view in Eclipse, which was very different from the clean, stripped-down view I like to use with my clients. In addition, two of the events had multiple viewers, seated at a distance from one another, and the event organizers didn't want me to project open captions to a big screen at the front of the venue. Wireless captioning to the rescue!


Samsung Galaxy Tab


Microsoft Surface Pro

I used my laptop to send the script and monitor my CART output, with pending translation display turned on to give me an extra 1.5 seconds of error correction, since the client wasn't reading my screen and wouldn't be forced to read Eclipse's confusing markup syntax. Then I used Streamtext to send the captions to web browsers on my Microsoft Surface and Samsung Galaxy Tab 2 (to replace my dear old Samsung Q1, now on its last legs and looking somewhat junky), as well as to the smartphones and iPads of any audience members who pointed their browsers to the caption feed's URL. According to the guy in the NYPL sound booth, there were about 15 people using their own equipment to view captions yesterday, which is probably a record at that particular event. Why Streamtext? Well, there are a few options for wireless captions, with pros and cons for each:

* Screen sharing apps such as ScreenLeap or Join.me.

* Peer-to-Peer connections such as Teleview and Bridge.

* Free document collaboration services such as Etherpad or Google Docs.

* Instant messaging applications such as Google Talk.

At these particular events, I didn't want to share my screen, since it was split into two unsightly panes, and because screen sharing is usually restricted to specific devices, while I wanted the captions to be accessible to any number of audience members without having to hook up their equipment individually. Screen sharing is also heavier on bandwidth than simple text streaming, doesn't allow the caption viewer to scroll backwards and review captions they might have missed, and is prone to lag, especially as more devices are added to a single screen. Peer-to-Peer connections such as Teleview and Bridge have a lot of potential, and many of my colleagues have used them, but I've been reluctant to use them much after experiencing several problems with freezing, broken connections, and incompatibilities with institutional Wi-Fi. Since reliability is all-important in a captioning situation where you're not on hand to troubleshoot potential problems with every caption viewer's device, I prefer to use server-hosted text streaming services. That way, if the connection drops on the user's end, they just have to refresh their browser once their connection resumes, and the captions start streaming again as usual. If the connection drops on the captioner's end, they have to reset their connection and then wait for users to refresh their browsers.

That's not ideal, but better than peer-to-peer services, which require both provider and users to go through a synchronized handshaking process whenever either party drops a connection. Instant messaging applications are similarly limited to predetermined lists of users, which wouldn't have worked for me in this situation (though they've proven to be helpful as a stopgap during one-on-one CART when the text streaming service has a sudden outage and I know the user's IM identity). Additionally, instant messaging requires the captioner to press "enter" after every line of text, which slows the rate of captioning, and it doesn't tend to support script feeding. Document collaboration services also don't tend to support script feeding, though they can be useful in live captioning situations that don't require script feeding. However, the collaborative editing features can often prove to be more of a hindrance than an asset in most live captioning situations, and the interface isn't always as clean and simple as I'd like.

So as of right now, Streamtext is my go-to service. It's server-hosted, reliable, supports line-by-line script sending, and can connect any number of users on several different devices by streaming the captions to a single URL accessible by nearly any web browser. It also offers customizable font and color settings, which can be set by the captioner or customized by the user. The only real disadvantage is that, like most good things in life, it costs a pretty penny, starting at $6/hour and increasing from there, depending on how many users are connected at a time. At times, my Streamtext bill has exceeded $400/month, and while it's deductible as a business expense, it hasn't been much fun to pay that bill, knowing that I might have been able to get by with a cheaper or entirely free service instead. Still, I've been burned too often by inconsistent services to want to switch from Streamtext without an extremely compelling reason.

So what other variables are at play, besides the text streaming service? Well, if you're supplying your own devices to clients instead of requiring that they provide their own, you'll want to configure them properly. In my case, the Surface was easy; I just pointed Chrome at my all-purpose text streaming URL (http://stenoknight.com/nypl, since I first set it up for use at the New York Public Library, and have been using it for various other purposes ever since), which redirects to http://www.streamtext.net/player?event=nypl. That way, as long as I set up my Streamtext job to point to a file called "nypl", users only have to input my short Stenoknight.com URL instead of the long, awkward Streamtext URL. I've put a link to the site on both my Surface and my Galaxy Tab 2, for quick and easy access. On the Galaxy Tab 2, I initially tried Streamtext with the default browser and then with Chrome for Android, but neither of them supported full-screen viewing, and I didn't like how much real estate was taken up by the address bar and browser UI, so I installed the Dolphin Browser, which supports simple toggling in and out of full screen mode. The result is a clean, simple text-only interface on both tablets, with customizable font resizing and seamless transitioning between portrait or landscape mode, to fit each client's preferences. One of the three events I captioned was held outdoors, so I was able to crank up the contrast on both devices, with large white text on a black background, to compensate as much as possible for glare.

The last and ultimately most crucial decision was how to make the internet connection that would keep everything running smoothly. My preference when providing remote or wireless captioning is always to connect my captioning computer to a wired wideband Ethernet connection such as the one I use in my home office, but that's not always possible in every venue. At all three recent wireless captioning events, I had access both to institutional Wi-Fi and to the connection offered by my 4G wireless modem/hotspot, but my decision on which to use varied wildly with the circumstances. At the awards ceremony and the library gig (both indoors), the institutional Wi-Fi was strong and steady, faster than my 4G modem and more responsive, with significantly less lag time. At the outdoor graduation ceremony, however, the situation was reversed. The Wi-Fi signal was weak and patchy, dropping frequently and showing significant lag. My 4G modem, on the other hand, had a strong signal throughout, and I quickly switched all my devices over to it from the Wi-Fi during setup. The only disadvantage there, of course, is that the 4G modem has a limited range, and I was concerned that my client's connection would drop if the Galaxy Tab were brought up to the stage during the actual diploma-granting portion of the ceremony. My client decided to go without captioning for that part of the event, so it was never put to the test, but the range limitation is definitely something to keep in mind when choosing a hotspot-based internet solution over institutional Wi-Fi. I've heard of services such as Connectify, which claim to consolidate multiple internet connections as a sort of failsafe mechanism, but I haven't yet given it a try; definitely something to investigate now that the semester's wrapping up.

So there are some things to consider for onsite streaming to multiple wireless devices at public events. Please feel free to share your own tips and tools, if you solve these problems differently! There's always something to learn in this business, and the technology is advancing all the time, so it's important to keep up to date as much as possible. As more people start carrying smartphones and tablets, essentially providing their own caption-viewing devices, I foresee a boom in open-URL wireless device captioning for public events, and we captioners will need to be able to offer it.

Former CART Client Wins NSF Fellowship!!

CART providers are bound by rules of confidentiality not to disclose the names or details of people they've captioned for, but in this case my client graciously allowed me to use her name and link to her information. A few years ago, I captioned several classes (including Latin, one of my all-time favorite subjects) for Navena Chaitoo, an undergraduate at Fordham University up in the Bronx. Now she's graduating, and yesterday she informed me that she won a Graduate Research Fellowship from the National Science Foundation to further her education in public policy and management at Carnegie Mellon University! From the article she sent me:

“I was diagnosed with a severe-to-profound hearing loss when I was about 5 years old, and at the time, my audiologists relied on the latest medical studies to determine that I would probably never graduate high school,” said the Brooklyn native. “Ultimately, my parents knew better and saw to it that I had all the accommodations necessary to offset my hearing loss, which allowed me to be as successful as I am today.”

[...]

Chaitoo will continue research she began at Fordham on the economic wellbeing of persons with disabilities in the United States, particularly the indirect as well as direct medical costs of persons with disabilities—a topic in which she has been personally invested.

Navena is only one of countless examples demonstrating how important accommodations can be, and how much can be achieved if they're put in place. The communication access came from CART providers like me and the other captioners who've worked with her, but the brilliance, insight, and dedication all came from her. This woman is amazing, and I'm honored to have played a part in her success. I know she'll just keep going up and up from here, and I'll definitely be watching to see the great things she does in the future.

Thresholds and Tolerance

I'm not a fan of starting a blog post by quoting the definition of the topic in question; it's virtually always just a lazy attempt to co-opt some of the dictionary's presumed authority or credibility and doesn't add anything of substance to the author's argument. That said...

"Tolerance is the permissible limit or limits of variation in a measured value or physical property of a material, manufactured object, system, or service. [...] A variation beyond the tolerance [...] is said to be non-compliant, rejected, or exceeding the tolerance."

I'm quoting this definition because it refers to a specific technical meaning of an otherwise well known word. Most people aren't familiar with the word "tolerance" used in this sense, but it's a useful concept not just in mechanical engineering but in the provision of transcription services for Deaf and hard of hearing students and professionals. In my CART Problem Solving series, I addressed the popular misconception that a tolerance of 90% accuracy was acceptable, because most people think of 90 and 100 as rather large numbers that are pretty much equivalent to each other, even though language is such a fine-grained system that 100 words constitutes only about a paragraph of text, and a 90% error rate works out to an error in just about every sentence. I also talked about the ways in which human captioners are able to use lateral context clues to fill in the gaps of non-ideal audio conditions, while outside of a perfectly amplified, perfectly enunciated standard American accent, automated speech recognition systems go from almost adequate to laughably awful perilously quickly.

Tolerance enters the captioning sphere in other cases as well. Speed, for instance; if a professor's average rate of speed is 160 words per minute (quite a bit below the typical rate of speech, which tends to be between 180 and 220 WPM), a stenocaptioner (AKA a CART provider like me) with a speed of 240 words per minute will be able to achieve virtually 100% accuracy, because any errors can be immediately caught and corrected. A text expansion provider (using a system such as C-Print or Typewell) may have a speed of 140 words per minute or so, which means that if the professor's rate stays completely steady all the way through, they will probably be able to capture a good 85% of what's spoken. Since they're human and not just a mindless speech recognition system, they will give preference to writing down important things (names, technical terms, relationships between concepts), and will try to make sure that the remaining 15% of speech that they're too slow to capture consists mainly of "Um", "Uh", "You know", repeated words, irrelevant asides, and inefficient phrasing that can be tightened up and paraphrased to use fewer keystrokes. In some cases, that will be enough. The professor's speed will never rise above 160 WPM throughout the entire class, and there will be plenty of chaff to ignore, leaving enough time to take down the important content, even though the provider's writing speed is lower than the professor's average rate of speech. By contrast, the stenocaptioner will probably choose to leave out the "Um", "Uh", and "You know" sorts of filler words for clarity's sake, but will not omit repeated words or attempt to paraphrase the professor's wording, no matter how inefficient it might be. Stenocaptioners are focused on providing a verbatim realtime stream, only omitting words that add absolutely no value to understanding, while text expansion providers are focused on tightening up whatever they hear so that it can be written in as few keystrokes as possible. So far, so good. This is a case where stenocaptioning and text expansion are more or less equivalent, and the difference lies mostly in whether the client wants the pure, unmediated words of their professors to interpret for themselves, or whether they'd rather have a condensed version of the information delivered in class, more along the lines of the bullet points on a PowerPoint slide.

Change any of the factors in play, and the results will be very different. For instance, say the professor's average rate of speed is still 160 words per minute, but that's because his rate is 135 when he's writing formulas on the board (about half the class) and 185 when he's explaining what the formulas mean (the other half of the class). Or it's 140 for long stretches at a time, when he's lecturing on the information mandated by the syllabus, but it shoots up to 200 for brief moments, when he gets excited about a particular detail of whatever he's talking about. The stenocaptioner, whose top speed is 240 WPM, is still able to get 100% in all of these situations. The text expansion provider, on the other hand, will be able to handle the 135 WPM formula sections almost perfectly, but will start cutting or condensing words and phrases from the 185 sections, and will be forced to leave out over a quarter of the material from the 200 WPM sections. If this particular professor has a tendency to repeat words, insert lots of filler words, pause between sentences to take a drink of water, or otherwise speak in a lightweight, inefficient way, the text expansion provider might be able to deliver a workable portion of the class's important material, because there will be enough less important stuff they can cut out and still have enough reserve speed to write down the good parts.

If, on the other hand, the professor is an accomplished speaker, who says precisely what she means in precisely the way she means it, if her lectures are a constant stream of dense technical jargon and precise, specific descriptions of how everything fits together, if there's no chaff or filler to cut out and no awkward repetitions to rephrase... The text expansion provider is out to sea. They've got to start cutting important material in favor of leaving in vital material, and that becomes a dangerous guessing game when it comes to the grade of the student they're transcribing for. Text expansion services acknowledge this to a certain extent; they tend to say that CART is recommended when the material is technical or highly precise, such as in the graduate and professional programs that I specialize in. And admittedly, there are some classes and some subjects and some professors where a 140 WPM typing speed, as slow as it is when compared to a stenocaptioner's 240 WPM typing speed, is enough to deliver most important material given in the class.

The question is: How do you tell which situation you're dealing with? If you're a disability director and you're trying to decide between hiring a text expansion provider or a certified CART provider for a given student's schedule of classes, it may seem obvious to choose the former, since text expansion services are cheaper and more widely available. But have you audited the professors in all of the classes in question? Does their average speed always stay under that 160-180 WPM sweet spot? Is there enough extraneous speech to discard and paraphrase without losing important information? Are there ever spikes of higher speeds, and if there are, can you guarantee that none of that high speed material will appear on the test? Have you checked to make sure that there won't be any guest lecturers or student presentations during the course of the semester? Guest experts, since they're not used to speaking for students, tend to speak at 200 to 220 WPM or higher. One that I transcribed a few years ago spoke at 280 WPM, and I found myself starting to do the same sort of paraphrasing and chaff cutting that my text expansion colleagues do as a matter of course. I think I managed a good 90% to 95% of relevant material given in that lecture. But I didn't reach that paraphrasing threshold until I encountered a speaker at the high end of the rate-of-speech bell curve; for text expansion providers, it's their starting point. They don't have any speed in reserve, and if there's nothing extraneous to cut out, they start losing important material very quickly. Give them a 280 WPM speaker, and they're now losing a full 50% of everything that's spoken.

Of course, you could make the argument that most students without hearing loss don't take in 100% of every lecture. They might daydream or nod off, experience a moment of inattention, miss a word or two here or there while skimming through their notes from the class before. Even without getting every word of every lecture, many students do quite well. But where's the cutoff? How many words can you lose and still receive equal access? Which words can you leave out and which must you absolutely leave in? Who do you trust to make that call? It all comes down to tolerance.