Vragen Van Theo

Several months ago, I had a pretty comprehensive discussion with a Dutch colleague, Theo Tomassen, who had sent me questions regarding my general procedures as a captioner. Seeing as how there is very little material on stenography on the Internet in the Dutch language, I thought I’d share his questions and my responses on my blog. It is still not complete as Theo is working on his responses to my questions I posed in response but I will post a follow-up as soon as I have them! What follows is completely in Dutch. If you don’t speak Dutch but would like to know what was said, there’s always Google Translate :]. Also, please keep in mind that Dutch is not my native tongue.

Een paar maanden geleden, had ik een hele uitgebreide discussie met een Nederlandse collega, Theo Tomassen, die stuurde mij een aantal vragen over mijn algemene procedures als schrijftolk. Aangezien het gebrek aan publicaties hierover in de Nederlandse taal op het internet, heb ik besloten om zijn vragen en mijn antwoorden op mijn blog te delen. Het is nog niet klaar want ik wacht op Theos antwoorden naar aanleiding van mijn vragen maar ik post ze hierop zodra ik ze heb! Het navolgende is compleet in Nederlands. Als je geen Nederlands spreekt en je wilt graag even weten wat er gezegd werd, is er natuurlijk altijd Google Translate :]. Bovendien, hou er rekening mee dat het Nederlands niet mijn moedertaal is.


THEO: Mijn belangrijkste vraag is wat langer, die moet ik even inleiden. Deze heeft betrekking op finger spelling. Ik heb je verteld dat ik voor Nederlands werk als gediplomeerd schrijftolk (“CARTer”) voor doven en slechthorenden. De vraag naar Engels is groot, maar er zijn maar weinig schrijftolken die dat willen/kunnen. Echter, het Engels wordt vaak gesproken door Nederlanders. Dit betekent dat er regelmatig Nederlandse instellingen, plaatsnamen, namen van personen worden genoemd die uiteraard niet in mijn dictionary staan.

STANLEY: Dat is geweldig te horen! Ik vond Amsterdam heel, heel prachtig wanneer ik deze zomer op bezoek was. Ik begon over te denken de mogelijkheid van misschien daarheen verhuizen en werken maar voor nu, geniet ik van het leven in New York. In Januari, woon ik hier pas twee jaren. Ik kom oorspronkelijk uit Seattle.

THEO: Stel dat een spreker zou zeggen: “Ladies and gentlemen, I should now like to give the floor to Theo Tomassen, president of the Nederlandse Schrijftolken Vereniging.” Ik weet niet zeker of het praktisch om dergelijke woordklonten steeds allemaal te vingerspellen op de Diamante. Ik weet dat Stenograph een QWERTY-toetsenbord heeft dat je op de Diamante kan bevestigen. Ik kan heel snel typen op QWERTY, die snelheid zal ik nooit halen op de Diamante.

STANLEY: Wat mij betreft, zou ik nooit een extern toetsenbord gebruiken. Je zou wat heel tijd vergen voor wisselen tussen de beide als je moet dat vaak doen.

THEO: Vraag dus: is het een rare werkwijze om te wisselen tussen de Diamante en dat toetsenbord in dergelijke gevallen? Ik snap dat dit op een snelheid van 230 woorden per minuut misschien lastig is, maar in Nederland onderbreken de tolken de spreker als ze op dit soort abnormale snelheden praten.

STANLEY: Zoals ik al zei: Ik zou alleen op het klaarmaken (prep) en op fingerspelling vertrouwen voor woorden die ik niet in mijn woordenboek heb.

THEO: Als je aan het CART’en bent en er valt een woord waarvan je sterk het vermoeden hebt dat het niet in je woordenboek staat, vingerspel je dat dan of kies je een synoniem?

STANLEY: Bijna altijd fingerspelling. Ik zou een synoniem kiezen alleen als ik geen andere keuze heb (bv, de spreker gaat te snel of ik kon niet het precies woord horen).

THEO: Schrijf je tijdens het CART’en alle hoofdletters —

STANLEY: Nee. Mixed case, altijd ;].

THEO: contractions voor “he’s” en dergelijke?

