Government open data presents a number of opportunities for citizens, designers and elected officials.
Using the TTC transit system here in Toronto, I would stand amongst other commuters on a cold winter day and watch as someone would step impatiently off the curb, press off their heel and try to get a glimpse of any streetcar on the horizon. After a few seconds, they’d step back with their head to the ground, and we would try to assess their gaze.
As a UX designer, it’s impossible to suppress the natural instinct to observe human behaviour and imagine how I might make peoples’ lives more enjoyable — to me, the question on everyone’s mind was the same, “Where the hell is my streetcar?”
Late last year, the TTC, in a bold and rather unexpected move, made an open data feed available that showed the exact GPS locations and expected arrival times for each streetcar. Just like that, an app that I’d been dreaming about since third-party apps for the iPhone were announced was now feasible.
I spent a week sketching out what the experience might look like, and then assembled a team to help me build it: T+L’s own Jason Sao Bento, and co-workers from a previous gig, Mohammad Kurabi and Jeremy Koch. Within 60 days, Rocket Radar for iPhone was for sale on the App Store.
It’s been six months since then, it’s received some great coverage from the media and has been downloaded thousands of times. I’ve also learned a great deal about not only building mobile apps, but building them on open data sources.
Solve one problem
Prior to Rocket Radar, transit apps offered every piece of information under the sun related to the TTC — schedules, routes information, maps, advisories, RSS feeds and more. There was no focus on what the user was trying to do; instead, it was a data repository.
By their very nature, open data feeds are a raw dump of all information available from the given source. While it can be tempting to consider how to fit all of the information into a user interface, always consider the primary purpose of the app. Just because the data is available, doesn’t mean you should use it.
This was reflected in the information design of Rocket Radar. Throughout design and development of Rocket Radar, I constantly questioned each idea with, “Does this help me find out how long I’ll have to wait for the next streetcar?” If the answer was no, the feature was cut.
For all mobile apps, it’s important to be judicious about context and sensitive to core functions. For open data apps, resist the urge to take a shotgun approach to design.
Clean it up
Open data doesn’t see the light of day easily. It took a handful of passionate people with a bold vision rallying the city and the TTC to shepherd Toronto’s open data catalogue into existence.
Large organizations, governments included, are almost always wired together like a bowl of spaghetti where isolated legacy systems were created for a very specific purpose, and are rarely designed to talk to one another.
As a result, what comes out the other side when a department is ordered to make their data public can be unwieldy at best. Live data feeds might have improper syntax, markup, and change management. Accept it. The quality of the data is a by-product of this environment and in most cases you won’t be able to do anything about it.
It’s the designer’s responsibility to reduce the cognitive overhead of the user, and in this case, it’s taking a mess of data in, and presenting it elegantly in a way that the user can intuitively understand. For Rocket Radar, that meant taking extremely verbose stop names such as “Queen Street West At John Street” at renaming it simply to “John”.
All stops within Rocket Radar are named in the same way that TTC drivers announce them and in some cases even use nicknames that passengers use like “Ronci” to represent Roncesvalles where screen real estate doesn’t allow for the full name. This gives the app a conversational tone that feels welcoming and familiar and helps to speed up the user’s ability to process the information.
Do it magically
Mobile apps require laser-like precision in their focus in order to properly respond to the user’s context. Prompting the user for information and asking them to configure options are just roadblocks between them and what they’re trying to achieve with the app. Mobile apps should ideally provide something of value to users as soon as they are launched with as little friction as possible.
With GPS, gyroscopes and other types of sensors now built in to smartphones, there’s so much that we can gather from users without having to ask them every time, and that’s how Rocket Radar has seen some pretty astounding reactions from users. As soon as it launches, the app finds you, the route that you’re on, the stop you’re closest to, even the direction you’re probably going, and then tells you when the next few streetcars will arrive.
CFRB’s John Downs, speaking about his first experience with the app when he saw a streetcar arrive right when the app said it would, exclaimed rather hyperbolically, “We let out a giant cheer like we’ve seen the first shuttle ever blast out in to orbit. It was one of the most amazing moments of my life.”
We put a lot of effort into making the app as frictionless as possible, making best guesses as to what the user might be trying to do. It was quite technically challenging to figure out how to select the stop on the other side of the street if the user changes directions (since the list of stops for each direction are maintained separately), but for the user, it just works.
That’s why I equate some of the best experiences on any platform to magic, even if Apple has reduced the word to a bit of a cliché; there might be quite a few levers being pulled behind the scenes technically, but to the user, when you deliver an experience that was never possible before in a matter of seconds without them having to do anything, it can really feel like magic.