Pretty soon, I began to notice something — a distinct lack of signs in the newly renovated areas, from the elevators to the front entrance:

Don’t believe me? Here’s the opposite angle — the other side of the lobby:

If I didn’t tell you outright, would you really think those computers up there in the last photo were for self-checkout? Me, I would think they’re catalogues, just like at Indigo/Chapters, right? (Wrong.) Let’s look closer, can we tell now?

Well, we’ve an obvious sign now, and if you look over at the service counter on the far right (not pictured), you can see similar capital-letters-on-blue signs. Personally I find these signs ugly, hard to read, and a touch condescending, but maybe that’s just me.

We’ve a self-checkout, but how does it work? Can you tell from this photo alone? No? Well, here’s a shot from another angle. I’ve added my interpretation of how it *should* work, but we’ll see in a minute that it’s not that simple:

Now, to take those instructions and make them clearer, let me show off what I think the above photo SHOULD look like:

As you can see, there’s a much more obvious 1-2-3 progression inherent both in the signs and software. A colourful bullseye is printed on the RFID pad, and in the sign next to it, books are shown on the same bullseye to help associate its functionality. Similarly, the scanner has a little sign with a library card on it being “scanned” by a red laser-like line. Even the receipt machine is pointed out, to emphasize that the books are “checked out” only when the “Done” button is pressed and the receipt is printed. (I wish it would email instead, but that’s another problem entirely!)

This is however, in an ideal world, and the system doesn’t work this way. I tried to checkout a book, Tom Peters’ excellent “Little Big Things” (and these problems are definitely a bunch of little-big-things!) and here’s what I saw (with my notes in red):

So I tap English (and it works the third time, dang those are tiny buttons.)

Ooh, finally some instructions. But uh, why should I place items down before scanning my card? Isn’t it more logical to scan the card first, THEN checkout the items? Maybe it’s done all in one step/screen? (I wish!)

Uh oh! Seems I might have an error, look at that giant exclamation mark (!) but wait, I can still “Continue”? Why show this screen separately, then? Let me checkout! This isn’t feeling very “Express” right now…

Okay, now I’m getting lazy at cropping the photos. Here we see a list of items “on the pad” (which it says in a dozen words). Note it says “To check out more items, press Continue” — that’s actually a mistake, but it’s par for the course in this poorly designed software. When you push Continue, it will “check out” the shown items, not ask for more. But hmm, how can a book be in TRANSIT when it obviously isn’t? (And why do I care?)

So I blindly hit the blue Continue button (you knew the hard to read black-on-blue text is Continue, right? Unlike the black-on-black Cancel, that is. More on that in a sec.)

Feeling “Express” yet? We’ve checked out our one item. It says to remove “when due dates show” — which makes me wonder how often due dates might not appear … but oh look, another blue button! I must be done, so I click it and remove my “item”, expecting a receipt.

But … no receipt prints. Argh, this was supposed to be express! Where did I (a geek!) go wrong? Better yet, what screen do I see now?

Ooh, this looks familiar — we’re back to the fourth screen. And yes, the items on the pad now match the items on the screen. But it says to check out more items press Continue. I don’t want to do that. So what other option do I have? Cancel. But I don’t want to do that either, I want to keep my checked out book, not cancel it. Why can’t I just say DONE? At this point I’ve spent a good 3 minutes here, and I’m frustrated. I can’t even lose the book because I don’t know if I can walk out now, or if I might be responsible for the book if I leave it here and it becomes overdue later.

Luckily a librarian hovers near (wonder why, eh?) and notices my dilemma. She brings up another point, seeing this screen — what if the book hasn’t been securely deactivated? (Eep, never thought of that myself and it isn’t mentioned anywhere!) So I let her take the book behind the service counter’s door in the wall, and wait another minute for the all-clear.

What an “express” checkout that was.

Still, we’re on to something here. The idea of just scanning a card, stacking a bunch of books, then a bunch more, and grabbing a receipt, is too tempting to ignore. The only problem with the above experience was a lack of clear direction in both the software and physical kiosk setup.

As a reminder, let’s see my version of the kiosk again:

Notice that in my version of the checkout, the screen looks like a kiosk, with big “touchable” buttons, sensible defaults (English) and a sense of physical presence, with the arrow pointing at the barcode scanner. As some of the stations have the barcode scanner on the other side, the software might need to be configured to allow for different physical situations, just as left-click and right-click swap functionality when the mouse is on the other side of the keyboard.

You’ll also note I’ve hypothetically introduced a DONE button in my Step 3 instructions. That’s a direct result of my personal confusion over when I was actually “done” and could leave the checkout. I figure a dedicated button solves the “Do you have more books?” question, by assuming I do unless I say I’m “done”. After all, what are the dangers of scanning the same RFID tag twice? Nada.

Which leads to another point — why bother with a touch screen when you can use physical manipulations instead. Want to sign in with your library card? Just pass the card underneath the scanner, no need to hit Continue for that. Similarly, want to tell the system you’ve more books to checkout? Pile them on the RFID reader and it’s obvious.

Now, the way I see this kiosk UI working best is in a triple-pane configuration that’s based on the physical layout (roughly). The half of the screen closest to the RFID Reader displays the full book covers (or titles if covers missing) of books placed on the Reader, while the half closest to the barcode reader does the same for the books checked out by the account, along with their name and status. Action buttons, such as those to checkout books or say you’re DONE are placed somewhere in the middle, or perhaps not. Regardless, when you click Checkout, the books smoothly animate from one side of the screen to the other, to visibly show their status changing. They fade out on the Reader side, but still remain visible to show the books are still being read there.

But wait, what if you make a mistake? No need for a cancel button. Just hit DONE when you’re done (even if you haven’t done anything) and that will clear the screen for another patron. And if you’ve accidentally checked out some books, just drop them off in the drop box as you leave. (There should be a drop box right next to the checkout, because that’s where people expect it, but whatever works—)

So I wrote this post in response to a surprising lack of signs. Left, you can see a typical configuration of self-serve equipment, clearly labelled and designed for you to understand what you’re doing at a glance. Sadly, the same care and attention to detail hasn’t been applied to the new self-checkouts, causing delays and confusion. (Though indeed, once you use it a few times, you learn to jump through the hoops, and I even saw a 7 year old working the checkout system faster than his parents, so maybe I’m just too old…)

And I can do further mockups of the system in action. Certainly, if I know that what I’d post here could go in the next revision of the software, I would, but I worry that “skinning” the current interface won’t make up for the problems I outlined above, and a fundamental rejiggering of the RFID reading is in order.

I actually played with RFID reading in Max/MSP, with a classmate at York University and some RFID readers the Digital Media dept. has. What would be really nice is if the barcode scanners disappeared entirely, as did the kiosks, and instead the giant security readers did the checkouts based on an RFID reading of our library cards as we left with whatever books we wanted. If we weren’t allowed to leave, they would beep, as they do now, and nothing new is required from a security perspective. Plus it would make me feel better at having so darn many of those security scanners. I mean, really, it’s like an airport:

Just my two cents. Let me know your thoughts in the comments below, or @-reply me on Twitter, I’m @4lou.

Remembering how in a previous post’s comments, Mike, the Director of Engineering at NextBus clarified for me how the GTFS data they offer differs necessarily from other versions published, I knew such data should be available somehow. But all they list is their predictions, which they of course have copyright over. The raw data, I remembered, was once visible from a Google Map, which I couldn’t find. But I stumbled on the URL again and decided to manually load the data, with the required referrer header:

$ curl --referer 'http://www.nextbus.com/googleMap/googleMap.jsp?a=ttc#' 'http://www.nextbus.com/service/googleMapXMLFeed?command=routeConfig&a=ttc&r=501&key=2826347560685'


Here’s the result:

<?xml version="1.0" encoding="utf-8" ?>
<body copyright="All data copyright Toronto Transit Commission 2010.">
<Error shouldRetry="false">
Your IP address 99.235.xx.xxx is not authorized to access data for agency Toronto Transit Commission. Contact [website at nextbus dot com] if you should have access to this feed.
</Error>
</body>

Please note the copyright above, in red. This shows that as should be expected, the raw data (not the predictions) are indeed copyright the TTC rather than NextBus. But of course, I get the error listed above, that I’m not authorized. I expected that, after all it was hard enough to find this feed URL.