STANLEY: Ik probeer doorgaans, een echte woordelijk verslag te maken dus schrijf ik, alles, zo veel mogelijk, precies hoe ik het heb gehoord, zelfs wanneer wat de spreker zegt is formeel niet goed Engels. Als hij “‘cause” zegt ipv “because”, dat is wat ik in de transcriptie zet. Want deze (in tegenstelling tot situaties in de rechtbank) zijn geen officieele verslagen, is het niet noodzakelijk altijd aan formele grammaticaregels te houden.

THEO: Als bijvoorbeeld een instelling “City Health Care” heet en het tempo is voor mij hoog, schrijf ik “city health care”.  Ik weet dat er een Case CATalyst een aanslag is om bijvoorbeeld de vorige drie woorden een hoofdletter te geven, maar het is toch allemaal weer bagage.

STANLEY: Ja, doorgaans als de snelheid is te hoog, zorg ik me niet zo veel over kleine details zoals hoofdlettergebruik. Het belangrijkste ding op dat moment is alle de woorden krijgen.

Als het mogelijk is, je moet gebruiken alleen macros die veranderingen maken voordat de text verzonden wordt. Met andere woorden, gebruik functies die het volgend woord een hoofdletter geeft (en niet het vorig). Met meeste systemen zoals Text-On-Top of broadcast encoders, je bewerkingen zullen niet weerspiegeld worden als je probeert naderhand veranderingen te maken. Laat me eens weten als je dit niet begrijpt.

THEO: Heb je bepaalde dingen in je dictionary gedefinieerd die bij het CART’en enorm handig zijn en tijdwinst opleveren?

STANLEY:

  • Een stroke voor het toevoegen van definities.
  • Gemeenschappelijke symbolen zoals @, $, _, %, <, >, <=, >=, -, –, =, !, daarnaast Griekse letteren, en definities voor Spaanse en Duitse letteren: á, é, ë, ä, enz. Ik heb zelfs alle de emoji gedefinieerd.

THEO: Wat is jouw mening over briefs? Als ik op de Facebook-pagina Supporting Court Reporter Students kijk, zie ik dat veel mensen voor de meest gekke termen een brief vragen. Termen die je niet zo vaak tegenkomt. Natuurlijk leveren briefs tijdwinst op, maar ik briefs voor zeldzamere termen onthoud ik toch niet.

STANLEY: Als ik moet een woord of zin meer dan twee keer schrijven, dat bestaat uit meer dan twee toetsenaanslagen, maak ik een brief. Ik heb weinig of geen probleem om veel briefs te memoriseren maar ieder mens is uniek qua talent dus ik denk dat je moet doen wat is voor jou de makkelijkste.

Ik wil je laten weten dat je moet niet alles wat je leest op die pagina serieus nemen. Hoewel er goede en handige informatie is, zit er heel veel advies dat het niet waar is, gebaseerd op ouderwetse meningen. Je moet altijd je eigen oordeel vormen nadat je een aantal mensen geraadpleegd hebt.

THEO: Zijn er dingen die je op de opleiding voor court reporter leert, maar die je werkelijk nooit zult toepassen in CART? Ik denk bijvoorbeeld aan “8 o’clock”. Dat zou je dan moeten schrijven als “8:00 o’clock”. Nu heb ik in mijn dictionary aanslagen gedefinieerd als /8 /KHRBG, dat wordt dan “8:00 o’clock”. Maar vanuit CART gezien vind ik het een beetje van de zotte om in alle gevallen aan een hypercorrecte schrijfwijze vast te houden. Of zie je dat anders?

STANLEY: Ik heb geen ervaring met in de rechtbank werken dus ik voel  me niet bevoegd/gekwalificeerd om deze vraag te beantwoorden.

THEO: Een beetje aansluitend op vraag 6: heb je misschien nog suggesties hoe ik mijn speedbuilding-traject zou kunnen aanpakken?

