1. Profile Information (user data)
2. Friends Information (social graph)
3. Activities (things that happen, News Feed type stuff)

Looks like OpenSocial won't have its own markup language (Facebook, for example, requires the use of FBML), which means developers will have one fewer thing to learn. The platform is launching with a bunch of partners in place, including Orkut (owned by Google), Salesforce, LinkedIn, Ning, Hi5, Plaxo, Friendster (apparently they still exist), Viadeo and Oracle (not well known for social networking, but they've got an impressive sounding internal app). They've also worked with some of the bigger Facebook developers to get them on the new platform, including Flixster, iLike, RockYou and Slide.

This is interesting, if for no other reason than that Google has managed to perform a buzzword bingo coup and cram two of the hottest words of 2007 into a single name. Sometimes it feels like the sky is raining social from giant buckets, and you'll be seeing a lot more about open in the coming months as the open source world continues its mainstream push. We're big believers in (and supporters of) openness and I'm glad to see some of the walls around the garden come down. The is brilliant in a lot of ways (particularly in their ability to scale and to solve the security issues which typically ruin similar efforts), but your data is very much locked into their site. We'll have a better idea of how OpenSocial will change that when the API is actually released later (and particularly about whether a layer could be developed which allows developers to build Facebook apps on it), and will report back.

Some of those things are familiar from my own days as a student (7 hours of sleep was definitely not), but some of them have definitely changed. I think, to me, the most compelling series of sheets in this movie is the one about graduating into a job that doesn't exist yet. Stop and think about for a moment: are you doing what you trained to do in school?

So, almost needless to say, we're getting really excited about the emerging drafts of the HTML5 and CSS3 specs. This may seem somewhat abstract to some of you, particularly if you don't do what we do, but it means your websites are 'about' to gain some great new functionality which will solve a number of the problems we bump into on a regular basis. Some things we're really looking forward to:

