Requirements for TTC Web redevelopment

I complained for weeks that the TTC is a billion-dollar corporation but we aren’t, so we shouldn’t be doing free work for them. Then we had TransitCamp and I pretty much got outvoted. In for a penny, in for a pound.

The RFP for the redevelopment (it isn’t just a “redesign”) of the TTC Web site has not come out yet. It’s not too late to put a few ideas out in the open for everyone to work from.

Must-have features (immediate)

Features that have to be up and running on the day the new site goes live.

1. A blog with RSS, with room for separate additional blogs
2. RSS (preferably valid Atom) for other features to be determined. (Set this up so we can just duplicate and edit templates to create new feeds)
3. A way to show sudden or unplanned schedule changes (as happened on Friday the 13th due to a homicide; TTC screwed it up completely). Do so on the homepage and on every relevant schedule page
4. A way to show ongoing schedule changes (like the Dundas streetcar diversion) that changes from time to time so that people do not develop banner blindness and skip over it completely
5. Human-readable URLs, which may never end in a file extension for HTML pages
   • Every URL on the system has to be easy to dictate over the phone, must be as short as possible, and must use real words and numbers (with exception to be noted)
     • There is no need to redirect URLs from the current site, as not a single one of them is worth saving
     • Predictable mistypings must be handled intelligently:
     • Lawrence North should ask “Did you mean Lawrence, Lawrence East, or Lawrence West?”
     • yonge & bloor, SHEPHERD, Broad view have to resolve to the real station names
     • Confusable route numbers (510 and 501) have to be resolved
6. Online contact forms and instructions

Must-have features (eventual)

Features for which room must be made at the outset even if we haven’t figured out how they’re going to work yet.

1. A trip planner (using map data the TTC is developing in-house at great expense)
2. E-commerce of various sorts; here the URLs don’t have to be human-readable, but it should be possible to bookmark an E-commerce page using a short URL, perhaps one that uses randomly-selected words (ttc.ca/buy/equal-hearts)
3. Podcasts

Web standards

1. The entire site, save for exceptions listed below in several sections, must use valid, semantic HTML 4.01 Strict
   • No, not XHTML. There will be too many cooks stirring the broth after the Web developer leaves. HTML Strict is much more permissive than XHTML; simply allowing for deletion of end tags and use of mixed case will allow the code on the site to retain its high quality longer
   • Yes, valid HTML
   • Yes, semantic HTML, but we know that reasonable people may disagree on edge-case markup
   • Exceptional pages (for example, meeting-minutes pages, which are exported from noncompliant applications like Microsoft Word) may use a Transitional document type and don’t have to be valid when first posted. (In any rational maintenance plan, somebody would go in later and fix the HTML, and I’m not willing to get all upset about a few documents that present invalid HTML for a few days)
2. The developer must demonstrate how the principles of progressive enhancement are obeyed – in particular, how users of advanced browsers will enjoy a better experience than users of inferior ones. (The latter does not limit itself solely to standards-compliant features, but may include CSS3)
3. Print CSS must be available for all pages, and must reduce or eliminate the use of graphics and colours (pure black printing of text is desirable almost always). Certain illustrations, like photographs and maps, may naturally retain their original colours
4. All primary functions of the site must work when a combination of JavaScript and CSS are turned off together
   • Developers need not worry about scenarios in which the only things turned off are JS individually or CSS individually, since, in the real world, that happens only with seriously broken browsers that no reasonable amount of work can accommodate
   • Some advanced features may depend on JavaScript, but have to work with existing adaptive technologies. (That doesn’t mean they have to use the same input methods, e.g., to pan a map image. It merely has to work)
5. Unicode encodings only
6. Use microformats whenever possible
7. No Flash unless absolutely necessary. (This is not a time to defend the hypothetical user-friendliness and accessibility of Flash. This is a time not to use it unless you have to)

Accessibility

1. Rational, informed compliance with WCAG Priority 2, which, I emphasize, requires valid code. (The site will not claim to conform to it, as such claims are unhelpful and often untrue, but will genuinely do so behind the scenes.) Some exceptional pages (as above) will comply only with Priority 1 until their initially-poor HTML is repaired
2. A page giving help on accessibility of the site, which must offer different colour schemes and, if necessary, different column layouts, but need not include font-resizers (solely a browser issue)
3. Unambiguous differentiation between accessibility of the site and that of the transit system
4. A standards-compliant means to include sign-language or other videos (if necessary, by using a custom XHTML document type)

Languages

1. Every part of the system, even text in images (undesirable, but almost inevitable), must be adaptable to other languages. That includes making buttons, navbars, and everything else work if their text lengths become much shorter (Chinese) or much longer (German) than English originals
2. At the very least, the homepage, contact and help pages, and individual pages intended to be written in right-to-left languages must work perfectly in those languages, leaving no impression at all that the page ever had a left-to-right form. (Additionally, font sizes must be carefully matched)
3. A plan for proofreading and user-testing of all translations

