crazed monkey

Yesterday I posted a little tirade against the spreadsheet containing the suggestions for the TTC website redesign. Not only did Reading Toronto respond in an emaila comment, they also posted a link to my remix on their site.

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.

Posted on January 25th, 2007 in ttc - No Comments »

On Monday individuals from the four websites who collected TTC website suggestions from the Toronto community through their weblogs released their findings to the TTC and the general public. They did so in the worst way possible; using a spreadsheet. These are four fairly successful websites, all running popular weblogs and collecting their suggestions from local web users in their comments sections, also on the web. Wouldn’t it have made sense to also release their findings on, oh I don’t know, a web page? Apparently that would have made way too much sense.

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.

Posted on January 24th, 2007 in programming, ttc - 5 Comments »

When I released my new Toronto transit map I promised to release some of the tools I used to create it. Possibly the most useful tool I created is my command-line tile cutter. True, there are other image tilers, such as a Photoshop script and a web-based tool which uses Google Maps. I don’t have Photoshop and find it slow, and the web-based tool is difficult to use even with small files, so I created my own tile cutter.

My image tiler uses Free Software, is released under the GPL, and has the following features:

• Tiles most image formats, including GIF, JPEG, PNG and TIFF.
• Works on most flavours of Unix, including Mac OS X.
• Supports version 1 and version 2 zoom levels.
• Automatically calculates offsets for all zoom levels.
• Supports padding from the upper-left as output by the web-based tiling helper.
• Automatically pads image to size appropriate to Google Maps (ie. multiple of 256).
• Optionally discards empty transparent tiles to save space.
• Optional prefix for each tile.
• Outputs tiles in PNG format.
• Compresses tiles with either advpng or pngcrush.

The tiler requires ImageMagick and advpng or pngcrush for PNG compression. (I recommend advpng as it is faster and compresses smaller in most situations.) Tiled image size is restricted only by disk space and ImageMagick limitations.

To use the tile cutter, one need only specify the image being tiled, the Google tile coordinates of the top-left tile, the zoom level for which those coordinates are valid and the zoom level the tile represents. For example, suppose we have three images (img15.png, img16.png and img17.png) for zoom levels 15 through 17 (in version 2 zoom levels), respectively. The top-left corner of the image at level 15 is 1812,1924. You would then run the following commands to generate the tiles:

% googletilecutter -o 15 -t 1812,1924 -z 15 img15.png
% googletilecutter -o 15 -t 1812,1924 -z 16 img16.png
% googletilecutter -o 15 -t 1812,1924 -z 17 img17.png

Note that the only options which need to be changed from image to image are the zoom level of the image and the image itself. Compression and discarding of empty tiles is performed automatically. For more command-line options execute the script with the -h option.

Download the Unix command-line tile cutter for Google Maps. If you have any problems or experience any unexpected behaviour, please leave a comment below.

Posted on January 24th, 2007 in googletilecutter, programming - 8 Comments »

I was mentioned again in the Toronto section of yesterday’s Globe And Mail, this time in an article on the TTC website redesign. I can’t find the link online, but here’s the paragraph:

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.

Posted on January 9th, 2007 in transitmap, ttc - 2 Comments »

After TTC chairman Adam Giambrone said he would be interesting in hearing input on the TTC site redesign, local blogs Torontoist, the Spacing Wire and BlogTO all took up the cause. Not only will the best ideas sent their way be passed on to the TTC chairman, but the blogs in question have vowed to track the TTC’s responses. Here are some of my suggestions:

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.

Posted on January 4th, 2007 in ttc - 6 Comments »