• CSS3 Fonts: The technology to embed fonts in a web page was first specified a long time ago (so long ago that there's a webmonkey tutorial!), but support from the browser makers never materialized and it died in the water (for a complete history, I refer you to our esteemed colleague, Joe Clark: Simon Daniels: ˜Web font embedding rides again!€™). This is a very complicated issue given that the web exists in virtually every language on the planet (does your favourite font include a full set of Kanji characters?), and that fonts have licenses (just like other software) and many of those licenses prohibit things like embedding them in web pages. CSS3 brings it back to life with the @font-face at-rule, which means that we will finally be able to use something other than Verdana, Trebuchet, Georgia, and Arial.
• CSS3 Multiple Columns: Clients who are used to working with print layouts are often surprised to discover that there's no way to automatically layout HTML content in multiple columns. Sure, we can count out the total number of elements in a list, divide by two, then output the first half, end the column manually, and finally output the second half, but that's about as tedious as it sounds. The Multi-Column Module in CSS3 makes it about as simple as specifying:

  column-count: 2

  and Bob's your multi-column uncle.
  
• HTML5 Client Side Storage: Of less import from a visual perspective, Client Side Storage gives web applications the ability to store data locally in the browser, which effectively makes the app accessible offline (e.g.: if you had a website which allowed people to store recipes and share them, client side storage would make those recipes available even when Tom's laptop wasn't connected to the Internet and he was in his kitchen making Duck à L'Orange). This is fundamentally similar to Google Gears, but would mean that your site's visitors wouldn't need to install anything in their browser to make use of the technology. Congrats to Dave Hyatt and the WebKit team, who have announced preliminary support in the latest nightly builds.
  

Keep in mind that we're a good five years away from actually being able to make use of these fun new features, since they'll have to get built into the next release of the major browsers, and then those will take some time to eventually replace the current versions in popular enough numbers to make the new stuff widely available. As always, we'll do our best to keep covering the new specifications for your ongoing edification, as well as to start producing some fun samples for you to play with once some browsers with HTML5 and CSS3 support become a little more stable and easy to download.

A quick poll of the office shows that we're feeling ready. Are you?

quiesce tablespaces for table dogfood

• Building software is a three phase process (the Art of design, the Engineering of the actual product, and the Science of debugging — see Seattle). This manifests in the way FogBUGZ breaks down into separate components (Wiki for specs and other documents created during the design, Project Management and Evidence-Based Scheduling (EBS) for managing the development, and bug tracking and email/discussions for handling the debugging).
• Joel has spoken at length about how to pick a release date for your project which is reasonable and which you stand a good chance of hitting (see Picking a Ship Date and Painless Software Schedules among many others).  This used to seem a bit like black magic, particularly if you were trying to pick a date that you had some faith in rather than just, say, throwing darts at a board. The new Evidence-Based Scheduling features in FogBUGZ 6.0 are pretty remarkable in that they provide a very realistic view of your probability of meeting your ship date as your project progresses, based on the ability of your team members to accurately estimate the time required to complete their tasks. Joel explained how the calculations work (Monte Carlo Simulations!) and it's all quite clever, but the important thing is that it lets you look at a graph that says our probability of shipping on January 3rd is 8% while our probability of shipping on April 20th is 98%.
• He told a story about how they've been using FogBUGZ internally for many years, but even up to v5 he noticed that he would come in every morning and open a little Notepad window to track the two or three things he needed to do rather than actually open cases. So they ate their dog food for v6 and created a method to open new cases which is as easy as typing lines into Notepad, and now he stores everything in FogBUGZ properly.
• FogBUGZ doesn't support the idea of pooling people into a single resource for handling a task, largely because they feel that you should have a single person responsible for every task. Likewise, you can link cases together but there isn't a concept of dependencies like there is in Microsoft Project, because they believe that they don't actually occur that often in software (which led to a funny story about how the Project team at Microsoft doesn't use Project to manage building Project because when they tried, it produced a Gantt chart 9,000 pages wide).

Not to be copied, reproduced or broadcast without the express written permission of the Toronto Transit Commission - Copyright 2007.

So, we'll leave it as an exercise to someone else who feels like tangling with the TTC's legal team. In the meantime, watch for the amazing old footage of the streetcars, the cool rebuild of a streetcar's drive system, concept footage of the new Light Rail and Subway cars coming in the next ten - fifteen years, and talk of the new transponder system currently being installed which allows for the nifty automated station announcements and (ominously?) for the possibility of automated train control. Is it just us or does the TTC's new command centre remind you of 1983's War Games (that was twenty four years ago?!)? And also, where are all the women in this futuristic nerve centre?

It's great to see material like this which goes deeper than a simple puff piece to really give a sense of the complexity involved in running North America's third largest transit system (following New York City and Mexico City). Suddenly makes it seem entirely reasonable that they have trouble paying for it when you realize that it's not just about having buses and subways run but about all of the infrastructure that goes into running them.

Unfortunately, our evil machinations fall to pieces when wireless gets involved. Our beloved carriers (and I use the term beloved where others might choose different expressions, like 'hated with the strength of a thousand suns'), an oligopoly consisting primarily of Rogers and Bell, and lesserily of Fido (now owned by Rogers) and Telus (who uses Bell's network in our part of the world), have determined that the best long term business strategy for data is to grab all they can while the gettin's good. They complain about having to service one of the largest countries in the world and the cost of equipment and wa-wa-wa, all of which is a pathetic attempt to justify this:

That horrifying graph is courtesy of our good friend Tom Purves and a brilliant bit of original reporting that you won't see in the mainstream media because they're pretty much all owned by Rogers or Bell. Yes folks, that graph actually says that Rwandans can download mobile porn for 4.625% of the price that Canadians can. Now I have nothing against Rwandans and I wish them all the ... content they can consume, but Rwanda is not a member of the G8, nor are they one of the world's leading technology producers. They aren't home to one of the better computer science schools in the world (University of Waterloo), or - perhaps more to the point - RIM, the company that has a virtual stranglehold on the wireless device market to the point that the US government stepped in to their patent lawsuit to keep the network online because they can't function without it.

If I sound a little bitter, it's because I spend a lot of time with my colleagues from the US, and since we're all a bunch of tech people, a big chunk of that time is spent with our BlackBerries and Treos and Qs and Blackjacks and etc. in hand. Our American friends blithely surf the web and show us streaming videos and download music and we sit in the corner, shamefully browsing with images turned off. If you think our data rates are bad at home - and they're almost disfiguringly bad - you should see what we pay when we're roaming.

So how do we fix this? As Tom points out, the problem largely rests in the hands of the CRTC, who are governed by the Canadian Telecommunications Act. Though you wouldn't know it by looking at the millions carriers spend on advertising, there's an almost complete dearth of real competition in the Canadian wireless market (I believe that there's a single carrier in Saskatechwan and Manitoba). We have new 'carriers' (known as Mobile Virtual Network Operators, or MVNOs) appearing, like the oddly named Amp'd, but they aren't really bringing any diversity to the market since they just piggyback on other networks (Amp'd uses Sprint in the US and Telus in Canada). They have to cover the cost of their own network usage in addition to making a profit from your services, so don't look to them to lower rates any time soon. Rogers and Bell charge what they charge precisely because they can charge it; we may rant and rave and post vitriol filled blog posts, but I still cough up $60 a month for data on top of my voice bill and I'll keep doing it if I want mobile service. This isn't limited to data rates, of course. Don't even get me started on how they're screwing us on SMS short codes, although you have to love the "let's hold hands and be friends!" message of the Catch the Code site which makes it sound like the carriers just want you to come and play with sunshine and lollipops all day. You have to pay their consortium an astounding $1500 for the first three months of the 'lease' of your shortcode, which effectively places SMS marketing out of the hands of small businesses who might use it for innovative programs. Now the carriers, bless their cold, slimy, black hearts, are pushing to end net neutrality so they can arbitrarily charge us more for data access whenever they feel like it, all the while pushing new initiatives like being able to video chat or watch YouTube on your mobile phone (I won't give them any link love, so look for Rogers Vision in the Google results). If our government, at the federal, provincial, and municipal levels, is so intent on promoting Canada as a leader in ICT (Information Communication Technology), they need to step in and end this insanity. The current pricing model stifles innovation and virtually guarantees that any exciting new wireless technology developments will not come from Canadian companies because the market and the funding to develop those products will not exist at home. I'm not usually a fan of legislating the rates that companies can charge for their services, but the only way the carriers are going to achieve parity with our cousins to the south is if they get hit with a big stick.

Update: Martin Cleaver has a bunch of great in-depth information about who regulates the carriers (not the CRTC for things like rates), and on how we can get out of this mess. I stand by my statement that the government (in some form) needs to step and in and apply some beat downs, but you should go read his post to be better informed. Thanks Martin!

So, other than the undeniable cuteness of watching a little yellow silicone snowman tear up a rug, why does Keepon matter? Keepon is designed to “perform emotional and attention exchange” with humans, particularly children. Using the two CCD cameras behind his little eyes, and the microphone hidden behind his little button nose (oh anthropomorphizing powers! definitely he), Keepon can direct respond to audio/visual stimuli and direct attention to his environment. You can watch him checking out a pink dog-like-thing and then bop at the sight of a person on the NICT site: Keepon's attentive/emotive actions (MPEG 2.6MB). He's not the first dancing robot (see PDRP and Qrio), but he is the first to dance autonomously (i.e.: not pre-programmed with a dance routine), and that's key. A significant pile of research has shown that interactions between people take place on many levels and that even a simple conversation is substantially influenced by the body language of the participants. In a post on the NewScientistTech site about Keepon (Robots with rhythm could rock your world), Marek talks about the importance of rhythm and synchrony to making us feel comfortable interacting with 'bots:

"In the future you are going to be talking to some robot and just the ability of the robot to nod to what you are saying will make it easier to interact,"

What really drew my attention to the story (other than my incredible weakness for dancing yellow marshmallows), was the end of that post:

Michalowski's team displayed the Keepon at the annual open house of NICT in Japan, where over 200 children aged from 2 years old to their mid-teens were encouraged to dance with it while songs were played. Many children chose not to dance, perhaps because they were embarrassed, Michalowski says. However, the team noticed that children were more likely to dance if the robot was itself moving in time to music, rather than if it was moving randomly.

It's all about the Uncanny Valley: the belief that our emotional response to increasingly humanoid-like robots will be increasingly positive until we reach the edge of the Uncanny Valley, or the point at which they become uncannily human, when our reaction suddenly changes to repulsion (at about 75% human-like). Our faith is restored at about 85%, at which point we quickly rise back up to full familiarity:

Illustration credit: Karl MacDorman.

Important take away point: zombies get no respect. Other important take away point: it's generally believed that we experience the repulsion because the creatures are human enough that we recognize them as human but there's something wrong — shuffling gait, insistence on eating brains, trailing body parts — and so we turn in fear and run. As we reach the other side of the perceptual Valley, those odd or unfamiliar traits go away and we feel much more at peace. Research like Keepon and Roillo is important because it gives us bridges to cross the Valley. Every step we take across those bridges is like a mirror turned on ourselves: if we feel a stronger familial tie to a little dancing yellow ball than to the awkward but much more humanoid Actroid robots, what does that say about us?

Alistair’s Key Awaited Feature List

Hurry Up and Wait

    
1. Our business is growing by leaps and bounds and we're having to take over the office next door just to find space for all the new people coming on board (give a big welcome to Alistair, our brilliant new Senior Art Director,  who posted a rave review of Photoshop CS3 today).
    
2. We've been lucky enough to avoid having to fly too much for business (some people might disagree, but our friends who spend too much time in the air can often be heard lamenting the endless parade of airports). Things are starting to change now with our fairly recent visit to Mozilla and an upcoming trip to visit Microsoft in Seattle, but so far we've managed to stay pretty well grounded.

So, given those points, it's kinda weird that all I can think about today is catching a nasty case of Disembarkaphobia and getting stuck on a Virgin Atlantic Airways flight to play with their cool in-flight system, Red. Sadly, it looks like I'll have to wait a while since Virgin America isn't airborne yet and you can only play with Red if you get a special invitation to board the Airbus A320 that they've parked at SFO (you can help get them into the friendly skies by visiting the Let VA Fly site and signing the petition to convince the U.S. Department of Transportation to reverse their decision).

At any rate, Red is a really interesting example of what you can do when you break down existing paradigms. I've flown WestJet flight with your own private TV and the ability to watch live television - which is pretty cool and all - but doesn't even come close to touching Red. Here's a little video, hosted by Charles Ogilvie (Director - In-Flight Entertainment and Partnerships), showing off some of the features:

Ooooh...list constructs! I'm impressed that they're planning to open up the platform to other Linux coders who have ideas for games - I suppose we'll see if that actually happens once they get permission to fly. In the meantime, for more tasty Redness:

    
• Check out the User Interface demo on the VA site.
    
• Take a browse through Engadget's Mega hands-on tour gallery of the Airbus (lucky bastards).

I'm impressed by things like watching streaming video or listening to a huge library of audio files, though those are expected features. Nice touches like armrest USB ports for charging your iPod are great, as is the full QWERTY keyboard on the remote control. Slightly less obvious but still really cool are the net access (email, IM, etc.) and ordering food to your seat, which will certainly cut down the cart-in-the-elbow syndrome. What really impressed me was the addition of a completely unexpected social aspect: seat to seat chat. Chat with the person next to you, with anyone on the plane (who has indicated that they're open to chatting), or join a chat room about the show you're watching. It used to be that getting stuck next to a chatterbox could ruin your guilt-free John Grisham reading time, but now you can just hop onscreen and virtually avoid them instead. We've seen this phenomenon make its way around the unconference circuit in the form of the backchannel, which is the use of a chat environment like Skype or IRC to enable a real-time online conversation alongside (behind?) live spoken reports. Adding that channel to airplane travel creates a whole new dimension in which your on and off screen personas occupy the same (cramped) physical space. Normally when you start chatting with hottie22, you only find out that she's actually a he when you've crossed state lines for an illicit encounter. Now when you start chatting with the hottie in 22C, you'll find out much earlier when you glance over (though you might still be crossing state lines and - hey - there's always the mile high club if he turns out to be cute).

