Last week, Google announced the availability of real-time transit information in Google Maps. In the US, they’ve initially made information available from MBTA, San Diego MTS, TriMet, and BART. In my (admittedly brief) testing, the service seemed to work, but the results available from Google Maps did not always match those available directly from the transit agency (this was the case with BART, for example).
You might think that this would be fantastic to have available on-the-go, but as with everything, there’s a catch. The announcement indicates that real-time transit information is available with the “latest version of Google Maps for mobile (requires Android 1.6+), as well as Google Maps on all supported desktop and mobile browsers”. What about iOS, the BlackBerry OS, WebOS, Symbian, MeeGo, or Windows Phone 7? What about older devices? What about feature phones that only have a web browser? What about feature phones that can run J2ME MIDlets?
From the announcement, you might think that “all supported…mobile browsers” would include these platforms. Unfortunately, that’s not the case. The mobile version of maps.google.com works, after a fashion, on iOS. But I found it didn’t load in either the native Web browser (which is WebKit-based) or Opera Mobile on Symbian^3. Reports on the Web indicate that it doesn’t actually work in the default browsers for BlackBerry or WebOS, either.
It’s clear that as far as the mobile experience is concerned, Google’s focus is on Android, and that’s a problem. Transit agencies must not be lulled into thinking that making their data available to Google fulfills their obligation with respect to open data, and they must also recognize that Google does not serve all users equally.
There’s nothing inherent in the task of trip planning that requires anything more than plain text and some simple HTML forms which will work in almost every mobile browser out there (with the possible exception of those very old phones that only have WAP browsers). However, Google has decided to shut out older phones. There are actually native versions of Google Maps for BlackBerry and for S60, and at one time there were Windows Mobile and J2ME versions as well. But in the wake of Android’s rise, those native apps are no longer updated. All that’s left is a mobile Web site, in which the newest features (including real-time transit information) are only available on iOS and Android. From the perspective of making transit information available to as many riders as possible, Google’s actions make little sense. From the perspective of pushing mobile users towards the Google-controlled Android platform, though, Google’s actions make perfect sense.
Transit agencies who partner with Google to get their data out there, and then assume they’re ‘done’ will have shut out all of their riders with older mobile phones, and even brand-new mobile phones, straight off the shelf, which happen to run the ‘wrong’ mobile platform. This is especially important considering that real-time information, including vehicle locations and alerts, is most important to riders when they’re on-the-go, actually standing at the bus stop or on the platform waiting for a train.
In addition, thus far, Google has shut out developers. Technical information on Google Maps’ “live transit updates” program only indicates that documentation on Google’s new real-time feed standard is “to be released soon”. There’s no mention of how yet another standard for real-time transit information helps the transit technology community, when there’s already a proliferation of standards and protocols for real-time transit information, including open standards like SIRI, and proprietary standards like those used by Clever Devices and NextBus, plus home-grown formats developed by a number of transit agencies. Nor is there any information on how developers can participate, either by consuming these data feeds, or developing software to generate real-time data in Google’s format from existing AVL systems.