Those who know me know that I have an Android phone and prefer the platform over the iPhone, but there’s a bit more too it than that. I’ve gone all in to the Google ecosystem. Gmail (Inbox, actually) and Google Calendar windows are almost always open on my computer, and I’ve even set Google Keep to remind me when the last buses leave Hamilton on days when I have evening classes at Mohawk College (I don’t really use Google Plus, though). While that means that I give Google a lot more personal information than most people might be comfortable giving, I do get some great features in return. This post is about one of those features, and how it can be leveraged to improve the way people get transit information.
Google Now is a Google product that tries to predict what information you’ll need as you go about your day, and one of the most common use cases is to have traffic predictions or transit schedules for your regular commute ready when you wake up in the morning. In addition, it can give you or transit directions or traffic information based on the appointments you have in your Google Calendar. It can handle different modes for regular commute and “getting around”, so it can show you traffic directions to work and then transit schedules for other events. But, what it cannot seem to do is accommodate the way that many people interact with the transit system – using park-and-rides.
I grew up in a very transit-unfriendly area (which is probably why I became interested in transit), so “commute” means driving to a train station or to a carpool lot where the bus stops (Bramalea GO and Erin Mills Transitway are my two most frequently used locations right now). Park-and-rides are probably not the best and highest use of land – especially in urban centres – but they are a necessary evil unless we’re willing to run routes through neighbourhoods at usable frequencies. So, for a lot of people, a feature that can say “leave in 10 minutes to drive to the station to catch the train that gets you to work on time” would be very useful. So why doesn’t Google do that? Perhaps the answer is in how Google gets the schedule data.
The industry standard for publishing transit data is the General Transit Feed Specification. Transit agencies publish their schedule data to this standard (either static schedules or realtime information) and independent app developers create products to disseminate the information to users (Transitapp is my personal favourite as it shows departure times for all nearby stops and routes, but there are many others including Google Maps). There are often complaints that Google doesn’t show schedules for ______, but this is typically because that agency hasn’t provided the data.
There is a fear amongst some agencies that open data exposes the agency to criticism, misinterpretation, and loss of control, but to that I say a stern “stop it.” There are some good agency-made apps, but many proprietary customer information systems are inferior to those that software companies – the experts in the field – create. This is even more critical in areas like Toronto where multiple transit agencies operate. A TTC app won’t show necessarily show GO Transit or York Region Transit, thereby denying relevant information to the customer. Riders should not be forced to use multiple apps to get their information when one app that can deliver the same information for multiple providers is possible, so thinks like Triplinx are a step forward. But, I strongly believe that transit agencies should meet their customers where they are rather than trying to bring them inwards – often against the grain. This isn’t a radical concept, as Microsoft has embraced it by making Office available on Android and iOS as well as Windows and OS X. If you lived though the Internet Explorer controversy then you know that this is a big deal.
In short, I call on all transit agencies to publish their schedule data to the GTFS standard and make it available to app developers. This in and of itself doesn’t explain why Google can’t handle park-and-rides, but its a necessary step to getting that functionality. The next step is for transit agencies to use all of the features of the GTFS to their fullest – including some of the more obscure features that can really improve things for riders.
One of the lesser known abilities of the specification is that it can differentiate between “stops” and “stations”. Stops are the individual locations where transit vehicles stop, while stations are locations which contain one or more stops either inside or outside. While this can seem like an academic difference, using this little-used feature can result in a cleaner interface and provide more relevant information to riders. At Hamilton GO Centre, HSR bus stops are marked as “Hamilton GO Centre Platform 17” and “Hamilton GO Centre Platform 18”. As far as the software is concerned, these stops are two independent locations. Coding them as two stops within a station establishes a connection between the two places, and means I can see all of the routes that serve the GO station without having to click on more than one placemark. Plus, it means that we can better isolate locations that are likely to have commuter parking – and knowing where there is parking is the final piece of the puzzle.
It’s relatively easy for Google to say “drive to this stop”, and you’ll sometimes get “drive or take a taxi” instructions when there is no reasonable transit option available (I sometimes get it with direction home from the GO station late at night after Brampton Transit stops running). But, if there is no parking for commuters then there will be a backlash when users’ cars are towed by shopkeepers. So, I propose modifying the GTFS to add a field to indicate if commuter parking is available in proximity to a station. “Within”, “nearby”, and “third-party” could be options to identify where the parking is, who is providing it, and where to go to get information about parking rules and costs. Once that information is coded into the feed, Google Now can work its magic and determine the best combination of driving and transit to reach the destination on time.
An interim solution could be to let users declare their preferred parking location, but coding the information into the feed makes it platform agnostic and gives riders more information about the transit system. It could show non-riders that driving to the station can be competitive with driving the whole way, and it can show people who do drive to the station that there might better options available.
Over the past few years I’ve been exposed to the inner workings of technology-focused companies like Remix (who donated their software for me to do my thesis) and Zipcar (who flew me to Boston last October for their member roundtable and from whom I won a $150 VIA Rail Canada gift card from a few years ago) and I’ve gained an appreciation for how nimble and innovative they have to be to go from fledgeling startup to success. A by-product of that agility is that they can probably develop better customer information systems than governments and transit agencies can when working with the contractors they traditionally work with. So, why not let them? AODA-compliant tools will still be necessary even when the schedule data is shared with third parties (as I don’t think that there is an AODA or ADA friendly transit app on the market), but disseminating the data broadly is not incompatible with these goals. In fact, letting third parties work their magic may result in companies innovating in that space. Being the go-to solution for transit information for people with disabilities is a great marketing angle.
At the end of the day, we need to keep in mind that people cannot ride the bus if they have no idea when it comes and where it goes. Making that information available as widely as possible is a low-cost, no brainer solution to go alongside faster and more frequent service.