The question I really have is, TTC, why haven’t you made any plans for an API for this data? Perhaps I should contact that projects director, whose phone number I received after a two week struggle last December. Given how I’ve scraped the TTC data already, found some problems, and would like better solutions for standardized data sharing, there should be room for mutual improvement of all our services, with all the benefits therein for TTC riders.

Next I think I’ll start writing up posts detailing my adventures scraping ttc.ca and geolocating all 1,886 timed stops. Oh and if anyone wants the database (it’s a work in progress), let me know. I’ve also got an API based on Google Protocol Buffers from when I was experimenting in BlackBerry app development (a nightmare of its own).

Now ideally, there would be changes made based on our contributions: Signage could be reviewed/improved, buttons could be sold at stations, myttc.ca could be compared with the official trip planner, my iPhone app could inspire a mobile version of ttc.ca or an official app (I’d freely share my code if anyone asked, or work on a new better app). As I wrote in my blog, the San Francisco system actually supported a community effort at 511.org and two years later bought the website for its own use and encouraged its further development. In fact, SF Muni even has a Labs website with experimental features like an API for live next-bus information. Other transit systems and cities are providing contests (with cash prizes or passes) to encourage indie developers to make apps, like New York City, Edmonton, etc. Supporting developers and designers, indie creative thinkers, is important, and something the TTC doesn’t do– beyond the occasional public art installation bid. Why does everything have to cost money at the TTC to be valued?

In addition, the TTC doesn’t have enough customer support people. From my attempts to gain information on the lack of updates to the TTC’s official release of open developer data (at toronto.ca/open, hasn’t been updated in 6 months despite many service changes and inaccuracies), I used the feedback form at ttc.ca, then after 7 days, emailed followup@ttc.ca and still waited further for a response. Phoning the TTC Info line revealed that there are only two people to answer 300 emails/day. That’s why there’s a followup system, and why such a system is dysfunctional. Then add to this my frustration at not getting an email response directly from anyone working within TTC marketing or IT (though I did manage to get a phone number when I explicitly requested one), and I just feel as if a disconnect is maintained between customers who want to help improve the system, and the people in charge of doing so.

By comparison, at YRT, they’ve 3-5 people to manage a much smaller volume of emails and calls, and yet can promise a 3 day turnaround. And unlike at the TTC, at YRT my request was responded to by actual systems employees, such that when I discovered a security flaw in their trip planner, I was able to email and notify the right people by the next business day, something I was unable to do when the TTC had the same flaw.

YRT also has their routing data (though not live GPS data) available for programmers in GTFS format. The TTC doesn’t, unless you count the efforts of the myttc.ca folks (which hasn’t been updated since last Summer, unfortunately). I’m not even sure the TTC itself has GPS data for every stop, or numbered every stop, though I do know myttc.ca is close — and currently working on adding station-accessible entrance routing to their database. Myself, I’m getting requests everyday for offline data, GPS-enabled routing, and more– but the reason I made my app in the first place was to show accurate data and how can data be accurate if it doesn’t come directly from the TTC? I’m in a catch-22 though, as the data from the TTC is inaccurate, sometimes even on ttc.ca, and so who actually has accurate data then, if not the TTC? And why can’t us customers help the TTC with its data and services for our fellow travelers?

All we’re looking for is a little respect. Why is openness, open data, such a foreign concept at the TTC?

Before I outline the various forum/community software I’ve used and how each differs, I wanted to mention an old yet excellent book by Derek Powazek called Design for Community: The art of connecting real people in virtual places (WorldCat). I bought it almost nine years ago for $45 at the World’s Biggest Bookstore, and while all its examples are dated now, given Facebook, Twitter, YouTube or even CSS, web standards and blogs (I love the quaint use of “homepagers” rather than “bloggers” to describe people like Jeffrey Zeldman) it was solid gold then and still is now with great interviews and predictions.

In fact, a careful reading of just the Table of Contents can tell you a lot about community:

And the Preface is fun, honest introduction to community basics:

And now, on to some examples of community software:

PunBB

PunBB was founded by Rickard Andersson who conceived it for a personal project as an alternative to over-featured or too graphic discussion boards. Now available at punbb.informer.com under the GPL, it’s come a long way since I first used it in 2003 for a 500-member gaming community, though it’s still very simple: If it does what you want it to now or is close enough, then great! Its code is easily hackable and it has a plain CSS-based style best suited for a smaller, personal feel or when all you really need is a forum. Not recommended for much beyond a forum, however. Below is the new Copper theme displaying my profile:

Simple Machines Forum (SMF)

www.simplemachines.org – A full-featured yet open source competitor to more commercial offerings, SMF has had a bit of trouble (like PunBB) in evolving quickly, though there is still promise and what currently exists works well at what it does. SMF is quite stable, though some might call it bloated, and it has a metric ton of themes, mods and translations. I swapped to this from PunBB back in 2004, wrote a few mods and even made a theme for this that closely matched what PunBB used to look like, though by that point the community on the site wasn’t the same and by 2005 I’d stopped using SMF and that community website, entirely.

“Modern” forum software

I’m running out of time, so I’ll just link to them right now, and write more later: Vanilla Forums (GPL, licensed, or hosted), Invision Power Board ($150 or $10/mth hosted), vBulletin ($195 for forum, $285 with blog & CMS)

Please note these are just the forums I’ve actually used or modified in the past. And I’ve still more I can write about them or alternatives, so expect a Part II post soon.

To that end, the UK is even thinking of buying or sponsoring projects made from its data– why can’t other organizations and governments adopt this kind of forward-looking way of thinking. I’m not suggesting that the government can’t make these connections itself–it should–but that rather it should allow for others to contribute also. Think of it as having volunteers working on something that you also pay select people to do, because volunteers still have to make a living. At the same time, you don’t want to lose people because you’re ignoring them, and opening the data is the easiest way to remain inclusive to all possibilities.

I was inspired to write this post as I read the following emails from Roger Slevin to the gtfs-changes group and felt I had to share this info here, to show how differently things can work elsewhere. (Emphasis mine)

Let me give you more context of the situation in Great Britain. There are three regional information systems currently contributing schedule data to Google Transit – and between us we cover about 500 different operators within the four data feeds that we supply each week – these comprise coordinated and de-duplicated sets of data. As already mentioned, Google also receives a weekly update of the details of every one of c350,000 public transport stops and stations across Britain – each with a unique reference.

GTFS is not used in the UK for anything other than supplying Google Transit because we have more robust and detailed protocols for transferring data between local information systems – so our concerns are about how the data, which meets the specifications of being coordinates, with unique references, etc across multiple agencies, still cannot be processed robustly into Google Transit … and, unless things have changed very recently, still show multiple stop icons at some locations for what is a single physical stop point.

Roger continues later on in the thread:

Oh dear – that is very frustrating, as we have a national standard stopID which is available from both the stops.txt file that you get for national data in Great Britian and is then used in all of the schedule feeds. We have a problem right now that an area which has just done a major tidy up of stop data, and amended (often in a very minor way) the name of a stop – change of punctuation, even … has lost the display of next departures from those stops …. even though their unique references remain unchanged. Given that you are not importing stop data more than three or four times a year – when it is continually changing day by day – this is a serious problem and undermines the credibility of what is being offered to the public. I hope you can be persuaded that it is worthwhile using unique ID values where they are available to ensure that matching happens, whether or not the name field is precisely the same.

Regardless of the Google Maps issue, where Google updates only 3-4 times a year, I love that their data is even more accurate than that, and that it’s national! Consider if Ontario sponsored such a project for transportation across Ontario, from bus to rail to transit of all types. More than likely that would show why EFA by mdv is used more in Europe and the crummy-by-comparison Trapeze is used here in North America. They’re more inclusive-thinking in Europe for these kinds of solutions probably because they’re more densely populated areas and less car-focused compared to North America. Still the idea of the TTC offering weekly updates or with Metrolinx doing a stop-recount for an area– wow, imagine the possibilities.

Too bad they’re unlikely to become reality without a major push from news media and individuals. I wonder if I can organize such a thing…?

511 Transit is a Part of the Bay Area 511 Traveler Information (www.511.org)

MTC’s 511 Traveler Information suite of websites provides comprehensive information about how to get around in the San Francisco Bay Area. Whether you need transit, traffic, rideshare or bicycling information, you can find it in a single place, at this one-stop resource. For more information, visit the 511 home page at http://www.511.org.

