In case you missed this over the weekend, here’s a repost from Saturday. My brother Daniel X. O’Neil was a beta tester of Train Tracker. In this guest post he recounts his experiences with testing.
Over the last few weeks, I was a part of the beta test program for the Train Tracker system launched by the CTA today. I tested this Web-based application on the Red, Brown, and Blue lines in about six different trips (riding multiple trains) using an iPhone, an iPad, and an iMac. My main mobile experience was using my BlackBerry Curve that is about 6 months old.
In my experience, the system works great and it is a very positive addition to the overall CTA communications regime. Here’s why:
It is a native Web application that runs in a browser. That means it’s not an “app” — there’s nothing to download, no device-specific versions to cover– just go to the page on the Web and it works. The menus make sense, the flow is simple, and the interface is what you’d expect it to be– route-colored bars white familiar typography. Here’s a look at Train Tracker start page on the iPhone:
I also like the language they use– not transit jargon, but makes sense for regular riders. Here’s a nice example when choosing a station for a particular line on the standard Web interface:
“Pick a stop, get arrivals.” In this small screenshot, there are many terms of art (route, stop, arrivals, line, and, of course the color-coded lines themselves), and they are all used in logical ways. It’s well-organized and standard enough to make sense to people with no prior knowledge of the CTA while making easy for people to find “their” line. One nice touch is how the background fill of the Stops-list pulldown menu turns to the color of the chosen line.
There are other nice design touches. The standard Web view uses the word “Approaching” when the train is just about to arrive, and on the mobile version it is the truncated to the economically-lettered “Due”.
Speaking of the word “due”, I found the core service– telling you
when the train will come– to be higly accurate. In my experience, the
predictions were never off by more than a minute. Here’s a look at a
“Due train” indicator on BlackBerry at the Belmont stop:
In their announcement, the CTA gave the bare bones on how it works:
Estimated arrival times will be generated through a combination of
scheduling information and data collected by the CTA’s QuicTrak program,
which monitors signaling systems and indicates when a portion of track
is occupied by a train. An average transit time is determined by
measuring how long it takes a train to travel a portion of track. By
averaging the travel times of the last five trains to move across a
portion of track, the CTA can calculate the estimated arrival times for
trains at each station.
That means that if the trains are on the track, they have a pretty
good idea when it will arrive at a given station. It also means that if
your train (we always like to be possessive that way, don’t we?) hasn’t
started on the tracks yet, they are relying solely on estimates w/o any
live info. This is especially important if you’re near the beginning of
the line– I’d be interested in hearing how this works for people.
Based on my take on the data that feeds the Train Tracker, it seems
like will allow enterprising developers to download the data on the fly.
Here’s what they have to say in the help & notes
section of Train Tracker:
If you’re a developer, you may be wondering about APIs for CTA Train
Tracker data. Because this is an early beta and we’re still working on
certain aspects of the underlying data, we’re not ready to give you an
API just yet. The good news, however, is that we are working on it! We
do hope you can bear with us for just a bit longer so we can give you a
solid, reliable and stable API on which to build your apps.
And a cautionary tale to scrape-lovers:
Note that because the Web site (and the code behind it) is likely to
change regularly, attempting to “scrape” information off the Web pages
is likely to cause instability in your apps, and our site may reject
access to anyone making an excessive number of requests to ensure
overall availability. We strongly encourage you to wait for an official
API. Thank you, in advance, for your patience.
Based on what I know about the Web team at the CTA, and their commitment
to developers, they will come through on this front. Having said
that, I would strongly encourage developers to scrape the current output
and figure out what’s going on behind the scenes. Harper Reed did that to
pretty good effect with the unofficial Bus Tracker API.
HOW IT WORKS ON MOBILE
So here’s the basic steps in finding out when your train is coming:
Choose a route:
Choose a stop:
They also have some thoughtful options (on both the standard and
mobile views). You can sort the results by Route, Time to arrival, or
Platform side, and you can choose how many results to view. The default
is to sort by route and display five results per set of arrivals (FACT
Nice stress test!
There are some quibbles to be had. Alerts are not handled as
gracefully as they could be, although I’m told that this is not present
on the live site. After clicking on an alert, you have to scroll down
through the mobile site navigation in order to read the content:
Another important note, while you’re out and about, is that you have
to refresh the screen manually in order to see new arrival times. If
you’re viewing Train Tracker in the standard Web view refreshes
automatically. So you can keep a browser window open while you’re
getting ready to leave work, and the page will keep you updated
This was just one person testing the beta version of the Train
Tracker. The CTA had others testing it, and I’m sure they got lots of
real-world feedback on how to improve it. The best part begins now–
when the great mass of regular riders get a crack at it. Based on what
I’ve seen over the years here on the CTA Tattler, you won’t be shy in letting them know what you think!
Tattler on Facebook.