Developing TramTracker for iPhone – an interview with Robert Amos

Audio (mp3: 9.34MB, 10:11)

Published: July 2009

Commuters in Melbourne can get real-time tram information direct to their iPhone. Robert Amos tells Gerry Gaffney about the development process and history.

Gerry Gaffney:

This is Gerry Gaffney with the User Experience Podcast. Long-time listeners may have gathered that I am a little bit obsessed with transport and public transport in particular. I remember years ago when GPRS first came out on mobile phones, I was standing at a bus stop and I decided “here’s the time when obviously the data that I need will be provided to me on my device”. I attempted to find information about the next bus and was told that I needed to upgrade to a new browser. That seemed to me to be typical of what GPRS did for us.

Recently however I came across an iPhone application that finally hits the spot, that I find I’m using almost every day, and that provides real-time data on tram movements in Melbourne.

The application is called TramTracker, the person responsible for the user interface aspects and in fact most of the technical design is a chap called Robert Amos.

Welcome to the User Experience podcast.

Robert Amos:

Thank you.

Gerry:

Let me start by asking whether you have a specific interest in public transport and, if so, why.

Robert:

Yes, I do. Public transport has always interested me, purely because of the complexity, trying to understand it all and how it gets scheduled. That actually led me to develop iTransit, first of all as a way to learn more about Melbourne after moving here, and then my friends said I should release it, so I did.

Gerry:

And at that stage, had you developed other stuff for the iPhone, or was that your first?

Robert:

That was my first iPhone application.

Gerry:

So it was also a learning process. So that’s the background to how TramTracker came about or how iTransit came about?

Robert:

That’s how iTransit came about. Once I was hired into Yarra Trams it was specifically to develop a TramTracker web application. And our experiences from there, we actually evolved from a text-based list of departures and arrivals, and we went on to do the gadgets and widgets. From there, reusing our existing physical PID or passenger information display that we have at every stop, we ported that to a soft interface for the gadgets and widgets.

Gerry:

When you say gadgets and widgets, you’re talking about reusable components…

Robert:

Yes, the small applications that live within your desktop, especially within Vista and Mac OS.

Gerry:

And I guess we should mention since most of our listeners are not local that there’s an information panel on each tram stop with a number on it. And for the last few years users have been able to send an SMS and find out when the next tram is coming.

Robert:

Yes, we send back real-time information via SMS.

Gerry:

And that’s become quite popular. What sort of numbers have you had on that?

Robert:

As of six months ago we passed a million requests – that’s SMS, IVR and on our website. Since then we’re very rapidly approaching the two million mark.

Gerry:

One of the things that’s very apparent is that the TramTracker application is very consistent with the offline materials. The colour scheme is very similar, there are smart displays at some of the key tram stops around the city and when you fire up the iPhone application it looks very much like you’re standing at one of those tram stops. How did you achieve… or, did you deliberately achieve that level of consistency?

Robert:

We actually evolved into that stage. We started with a static list of arrivals coming, similar to what our SMS looked like. As we moved on to the gadgets and widgets, we actually had another project that was in progress before I came, which was to use Silverlight or a Flash-based interface to the same thing. That would show the PID that looked like the ones that are physically at the stops. The idea was to give them to cafés and shops and things like that so you could install it with your tram stop outside and go from there.

Gerry:

So this would be a stand-alone device that a business owner could put on their premises…

Robert:

Basically all you needed was a PC and an internet connection.

Gerry:

Did anyone take that up?

Robert:

We haven’t launched that yet.

Gerry:

Is it still planned for launch?

Robert:

I don’t know actually. [Laughs.]

Gerry:

We should also mention that Yarra Trams has just lost the contract for maintaining the tram system for the next several years, although it may be the same people running it, but different ownership because of contractual obligations with the Victorian government… stuff that I suppose we don’t need to go into now.

But that sounds like an ideal application, where you can sit in your café and you can actually know whether you’ve got time for a cappuccino or not. Particularly in a city like Melbourne.

Robert:

Exactly. So we actually took that user interface when we did the gadgets and widgets. And because the widget code for Mac OS X is very, very similar to the iPhone’s web browser, I actually ported it across to the iPhone. And we found over the next month or so of testing that we would purely use just the PID interface, we wouldn’t use the lists anymore. We would save the PID to the home screen and just use that.

Gerry:

Right, and PID again is passenger information display. When did TramTracker come out on the iPhone?

Robert:

About two weeks ago, I think.

Gerry:

Oh, is that all? So it’s pretty new. What’s the reaction been?

Robert:

Very positive for the most part. Very very positive.

Gerry:

Are you pleased with where you’ve gotten to with it?

Robert:

Yes. We haven’t implemented everything that we wanted to do yet, so there are still follow-up versions to come. But so far we’re very pleased with what we’ve actually achieved with it.

Gerry:

What sort of things are you looking at down the track?

Robert:

… We have a 1.1 release that we’re scheduling to submit to Apple sometime this week. That will include additional markers like turning indicators within the onboard screen. For people who get on the tram and don’t actually look at the number correctly, or who aren’t familiar with the network, and the tram turns off before it gets to where they want to go…