But there’s more to 511. 511 is also a toll-free telephone information number. This easy to remember three-digit number provides up-to-the-minute information on traffic conditions and incidents, details on public transportation routes and fares, instant carpool and vanpool referrals, bicycling information and more. All available by dialing 511 from anywhere within the Bay Area.

Evolution of the Transit Website

The original transit website began in 1994, as a comprehensive Bay Area transit information resource started by two U.C. Berkeley students. In cooperation with individual transit agencies, that website provided customized methods and tools for posting and updating schedule, route, fare and map data on the internet.

In 1996, MTC worked with the original transit website developers to continue their efforts and begin expanding the information base to include all public transit services in the nine-county San Francisco Bay Area. Since June 1998, the project has been funded by MTC.

As part of a separate project and with the cooperation of regional transit agencies, MTC implemented a transit trip planning system that, given an origin and destination, computes a transit itinerary connecting the two points. This system was originally developed primarily for the benefit of telephone information operators in the different transit agency call centers. In 2001, MTC launched its original regional transit trip planning system on a website interface for the general public.

In November 2003, MTC launched its revised Transit website as a part of the new 511 service. MTC and its contractor bd Systems (later acquired by SAIC, Inc. in 2006) were responsible for designing, developing and implementing the Regional Transit Information System (RTIS), the larger project under which the transit website is included.

From 2004 through the present, the 511 Transit project continued to incorporate transit service information from additional transit agencies into the 511 Transit website. Today, most of the major public transit agencies in the San Francisco Bay Area provide service data that MTC and its contractor make available to the public through 511.

In 2007, MTC decided to acquire a new transit trip planner to replace its current aging software. Along with the new trip planner, being launched on this website, a comprehensive update of the entire Transit website was undertaken by MTC and its contractors. While offering this all new website, MTC will continue to make the original 511 Transit website available, with features that are optimized for accessibility purposes, including screen reader capabilities and an accessible version of the new trip planner. The link titled “Accessible Version” in the upper left corner of this new 511 Transit website is a quick way to get back to the older, accessible version of the site.

Through the 511 Transit project, MTC currently oversees all aspects of these transit websites. With the invaluable cooperation of Bay Area transit agencies, MTC and its contractors manage the entry and updating of transit service information for the benefit of the Bay Area riding public. This new website is a joint effort of MTC, participating transit agencies, and SAIC, with trip planning software provided by Mentz (mdv), and website design assistance by 352 Media, Oakleaf Consulting, and Swirl, Inc.

Inspired by recent articles on the Toronto Ombudsman, I’m going to write a formal complaint and address it to Roman Muetz, the TTC’s Customer Information Director, if the Customer Service line can’t help me tomorrow. Alternatively, I’ll phone him at the number listed on the Ombudsman’s website and point him at my blog. If he can’t help encourage the TTC to release good, open datasets, or encourage community contributions like myttc.ca, then all I can think to do is mount a campaign for quality GTA data and support of us transit hackers, by harnessing both the 6,000 downloads of my TTC Mobile app (100/day) and anybody else I can snare though Facebook/Twitter/other app platforms.

It’s disgraceful that when a developer really wants to make a difference, for free, that there’s zero support from a public-supported entity. Do I need to request an RFP and $$$ from the TTC to build something for them? Really? And what’s with the zero-response customer service, where @bradTTC on Twitter tells me to phone, and phoning tells me to email, and email goes nowhere with not even an auto-reply? They make YRT look like a five-star hotel by comparison.

Something new will arrive north of Downsview Station this summer (according to an interview with the artists in Canadian Art). “Dodecadandy,” a November 2008 TTC report notes, “refers to corridors of transit, the outward push of the city and the routes that commuters and pedestrians follow.” Approved last February, the work has strangely received little attention so far, with only seven results on Google. More photos/quotes after the break.

As the report’s description continues:

The interaction between artwork and landscape reflects the continuing dialogue between the universal themes of modern urban growth and the universal theme of nature and its regenerative energies. The artwork is comprised of stainless steel metal components with a durable painted finish. Together, the sculpture and landscape suggest a juxtaposition of linearity and urban design harmonized with motifs of nature and natural plant growth.

