TTC Web deficiencies

Everyone seems to have forgotten that the TTC intends to redevelop its Web site.

I haven’t. I’ve been checking the TTC tenders page every day for eight months. (I know how to bookmark it.) Over the last several weeks, placeholders for a Web-site RFP and a trip-planner were published, but they always 404ed, a fact I complained about repeatedly. Then, one day, there they were.

The next morning, in the heat, I schlepped across town to buy the tender documents. (That’s what you have to do. Tender documents are never online.) I sat at a coffeehouse in the slums of the Annex, eventually moving my seat to avoid overhearing some undergraduate asshole discuss his plans to spam people via text messaging, and read both tenders cover to cover. I would then feel like shit for the rest of the day.

It’s a lot better than the TTC’s first attempt, whose documents I also have and you don’t. I’m not surprised it’s better. The TTC had lightly abused my good graces by summoning me to a meeting last spring. At no cost, I taught them Web standards in minutes (that’s all it takes; blind kids can learn this stuff almost on the spot and so did they). We went through the original RFP practically clause by clause. What surprises me is how many things are still wrong with it – especially after I wrote so much about it (1, 2). I’ll get to those in a minute.

Skill-testing questions

I also filed questions with all bidders after the first round quizzing them on Web-standards and accessibility knowledge.

• Cyberplex (an appalling prospect) wrote: “I am seeking to clarify your role/motivation…. [D]o you think you can help us ensure that we will meet the requirements…?” (They weren’t clear on what “for attribution” means, and this giant Web shop, which never produced a standards-compliant site even once, could not figure out how to Google the term. Æron chairs all around!)
• Ituitive gave a substantive response.
• Bad Math more or less claimed to be knowledgeable, but were “not in a position to discuss the project in any detail.” But “it’s a dream job for the information/graphic designers/programmers that we all are.”

Don’t read this if you are in any way unsympathetic

You can skip this section if, even deep in the recesses of your conscience, you think I deserve everything I get.

The errors and deficiencies were one reason I felt like shit. There were bigger reasons.

1. Whenever you think “TTC redesign competition,” you must always also think “presumptive winner Jay Goldman of RÄDIANT CÖRE.” Really, this is his baby. Why else do you think he cofounded and coörganized Transit Camp? (I was invited along, but the meetings were all held in Spacerville™, a full 40 minutes away by unheated streetcar.) Why else did they try to shove a Creative Commons licence down your throat?

   I was a skeptic at first, but I thought Transit Camp was great. It was also a brilliant vehicle for Jay and his company to insinuate themselves with the TTC.

   Wily. Crafty. Good for business. The free market at work.

   So far I have refrained from filing an information request to find out how many meetings and phone calls the TTC and Radiant Core have had, and to obtain all the TTC’s notes from those. I’m going to speculate there were quite a few. There was, I also speculate, quite a lot of chitchat between Jay and Giambrone’s assistant.

   RÄDIANT CÖRE is a qualified shop with all sorts of bonhomie and joie de vivre. Why, they’re expanding so much they had to knock down a wall! There is no imaginable scenario in which they’d completely or even significantly screw up a TTC redesign. I just resent the fact that the whole thing seems like a fait accompli or a backroom deal.

   If I’m completely wrong about this, fine. I have a low tolerance for error, but not zero tolerance. I’ll live with being wrong. This is nonetheless how I feel.

2. The RFP demands that each applicant team include one Web-accessibility expert. Well, there go my chances, I thought. First of all, I am nominally retired from the field, though there are still a few odds ’n’ ends (like the WCAG Samurai). But I’m trying to make a living here and I would take a reasonable offer. No such thing is likely, because I lack the bonhomie and joie de vivre that stand in for actual competence in a town that hands Canadian New Media Awards to sites built with Flash and tables. I simply call bullshit too much.

   It seemed obvious to me that the holder of 100% of the Canadian Web-accessibility business (the hard-won final 1% having been 100% of my business) would be immediately recruited by a bidder. At that point, you run out of experts in Canada and you suddenly have to scour foreign countries. I’m just not on the list.

