This is an awesome article. Thanks for posting it Susan!. I actually was just about to post it myself since I read it after seeing a link posted on the Transitwire.
Here are some quotable quotes:
“Undeterred by Roadify’s failure (dangerous to use, bad data), the city announced the third installment of the BigApps contest in September, in which the city awards $50,000 in cash to the best app that uses city data. So far the first two contests have yielded apps that have received a fair amount of media attention but have lagged in user adoption. Sportify, another winner that garnered a lot of press, also relies on a critical mass of users to function. It, too, is a great idea in principle (find people near you who want to play pickup sports!), which has yet to catch on. All of this is the predictable result of the city’s approach to digital development, which focuses on plenty of sizzle, not much steak. It’s time for the city to deeply explore what New York’s citizens actually need, and the ways in which those citizens are likely to behave.”
“The problem with the BigApps contest is that it leaves both user needs and likely user behavior out of the equation, instead beginning with an enormous data dump and asking developers to make something cool out of it”
“Some quick user experience work would have made this abundantly obvious and saved the city $50,000. “
“Instead of just throwing technology at New Yorkers purely for technology’s sake, why not start by spending $50,000 on talking to the people who live in the city and finding out what they really need? “
“And the widely publicized “Re-Invent NYC.gov Hackathon” held over the summer is only going to encourage more Roadify-like ideas, rather than address what people really need out of the city’s website. “
Clearly, the article is not a fan of NYC’s digital approch.
Other issues raised concern providing long url’s to service change pages on posters in a subway, where there is no internet or phone access, and the mobile app on when the next bus will arrive.
The author does praise other cities such as Boston and Louisville, Kentucky.
Thanks, Jim. Great comment, and glad to hear you first found the story on TheTransitWire. (You know I edit that, right?)
I thought Hana made a lot of good points about the disconnect between what users want/need and what developers create.
At the same time, I thought she was a little harsh about the MTA’s Bus Time app, in particular, which is a pretty creative solution for cash-strapped agencies that cannot (or choose not to) invest a lot of money into services that estimate bus arrival time to the second. It’s not quite as simple as multiplying distance times speed, unfortunately.
As a Boston resident, I was pleased to see that she cited Citizens Connect as a good example. Although for some reason every time I’ve tried to use it, I give up in frustration and end up sending an email to the city through its online interface with equally successful results. (Probably just my problem.) I also know that some agency people (at the kind of agencies that rely on developer competition to develop apps rather than pay someone to come up with a product) have privately questioned the city’s decision to spend money on something a third-party developer would do for free.
Wow – It’s a small world. FYI – I think The TransitWire is a great resource and follow it religously. I help track the benefits, costs, and lessons learned of Transit ITS systems for the ITS JPO Knowledge Resources, and it has given me many a good lead to track down :-).
I agree that Hana might have been a bit harsh on the design of the MTA Bus Time app, and if you follow the links someone explained more fully that other options exist. However, the main point remains the same that evidence is starting to come out that app contests and hackathons may be more sizzle than meat, if the agency and the app developer doesn’t commit to maintaining the information feeds and the app itself.
It also doesn’t cost a lot of money to build on others successes and replicate (or expand upon ) what has been proven to be a good user interface or tool. What is happening now in some of the contests is too much starting from scratch by folks that may be whizzes with the data, but may not have the domain knowledge to not repeat others mistakes.
Now that the pioneers have proven what can be done with open transit data and other information we should really start building an understanding of good practices, what works and doesn’t work, and what really should not be done.
Are you going to be at the transportation camp in DC prior to TRB? This may be worthy of discussion there.
This is an awesome article. Thanks for posting it Susan!. I actually was just about to post it myself since I read it after seeing a link posted on the Transitwire.
Here are some quotable quotes:
“Undeterred by Roadify’s failure (dangerous to use, bad data), the city announced the third installment of the BigApps contest in September, in which the city awards $50,000 in cash to the best app that uses city data. So far the first two contests have yielded apps that have received a fair amount of media attention but have lagged in user adoption. Sportify, another winner that garnered a lot of press, also relies on a critical mass of users to function. It, too, is a great idea in principle (find people near you who want to play pickup sports!), which has yet to catch on. All of this is the predictable result of the city’s approach to digital development, which focuses on plenty of sizzle, not much steak. It’s time for the city to deeply explore what New York’s citizens actually need, and the ways in which those citizens are likely to behave.”
“The problem with the BigApps contest is that it leaves both user needs and likely user behavior out of the equation, instead beginning with an enormous data dump and asking developers to make something cool out of it”
“Some quick user experience work would have made this abundantly obvious and saved the city $50,000. “
“Instead of just throwing technology at New Yorkers purely for technology’s sake, why not start by spending $50,000 on talking to the people who live in the city and finding out what they really need? “
“And the widely publicized “Re-Invent NYC.gov Hackathon” held over the summer is only going to encourage more Roadify-like ideas, rather than address what people really need out of the city’s website. “
Clearly, the article is not a fan of NYC’s digital approch.
Other issues raised concern providing long url’s to service change pages on posters in a subway, where there is no internet or phone access, and the mobile app on when the next bus will arrive.
The author does praise other cities such as Boston and Louisville, Kentucky.
What do you think?
Thanks, Jim. Great comment, and glad to hear you first found the story on TheTransitWire. (You know I edit that, right?)
I thought Hana made a lot of good points about the disconnect between what users want/need and what developers create.
At the same time, I thought she was a little harsh about the MTA’s Bus Time app, in particular, which is a pretty creative solution for cash-strapped agencies that cannot (or choose not to) invest a lot of money into services that estimate bus arrival time to the second. It’s not quite as simple as multiplying distance times speed, unfortunately.
As a Boston resident, I was pleased to see that she cited Citizens Connect as a good example. Although for some reason every time I’ve tried to use it, I give up in frustration and end up sending an email to the city through its online interface with equally successful results. (Probably just my problem.) I also know that some agency people (at the kind of agencies that rely on developer competition to develop apps rather than pay someone to come up with a product) have privately questioned the city’s decision to spend money on something a third-party developer would do for free.
It’s a really interesting debate.
Wow – It’s a small world. FYI – I think The TransitWire is a great resource and follow it religously. I help track the benefits, costs, and lessons learned of Transit ITS systems for the ITS JPO Knowledge Resources, and it has given me many a good lead to track down :-).
I agree that Hana might have been a bit harsh on the design of the MTA Bus Time app, and if you follow the links someone explained more fully that other options exist. However, the main point remains the same that evidence is starting to come out that app contests and hackathons may be more sizzle than meat, if the agency and the app developer doesn’t commit to maintaining the information feeds and the app itself.
It also doesn’t cost a lot of money to build on others successes and replicate (or expand upon ) what has been proven to be a good user interface or tool. What is happening now in some of the contests is too much starting from scratch by folks that may be whizzes with the data, but may not have the domain knowledge to not repeat others mistakes.
Now that the pioneers have proven what can be done with open transit data and other information we should really start building an understanding of good practices, what works and doesn’t work, and what really should not be done.
Are you going to be at the transportation camp in DC prior to TRB? This may be worthy of discussion there.
JAB