This app has some interesting ideas, but fails at the core task of navigating to a destination when it tries to be too clever about the address.
Say I'm in SW Connecticut, trying to go to our datacenter in NYC, at 111 8th Ave.
For all variations on 111 8th Ave, New York, NY, 111 Eighth Ave, Manhattan, NY (and all combinations thereof), this app suggests bizarre alternatives in Brooklyn, San Francisco, or what look like misspellings from Foursquare like "8th Ave Parkimg Garage" (sic).
Unless one can enter an address and go to it, no other feature or UI element matters.
I agree this needs to be improved. The problem is with Apple's geocoder, which seems to be really dumb at finding addresses. We would like to use Google Geocoding Service instead, but they don't allow it if we don't display the results on a Google Map (and starting with iOS 6, the map tiles are now provided by Apple).
In New York, Apple and others often show streets off of Manhattan island unless you call the island locations Manhattan. That's because for the other addresses, they have to accept users looking for them using New York as the city too.
Navigon, Tom Tom, Garmin, Google Maps, and Apple all exhibit that issue. But doesn't seem to be the issue here. Issue here seems to be results from Foursquare instead of an address lookup, with no valid address ("what I typed") option to select to continue.
Thanks for the technical precisions re: address geocoding in NYC.
Right now, tapping the return key will try finding an exact match of what you entered on Foursquare. If it fails, it will fall back to the geocoder and then proceed immediately with the routing request. This will be improved in 1.2.1 as the return key will now be labeled "Search" instead of "Route" and will no longer trigger the direction request.
Indeed the foursquare suggestions make address lookup confusing, as the Foursquare suggestions sometimes make no sense with what the user entered. I thought of maybe leaving them out when the search text starts with a number, but then that would leave out venues that start with numbers as well.
Have you looked into Yahoo PlaceFinder? My understanding is that they don't have a similar restriction on use, although I don't know if they're better than Apple's geocoder.
I'm sure it is. In fact, I've wondered if Google might try something like that (e.g. if/when they release an iOS app, expose some custom URL schemes for third-party developers to use if they want).
That being said, there is another problem. I can't see Apple looking kindly on developers deliberately routing around a system API to use a competitor's. Perhaps, given the current PR issues, they'd be forgiving in the app approval process for the moment, but I certainly wouldn't count on such forbearance.
The app looks interesting with a unique UI. It is certainly hitting at the right time for iOS, and considering that the transit directions in the old Google-powered iOS Maps app were never very good, this has the ability to give users an even better experience.
The supported cities seem strange to me, however. In the US, the first two cities you would develop transit directions for would be New York City and Washington, DC, as they are No. 1 and No. 2 in train/subway use in the country and having by far the best transit. After that you would do the second tier of Chicago, Boston and San Francisco. Then you'd look into less transit-friendly cities.
Houston, which is pretty much a giant suburb, is a strange pick to go before more transit dense cities. I do see that the app makers want data in a public GTFS feed. But users won't know what that is. It's up to app and service makers to work with cities, not users. They just want something that works.
I say all of this, because the goal of any app launch should be to maximize user uptake and publicity. Skipping major transit cities like DC and Seattle for launch and instead including Houston, San Diego, etc. seems like a wasted opportunity. Shooting up the iOS most popular charts is the best path to success on iOS and city selection, and thus user availability, would be pretty critical here.
All excellent points. You're right we should have put more thoughts into our city roadmap. We basically looked up US city metro populations and went with that (how terrible, I know). With all the traffic and feedback we get now, it has become clearer which cities should have been prioritized (Miami and San Diego for instance were an absurd waste of time and resources). DC is definitely coming this week, followed shortly by Seattle and LA.
Not sure about Seattle, but I would bet that there would be more users of the app in SF and NY than DC which is probably why the devs chose to prioritize these cities.
The submission title, 'Best IOS 6 transit app is "The transit app" from creator of SVProgressHUD', is too sensational for a Hacker News title. Check out the guidelines: http://ycombinator.com/newsguidelines.html
I really like the screenshots but this app doesn't support Phoenix yet. I guess our local government doesn't provide the necessary public data feed?
As a general tip for app websites: please prominently show on your website the app logo I'm looking for in the app store when I search for "transit" - with no knowledge of what combination of words in your url make up your actual app name. I searched for "Transit" and had hunt through several transit-y apps before matching up your screenshots (I'm on iOS 5).
The "Available on the App Store" button is nice, but if I'm reading this on my laptop I'm not going to go to your website so I can click the button.
"Transit also integrates closely with the new Maps in iOS 6." - I would seriously reconsider telling people that and go with a Google Maps solution. I'm not trying to be rude, this is seriously one of the best and most useful applications ever, but the integration of iOS 6 maps is going to be your downfall. My initial testing of the app showed some serious flaws with Apple's geocoder not correctly picking up on variations of address and location names.
Agree that it should be using Google's geocoder. Disagree that it shouldn't be advertised as integrating closely with iOS 6 Maps--this app wants to position itself as a viable replacement for Maps.app's missing transit data.
Firstly congrats on putting the app out there. It's great to see you've actually paid attention to your web presence, which is neglected by so many app developers. With that said, there are a lot of PT routing apps out there and I think you'd be a prime candidate to utilize your web presence to truly demonstrate how the app works by using Kickfolio - http://kickfolio.com
That's a fascinating pricing model. It makes a great deal of sense, too, since presumably there's work to be done keeping all that data fresh and up to date. But I wonder how many other transit apps we're going to see with a subscription model, when users are so used to ridiculously cheap, one time purchases?
Indeed, we're getting ridiculous amounts of bad reviews re: our pricing model. People were used to getting transit direction for free in iOS 5, so there's a lot of angry people out there. Some people suggest we should get VC money and make the app free, but what we (@gcamp and I) really want is to make the best transit app out there and not have to care about an exit strategy or pleasing greedy angels.
In my personal opinion, if you're not thinking about an exit strategy, you should be.
In the bigger picture, Apple's top two smartphone competitors build transit directions into their mapping solutions. Apple can't afford to leave transit the exclusive domain of third-party developers indefinitely. To use Joel's phrase you're "picking up nickels in from of a steamroller". You should expect to get Sherlocked eventually.
Not everything has to be a startup with some grandiose exit strategy. Making a great product and a solid living off of it is perfectly viable, and quite preferable for many people.
But you're right about being aware of what apple may do in the future. I'm not convinced they'll add public transit (back) into their core mapping app though, as you imply. I think apple has made the decision to optimize for drivers, which tends to be the majority especially outside of huge cities.
We haven't. You're right that some help on the business side of things wouldn't hurt. With the iOS 6 launch though, Apple is pretty much taking care of the marketing end. Not sure what else could VCs bring us... (maybe that's just me being naive here)
I don't think the work to be done to keep the data fresh is that much, since they're basically scraping publicly available data. Plus, as nice as the interface is, Google has already done this with Now, and presumably it'll be coming to the iPhone soon.
Great looking app, but some of the directions just don't make sense or are flat out wrong. For example, in NYC it tells me to take the 4 train from 23rd St. - the 4 train actually doesn't stop at 23rd St.
Again, thumbs up but could use some improvements especially on the routing side.
Everything about this App looks great except for the pricing model. Why can't I just buy it? I have to pay for a subscription if I want to use all of the features?
Servers and app maintenance has recurring fees. Taking public transportation itself is based on a pay-per-use model. Why assume that paying 2.99$ for an app entitles you to free lifetime updates and support? A lot of apps do it, but more and more we hear that it is not a sustainable revenue model. It would be a whole lot different if Apple allowed paid upgrades, but they don't.
The only issue I have with this is that, AFAIK, the city is offering you this information for free. I can understand if you were paying a licensing fee to have access to the location data, you'd want to cover that fee. But wrapping up a stream of data someone else produces and curates doesn't justify a recurring fee to me.
You'd be surprised at how ugly the data we get provided is. The "curating" is actually much of the work we do. We probably spent as much time developing internal tools that clean and improve that data that on the app itself.
Server costs and continued development also are recurring expenses. Like I said, we might have gone down a different path if Apple allowed paid upgrades, but they don't.
I actually feel more confident paying for this app's service than I do using the competing City Maps by Lumatic, just because the economics are clear and I know the app won't suddenly change to a new revenue model after I've been relying on it for a year. $5 / year for always-up-to-date routes seems more than fair.
Not sure about Montreal as I'm not familiar with the names of the lesser agencies listed, but under "Toronto" they have listed Guelph Transit and Grand River Transit which are pretty far from Toronto, well outside of urban and metro area. Might be a similar deal for "Montreal."
Edit: for Montreal they mostly look like agencies for Montreal's suburbs (RTL, STL) and minor agencies for smaller towns outside Montreal urban area. They do all connect to Montreal itself either directly or via the commuter rail (AMT) and express bus service.
Yeah, like Jarek said. A bunch of very small agencies in cities close to Montreal, but not far/big enough to give them a "dedicated" city page/bundle...
I'm still curious about the inclusion of GRT under Toronto. I realize the region isn't that large but that's not an intuitive classification for locals - unless they go off exploring and check the agencies listed under Toronto, they might think it's not supported.
I agree. It's also a problem for Victoria and Kelowna in BC, which are both listed under Vancouver. We need to find a way to better communicate this information in the near future. Maybe something like a search or use the browser's geolocating services to tell you whether your area is supported or not.
Wow, I totally didn't realize Victoria and Kelowna were actually supported from reading the Vancouver list. (I live in Vancouver now.) I know the BC Transit thing is a pain in the ass from naming perspective, but yeah, get that reworked when you have the time.
As someone who has looked into building something like this, a subscription makes a lot of sense. These GTFS feeds are (generally) a huge mess. Cleaning them up into a dataformat you can use is tons of work. And with all the cities changing their routes (or cutting service) every six months, it means continued work and support.
I'd happily pay a subscription for something that works well. But yes, it will be interesting to see how naive consumers react to this.
weird city support, austin before seattle... I guess perhaps the data is of different ease to consume, but I'm pretty sure Seattle is a substantially more transit using city than Austin. (Having lived in Seattle).
Haha, yeah probably canadian myopia. I think it's because we had a couple requests for Austin a while ago so we decided to do it. But with all the requests we're getting now, it's much more clear which cities need to be added next (Seattle, Washington DC, L.A., Portland).
Austin is hipster central-its where all the young RoR and JS devs go to do startups during SXSW. Don't know what that has to do with transit, and I'm pretty sure Seattle has more transit than Austin. Oh well, that's the problem with crowdsourcing.
Say I'm in SW Connecticut, trying to go to our datacenter in NYC, at 111 8th Ave.
For all variations on 111 8th Ave, New York, NY, 111 Eighth Ave, Manhattan, NY (and all combinations thereof), this app suggests bizarre alternatives in Brooklyn, San Francisco, or what look like misspellings from Foursquare like "8th Ave Parkimg Garage" (sic).
Unless one can enter an address and go to it, no other feature or UI element matters.