3. There is an apparent saving grace. It is merely apparent. The winning bidder’s work will be independently evaluated by a Web-accessibility expert whom the TTC hires and pays for. This has my name written all over it. But I know for a fact that I made almost no impression on the signage topic with TTC (I requested and possess all their records) and I don’t expect things are any different on this topic.

   Let me tell you what else happened at that meeting. I told them it would be improper for them to say anything about budgets, but, I continued, a job like this wouldn’t possibly cost less than $150,000. Three times during the meeting they implored me to “consult” on the redesign. I told them it would be improper to talk about that, or anything related to money. (Because I’m all about ethics. And that’s been working out great for me.)

   I later found out that they meant I should go in on a joint venture with some other bidder. My response, provided in a written and signed letter, was that I might not get hired by anybody, or they might not agree to my terms, or they might fire me after they got the contract, or they might just ignore what I told them (and, I add here, it absolutely would be a case of my telling them). If I wanted that kind of risk, I told TTC, I’d play the ponies. There is a certain point at which the TTC has to pay me for my expertise, I wrote them, and we were now at that point.

   What I suggested doing was to vet each of the applicants for Web standards and accessibility. They could remove the financial pages and hand me everything else. Later I could vet the actual work of the winner. I guess I’m getting about a third of what I asked for. Or whomever they hire will get it. You’re welcome, I guess.

4. I’ve done some thinking about whom I could get in bed with. Let me mention just two from the list (there’s a list). One boutique shop would be well situated, though not ideally situated, for this job, but a principal there took the time a while back, apropos of nothing, to E-mail me a list of my deep-seated character flaws, and that is not the sort of thing I can readily forget, let alone forgive. It’s still shocking. Another boutique shop, actually much less known, would be a superb choice, as they come complete with their own software. But they have bona fide Web-accessibility experts on staff, making me superfluous. Tits on a bull is the last thing the sarcastic gay vegan really feels like being.

   So much for that idea, I guess. I give up.

This is such a cutthroat goddamned business that I felt I had to act in secret. This too made me feel like shit. Really, with rare exceptions, I publish everything. Even initially secret documents, again like the WCAG Samurai, eventually get published. That’s what writers do: We publish. But I’ve been sitting on this thing for weeks. My fear was that publishing anything at all would tip off the second-rate assholes who pass for Web developers in this town, and also Jay Goldman, who would all then stampede over to buy the tender docs and put in a bid without hiring me.

In the case of the second-rate assholes, they’d lie through their teeth about their competencies and, once they had the contract, they’d use Flash, tables for layout, “XHTML,” and Microsoft server products (every page ends in “asspix”!).

I have very few avenues to secure business in this TTC redesign and I felt that saying anything at all would blow those out of the water. I’m the last person anybody wants on their team, so I knew this was a futile and contradictory fear, but there it was.

But I have changed my mind

I have talked this over a little behind the scenes. You’re not going to find out with whom, so don’t ask. We have agreed on two objections, either of which is fatal to a prospective bidder though both are true at once:

• This isn’t a clueful client. You may think the world of adorable, skyscraper-tall, clean-cut Adam Giambrone, age 29 and a Macintosh user, which is your problem right there. (You haven’t been publicly singled out by him. I have.)

  But the people you’re dealing with all are stuck with Windows and IE6, the most impoverished possible browsing environment. And I know for a fact it will not change in the future. No Firefox, no Opera, no Mac, no Safari, no nothing. The cluelessness manifests itself in some of the requirements of the tender, which I will list shortly and which you will barely be able to believe. You’ll spend half your time bringing these people up to 2004, and the other half trying to beat down the objections of their IT department, telecommunicating via time machine from the mists of 1997.

