Blog > Bettering the Better Way

A Little Background

We were really inspired by our good friend Robert Ouellette's post How Would You Improve The TTC Web Site? and thrilled at the ensuing support and coverage it collected during the first few weeks of the New Year. Some of Toronto's leading blogs leapt to support Robert's cause and quickly asked their readers to provide their ideas in the comments of the following posts:

The Press rallied shortly thereafter, providing some pretty good coverage about Adam Giambrone, the TTC's new Chair, accepting Robert's offer and offering to review the feedback. Amongst the radio coverage on AM640 and CBC, the nation's newspapers rang in:

  • National Post: Blogtown
  • Globe & Mail: The TTC Gets Some Online Help

Here's Where We Come In

Figuring that we know a thing or two about building websites, we thought that we could offer some useful feedback to compliment the already excellent thoughts collecting in the comments on the original blog posts. In addition to our Solutions and Portfolio of experience, we know lots of really smart people who could bring a lot of value to the table. And so we did exactly that and gathered a crack team in Radiant Core's boardroom to scratch our heads and stroke our chins and ruminate on how we could help to better the better way. And what a crew it was! In addition to your intrepid scribe and Michael Glenn, our Architecturally Awesome VP of Technology, we invited (in alphabetical order - ranking a team of this calibre would be impossible in anything but):

David Crow

David is a passionate advocate for Toronto's technology community. An open community has catalyzed around David in the form of BarCamp, DemoCamp, and the Innovation Commons, reinforcing his belief that openness can spark innovation - "the community is the framework". David is an experience designer, consultant and a software developer.

Joey DeVilla

Jose Martin "Joey" deVilla is, among other things: The Thrilla from Manila, based in Toronto, Canada, Technical Evangelist for the web services company Tucows, and a guy who often takes his accordion with him, playing AC/DC, Nine Inch Nails and other pop and rock stuff on it.

Madhava Enros

Madhava is a Toronto interface/interaction designer who spends, perhaps, too much time thinking about public transit. A dedicated TTC-rider, he has been following Toronto transit planning and policy matters for many years.

Mark Kuznicki

Mark is a strategy consultant, policy wonk and a TorCamper. Mark's recent policy work includes consulting in cultural policy and in the development of an economic strategy for the entertainment and creative industries cluster. Mark's professional background includes work as a tech startup entrepreneur and in business analysis and tech project management in the financial services industry.

Will Pate

Will is an all-around web geek: blogger, photographer, videogamer, online community and social media consultant. He's a peopleperson who seeks out technologies to enable self expression, connection, or the creating of meaning.

We really couldn't have asked for a more amazing brain trust. Will captured the moment as we settled in for some serious thinking:

And so we were off and running! Stand back folks, because we really rolled up our sleeves and did some serious analizing.

State of the Union

No one would argue that the TTC currently has a good website. If you've somehow been spared the pain of trying to find information on it, take a few minutes and do your own mini-review now:

