CART Problem Solving Series
Superscript and Subscript
Communicating Sans Steno
Speech Recognition, Part I
Speech Recognition, Part II
Speech Recognition, Part III
Speech Recognition, Part IV
This poor blog has been lying fallow while I've been focusing on The Plover Project and keeping busy with all my CART, medical journal transcription, and theater captioning work, but this week I was just informed that one of my CART clients had dropped a class, leaving me with six more hours in my weekly schedule than I had anticipated. In order to put them to good use, I've decided to start a new series on this blog: CART Problem Solving, weekly discussions of various issues that come up in the daily life of a CART provider, and how I've tried to handle them. Some solutions are more satisfying than others, but they're all real-life issues that I've experienced in my work over the past several years. I've already drawn up a list of 10 CART problems on my hard drive, and I've just set a weekly reminder in Remember the Milk to post a problem with its solution to this blog every Monday. I had a pretty good track record the last time I gave myself a rigorous schedule on this blog (the NatCapVidMo Project), so I'm hoping this will be just the incentive I need to get it going again. Okay, let's do the first one!
CART PROBLEM: A CART client doesn't want to sit next to the CART provider.
This problem came up for me at the beginning of the semester, for the class I do every Monday morning. The client is a freshman, and he feels self-conscious when he has to sit next to a total stranger with a laptop on a tripod and lots of other weird, conspicuous equipment. He needs the CART to perform well in the class, but his embarrassment was so great that he asked me to sit far away from him on the first day, and told me he'd just read the transcript when I sent it to him that evening. I complied, but when I looked over I could see him straining to understand what the professor was saying. I knew that just reading the transcript after the fact wasn't enough for him to get the full benefit from the class. He needed to have the words in front of him as they were being said, so that he could interact with the professor and the other students in realtime as the class went on. I noticed that he had his laptop with him, so at the end of class I asked him if he would like me to send the realtime feed to his laptop during the next class. He agreed enthusiastically, so when I sent him the morning's transcript I also emailed him a URL he could use to access the CART feed using his web browser. The next week, I set up my computer in the front of the class (near a power outlet, another advantage for me; the student liked sitting in the back, away from all the outlets) and plugged in my 4G wireless modem. Then I started a job on StreamText, with a job name corresponding to the URL I had given him. He logged into the chat room, which let me know that he was present in the classroom (it's a class of over 100 students in a very wide room, and I didn't want to make him come all the way over to check in with me in person, but the disability office doesn't want me to write unless the student is present, so that there isn't an incentive to just read the transcripts instead of showing up every day.) Since I was sitting in the front of the room, I could hear the professor and all the other students very clearly, and he was able to hang out in the back with his laptop, looking just like every other plugged-in freshman in the room.
Some remote CART companies offer this problem as a reason for a university to contract with remote rather than onsite providers, but as you can see, I'm able to offer all the advantages of remote CART:
* Letting the student blend in with their peers
* Letting the student sit wherever they want in the room
* Giving the student a realtime transcript that lets them scroll backward and forwards at will
without any of the disadvantages, such as:
* The inability to hear anyone in the classroom other than the person wearing the microphone (usually the professor, though sometimes remote CART classes use the student's laptop microphone, which usually results in terribly substandard audio quality).
* Lack of access to PowerPoint slides and other visual cues present in the classroom.
* Data disruptions caused by spotty Wi-Fi signals. (Streamtext is very low-bandwidth, so it tends to be quite stable, unlike the higher bandwidth VOIP applications usually used to send audio to the remote provider, which can cut out, fuzz up, or disconnect unpredictably.)
This solution lets me provide the more consistent service that onsite CART is known for, while keeping a low profile and letting the student view the text discreetly on his own computer. Stay tuned next week for another CART problem and its corresponding CART solution!
Thanks, Mirabai. I like that option. One of our onsite CART students tends to be rather chatty but needs to project in order for all (including me) to hear him. Any suggestions on how to politely ask him to "speak up"?ReplyDelete
I think probably nonverbal cues are the best in that case. Furrowing your eyebrows and leaning in are good indications that you can't quite hear the student. Writing what they say with the occasional (inaudible) inserted can also make the point subtly and discreetly.ReplyDelete
IEEE Project Domain management in software engineering is distinct from traditional project deveopment in that software projects have a unique lifecycle process that requires multiple rounds of testing, updating, and faculty feedback. A IEEE Domain project Final Year Projects for CSE system development life cycle is essentially a phased project model that defines the organizational constraints of a large-scale systems project. The methods used in a IEEE DOmain Project systems development life cycle strategy Project Centers in Chennai For CSE provide clearly defined phases of work to plan, design, test, deploy, and maintain information systems.ReplyDelete