User testing

A plan for a user-testing program, to be funded separately, that includes:

1. The general population, however defined
2. Seniors
3. Infrequent riders
4. Out-of-towners
5. Disability groups
   • Blind and/or low-vision (may be two separate tests; cannot rely solely on CNIB for test subjects or any help)
   • Deaf and/or hard-of-hearing (may be two separate tests)
   • Mobility impairment (related to Web usage, as with hands and fingers)
   • Learning disabilities (possibly only certain defined disorders)
6. Assume two rounds of testing for some of these groups (i.e., one group finds a serious problem, we fix it in a new build, and we re-test solely with that group)
7. Allow for informal testing by everyone during a public beta period

Browser testing

Plans for:

1. Testing on all current browsers reasonably capable of rendering a standards-compliant page on Linux, Macintosh, and Windows platforms
   • Testing must include any accessibility options built into the browser and must account for font sizes two increments below the default and five above it (not from two to five, just those two discrete points)
2. Testing on handheld devices
3. Testing on video-game consoles

Prototypes

1. Shortlisted developers will be paid to produce exactly one prototype design each, which remains the developer’s property unless and until it signs a contract with TTC
   • No, we won’t make you produce more than one design
   • No, we don’t try to seize ownership of your work
   • No, you won’t have to work for free
   • The term “prototype design” is intentionally vague, but must include screenshots or visual mockups and at least one fully-functioning HTML/CSS/JavaScript page with bulletproof markup
2. All developers submitting bids must, however, explain their design process and, in addition and in specific detail, explain their design intentions for the TTC project (minimum 750 words each)
3. Only shortlisted developers have to produce a design. All developers must be able to prove they have a plan for design

Maintenance plans

The winning developer will not get a maintenance contract and shouldn’t expect one. They’re a drain on both parties, not to mention a drag. Instead, the winning developer must create plans for:

1. Training TTC staff to maintain validity, standards compliance, and accessibility, even while using validity-, standards-, and accessibility-hostile software like Microsoft’s
   • Will almost certainly include producing written manuals in various forms (for separate payment and after initial launch)
   • Converting noncompliant documents (e.g., Microsoft Word files) to valid, semantic HTML
2. A replacement for PowerPoint
3. PDF accessibility and remediation
4. A test suite of hardware and software to be permanently located inside the TTC
5. Unforeseen future platforms: When somebody invents a new YouTube, MySpace, or Twitter (which is going to happen), how should TTC respond?
6. Separate creation and publication of microformats for public transit, including accessible transit (both the accessible portions of a mainstream system and paratransit)
7. A replacement program for TTC staff browsers (currently mired at IE6 on Windows without ClearType, the worst possible browsing environment)
8. An eventual kiosk mode
9. An API for functions as yet unknown, but certainly including delivery to handheld devices and to displays inside subway stations and at transit stops

Additionally, for separate publication (as at A List Apart) and for no additional fee, the winning developer must document and explain the redevelopment process so other transit agencies and developers may learn from it.

Incorporation of PAS 78 recommendations

The famous Publicly Available Specification (PAS) 78 (q.v.), “A Guide to Good Practice in Commissioning Accessible Web Sites” is still downloadable for free) and lists, at Annex C, a top-notch set of “suggested questions for suppliers” (excerpted):

• Describe how your solution will meet the accessibility targets as outlined within our accessibility policy
• Provide an explanation of how your process will deliver an accessible design
• Describe how you will validate early designs with users, including disabled users, and how feedback will be taken forward within your design process
• If your solution includes a packaged application that generates Web pages, describe how your proposed package will ensure [that] generated Web pages meet accessibility targets
• Describe any scenarios where the package application will not generate complaint WCAG [Priority X] Web pages and what will be done to correct [it]
• If rich-media formats will be used, describe how these formats will be made accessible
• List the usability-testing techniques that are appropriate for this project and describe which standards will be followed and what measurements will be taken
• Describe the process for correcting designs and code as a result of accessibility testing

Why so many requirements?

The list above is tough but fair. No more than one or two items will come as a surprise to any qualified standards-compliant developer. Any more than that and you are in no shape to bid on the project (and you are, moreover, possibly an employee at Cyberplex). If you have to sit there and Google half these concepts, or if you can’t figure out how the hell to make them work with IIS and IE6, or if you think you’d need at least four tables to lay out a page like that, well, you shouldn’t be in this business (and are possibly a Cyberplex employee).

These requirements are only barely in excess of the really quite solid Dutch-government accessibility requirements (original documents and response), which, with minor quibbles, represent the current state of the art.

I would be very interested to see a case made against any of these requirements, very much including the obligation to use HTML Strict for new pages rather than XHTML most of the time. (If you think XHTML is newer and better, well, as the saying now goes, you must be new here.) If you think I’m wrong about any of the foregoing, I predict you will have a tough time proving it.