• They demand work on spec. You the applicant must submit a homepage design with your application. This is flagrant and indisputable speculative graphic-design work, explicitly forbidden by the Registry of Graphic Designers of Ontario and universally recognized as an unethical practice.

  Just cut me some slack here for a moment and agree with me that we do too much work without getting paid and it’s gotta stop. Where it’s gotta stop is with a billion-dollar government agency which, were it more clueful, would know better than to ask designers to cross an ethical line.

  Design means nothing at the TTC. They’d never ask an architect to do this sort of thing. (Do you think they’d insult Jack Diamond by even asking?) Because architecture is “real” in some way that graphic design isn’t. The fact they’re a Windows-only shop is indisputably a cause; Windows users have either apocalyptically bad taste or none at all.

What’s in the RFP?

Here is a tidy digest of the requirements of the RFP, a public document excerpted for review and criticism. You may mentally add “sic” to much of the official phraseology.

• Deadline: 2007.09.13 14:00. You must use only their specific printed forms, some of them on green paper.
• List of contracts completed within the last five years (difficult for younger shops). “[C]urrent client listing, in rank order of annual billings.” “The value of the Proponent’s annual billings for the past three years.” Accounts “gained over the past two years” and “why the Company was chosen.” Also accounts lost or resigned. But also “[p]rofessional references and samples of your agency/organization’s past work.”
• “Why this project (i.e., TTC Web-site redesign) is interesting/important to the Proponent.”
• “Your plan to increase traffic to the TTC Web site.”
• A full training plan for four people (presumably at TTC).
• You must provide or specify a CMS, not necessarily one you wrote yourselves.
• Your team must include one each of project manager, senior Web/application architect, Web developer, Web-accessibility expert, tester, copywriter.
• “The Company may be required to provide annual hosting and maintenance.”
• “The Proponent shall provide samples of recently-completed Web-site redesign projects in an electronic format (CD/DVD) for evaluation. As well, the Proponent shall provide one sample of a potential ‘TTC HOME PAGE’ layout of the redesigned TTC Web site. NOTE: The selected Company must be aware that the submitted sample of a potential ‘TTC HOME PAGE’ may or may not be used for the future [site].”
• You have to score at least 75% on every criterion in an initial evaluation.
• You can bill for “PowerPoint/presentation templates.” What this has to do with the Web is unclear, possibly ominous.
• “Except as specifically indicated in its Proposal, the Consultant shall not subcontract any portion of the Work… without the prior approval of the Commission.”
• You have to meet WCAG Priority 2. I don’t think the TTC realizes this means valid HTML 100% of the time. Nor will many “proponents.” Nor will they actually be able to deliver it (again, lying through teeth).
• It has to be possible to retrofit trip planning, “eCommerce,” automated customer notification, next-vehicle arrival (they only mention “train” and “bus”), and Wheel-Trans trip booking onto the site.
• They use “Adobe/Macromedia software” at present to maintain and “update” the site, to the extent it is or has been.
• There are 150 HTML pages and also 165 route skeds and maps “within a frameset structure.”
• The homepage must be updatable and not static. They don’t say this, but that requirement will accommodate future wildcat strikes and shutdowns of the subway because the tracks get icy in winter. (And jumpers.)
• Your new site has to be “easily and quickly downloadable” even on a 56K modem.
• TTC logo must appear on every page (yes). “Use TTC’s graphic standards (to be supplied by TTC).” Wall-to-wall fake Helvetica?
• “Create ‘interior’ pages that carry through the look and ‘feel’ of the homepage throughout the site. Although the homepage should stand on its own, artistically, the interior pages should mirror the major design concepts of the homepage throughout the site.”
• “TTC HIGHLY RECOMMENDS THAT PROPRIETARY SOFTWARE NOT BE USED FOR WEB-SITE DESIGNS.” How this squares with the use of a Microsoft server is for you to figure out. You have to use “open Web architecture; Java or .NET Web services and… standard compliant HTML coding and cascading style sheets (CSS).”
• You must use “meta tags.”
• “Is designed to function effectively with common versions of software, hardware, and Internet browsers (i.e., Internet Explorer 5 or higher, Netscape 6 or higher, Firefox, Opera 8 or higher, and Safari).”
• “RSS feeds and Blog.”
• “Has browser-based administration as well as direct, non-browser-based administration capabilities” for bullshit reasons.
• “Provides an option” – repeat, an option – “for the functionality and capability of Multi-Language translations. The Company will work with TTC to define, select, and implement an optimal translation tool for a number of languages (e.g., Portuguese, Cantonese, Mandarin [not materially different when written], Italian, Spanish, French, Polish, Russian, Vietnamese, Korean, Greek, Tamil, and Tagalog).” You may have a veto over languages. And they mean machine translation.
• Station and route pages (but not Holovaty-style pages for every stop, clearly possible); What’s New; FAQ; “ ‘Forward to a friend’ and print-friendly functionality”; clickable maps.
• These are killers: Onscreen font and colour adjustment; “software to enable visitor to listen to the text” (yes, speech output); accesskeys.
• Unlimited user testing at your expense. I’m not going to retype it, but that’s what it amounts to. Never fewer than two test sessions.
• “The TTC retains complete ownership of the licensed database, design, graphical source files, data, and editorial content,” but possibly only “a perpetual software license” (the noun is spelled with a C in Canada) for “all scripts and/or code.”
• There will be a public beta that you must host.
• TTC will pay for preliminary surveys and focus groups, if needed.
• If you get the contract, you have to sit through many meetings (including one with unstated disabled persons) and provide three designs for each of five pages (Metropass, station, route, elevators, Commissioners).
• “The Chief Marketing Officer will review and approve each deliverable.”
• Site visits: 551,797 in 1998; 2,699,030 in 2002; 11,405,893 in 2006. The top three most-visited pages have 11%–17% each, the rest dropping off a cliff (Nº 4 at 3.6%, Nº 15 at 0.68%).
• You have to provide for “audio/video tour” of a station on its page. Oh, and mention of any stores in a station (“Next stop: Tim Hortons”).