STANLEY: Je moet met verscheidene materialen oefenen. Wat is belangrijkste is niet te vervelen. Ik luisterde vaak naar de uitzendingen van howstuffworks.com. Ze zijn vrij op iTunes om te downloaden. Vind inhoud waarin je bijzonder geïnteresseerd bent. Je hoeft niet naar dezelfde saaie drills opnieuw en opnieuw luisteren. Kies, bv, een Engelse televisieprogramma of radioprogramma dat je leuk vindt en doe dat maar.

THEO: Ik zal nooit in mijn leven werk doen dat op court reporting lijkt, maar begin straks gelijk met CART’en. Het heeft voor mij dus geen zin om een heel goede court reporter te worden die niet kan CART’en: stel dat een snel gesproken tekst over “Chicago” gaat en ik heb geen brief daarvoor. Ik kan zou dan als court reporter telkens een “C” kunnen aanslaan, want ik onthoud wel dat het om “Chicago” gaat. Maar als CART’er kom ik daar niet mee weg. Ik moet/wil dus nu al op CART-kwaliteit studeren: de output moet een volledig leesbare tekst zijn, waarbij ik uiteraard een paar fouten wel accepteer. Maar een hele reeks untranslates die nog wel te lezen zijn voor een court reporter, slaat natuurlijk nergens op voor CART’en.

STANLEY: Ja, dat is heel onaanvaardbaar voor schrijftolken. Je moet voor de eerste keer, de woord dat bestaat niet in je woordenboek fingerspellen en laat de software je een briefsuggestie geven. Wanneer je een moment hebt, maak je dan een definitie die ga in je dict te blijven.

THEO: Zijn er nog bepaalde realtime-instellingen in Case CATalyst die ik beslist goed moet bekijken omdat ze handig zijn? Misschien gebruik je Eclipse of iets anders, maar ik denk dat er veel functies zijn die elkaar veel overlappen?

STANLEY: Kun je hier, specifieker zijn?

THEO: Welke setup gebruik je om de tekst draadloos door te sturen naar bijvoorbeeld een tablet van een klant? Case CATalyst heeft nu CASEview, maar  de licentie daarvan ik niet echt goedkoop. En ik moet volgens mij een wifi-verbinding hebben, wat ook niet overal mogelijk is.

STANLEY: In het verleden, ik gebruikte de vrije versie van Bridge maar ik heb onlangs een programma geschreven die voert deze functie uit! Bovendien is het vrij (voor nu). Je kan mijn niet-zo-korte beschrijving op mijn website lezen. http://stanographer.com/aloft.

THEO: Voor mijn Nederlandse werk gebruik ik Text On Top voor een draadloze verbinding. Die kan ik ook met Case CATalyst gebruiken, maar de lay-out wordt dan niet overgenomen. Als ik een Enter geef, gebeurt er niets op het scherm van de klant. De ontwikkelaar heeft uitgelegd waarom dat zo is, gaat wat ver om dat allemaal uit te leggen. Maar het is wel zo.

STANLEY: Ik denk dat er een instelling is voor “verbatim mode” of zo waarbij je moet ctrl + enter drukken om een nieuwe lijn te maken en niet gewoon enter. Maar ik gebruik CC niet, dus ik weet niet wat zou dat gedrag kunnen veroorzaken.

THEO: Ik heb je videoblog over de Lightspeed gezien. Is het iets om te overwegen?

STANLEY: YES! I LOVE IT! Heb je specifieke vragen erover? Mijn god, ik kan niet langer in deze taal praten. Haha.

Aloft!

First off, apologies for the long radio silence. It’s been far too long since I’ve made any updates! But I just had to share a recent that I’m currently probably the most excited about.

[ Scroll down for TL;DR ]

To begin, a little background. For the past several months, I’ve been captioning an intensive web design class at General Assembly, a coding academy in New York City. Our class in particular utilized multiple forms of accommodation with four students using realtime captioning or sign interpreters depending on the context, as well as one student who used screen sharing to magnify and better view content projected in the classroom. A big shout-out to GA for stepping up and making a11y a priority, no questions asked.  

On the realtime captioning front, it initially proved to be somewhat of a logistical challenge mostly because the system my colleague and I were using to deliver captions is commercial deposition software, designed primarily with judicial reporting in mind. But the system proved to be less than ideal for this specific context for a number of reasons.

  1. Commercial realtime viewing software either fails to address the needs of deaf and hard of hearing individuals who rely on realtime transcriptions for communication access or addresses them half-assedly as an afterthought.

