Wireless for WMATA: what’s at stake?

Since late 2008, the Washington Metropolitan Area Transit Authority has been working to deliver modern wireless service throughout the underground portions of the Metrorail system. Unlike some mass transit systems, however, WMATA did not undertake this project simply out of a desire to improve passenger experience; they did so because of a few short sentences in the Passenger Rail Investment and Improvement Act of 2008 (hereinafter PRIIA), enacted on October 16, 2008:

No amounts may be provided to the Transit Authority pursuant to the authorization under this section unless the Transit Authority ensures that customers of the rail service of the Transit Authority have access within the rail system to services provided by any licensed wireless provider that notifies the Transit Authority (in accordance with such procedures as the Transit Authority may adopt) of its intent to offer service to the public, in accordance with the following timetable:
(A) Not later than 1 year after the date of the enactment of this Act, in the 20 underground rail station platforms with the highest volume of passenger traffic.
(B) Not later than 4 years after such date, throughout the rail system.

WMATA met the first deadline, turning up a new distributed antenna system and signing on the four major carriers (AT&T, Sprint, T-Mobile, and Verizon). But the second deadline has proved thornier. A recent Washington Examiner article described the contractor installing the system as being in “dire financial straits”. Anecdotal reports from riders have shown that cellular service has been spotty, even at stations which initially had good coverage.

With October 16 just over a month away, you might think that WMATA would be forthcoming with status updates. Unfortunately, WMATA has responded to the situation with its usual opacity:

So, what does WMATA stand to lose if they miss the deadline? As PRIIA states, “[no] amounts may be provided…”, and the amounts authorized under the Act are considerable:

There are authorized to be appropriated to the Secretary of Transportation for grants under this section an aggregate amount not to exceed $1,500,000,000 to be available in increments over 10 fiscal years beginning in fiscal year 2009, or until expended.

Clearly, this is not a deadline that WMATA should take lightly.

The Massachusetts Bay Transportation Authority, like WMATA, is in the midst of wiring its rail system for wireless service, and they, too, have experienced delays. However, they’ve been more upfront about the situation; an article published earlier this year distinguished between delays attributable to the MBTA’s contractor and those attributable to the cellular carriers.

Even if WMATA and their contractor manage to pull through and meet PRIIA’s October 16 deadline, there are still best practices they can and should adopt. In New York City, the contractor deploying wireless service on the subway, aptly named Transit Wireless, has established their own presence, rather than lurking in the shadows like the contractors deploying systems in DC and Boston. Through their Web site and Twitter account, Transit Wireless reaches out directly to riders, taking questions and helping them understand what services are available, and where.

By contrast, WMATA refers questions to the carriers, who tend to either deny knowledge of service in the Metro, or refer questions back to WMATA. After WMATA’s initial announcement of service at underground stations, updates have been spotty at best—and there’s no list of covered stations or timetable for future service rollouts.

Making transit alert feeds effective

The MBTA provides a real-time feed for commuter rail departures; as the service is in beta, they exhort developers to make use of the complementary T-Alerts feed, which is likely to provide useful information during disruptions that the real-time departures feed cannot convey. But transit alerts are hard to get right—something WMATA found out as riders started howling about useless Tweets like “Red Line: Alert cleared.”. So, while it’s good that the MBTA provides a feed of alerts, it’s important to make sure that those alerts are actually useful. Part of that means keeping in mind that developers are likely to use the information in a very wide variety of ways, and there’s no such thing as a one-size-fits-all transit alert.

Applications which are displaying alerts on mobile devices or digital signage, or feeding them into a text-to-speech engine, need simple, concise text. Text like “click here” which works when the alert is displayed in a Web browser becomes irrelevant filler when displayed on digital signage or rendered through a text-to-speech engine.

Let’s look at a few sample alerts from the MBTA and see how they can be improved:
Continue reading Making transit alert feeds effective

Better rail data for better apps

A number of transit agencies, including WMATA, BART, CTA, and the MBTA, offer real-time data rail system data as part of their open data initiatives. While each agency’s implementation is different, most revolve around distributing train predictions—the same data used by countdown clocks in stations. This data is immediately useful for many applications, like mobile and desktop widgets which mimic the look and feel of in-station countdown clocks. But for some applications, like How’s Metro, How’s the T (by the same developer), and this real-time train map for Metrorail, train predictions are not useful. These applications depend on knowing where trains are, rather than knowing how far a train is from a given station.

In short, if the only rail data a transit agency provides is train predictions, then developers who want to know the actual locations of trains must reverse-engineer that data from the predictions. Generating predictions based on track circuit occupancy and schedule information is far from a flawless process; the end result often contains glitches. When developers try to work backward from train predictions to infer the actual positions of trains, the result is noisy data. And besides, why should developers have to make the effort, when the transit agencies themselves already have the data available?
Continue reading Better rail data for better apps

Rider feedback for transit systems: the good and the bad

In July 2010, I attended a briefing for developers put on by WMATA, in advance of the launch of WMATA’s open data initiatives. One of the points expressed by developers at the meeting was a desire to give riders an easy way to provide feedback to WMATA from within mobile transit apps. So, while I was browsing the MBTA‘s developer resources page recently, I was interested to see that they have a pilot program to allow developers to communicate rider feedback to the MBTA from within apps. The program, called Commuter Connect, offers a web service which accepts text and images from riders. It looked great to me, until I checked the documentation. Rather than offering riders a simple free-form comment field, riders must give their full name, email address, home city, state, and ZIP code (what about non-US residents?), among other fields. Worse, riders must select a ‘topic’ and ‘subtopic’, choosing from dozens of cryptically-named options, like “Insensitive to Cust Needs” and “Passenger Bypass”.
The FAQ for the program says:

Why so many required fields? Commuter Connect is built as a part of customer care center′s management system. For us to follow-up on comments, we need all required fields. For full details of how to use the system please closely review the documentation.

Simply put, the problem with Commuter Connect is that it communicates with riders in the vernacular of the transit system, and expects them to do the same. There’s no absolute reason that riders have to classify the problem they’re submitting (least of all in the transit agency’s specialized vernacular); that can be done by the transit agency’s staff. More to the point, it exemplifies the sort of tone-deafness which perpetuates communication with riders by mass transit agencies—an inability to use plain language and communicate clearly. WMATA’s customer comment form exhibits the same problem—essentially ignoring rider feedback if the rider cannot be bothered to jump through all of the transit agency’s hoops—along with an expectation that riders will describe their problems in the same terms the transit agency would use. Perhaps the only redeeming factor for the MBTA’s Commuter Connect program is that it makes it easy to upload a photo (but accepting video as well would be even better).

By contrast, the approach taken by DDOT with the DC Circulator is a model for making rider feedback easy. Every Circulator bus has stickers prominently applied with a QR code and URL which allow riders to provide feedback; the feedback form is simple and uncomplicated:
DC Circulator feedback form
The mobile site requires no specialized software, and works on any device with a Web browser. Riders are not required to provide their personal information, nor are they required to categorize their comment according to the narrow confines of the transit agency’s schema. At the same time, if a rider wants to provide their contact information, there’s nothing stopping them from including it with their remarks. DDOT’s approach is designed to accept as much feedback as possible, rather than rejecting potential valuable feedback based on technicalities (like failure to include one’s home ZIP code, or classify one’s comment into arcane categories).

In short, transit agencies should be responsive to rider feedback even though it may come in a range of forms, and they should make the process as straightforward as possible—more like the DC Circulator, less like WMATA and the MBTA.