The TTC chairman confirmed my forecast of 8 months for a new website, giving an estimate of 6 to 8 months. That figure does not include the transit planner, which will be phased in for 2008. The planner has been budgeted for, although Giambrone said that the TTC has not yet decided whether it will be created in-house or will be out-sourced. He did state, however, that they were not looking to Google Transit due to fears that their service might require integration costs and ongoing fees in the near future. I hate to say this, but it seems like a wise move to forgo Google Transit for now. There have been complaints that Google Transit for Portland, whose system was included in Google Transit’s launch, provides sub-optimal trips which cost riders more than the ones provided by TriMet’s own planner.

I recently discovered that the TTC considered a trip planner in 2004 but shelved it due to integration issues and budgetary constraints. When I asked what was different now, Adam Giambrone cited increased outside pressure and an acknowledgement by TTC management that a planner was necessary. Before it can be created, however, its IT department must amalgamate transit data into one database, confirming my suspicion that it currently exists across a number of systems.

Speaking of Portland’s TriMet system, Bibiana McHugh, TriMet’s GIS Manager, is a huge fan of using open source for public transit. McHugh has proposed that TriMet and other public agencies in the Portland metropolitan region ‘organize [their] data and make it universally accessible and useful.’ This relates to both what I’ve talked about with open-sourcing the TTC website, and with the Transit Camp’s open TTC session. I hope that the TTC is paying attention and taking notes.

Update: Bibiana McHugh has left a comment which addresses some issues mentioned above.

The great thing about the Transit Camp was its openness. When the call for sessions came up, I encouraged my girlfriend, who wasn’t entirely certain how she could contribute, to draw on her strengths and introduce a PR-related topic. She did, but unfortunately her idea of TTC-endorsed parties inside stations along the subway line was superseded by the Newmindspace subway party presentation which was unannounced at the time, so only two people showed up.

I attended a session on opening up the TTC data, which centred around creating an API for third-party developers. That was one of my pie-in-the sky suggestions for a new TTC website, so I thought it would be interesting. It was, but much of the discussion involved creating a trip-planner based on data available on the website. Offshoots of that grand scheme, such as creating an interface for determining the time until a bus appears at a specific stop (an idea I’ve thought of but haven’t touched), were discussed as well.

One of the problems with bringing in people from the community is that those who don’t have a background in computer science often don’t realise how complicated certain programming tasks are. Transit route planning involves calculating the shortest path with minimum delay between two nodes and is NP-complete, meaning that no polynomial-time solution exists and that, even with intelligent search algorithms, massive amounts of processing power is required for an imperfect but reasonably fast solution. Even Google is unable to create a perfect solution to this problem, as anyone who has made frequent use of Google Maps to get directions can attest, and they can only return a timely result because they have vast amounts of computing power available. Factor in bus schedules as a third-dimension, and the problem becomes quite cumbersome. The TTC, with its more than 350 routes and over 12000 stops, is the third-largest public transit system in North America. It’s commendable that individuals want to attack this problem, but automated trip planning and scheduling is best left to those with doctorates and massive amounts of computing power.

In the afternoon I attended Joe Clark’s eye-opening “Why TTC Signage is Fucked” presentation. As my girlfriend will attest, I am often bothered and frustrated by inappropriate signage and directions, so this talk affirmed a lot of my own thoughts and made me realise just how bad and widespread the problem is. Sadly, it seems as though the solution to bad signage, apart from massive lobbying, is a lawsuit brought about by death or injury, at least until the TTC becomes more enlightened.

Next up were the design slams. I joined one of the slams on redesigning the TTC’s homepage. While not a task that an hour or so can solve, it was nevertheless an interesting exercise. My main interest was multilingual support. Language drop-downs and language selection pages are not the answer as far as I’m concerned. With which language do you present the drop-down or link? I’m also unconvinced of the reliability of using the Accept-Language header sent by the browser. I feel that a properly-encoded display of the top languages covering upwards of 95% of Toronto’s population and its visitors is a better solution, but one that is also fraught with problems.

As I mentioned before the camp, my intent was to connect with people, and connect I did. I managed to meet and speak with Adam Giambrone, Joey deVilla, Jay Goldman, Joe Clark, Bob Brent and David Pritchard, among others. Having not been to this kind of gathering since the release of my transit map, it was a little strange to be instantly recognised by name. I was introduced as both “the guy who did the Google Toronto Transit Map” and “the guy who remixed the website suggestion spreadsheet“, although I think the most flattering comment came when the team who created a concept for a new bus shelter described a map on their embedded LCD as “a Crazed Monkey type map.”

All in all, the Toronto Transit Camp was a success for me and no doubt a success for the community as a whole. Did it live up to the hype? Only time will tell whether it will have any lasting impact. Representatives from the TTC were present, so hopefully the ideas presented there will stick in their minds and be recalled when it comes to policy change.