As a bidder, you may not “take exception” to any portion of the RFP. I encourage you to do so anyway, with reasons.

The deficiencies I filed

One may communicate solely with a designated contact person in the TTC tendering process. I have done so. I provided the following deficiency list on the day I bought the papers. I’m not going to bother re-editing it so it seems like I’m addressing you rather than them. Whenever I say the TTC knew something already, it means I told them to their faces.

1. The RFP is inconsistent on the use of “new custom artwork” vs. TTC’s own art. It also does not even contemplate the use of third-party artwork (e.g., licensed photography).

2. It appears to force the proponent to actually host a beta site. You are opening a very large can of worms in requiring the proponent to host anything. Hosting is specifically listed as an optional provision later in the document. TTC must host its own beta site. It’s yours, after all.

3. “Ability to produce monthly availability reports for management reporting” is a meaningless statement. Do you mean uptime? (You want 99.9[99]% uptime, presumably.) The site will almost always be “available.” Do you mean reporting to or by management?

4. What exactly is meant by “performance analysis”? Turnaround time from an HTTP request? Number of pages returning 404?

5. The requirements for Web-site samples essentially state that, even if a bidder loses, TTC might use their design.

6. Print-friendly pages are completely obsolete. Print CSS, applied to all pages, automatically takes care of printing. [Yes, I know we have a hack now.]

7. Asking for three designs is two designs too many and TTC knows it. Qualified designers will refuse to provide more than one. TTC loves tinkering, and providing any client with more than one design invites them to move tab A into slot B because they “like it” more, as if that were the criterion.

   Additionally, it is later disclosed that “three design ‘working’ prototypes” really means 15 separate pages. This is again too much work to demand – by a factor of three.