The UI is still clunky and appears antiquated. Limited in its ability to change font sizes, line spacing, and colors, it makes it unnecessarily difficult to access options that are frequently crucial when working with populations with diverse sensory needs. Options are sequestered behind tiny menus and buttons that are hard to hit on a tablet. One of the most glaring issues was the inability to scroll with a flick of the finger. Having not been updated since the widespread popularization of touch interfaces, there is practically no optimization for this format. To scroll, the user must drag the tiny scroll bar on the far edge of the screen with high precision. Menus and buttons clutter the screen and take up too much space and everything just looks ugly.

  1. Though the software supports sending text via the Internet or locally via Wi-Fi, most institutional Wi-Fi is either not consistently strong enough, or too encumbered by security restrictions to send captions reliably to external devices.

Essentially, unless the captioner brought his or her own portable router, text would be unacceptably slow or the connection would drop. Additionally, unless the captioner either has access to an available ethernet port into which to plug said router or has a hotspot with a cellular subscription, this could mean the captioner is without Internet during the entire job.

Connection drops are handled ungracefully. Say I were to briefly switch to the room Wi-Fi to google a term or check my email. When I switch back to my router and start writing, only about half of the four tablets usually survive and continue receiving text. The connection is very fragile so you had to pretty much set it and leave it alone.

  1. Makers of both steno translation software and realtime viewing software alike still bake in lag time between when a stroke is hit by the stenographer and when it shows up as translated text.

A topic on which Mirabai has weighed in extensively — most modern commercial steno software runs on time-based translation (i.e. translated text is sent out only after a timer of several milliseconds to a second runs out). This is less than ideal for a deaf or hard of hearing person relying on captions as it creates a somewhat awkward delay, which, to a hearing person merely watching a transcript for confirmation as in a legal setting would not notice.

  1. Subscription-based captioning solutions that send realtime over the Internet are ugly and add an additional layer of lag built-in due to their reliance on Ajax requests that ping for new text on a timed interval basis.

Rather than utilizing truly realtime technologies which push out changes to all clients immediately as the server receives them, most subscription based captioning services rely on the outdated tactic of burdening the client machine with having to repeatedly ping the server to check for changes in the realtime transcript as it is written. Though not obviously detrimental to performance, the obstinate culture of “not fixing what ain’t broke” continues to prevail in stenographic technology. Additionally, the commercial equivalents to Aloft are cluttered with too many on-screen options without a way to hide the controls and, again, everything just looks clunky and outdated.

  1. Proprietary captioning solutions do not allow for collaborative captioning.

At Kickstarter, I started providing transcriptions of company meetings using a combo of Plover and Google Docs. It was especially helpful to have subject matter experts (other employees) be able to correct things in the transcript and add speaker identifications for people I hadn’t met yet. More crucially, I felt overall higher sense of integration with the company and the people working there as more and more people got involved, lending a hand in the effort. But Google Docs is not designed for captioning. At times, it would freeze up and disable editing when text came in too quickly. Also, the user would have to constantly scroll manually to see the most recently-added text. 

With all these frustrations in mind, and with the guidance of the GA instructors in the class, I set off on building my own solution to these problems with the realtime captioning use case specifically in mind. I wanted a platform that would display text instantaneously with virtually no lag, was OS and device agnostic, touch interface compatible, extremely stable in that it had a rock solid connection that could handle disconnects and drops on both the client and provider side without dying a miserable death, and last but not least, delivered everything on a clean, intuitive interface to boot.

How I Went About It

While expressing my frustrations during the class, one of the instructors informed me of the fairly straightforward nature of solving the problem, using the technologies the class had been covering all semester. After that discussion, I was determined to set out to create my own realtime text delivery solution, hoping some of what I had been transcribing every day for two months had actually stuck.