A proper TTC website will probably cost upwards of $1 million and will probably take at least 8 months to be done right. Any company involved in its creation will need web designers and developers who are not only familiar with creating high-traffic, intuitive websites with multilingual support, but should have the power to wean the TTC off its dependence on PDFs for bulletins and notices. That company will also need to employ user-interface and accessibility experts, translators and lawyers well-versed in the legal ramifications of accessibility. Each of these roles will be important for providing full translations of the TTC website for the city’s half-dozen or so most popular languages as well as ensuring that the website can be accessed by everyone, young or old, hearing or sight impaired. In short, everyone from a sight-impaired person accessing the web over dial-up and a Chinese-speaking senior should have no problems using the site. The accessibility lawyer will be needed to ensure that all guidelines (such as those of the Web Accessibility Initiative) are met to cover the TTC’s ass in case of liability. These experts will not come cheap.

In addition to the above roles, the TTC website will require one or more individuals who will be tasked with the responsibility of signing off on the finished product. These people will be responsible for seeing that the project meets the highest guidelines and must have the political backing so that their say is final and that the project isn’t complete until they say it is.

No company in Toronto can offer all these services. In fact, probably only a handful of companies world-wide have the personnel, experience and technical know-how to create a website suited to avoid lawsuits similar to that of NFB v. Target. In addition to being expensive, these companies are probably backlogged with work.

Toronto has some intelligent people who can provide the skills and knowledge, but they are few and far between and already have jobs. What this city needs is a sort of Justice League of web experts who can occasionally group together for the common good. Single-day initiatives like the Toronto TransitCamp are not the answer.

Probably the best solution is to open-source the TTC website, but make it more cathedral than bazaar. Invite people knowledgeable about accessible, multilingual websites to submit, maybe even as a cross-discipline project for senior and grad students within the University of Toronto. Have one or two people tasked with deciding which changes are integrated to the final product. Gather requirements, design, develop, test and repeat until done. The website will take longer (maybe a year or possibly two) but it will be cheaper and will be more likely to meet the public’s requirements.

Now, I’ll admit that the spreadsheet makes some sense in the context of the open letter to Adam Giambrone, but my critique was based on the spreadsheet in isolation. It is extremely likely that the spreadsheet would be passed around within the TTC and to anyone contracted to create the new website without the benefit of the original letter. Those people might not know of the four posts containing the original comments, so the references would be meaningless.

In retrospect, I’m sorry I missed the post which announced the upcoming matrix. Had I seen it, I might have offered suggestions then and not after the fact. Also, my critique wasn’t meant personally and certainly not as a jab at what the four weblogs are contributing. Indeed, I offered my own suggestions for improvements to the TTC website a few weeks ago. I realise that my post may have come across as gruff, but understand that the fields of software development and usability are ones about which I care deeply, and so I am often perturbed when others aren’t as careful as I would like them to be.

Let’s ignore that not everyone has Microsoft Excel on their machines. (I don’t and instead had to wait for that ugly behemoth, NeoOffice, to sputter to life and display the data.) Let’s also ignore that if a spreadsheet was the answer, it could have been released in CSV format. Instead, let’s look at the data. (Those of you without Microsoft Excel will have to follow along using the image below.)

The open letter to Adam Giambrone describes the spreadsheet as “easy to use”. When you say something is easy to use, it had damn well better be. Personally, I had to stare at the spreadsheet for a few minutes before I could make heads or tails of it. Describing something as easy to use when it isn’t has the adverse effect of making anyone who doesn’t find it intuitive feel like an idiot.

First, the data is not a table and the first column seems to have absolutely no relation to the matching rows in the other columns. I have no idea what that first column is supposed to represent. Is it the cities from which the comments originated? Who knows.

Second, the acronyms and numbers you see (SPC 3, RT 4, etc.) are supposed to describe the website and comment number which made the suggestion in that column. There’s no legend, so I can only assume that “TI” means Torontoist.com and “RT” means Reading Toronto, “SPC” means Spacing and “BT” means blogTO. No website addresses or comment URLs are given so when this spreadsheet is printed or passed around the internals of the TTC, nobody will know what the heck those letters and numbers mean and won’t know where to go for more information.

Third, the spreadsheet isn’t even using spreadsheet functionality. It’s a table, but it’s not. The comment references are comma-separated across multiple rows, so there’s no way to do anything meaningful with this data such as sum the columns and graph the results, which is what everyone wants to do with spreadsheets. To find comment totals, you will have to manually count the references.

Fourth, you can’t see it from the image but my website is misspelled in row 22. It’s crazedmonkey.com, not crazymonkey.com. Thanks, guys.

Fifth, many of the comments referenced do not match the feature under which they appear (eg. TI 23 under the independent server suggestion). Also, RT 14 does not exist.

How would I have captured the website findings? First, I wouldn’t have made the mistake to release it in spreadsheet form. Instead, a simple HTML page would do the trick. The data can be expressed as a list using CSS styling wherever appropriate:

<ol>
  <li>Suggestion 1
    <ul>
      <li><a href="link to comment">website and comment author or number</a></li>
      …
    </ul>
  </li>
  …
</ol>

With the above format, every comment has a link to check. The file or link can still be passed around with no loss of information.

