For a while, I’ve entertained the idea of building a notification app for the NYC subway. It seemed like a good idea when I first considered it—near as I could tell, there wasn’t anything like it on the market—and I wasn’t really considering it as a money-making endeavor. Instead, I viewed it as an attainable goal: the MTA likes to advertise the availability of its data on subways. All one has to do is parse the feed and compare with users who have defined times and stations they’re concerned about, right? As it happens, I’d forgotten about the most important element: clean data.
Few things more unsatisfying than looking at the MTA site on a stalled subway and finding "good service."— James Barnes (@j_m_barnes) February 19, 2013
While the MTA does publish data in the GTFS format [1. GTFS started as the Google Transit Feed Specification, but was released to the public name, becoming the General Transit Feed Specification.], the data isn’t, strictly speaking, accurate.
Some years back, the former IRT lines (1,2,3 and 4,5,6) got countdown clocks in some stations. For these clocks to function, the MTA had to first install sensors that tracked where trains were in relation to the stops. Intuitive, right?
Strip away the push-notifications server and geolocation, the app I’d conceived of would do essentially one thing: syndicate content. The content, provided by the MTA, would be the current service status. I’m in no position to install my own array of subway sensors, so to make an app, I’d have to rely on the MTA’s data.
It’s important that when an app or website represents something as happening, that information is accurate. Just knowing that a train is delayed is enough to assuage some of the anxiety one might feel while waiting at a stop. That morning, when I tweeted my frustration, I was angry not only that I was being made late for work, I was angry that the MTA’s website, by claiming “Good Service” on its website, seemed to be not owning up to a clear series of delays. While I’m lucky enough to work in an environment where being a few minutes late isn’t a big deal, and I tend to leave early anyway, that hasn’t always been the case.
Which brings me back to my notional app. While I may still get around to building it one day, my biggest concern is that users would feel the app is a failure, even if it performs the task I design it to perform admirably, because it won’t be able to accurately represent the real reason it’s performing that task: alerting users to potential subway delays.
Organizations considering syndicating content, especially if such syndication will be automatic, should always consider how their users might react if the syndicated content falls short of the standards expect. While it’s unrealistic for every business to create all the content users of its digital presences might desire, sometimes accepting that it’s not worth trying to be the source for that information is the safest bet. Consider the risks of providing bad information, and ask yourself whether that bad information would do more damage than saying anything at all.