Sure, it's ugly and all, but just how bad is it? Here's the quick breakdown using a Radiant Core technique called The Five Thumbs - a quick set of five that you can use to evaluate any software or website. The Five Thumbs are easy to remember if you know your vowels (just think AEIOU and you'll be most of the way there):

  1. Adaptive: a good tool adapts to the user rather than the user adapting to the tool. The TTC's site is very inflexible and forces visitors to do things very much in machine-speak like searching for routes by number rather than by name. The site also doesn't bend when it comes to the format of the information: as Henry Ford might have said, you can have it in any colour you'd like as long as it's a huge PDF or badly formatted HTML.
  2. Expandable: a good website is easily expanded on by encouraging an ecosystem of third parties to build on a solid foundation. There's no way to get access to the wealth of data behind the site including schedules, stop locations, routes, etc. To make matters worse, the HTML is non-standard and schedules aren't presented in tables but rather spaced out using tab characters in a block of <pre> code, making them hard to parse by screen scrapers and readers.
  3. Intuitive: the basic functions of a good tool are easy to figure out with minimal assistance. Given that the basic function of this site is to disseminate information, it's a tangled maze of bad Information Architecture which hides important details in deeply buried pages. Navigation is via HTML <select>s, form controls which are usually reserved for selecting options from a list and can cause problems for screen readers and other accessibility devices.
  4. Open: how well does it play with others? We usually measure websites on how well they both render across browsers and validate for standards compliance, as well as how deeply they incorporate accessibility features like tabindexes, accesskeys, alt attributes on images and titles on links, etc. The W3's validators can't get passed the lack of a doctype attribute, though the site does fair somewhat better using Watchfire WebXact, which returns few serious accessibility issues.
  5. Usable: how useable is it? This can be a fairly subjective measure, but empirical evidence from the comments left in the original blog posts suggests that users of the site have a very difficult time finding content.
We also tried to take Joe Clark's words to heart and pay special attention to accessibility concerns, even before we really started talking about features. Joe has forgotten more about building accessible websites and PDFs than our entire crew combined will ever know and his opinion counts for a substantial amount (although we might disagree on the 'free consulting' bit, we're glad that there's someone out there other than us waving the web standards flag).

The Better Way

It doesn't take a room full of web-savvy thinkers to come up with a great plan for the Commission's site as the way forward is obvious in many respects. We were pleased to see that the commenters on the original blog posts have thought of many of the same avenues (and even a few that we didn't touch on), so I highly recommend a read through them as well. Our thoughts, in no specific order:

Site Features and Functionality

  • Trip planner
    • This one is a no-brainer: give us a tool to figure out the easiest way to get there and we'll ride more often. It's not a very original idea either; a quick perusal of Transit Authority sites will provide a dizzying tour of Trip Planners. Some pretty decent examples:
    • Google has built a pretty fantastic Trip Planner for Transit on top of their already swell Google Maps: Google Transit. It's meant to be used by Transit Authorities all over the world to provide planning tools for their riders, and it currently provides coverage for nine US cities including Portland (the first city covered), and Seattle. The TTC and Google have been in talks for some time (see The TTC and Google on Spacing Wire from March 2006), though nothing has come of it yet. According to the Toronto Star article mentioned in that post, the Commission costed out its own route planner at $2 million, which sounds like a pretty expensive wheel re-invention to us! We'd like to see the TTC jump on the GT Bandwagon and publish the data in the Google Transit Feed format (see the API points below).
    • Any Planner they do build/use should make an effort to include other Transit Authorities in the area (e.g.: Go, Markham, etc.) in order to provide a seamless experience for the Great Transit Riders of the GTA.
    • Lots of people come to our fair city to visit and make their way around by transit, so it would be a great idea to include some bookmarked destinations and starting points to help them navigate more easily (e.g.: tourist spots, conference halls, shopping, hotels, etc.).
    • Although not required for the first version, mobile access would mean we could do trip planning on the go. Sure, the data rates from Rogers and Bell suck more than your average vampire, but it would give you one more reason to spring for that new iPhone you're all craving.
  • Schedules and Route Maps
    • Easily printed route maps as PDFs (no more monolithic files with every route!). People like to carry schedules with them, so make handy-sized ones which we can print out and staple together to keep in our pockets. Better yet, offer schedules for download, pre-formatted for popular hand-held devices. It would also be great if you could add different schedules to a cart and have them packaged into a customized PDF that you could keep on your laptop or print out whenever it gets too dog-eared and weather worn.
    • Trip planners are great for "Get me from A to B" type foresight, but sometimes you just want to know what time the bus goes there and comes back here. The current site makes it fairly hard to find the first part and an exercise in repetition to get the second, so include a link to the opposite direction of travel on all schedules (e.g.: link to eastbound schedule on westbound page).
    • Consider changing the format of the schedules to something a bit more graphical and easy to follow. Nick Provart suggests a pretty good one (see here), an idea which we quite liked and seemed like an emergent de facto standard, but then again, just say Tufte and we're all ears (see pg. 46-47 of Envisioning Information for more information).
    • Each station in the system should have its own page, which can provide information (e.g.: washrooms, vendors/stores in the station, last/first train, bus connections, etc.) and could even be expanded to act as a hub for the community around the station (e.g.: upcoming neighbourhood events via RSS, etc.).
    • The TTC Timeline system was ahead of its time - a phone number for every stop with recorded schedule information - so far ahead, in fact, that it's one of the only real Y2K bugs that we know about. The system was shut down in late 1999 as it become evident that "...the TimeLine system is not Year 2000 compliant and because of the age of the system hardware and other factors, it cannot be upgraded in a cost-effective and timely fashion to allow for its continued use past December 31, 1999." (see TTC Report F591). We'd like to see a return of the Timeline, but this time as an SMS-based service which works by sending your stop ID to a TTC shortcode and getting a schedule update back. The same stop IDs can be used throughout the Schedules and Route maps to remain consistent across the whole system and to make it easy to get schedule info whenever you see an ID.
    • The City of Chicago is running an experimental, GPS-based bus tracker on their #20 line, which gives a hint of what a system like that could deliver. In addition to providing automated recordings of stop announcements on vehicles, it offers the tantalizing possibility of in-stop signage with updated arrival times (à la York Viva system), accurate web-based schedules and maps, and the promise of not having to stand in freezing rain with no streetcar in sight.
  • Schedule Updates
    • Include a blog (with RSS feed!) of closures, schedule changes, etc. Use categories to indicate which type of service is being disrupted (e.g.: Subway, Bus, Streetcar) and/or areas of the city affected.
    • Although frequent transit users might get a chance to travel the length and breadth of the system, most of us just wear a groove into our favourite routes. General information about changes is important, but also build the system to allow users to register those routes and subscribe to updates and changes by email, SMS, and RSS.
  • Ecommerce
    • It's 2007 and high time that the TTC boarded the eCommerce train! The Metropass Discount Plan is a great idea, but it would be substantially better if we could complete an online form to apply and provide a credit card number to pay for it. Faxing is so 1843 (no, really). There have been rumblings for a while now that the TTC will consolidate with other GTA Transit Authorities on a Smart Card for fares which would negate this, but that might still be a ways off (personally, we're hoping for something like the Octopus Card).
  • TTC API (Application Programming Interface)
    • Open the walled garden and encourage the development of an ecosystem of user-created applications built on the TTC's data (routes, schedules, etc.). Our city is full of tech people who love whipping up new mashups and projects if you just give them the tools, so open the treasure chest and share the wealth. See this great Google Maps/TTC mashup as an example, built by Ian Stevens.
    • Use the Google Transit Feed format, which will likely become a de facto standard for transit data, but make sure its open and available to everyone. Build a system which requires an API key if control over bandwidth costs is a concern, or use a service like Amazon's S3 to host the feed.
  • Build a Web Standards compliant website with no (or almost no Flash). See our blog post, All Flash = Bad, for an explanation on why building all Flash based websites is just asking for a flashtastrophe.
  • Navigation
    • Navigation needs to move away from <select>s and into a more logical structure with more accessible controls.
    • URLs for pages should be logical in order to increase ease of navigation (e.g.: http://www.ttc.ca/metropass instead of http://www.toronto.ca/ttc/metropass_steps.htm). Human readable URLs are a great boon for people emailing links to each other, or for people looking through web traffic reports ("Great! 1,235 people visited the page showContent.php?id=27! Now which page is that?" vs. "Great! 1,235 people visited the page content/ttcwebsiteredesign!"). It's also a really good idea to hide the implementation of the site because it means you can more easily change your backend technology down the road without orphaning millions of bookmarks (e.g.: don't end your URLs in .html or .php, but use a feature like mod_rewrite to rewrite URLs from human readable to machine format, so http://www.ttc.ca/metropass/signup gets rewritten behind the scenes to http://www.ttc.ca/metropass/signup.jsp)

Process

  • Despite our knowledge of websites and best practices, we weren't able to answer a central question which needs to be covered: who uses the site and what do they use it for? You can't do a good job of building a huge site which is optimized for everyone, but you can do a fantastic job of building highly optimized micro-sites which share designs and content. The City of Toronto does a pretty good job of splitting their content into four basic groups depending on what you want to do (Living in Toronto, Doing Business, Visiting Toronto, Accessing City Hall), and the colour coding makes it easy to keep track of where you are. Once the TTC has answered the central question, it's easier to break the site down into similar groupings and optimize the Information Architecture around goals (e.g.: Frequent Riders, Visiting Toronto, Selling to the TTC, etc.).
  • We also ran into an obstacle establishing what the central goal for the website was, other than to provide information. Madhava has an excellent knowledge of the politics and history of the Commission and provided great insight into the fine balance between funding and ridership, which led us to discern that increasing ridership on suburban routes might be an important goal that the website could help to serve (particularly through schedule update subscriptions, SMS Stop Service, GPS tracking, etc.). That's a good start, but we would need more information to really finish a goals analysis.
  • Building the site is only part of the battle; maintaining a site of this size and complexity in a healthy manner requires a team of dedicated personnel. The TTC needs to make sure that they build that cost into their budgets, whether the team be internal or outsourced (or some combination). Can we convince the TTC to try a radically different, non-centralized approach to managing the site? Perhaps we can marry the two halves of the brain and have a Community Ombudsperson oversee the marriage between the central authority of the Commission and a community of volunteer web managers and moderators. This doesn't need to go as far as a wiki (although it would be a very good approach!), but there are many happy mediums between a monologue and a full conversation.
  • The Community is here to help! Despite what we perceived as an almost tangible antagonism between the Commission and its dedicated Ridership (see Withdraw anagram map lawsuit threat for an example), we still love the Red Rocket and we want to be part of the solution. Use us for our advice and skills and make sure that the process of building the new site is open and transparent. David likes to say that the "community is the framework", and that applies here just as much as it does there. We're riding a wave of new interest in our city and in the grassroots capabilities celebrated by initiatives like the Centre for Social Innovation, so sow some seeds and (to quote Guy Kawasaki intentionally misquoting Chairman Mao), let a thousand flowers bloom.

What's Next?

If you're still reading, we admire your persistence :) A few final thoughts on where we'd like to see this go from here:

  • The TTC should re-open the RFP for the Website Redesign. The original RFP closed on Thursday, November 23, 2006 and received responses from a number of traditional web shops (you can find the RFP info by browsing the somewhat confusing and highly frame-based TTC Materials & Procurements site, or by going straight to the otherwise-framed P01DR06363). The Planned Award date is February 1st, 2007 (which recently changed from January 29th), but we think a strong case can be made for the requirements having changed substantial as a result of the change in Commission Chair and the process kicked off by Robert's post - strong enough that the original RFP should be replaced.
  • The TTC should completely embrace the community. Soliciting feedback via blogs is a great start, but we'd like to see Adam Giambrone extend that initiative by keeping the rest of this process open and transparent (keep an eye on this space for a forthcoming announcement on this very topic). Collecting feedback in such a public fashion is an amazing step forward and we salute it wholeheartedly! Let's keep moving in the same direction.
  • The TTC should set a goal of building the best Transit Authority website in the world. Our former Mayor, Mel Lastman, was perhaps overly found of calling Toronto a world-class city, but he was often right. Even the best Transit websites out there don't set the bar very high and we feel that this is an opportunity to demonstrate our technology and transit leadership by establishing a new watermark.

©2010, Radiant Core Inc. All rights reserved.