The big example is St Kilda Rd, especially people who want to go all the way down St Kilda Rd, and they’ll get on a Number 1 tram thinking it’s going in that direction, it must be correct. And then it turns off too soon. It turns right and then they scramble to get back out.

So we’ll have that built in. That will include detailed information on where it turns.

Gerry:

So that means that when I’m on a tram I can type in the physical number of that car and it will tell me what’s happening.

Robert:

Right now we do… we can tell you where it is and its approximate arrival time anywhere on the network, anywhere on its route. So this is in addition to that.

Further down the track we want to start moving towards more “push” services. The new iPhone release, 3.0, has push built in. So we’re looking at things like setting arrival alarms. So if you enter your tram number into the phone and select your destination stop you can then close your iPhone, do whatever you like, and we will alert you two minutes before it’s due to arrive at that stop.

The other one would be… Say you’re leaving for work in the morning, you could bring up the iPhone and say “tell me when the next tram is two minutes away”. Or three minutes away or however long you know it takes you to get to your tram stop.

Gerry:

I guess one thing I should ask you about as well is the… you were telling me earlier on before we started recording about the technology behind all this. I thought it was all GPS-based but in fact it’s not.

Robert:

No. It’s all based on radio waves and radio beacons. We have a low-bandwidth link to all of our trams, and this system has been around for nearly 30 years now, I think. So we know constantly where our trams are. That position is updated very six seconds, which we then in turn provide the information back to the on-board screen. Within the six second period, if it’s available we’ll make use of the GPS to refine that position down to the nearest… I think 15 metres is the best we can get.

Gerry:

And of course the problem with GPS in the central business district is that there are too many buildings.

Robert:

Yes, the signal gets very skewed.

Gerry:

Whereas on the iPhone, generally speaking, people who are in the suburbs will be using the GPS within the iPhone to know where they are.

Robert:

Yeah, we find it’s a lot more reliable… So much so that when we’re at the stop we will actually say you’re at the stop.

Gerry:

And incidentally anyone who is in Melbourne or is visiting Melbourne and who uses an iPhone should definitely go and get this free application because it’s just the single most useful piece of public transport information that I’ve come across… other than having everything run on time. [Laughter.]

Tell me, though, Rob, do you have a focus on user experience. Because… one of the things that did occur to me is the degree of consistency that you’ve maintained and the ease of use of the product overall. Do you have a background or an interest in user experience?

Robert:

Definitely a background in user experience, especially as a user. I know what I like, and I know what’s easy to use and I always try to maintain some level of… I guess you could say I’m almost a perfectionist, but not quite. I do know when to draw a line in the sand.

Gerry:

Do you do usability testing of any sort?

Robert:

At this stage, no. We’re still a very, very small outfit. We did run it past some focus groups before we went live with it, but that was pretty much very late in the game.

Gerry:

Do you prototype or do you just go straight to… Because it just occurs to me that it’s got the feel of the sort of thing that’s got a lot of user interface design work gone into it. And it’s unusual to see something emerge without a significant amount of user involvement in the process.

Robert:

No… When we started on the native application, we started with the PID as the focus, that was the core of it. And we just prototyped everything from there. We started with basic lists, the list that Apple provides with their guidelines. And we slowly evolved it up from there with what we thought would be good.

Gerry:

So you have tried to abide with the Apple guidelines.

Robert:

As much as possible, yeah.

Gerry:

What’s the setup in the development team, and how does that operate?

Robert:

We have two parts to our development team. The core of our development team is our back end guys who work on the web service that we provide, as well as the interfaces to SMS and to the phone and stuff like that. Then there’s the front end which is mainly myself at the moment. And I do the iPhone applications and widgets and the widgets and gadgets.

Gerry:

And do you use Agile or any particular development methodology?

Robert:

For the iPhones we use Xcode and the built-in tools.

As far as the development platform, or methodologies, it’s mainly just prototyping, rapid prototyping.

Gerry:

Are you working to particular deadlines, do you have scheduled release dates, or do you just work and finish it and get it out there when it’s done?

Robert:

Initially it was… we had no set release for it. We weren’t sure when we were going to go live with it. That depended a lot on communications with the government and stuff like that. I worked to my own schedule to start with. But I was very enthusiastic in the early days, so we got out pretty fast.

Gerry:

Well, it’s a fantastic little application. As I say I do suggest to any listeners who are based in Melbourne or are coming to Melbourne and who have an iPhone to download TramTracker and have a play with it because it’s extremely useful.

Are you open to job offers at the minute Robert?

Robert:

[Laughter.] Not right now, I don’t think so.

Gerry:

Not right now. OK, so watch this space. Robert Amos, thank you very much for talking to me today on the User Experience podcast.

Robert:

Thanks.

Published: July 2009

We make verbatim transcripts of the User Experience podcast. We then edit the transcripts to remove speech-specific elements that interfere with meaning in print (primarily space-fillers such as “you know…”, “um…”).