Personally, I can’t wait. My only complaint with the report is when it says, “this project will result in a significant improvement to travel times, and an increase in the reliability of the 196 – York University Rocket bus service.” Because while it’s done both those goals, the wait times (at a stop) have increased significantly as spacing is an issue for the line. Still, at least this summer we’ll have something nice to look at as we wait for the 196B. Go Canadian art!

So I’m trying to figure out how to structure the app to incorporate other regions, like YRT, without disrupting the smooth flow people are already used to. Right now my prototype is a tab bar at the bottom (as shown on the right, click for full view) with the following tabs:

Map, TTC, Subway, YRT, Updates

A perfect app would start in Map, always, and immediately show a GPS-enabled offline map zoomed in near where you are, showing a live view of where buses are.

Then if you click a stop and view its full schedule, the app swaps to TTC or YRT tabs, remembering that you viewed that stop (to save it as a favourite like it does now for routes) and shows you the stop info. Seeing a bus you want, you click it, and it loads that bus’ route, which you then see ends at a Subway stop.

You click the Subway stop and it switches to the Subway tab, showing that subway station, its buses, and perhaps a brief map of what the station looks like inside and out, including accessibility features, bus loading areas and nearby amenities.

Then an alert appears at the top of the screen, saying that the line the subway station serves is now running shuttle buses at this station, so you tap the button to follow this alert. After a minute of browsing what’s nearby, you decide to grab lunch at a place just outside one subway exit. Maybe the app could tell you who else is thinking the same thing, foursquare-enabled perhaps? Halfway through your meal, your iPhone buzzes with a ping from the app that the problem has cleared. So you take the rest to go, and head back on the subway.

As you leave the restaurant, you see some stalled streetcars and hit the TTCU button on the Updates tab to quick-report it, with GPS pre-filling the nearby routes and helping pinpoint the problem. While on that tab, you see that routes are expected to change next Monday, and that you can download another GTFS dataset from the TTC to cover the new changes. You decide to download that now and hit the button, which adds a progress bar as it downloads in the background….

Now, in reality, I don’t have that kind of info or map yet, so the app will likely start with the TTC tab open, and that tab will be exactly like the app is now, displaying Routes and Favourites, but with new offline data powered either by a cached ttc.ca or myttc.ca GTFS or both, along with the option to instead use the same old online version in the current app. YRT at least will be GTFS-based, since the YRT has released it’s non-real-time info in that Google-compatible format. GPS data is another problem, though I suppose its primary use will be on the Map view, secondarily as yet more accurate timings on a Stop or Route list.

Oh and this isn’t limited just to an iPhone/iPod Touch. I think I’d port the idea over to Android/BlackBerry. Not sure yet how I’d replace the tab bar on a non-touch screen but I’m sure I can figure something out. (Secondary click? Hmm.)

How else can I add social features, more accuracy? I was thinking of having buttons like “I’m at this stop now” and “Bus just arrived” or a GPS-enabled bus-location-sharing and early-warning-system, like a stand-alone GPS device for transit: Imagine playing music through this app and having the app play voiceovers like: “Bus 84 will arrive at Downsview station in 1 minute.” or “Next stop, Allen Rd.” If you enter your destination, or have a route planned, it could just announce the time and let you know as you approach the stop you should transfer at, etc. Meanwhile it can also report where the 84 bus is for anyone waiting for it at upcoming stops.

Any comments? Please reply below with your thoughts/ideas. Thanks!

Of course, I’ll evolve the structure as I go along. It’s obviously designed primarily for routing applications like Google Maps, with such fields as color or text_color. So I’ll have to add my own fields too. You can see, for instance, the count and accessible fields in Route from the existing TTC Mobile app. (I’m surprised that there’s no machine-readable way to add such feature codes to GTFS, actually, e.g. Washrooms. You could put a human-readable version in Route’s desc or Stop’s desc, however.)

Also, right now there’s duplication in the dataset such that there’s both a trip_id and a trip relationship — this is primarily for debugging purposes and will eventually be eliminated.

So I still have a bit more modelling to go, and then I have to write some loading code, but within the next month, lets say, I might have a working version of TTC Mobile with GTFS data from YRT. For TTC data, I’ll additionally need to scrape together my own GTFS file, or use myttc.ca’s (clearly marked as such and/or unofficial).

Edit: Still working on this, just noticed a bug in the image I posted, Trip should have many Frequiences, and not the other way around. (The arrows are incorrect)