All of this begs the question, why even bother with a findings document at all? The comments are in an open forum which everyone can read and from which they can draw their own conclusions. Releasing a difficult to understand requirements document does nothing to help, but actually serves to inhibit. Who is going to take seriously anyone who creates a spreadsheet like that and passes it off as helpful? It’s well-intentioned but there’s a reason why the requirements gathering process, particularly in the software and usability fields, is left to the experts, or at least those with domain experience.

Update: I have since remixed the suggestion matrix into a HTML page as described above.

During the past year, the TTC went from sending a cease-and-desist letter to blogger John Martz for publishing a satirical subway map — renaming stations with irreverent anagrams — to the new commissioner praising the efforts of Web developer Ian Stevens, who used free Google tools to create a GTA-wide map.

It’s great to see such a change at the TTC with only a change in commissioner. I’m hoping that it won’t stop with the website, but will spread to all aspects of the TTC from scheduling to swag.

1. An accessible website with proper use of HTML with CSS. The current site design relies heavily on Javascript and images for navigation, and doesn’t use HTML properly. I can’t imagine how frustrating the site is to someone who is sight-impaired. The links on the front page to accessible pages aren’t even accessible!

2. A proper bus schedule page. Aside from being lodged in a frame, thereby denying the ability to be bookmarked, the bus schedule page needs a complete rework. First, it only lists major stops, not every one, forcing the user to interpolate stop times. Most importantly, the stop times are pre-formatted in plaintext, not in a table or in a list styled with CSS, as would be preferable. A high school kid wouldn’t even churn out something this bad.

3. Everything should be bookmarkable. Although the TTC site has pages for surface routes, they cannot be bookmarked. Thankfully, Chris Johnson addressed that problem, but the TTC needs to go much further than that. Every surface stop should have its own bookmarkable link, not just major ones like those currently listed.

4. Search. It’s 2007 and I still have to scroll through hundreds of surface routes to get to one I’m interested in. If I don’t know the route numbers by heart, I’m screwed and have to check the map first. All that information should be searchable. Enter a route, get its page. Enter a stop, get its link. Enter a street, get a page with a list of routes and a list of stops on that street. Enter an address or intersection, get a list of stops nearby. It should go without saying that searches should be bookmarkable.

5. Pages for stations. When building my map, I was astonished to find out that each subway station doesn’t have its own page, listing the connecting routes and features of that station. Montreal’s transit system has a page for each station, and it’s light years ahead of the TTC. Just look at this page for Beaubien Metro Station.

6. A trip planner, ideally with Google Transit integration. Mississauga Transit has trip routing, but it’s limited to pre-selected landmarks, is almost unusable (I can’t get the non-standard pulldowns to work) and doesn’t allow bookmarking of the route. A TTC trip planner should route between two addresses or landmarks, and the resulting route should be easily bookmarked for later.

7. Decouple the TTC and City of Toronto pages. Going to ttc.ca redirects me to www.toronto.ca/ttc/. Why is this? Why do many TTC pages have the same look as the City of Toronto pages? Pages for the city and pages for the TTC should be unrelated.

8. A query API for third-party apps. Before I created my transit map, I wanted to build a webpage or a Dashboard app which would quickly list how many minutes before a bus would appear at stops near my favourite locations. Unfortunately, this would have meant wading through the crap that is the pre-formatted TTC bus schedule page and would have necessitated my own surface route database, so I gave up on the idea. It would be wonderful if the TTC could offer an API to its data so that third-party developers could represent the data in new and interesting ways.

That’s all for now. Notice that the trip planner is further down on my list than accessibility-related features. This is because the current site is completely inaccessible, and adding a trip planner would do nothing to help that. Also, a proper trip planner would require an accessible site to work properly. Joe Clark has more ruminations on this subject, be sure to read them.

I’d like to think that my map had a small part in this hunt for ideas. Maybe it was a small catalyst that came on the scene at just the right time, where anger over the TTC website became apparent in the public eye at the time the TTC was considering a redesign. Maybe my map had nothing at all to do with it. One thing is for sure, though, and that’s that it’s high time the TTC website was born anew. Let’s hope they don’t screw it up.

As I said, the interest is pretty overwhelming. I’m particularly struck with the disappointment in the TTC for not coming up with something similar much sooner. It’s sad that it took one guy working with a finished product on his laptop to produce something of greater use than the TTC can currently provide with its reams of internal route data. Sure, it’s a complicated system, with over 200 routes, and my map is far from perfect but anything would be better than the information the TTC currently offers.

Stay tuned for more updates. I’m currently working out a way to include user contributions to the map to greater increase its usefulness.

• GO Train stations and addresses.
• Link generation for a search result so that searches can be bookmarked.
• Optional rendering of station names and info on a separate layer.
• Listing of adjoining surface routes for each station, with link to the schedule for that route.
• Surface routes, subway and train lines on their own layer along with the option to select which layers are displayed.
• Clickable bus and street car line markers which bring up the TTC web page for that line.
• Clickable bus and street car stops which link to the corresponding page on the TTC website.
• Rendering of station entrances.

Of these features, the first five seem to me to be a good combination of usefulness and feasibility. The other three require either large amounts of time and/or the usage of a GPS receiver.

Which features would you like to see?