Lastly, for our geekier readers, you'll be happy to know that you virtual seatmate is really just your favourite penguin mascot, Tux, in a pretty disguise (or not so pretty), and that Red passes the Ultimate and True Test of New Technology: it runs DOOM.

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:

• Spacing Wire: Help improve the TTC's website
• Torontoist: Help Make the TTC's Website The Better Way
• BlogTO: Bloggers Help TTC Website
• Transit Toronto: Giambrone Turns to Transit Fans for Suggestions

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 CrowDébonair Developer

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 DeVillaAccordion Articulator

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 EnrosTTC Guru

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 KuznickiPolicy Wonk

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 PateSocial Media Maven

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: www.ttc.ca.

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 heuristics 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.

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:
    • Bay Area
    • Hopstop for NYC, Boston, Chicago, San Francisco, and Washington
    • London
    • Mississauga
    • Ottawa
    • San Diego
    • Vancouver
  • 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).
  • Partner with people who produce merchandise that we'll actually buy and build out a great online store to sell it in. We suggest starting with the Spacing station buttons and Torontoist T-shirts, but this city is jam packed with creatives who are just itching to submit their own designs. Take a cue from Threadless and crowdsource the designs to help support our arts scene. And please (please!) spare us the Legacy Sportswear gear which has been passing as Official TTC Merchandise. No offence to them - we're sure they do great work - but stamping the TTC logo onto a catalogue full of generic items isn't what we're looking for.