8. You’re going to have a real problem under §6.3, because some of the requirements are patently ridiculous and no qualified developer will agree to provide them. It is ill-advised in the extreme to include text resizers, colour changers, accesskeys, and (very much especially) text-to-speech on a Web site. Browsers handle text resizing and stylesheet selection. (It could be argued that colour schemes are different enough to warrant browser functions, but that might be a stretch.)

   Accesskeys interfere with accessibility. Requiring that a site voice itself on the spot is like requiring that it print itself on the spot. The duty of a WCAG-compliant design is to separate content from presentation. Voice output is a user-agent issue and is solely and permanently the responsibility of the site visitor.

   If TTC insists on these ill-advised provisions, expect to spend $30,000 to $50,000 extra up front, and to have the whole thing ixnayed by the independent accessibility audit. In the current environment, it may be helpful to view that figure as a certain number of “underperforming” bus routes to be cancelled, or the number of stops by which the Sheppard subway would be shortened.

   You can expect all qualified bidders to refuse to provide those features. Qualified bidders will have alternatives for some of them and will cite reasons why all of them are a bad idea. Any bidder who cheerfully agrees to provide them is prima facie unqualified.

   Given that a later section encourages the vendor to “work collaboratively and provide proactive suggestions… for future development of the site that would benefit the [TTC] most,” you might as well save your money up front and simply delete those requirements through an addendum. They won’t survive an outside audit and any qualified vendor will recommend that they never see use in the final Web site (even if they billed you to create them).

9. In another example of unfamiliarity, TTC requires the use of machine translation. Machines can’t translate. Here is the first paragraph (including headings) of a page from the Madrid transit system:

   ACTUALIDAD
   27/07/07
   AGUIRRE INAUGURA METRO OESTE, QUE DARÁ SERVICIO A BOADILLA Y POZUELO Y BENEFICIARÁ A 100.000 VECINOS
   

   La presidenta regional, Esperanza Aguirre, acompañada por el consejero de Transportes e Infraestructuras, Manuel Lamela, inauguró hoy Metro Oeste, las dos nuevas líneas de Metro Ligero que darán servicio a los municipios de Boadilla del Monte y Pozuelo de Alarcón. La Comunidad de Madrid ha construido dos líneas, la ML2 y la ML3, con un total de 28 estaciones y 22,4 kilómetros, con una inversión de 362,2 millones de euros, para beneficiar a 100.000 vecinos de estas localidades, que a partir de ahora tendrán una forma rápida, cómoda y eficaz de conectar con la red de Metro convencional.

   Here is a machine translation:

   The PRESENT TIME
   27/07/07
   AGUIRRE INAUGURATES METER THE WEST, THAT WILL GIVE SERVICE TO BOADILLA AND POZUELO AND WILL BENEFIT 100,000 NEIGHBORS
   

   Regional president, Esperanza Aguirre, accompanied by the advisor of Transports and Infrastructures, Manuel Lamela, inaugurated Meter today the West, two new line of Slight Meter that will give service to the municipalities of Boadilla of Monte and Pozuelo de Alarcón. The Community of Madrid has constructed two lines, the ML2 and the ML3, with a total of 28 stations and 22.4 kilometers, with an investment of 362.2 million euros, to benefit 100,000 neighbors from these localities, that from now on will have a fast form, comfortable and effective to connect with the network of conventional Meter.

   Unless you’re a security service running a Cray supercomputer, your quality will never exceed that. There is no such thing as an “optimal translation tool”; they all suck.

   Machine translations will be actively objectionable to native speakers of the target languages. TTC has already had to deal with press coverage (I could send you the clips) of a minor accent error on French warning labels on buses. (TTC is unaware of other French errors on buses.) That will be child’s play compared to what will happen if you roll out machine translation.

   TTC should have known to require proponents to offer a plan for qualified human translation and presentation of translated documents as real Web pages, not PDFs. TTC should not permit the vendor to pick and choose which languages to support, as an underqualified vendor will simply balk at anything that doesn’t use Latin script without accents (i.e., anything other than English).

10. The requirement to quote according to number of pages is nonsensical given that pages can be and will be dynamically generated and the exact number will never be fixed.

11. The RFP appears to require a specific technology (“Flash animation with accessibility, [e]ditable Flash templates” – actually, due to bad writing, that may be two). The RFP unfairly and unnecessarily induces proponents to jury-rig the only kind of site that would be more customer-hostile than the one TTC already has – a site with Flash. There is almost no conceivable use case for Flash (“animation”) on a transit Web site. Further, it conflicts with the requirement that the site function adequately with a 56K modem.

12. You have a less-than where you should have a greater-than on one of the green sheets. Respondents should not be penalized for answering the question exactly as listed.

