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.