• Online trip booking for Wheel-Trans. Danny, in the comments on the Spacing original post, tells a horrible tale of trying to make a booking via the antiquated phone system. Wheel-Trans provides mobility to people who would otherwise not have it, and we'd like to see the service made even easier by a full web-integration.
• Multi-lingual Content beyond a pre-canned page of info. We live in one of the world's most multi-cultural cities, a fact that we love to trumpet, and the information on the TTC's website should reflect that. Here's another opportunity for crowdsourcing: post the info in English and provide a translation UI so the community can work its magic.
• 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 (like Google Maps, WordPress, and Flickr to name a few), 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).
• Visual Design and Navigation
  • The People love the TTC font, so use it!
  • How about using some of those fantastic T.O. photobloggers TTC images?
  • Station pages should use their unique tile patterns as visual elements.

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.

As always, we look forward to your comments! Help us help the TTC and everyone wins.

1. You can use the DOM Inspector to look inside any element of chrome, the term Mozilla uses to refer to the browser's interface. Just open the inspector and use the URL to your chrome as the address - try chrome://browser/content/browser.xul to pick apart the browser's interface.
2. You can use Venkman, the Mozilla JavaScript debugger, to step through you component's code too. If you're running Firefox (as opposed to Mozilla), you'll need to grab the Venkman Extension first, then launch it from the Tools menu. You won't see any chrome files at first, but they'll all show up if you turn off Exclude Browser Files in the Debug menu. Make sure that the component you want to debug is actually open or the files won't be listed (i.e.: if you're trying to debug a window, open the window once to get the files listed, set a breakpoint, close and reopen).
3. This one's a little more obscure but might save you a whole bunch of hair pulling - you can load a stringbundle from inside an overlay on a window, and the bundle will be visible in the DOM Inspector, but you won't be able to access it using JavaScript. Seems to be a bug, though we couldn't find anything listed in BugZilla. You can insert the stringbundle in the JavaScript first and then insert it into the window, or you can just put the stringbundle into the window instead. If anyone has a better workaround, we'd love to hear it.
   

1. Programming is extremely rational. If the plan is kind of like before, don't assume that the system will still work.
2. Programming is more difficult to schedule than marketing milestones. I can estimate all I want but sooner rather than later I'll find a bug that will completely exceed my estimates and throw my schedule way out of whack.
3. Most programmers have not attempted what you have requested of us and thus usually don't build a system optimally the first time. Please plan for continual iterations and we'll work together to refine the process.
4. Just because Larry is a brilliant marketer and a brilliant system architect doesn't mean that all marketers are brilliant system architects.
5. Programmers often prefer things that are inelegant, arcane or even broken too. Except when they don't. Remind them of this please.
6. Brilliant marketing is hard to quantify, demand or predict. Same is true with programming.
7. Seven is seven even when you think it doesn't exist. Computers are picky that way.
8. Unlike mediocre marketers, mediocre programmers occasionally get lucky. But then they have to extend their original design or pass it along to someone else and things fall apart.
9. Lots of programmers are dorky but not all, so don't assume your programmer is a dork unless he proves it to you.
10. Without coding, all your great marketing is pointless. Push your programmers for great code every day. The same is true of sales and all other components of the business. We can't survive without helping each other.

• They're really easily to implement. In fact, they're almost exactly as much work as you were doing before, only slightly different. You don't have to generate a proprietary file format or add any configuration to your web server - just some simple HTML markup.
• Because they're just HTML, you can easily style them with CSS and it means that your CSS files contain some more standardized class names, which makes maintenance a bit easier.
• If the site visitor doesn't have Microformat support in their browser, it gracefully degrades to simple display of the data.
• Search engines crawlers and other web indexers can use the metadata encapsulated in Microformats to get a better and more rich understanding of the content that they're indexing.

zeit·geist | Pronunciation:  'tsIt-"gIst, 'zIt  |  Function: noun | Etymology: German, from Zeit (time) + Geist (spirit) | Date: 1884 | Meaning: the general intellectual, moral, and cultural climate of an era

I’ve installed the software on my Toshiba Tecra S1 laptop, and on my HP TC1100 tablet.  Both of these systems are a little underpowered for Vista, which means it runs a little slowly on them.  The Tecra is a 1.4Ghz Centrino system with 1.2 gigs of memory, and the TC1100 is a 1.4Ghz system with 1 gig of memory.