13. You are not going to be able to achieve WCAG Priority 2 with Commission reports and other documents, unless you are willing to pay the winning vendor a lot of money in perpetuity to convert deficient MS Word “HTML” exports to valid HTML and CSS.

14. For the site to “allow for, and support the integration of[,] TTC’s future initiatives (i.e., Internet [t]rip [p]lanner,” the RFP for that trip planner is going to have to be amended. While it mentions some kind of functionality for the visually impaired, it says nothing about producing valid, semantic code, which is what WCAG P2 requires (itself a fact that will trip up many applicants, who will put on a good show in applying then fall on their faces if they get the contract). A typical trip planner will spit out frame- and table-based “HTML.”

15. It is not clear in the RFP if TTC.CA will finally be hosted on its own server or if it will continue to be forced to play handmaiden to Toronto.CA/path.

16. TTC has failed to explain how, or indeed why, the Advisory Committee on Accessible Transportation “will be involved in the [Web-site-]redesign testing process.” Apart from being disabled people or seniors, ACAT members have no published expertise in Web accessibility. Some ACAT members with disabilities will have no functional impairments in Web usage. TTC is aware of these facts already.

17. The “W3C Web Access Initiative” is actually the W3C Web Accessibility Initiative. A simple check of their homepage would have given correct text to copy and paste.

18. The look-and-feel requirements (note: feel does not need scare quotes) contradict themselves. The list of adjectives for the look and feel [“functional, accessible, friendly, contemporary, easy to navigate, easy to read, attractive, upscale, elegant (but not too ‘techy’), clean (but not busy), yet recognizing the unique character of TTC”]seems to come from another kind of tender competition, perhaps public art, rather than an actually implementable list of qualities for a Web page. The word “upscale” is particularly vague and troublesome. (“Classy” script type in bronze, like on the front door of 1900 Yonge St.?)

19. An “open Web architecture” and the use of .Net are mutually exclusive. Requiring absolutely any kind of Microsoft server application will doom TTC to mile-long unsemantic URLs that nobody will trust (and that take half a day to set up redirects for, meaning that URLs like ttc.ca/31 and ttc.ca/Greenwood will cost thousands in billable hours to create). Microsoft servers notoriously destroy valid HTML. (Try it and see.) They also cost TTC in annual licence fees. TTC should be prepared to receive proposals that use Apache at zero cost.

20. TTC knows already that meta elements are a relic of a previous era. Search-engine optimization happens automatically with valid, semantic HTML. TTC should expect vendors to include one or two meta elements to meet the nominal requirements, but they won’t mean anything or do anything.

21. As links <a> are inline elements, they cannot all be “brief and self-explanatory.” As written, the RFP bans the use of links in the middle of sentences.

22. Netscape ≥6, Firefox, Opera, and Safari are reasonably standards-compliant browsers. IE6 is seriously deficient but sometimes hackable. But TTC must recognize that requiring everything to work in IE5 will require any competent developer to serve IE5 either its own graphic design (costing TTC extra) or a no- or light-stylesheet version. IE5 is significantly worse in standards compliance even than IE6.

    TTC, through its unfamiliarity with platforms that aren’t Microsoft Windows, may be unaware that it has required IE5 for Macintosh compatibility, which is different yet again (a leader in its time, but now outdated).

23. RSS will not “allow users to voice their opinions on current events and services.” RSS is broadcast-only. TTC will transmit RSS feeds; they aren’t two-way. Be very sure you want public comments on TTC blogs, as the RFP suggests. Be sure you want public blogs with comments.

24. If TTC really means that the site has to be maintainable without a browser, it has to be clear on what that means. Command-line interface? Custom software? Either of those will cost money (i.e., cancelled bus routes or closed subway stations) for no defensible reason.

25. User testing is contradictorily defined. As written, unlimited test sessions (never fewer than two) must be carried out at the vendor’s expense until every single bug is squashed. And the company has to “host” 12 to 50 people at least twice. (At-home testing, while permitted, will be no panacea here.)

    Since the contract virtually bans subcontracting [on re-rereading, I find I’ve exaggerated here], TTC has materially limited the number of otherwise qualified developers and designers who can bid on the contract. Responsible vendors will defy the near-total exclusion of subcontracting and propose that user testing be carried out by a third party (though they may sneak it in under “[r]esearch surveys associated with public beta test”). They’ll also limit testing to two rounds. It can’t go on forever.

    Additionally, the author of the outside accessibility audit has, as written, a complete veto over every feature on the site, and the vendor must do exactly what that author says.

26. “Web accessibility” is seriously misdefined. Web accessibility is about people, not things. Not all people with disabilities use “a wide range of user-agent software and devices,” and making a new site work in devices does not mean it is accessible to people. The entire paragraph implies over and over again that this is about making a site work in IE6 and Jaws. That is a misconception. It is also at odds with the TTC’s misguided requirement for built-in text-to-speech. If I’ve got Jaws I already have the speech output I need; it’s nobody’s business but my own.

27. The Americans with Disabilities Act is named thus (not “American”) and has no bearing on anything in Ontario.

28. The RFP does not make any provisions for accessibility of any “[a]udio/video tour” of a station. (Is Queen’s Quay Ferry Docks a “station”?)

29. The RFP says nothing about microformats.

I filed a separate objection to the demand to work on spec.

More on the tender documents

I have them. I’m not going to copy or scan them for you (I don’t have a scanner, and I wouldn’t do it even if you bought me one). You can’t come over and look at them. You have to do what I did: Buy them.

Apart from me, as of today the following have copies: Kathy Krywicki, Nortak Software, Ottawa (not Norpak); Tyler Johnson, Solstice Solutions, Toronto.

But there’s more

There’s a separate RFP for an Internet trip planner. (The deadline? “9/11.”) I will give you the deficiencies I filed (which, unlike the other ones, were acknowledged). Items like “Gen-req-05” are section designations.

1. The most serious omission in this RFP is any discussion of Web standards and accessibility compliance. While one hand of the TTC is carrying out an RFP for a new standards-compliant and accessible Web site, the other hand publishes a much more lucrative RFP for a system that could spit out tables and frames à la 1997 (and à la the current TTC site). The integrity of the entire Web site will be undone if the trip-planning component isn’t producing the same quality of code. I cannot emphasize enough how likely it is that, without an explicit requirement, what vendors will do is charge TTC six figures for a system that spits out tag soup.

   As an example, Int-req-27 requires the ability to insert sudden schedule updates into a “bulletin box.” Back-end systems are notorious for despoiling perfect HTML pages by inserting tag soup via these methods. Nor does the RFP explain which methods will and will not be permissible, again inviting the use of frames and tables.

   In particular, inducing the respondent to list “minimum customer system requirements” and “compatible browsers and operating systems” (also at Gen-req-07) is antithetical to Web standards and accessibility. People will come at your site with devices you’ve never heard of (some that haven’t been invented yet), with devices you know about but never test on (like Safari on Macintosh), and with devices that only people with disabilities use. TTC implies that it would accept 1997-era Web-development practices in which the trip planner is “optimized” for exactly one browser (always IE6 on Windows) and simply will not work on anything else.

   I personally would not want to have to defend against the ensuing human-rights complaint.

2. OS X is OS X and not O/S X. And it’s pronounced ten, not eks.

3. There is no discussion of microformats, which are of particular use in transit applications.

4. Several lengthy sections of the document are repeated, for no apparent reason.

5. It is rather alarming that the future workstation complement still sticks TTC employees with the most impoverished browsing platform in current use, Windows + IE6. How exactly are TTC employees supposed to test the trip planner when they’re running the worst equipment in common use – and equipment, moreover, that at most a bare majority of outside Web-site visitors will also use?

6. I am not sure why TTC doesn’t know this already, but computers these days rarely (and, on Mac, never) come equipped with floppy drives. The included 3.5” floppy disc will be an unusable relic for many or most respondents.

7. I assume you meant Relational Database Management System, not Rational (green pages). (Also Node Pattern, not Patter. Oh, and Training, not Taining. And additional, not addition.) I am not clear as to why so many typos were permitted in a legally binding contract.

8. The RFP makes no mention of an overhaul of the information architecture of Infoposts, which presently show bus and streetcar schedules in a format completely incomprehensible to anyone who isn’t a TTC insider. (They’re also extremely difficult to typeset or output in standards-compliant HTML.) The RFP brushes off such a concern by stating that Ventura (not a person running it, just Ventura) “formats the file… in proper columns, fonts etc.” The columns and fonts you’ve got now are the problem.

   The RFP contemplates producing up to 7,200 more Infoposts, which means we’d have 10,000 incomprehensible schedules, not 2,800. Nor is there any provision to repair errors, such as on error-strewn Infoposts the TTC has known about for years, 31 Greenwood at Queen.

9. Does TTC really insist that output be compatible with that early-’90s desktop-publishing application, Ventura Publisher? TTC elsewhere suggests creation of native Ventura files. Isn’t that file format proprietary? Why doesn’t the RFP contemplate the exclusive use of published file formats, like XML? And why in the world aren’t you using InDesign yet, which, among other things, can import and export XML?

   More specifically, the flowchart at §19.1 states that the output format of first instance is .txt. (Which character encoding?)

   You are outputting completely unstructured data at that point, which is only marginally more desirable than no data at all. Just as an example, what time does “7:30” represent? That’s plain text and it would pass muster as the RFP is currently written. You want marked-up or structured data, not plain text.

   Also, the last people I’d want converting text to HTML is the City of Toronto. They haven’t even hit 1997 yet.

10. The definition of “accessible stops and routes” uses unnecessarily outdated, also inaccurate, terminology. Wheelchair users are not “bound” to their chairs (do they sleep in them?). Accessibility in the transit context is about more than just wheelchairs. (Ask David Lepofsky.)

11. The RFP seems to imply that the concept of “board period” will be presented to the general public as though it meant something to them, which it doesn’t.

12. The concept of walking times appears to exclude anyone with a mobility impairment. I am not suggesting that the proposed system take every option into account, but the system must be upfront that it is talking about walking times for nondisabled people (in point of fact, fit nondisabled men during fair weather).

13. I see no provision for error correction or synonym lookup. If I enter “the loblaw s on dupont” or “327 colege w,” the system should know what I meant. In fact, the range of possible inputs is much larger than the RFP comprehends; it acts as though everyone were reading from a playbook and copying exact entries as already extant in the TTC’s database. [The requirements read like a carefully-scripted demo in which the only inputs are known in advance to exist in the database and are typed exactly right.]

14. Gen-req-05: What happens when buses take over a streetcar route?

15. Gen-req-14: How are “wireless Internet devices” and “mobile data terminals” different from browsers? Does TTC believe that no one will attempt to use the trip planner from a cellphone on day one?

16. Inf-req-30: Why would short turns be listed on an Infopost or anywhere else, given that they happen ad hoc on the street? Additionally, short turns are the cause of much dissatisfaction (they’re how TTC cooks the books to make vehicles appear to be on schedule) and are not the sort of thing people want in their faces.

17. Ext-req-33 perpetuates the notion that printing from a Web site requires some separate object, like a print-friendly page or a PDF. We just use print CSS and it happens automatically. Also, the RFP does not discuss the unpopularity of PDFs or the fact they have to be tagged for accessibility. Nor does it discuss the need for strictly monochromatic output (with a white background) to avoid depleting ink cartridges. (Print out the current subway map and see for yourself.) PDF will not be an “Adobe” format for much longer, either.

18. Ext-req-37: Doesn’t that imply full UTF-8 or -16 usage throughout the entire system, and complete internationalization for right-to-left-writing languages?

19. Ext-req-43 is perhaps most worrisome of all, given that it collapses Web accessibility onto “functionality for the visually impaired.” Even if the system met that goal, which would involve a lot of smoke and mirrors from clueless vendors, the rest of the Web site has to meet WCAG Priority 2, which is not about blind people only.