Well, it turned out not much did. I spent almost a full week learning the basics the rest of the class had covered weeks ago, re-watching videos I had captioned, putting together little bits of code before trying to pull them together into something larger. I originally tried to use a library called CodeMirror, which is essentially a web based collaborative editing program, using Socket.io as its realtime interface. It worked at first but I found it incapable of handling the volume and speed of text produced by a stenographer, constantly crashing when I transcribed faster than 200 WPM. I later discovered another potential problem — that Socket.io doesn’t guarantee order of delivery. In other words, if certain data were received out of order, the discrepancy between what was sent to the server versus what a client received would cause the program to freak out. There was no logic that would prioritize and handle concurrent changes.

I showed Mirabai my initial working prototype and she was instantly all for it. After much fuss around naming, Mirabai and I settled on Aloft as it’s easy to spell, easy to pronounce, and maintains the characteristic avian theme of Open Steno Project.

I decided to build Aloft for web so that any device with a modern browser could run it without complications. The core server is written in Node. I used Express and EJS to handle routing and layouts, and JQuery with JavaScript for handling the dynamic front-end bits.

Screenshot of server code

Screenshot of server code

I incorporated the ShareJS library to handle realtime communication, using browserchannel as its WebSockets-like interface. Additionally, I wrapped ShareJS with Primus for more robust handling of disconnects and dissemination of updated content if/when a dropped machine comes back online. Transcript data is stored in a Mongo database via a wrapper, livedb-mongo, which allows ShareJS to easily store the documents as JSON objects into Mongo collections. On the front end, I used Bootstrap as the primary framework with the Flat UI theme. Aloft is currently deployed on DigitalOcean.

Current Features

  • Fast AFtext delivery that is as close to realtime as possible given your connection speed.
  • OS agnostic! Runs on Mac, Windows, Android, iOS, Linux, anything you can run a modern Internet browser on.
  • User login which allows captioner to create new events as well as visualize all past events by author and event title.
  • Captioner can delete, modify, reopen previous sessions, and view raw text with a click of a link or button.
  • Option to make a session collaborative or not if you want to let your viewers directly edit your transcription.
  • Ability for the viewer to easily change font face, font size, invert colors, increase line spacing, save the transcription as .txt, and hide menu options.
  • Easy toggle button to let viewers turn on/off autoscrolling so they can review past text but be quickly able to snap down to what is currently being written.
  • Ability to run Aloft both over the Internet or as a local instance during cases in which a reliable Internet connection is not available (daemonize using pm2 and access via your machine’s IP addy).
Aloft homepage

Aloft homepage appearance if you are a captioner

In the Works

  • Plugin that allows captioners using commercial steno software that typically output text to local TCP ports to send text to Aloft without having to focus their cursor on the editing window in the browser. Right now, Aloft is mostly ideal for stenographers using Plover.
  • Ability for users on commercial steno software to make changes in the transcript, with changes reflected instantly on Aloft.
  • Ability to execute Vim-like commands in the Aloft editor window.
  • Angularize front-end elements that are currently accomplished via somewhat clunky scripts.
  • “Minimal Mode” which would allow the captioner to send links for a completely stripped-down, nothing-but-the-text page that can be modified via parameters passed in to the URL (e.g. aloft.nu/stanley/columbia?min&fg=white&bg=black&size=20 would render a page that contains text from job name columbia with 20px white text on a black background.

That’s all I have so far but for the short amount of time Aloft has been in existence, I’ve been extremely satisfied with it. I haven’t used my commercial steno software at all, in favor of using Aloft with Plover exclusively for about two weeks now. Mirabai has also begun to use it in her work. I’m confident that once I get the add-on working to get users of commercial stenography software on board, it’ll really take off.

Using Aloft on the Job

Using Aloft on the Job on my Macbook Pro and iPad

TL;DR

I was captioning a web development course when I realized how unsatisfied I was with every commercial realtime system currently available. I consulted the instructors and used what I had learned to build a custom solution designed to overcome all the things I hate about what’s already out there and called it Aloft because it maintains the avian theme of the Open Steno Project.

Try it out for yourself: Aloft.nu: Simple Realtime Text Delivery

Special thanks to: Matt Huntington, Matthew Short, Kristyn Bryan, Greg Dunn, Mirabai Knight, Ted Morin