The Toronto Transit Commission (TTC)
Information System

Milestone 5: Prototype
December 1, 2003

Project group:
Natasha Flora (flora@fis.utoronto.ca) and
Anthony Hempell (hempell@fis.utoronto.ca)

Design Problem Addressed

The current TTC site, http://www.toronto.ca/ttc, appears to be a partnership with the City of Toronto. While the site provides information about routes, schedules, policies and the organization, it fails to offer a consistent, intuitive or enjoyable experience for the user. The home page is cluttered with competing graphic links (see example screen shot), the navigation is organized using drop-down menus that hamper the visibility of the site's structure, and the content is presented in a haphazard and sometimes confusing manner. Additionally, it can be difficult to find simple information one might be seeking as often links are poorly named, page content does not match the name of the link to that page, or content is incomplete or scattered through multiple pages.

There is no provision on the current TTC site for an interactive “trip planning” application, which can be found on some other transit sites in North America. A “trip planning” application allows users to enter their starting and end points, and have the system provide transit options based on time, distance traveled, or other criteria. Instead of having to navigate and decipher complicated transit schedules and maps trying to deduce their best route, it gives the user the ability to receive a customized answer to some of the most common transit questions: "how do I get there?" and "how long will it take?"

Our proposal is to redesign the Toronto Transit Commission (TTC) website in two ways:

  1. Redesign the information architecture and navigation structure of the site:

  2. Design an interactive "trip planner" application for the TTC site.

In addition, we are proceeding with the following non-functional requirements and assumptions:
  1. The scope of our work will be limited to information that can be reasonably assumed to be owned and stored on TTC information systems;
  2. Integration with other transit systems will be in the form of hypertext links only; no sharing or migration of databases is assumed.


User Group

The primary users of the system, and the user group whose needs we are focusing on, are riders. Riders include commuters, infrequent users, special events attendees, tourists/visitors, and school groups. Any of these riders could also fall into special categories such as the disabled, the elderly, or cyclists. An important goal of TTC riders who access the website would be to plan a trip. They might wish to know the best route(s) to select, how long a trip might take, the cost of a trip, or the rules for riding the system (for example, a cyclist would want to know at what times of the day a bicycle could be transported on the subway).

Other possible user groups for the TTC site that we are not considering in this report are: employees, media, government or administration users.

Context and Required Functionality

Based on the user analysis we conducted, we identified several rider personas, several scenarios for which they would use the web site, and a number of tasks they would wish to accomplish on the web site. We discovered that users require a clear information architecture and navigation structure to facilitate information seeking tasks such as finding out how to use a Metropass or whether they can bring a bicycle on the subway. Additionally, they require an application which allows them to determine how to get from their point of origin to a destination without any prior knowledge of what transit routes are nearby, route schedules, or where TTC stops are located.

Design Concepts Considered

There were a number of design concepts considered for the content presentation and navigation of the redesigned TTC web site. Whenever possible, all of our design choices were made to maximize accessibility of the site and its content. Following is a select list of the design decisions we made:

  1. Global Navigation – We chose an upside-down “L” structure for the site’s global navigation. We liked this structure because it allowed us space to present the most important features along the top (such as the trip planner and the search function) and to include the comprehensive list of menu items along the right hand side of the screen. We believe this reduced the clutter that would have been found in a structure that listed all menu items along the top of the screen. Additionally, the left-side menu draws a users eye to it more so than would a right-side menu, since English, which is the main language of the site, is read from left to right.

  2. Navigation Menu Features – We considered rollover menus as well as pull-down menus, however decided that there were problems with each of these options. Rollover menus would possibly require more recent browser software and could interfere with systems for seeing-impared or blind users. Pull-down menus reduce the visibility of system status for the user and hamper the reinforcement of navigational cues by hiding options. Instead we chose simple, expandable menus which we believe to be much more straightforward, visible, and usable by most users.

  3. Introductory Category Page – For each main heading in the left-side menu, there is an introductory page. This page provides basic category information, when appropriate, as well as links to the different subheadings (which were also expanded in the left-side menu when the main heading was selected) with descriptions of each of the subheadings. These descriptions are very important in clarifying what is and is not included within a subheading. This clarification will both facilitate the user’s efficient location of the specific information he or she is seeking and save the user time by preventing him or her from selecting an inappropriate link. The user will no longer have to click through multiple links in a sort of hunt-and-peck information seeking strategy.

  4. Design Aesthetic – We considered using Flash or other kinds of multimedia to enhance the design of the site, but instead used HTML. We decided that functionality for all users, regardless of their web-access technology, was more important than a flashy design. In a manner of speaking, we designed to the lowest common technology denominator so that users with older or dial-up systems could use their time on-line more efficiently and not waste it waiting for fancy graphics to load.

  5. Sound – The current TTC uses a sound clip that recreates the “closing door” sound made on the subway. We recommend not using sound files in this manner as they provide little information to the user and quickly become annoying after repeated listenings.

  6. Readability – We were also concerned with accessibility of the site for users with vision impairments and made a number of choices to facilitate their access. To support the use of browser setting to enlarge text to make it more readable we chose to use relative font sizes and not to use cascading style sheets. The flexible screen layout we used, which is based on the percentage of space covered rather than number of pixels, is also helpful in that it allows the user to make use of all available monitor space. Also with the visually impaired in mind, we used text instead of or alongside graphics wherever possible. Doing so facilitates the use screen readers, which cannot interpret complicated information that might be found in a graphic (Theofanos & Redish, 2003). For example, we used a text table to explain TTC fares (see prototype example) rather than the colorful image of the farecard (see example image), which is found on the current TTC site.

    An added bonus of these readability strategies is that they also work in the opposite direction; they facilitate making the site visually smaller so that it can be used with smaller monitors or other small screen areas such as those found on handheld devices.


Nature of Prototype constructed

We have constructed a TTC website prototype which has a comprehensive navigation system, several tiers of content pages, and a featured trip planner function. The prototype allows the user to navigate through the site to find information about a TTC transit pass and to use an interactive trip planner to find out how to take transit to a new destination within the GTA. The prototype includes a global navigation system which directs users to the most appropriate areas of the website for them.

At the highest tier of the site, the home page features useful information, quick access to the trip planning function, and is organized, uncluttered, and inviting to the user. The prototype also includes two second tier pages, the “Getting There” page and the “Fares and Passes” page which guide the user deeper into the website and facilitate access to information in those categories. The “Getting There” page again features quick access to the trip planner function, but also includes a descriptive menu, which facilitates user access to other useful information about how to use the TTC to arrive at one’s destination. The “Fares and Passes” page includes basic information about fares and passes and, like the “Getting There” page, also includes a descriptive menu to guide the user through other information and pages in that category.

Also included in the Prototype are third-tier pages, the “Metropass” page and the “Trip Planner” page. The “Metropass” page provides the user with information about using a monthly pass on the TTC. The “Trip Planner” page, however, is interactive and functions as a search system. It allows the user to input information about his or her origin, destination, date and time of trip, and route preferences. The system, if it were implemented, would use this information to determine several route options for the user. For the prototype, we have built in a canned search (based on a trip from the Annex to Yonge Street) which leads to other tiers of pages – the results page, the results details page, and the return trip page.

Methods used to Evaluate Prototype and Results Obtained

To evaluate the prototype, we conducted cognitive walkthroughs of various processes. The cognitive walkthroughs allowed us to “walk through” the tasks a user would perform enabling us to determine what kinds of problems they might encounter. From the walkthroughs, we found that overall our designs were sound, however there were a few areas which could prove problematic or confusing to the user.

Most notably, we discovered that some of our category names were not as intuitive as we had hoped. For example, “Metropass” as a category name for monthly TTC passes, while accurate in that it is the brand name of the monthly pass, is not intuitive. A user who is not already familiar with the Metropass may not recognize it as being a monthly pass. An easy solution to the problem was to re-name the category using the generic name “monthly pass” rather than “Metropass”. Other examples of names that were not expressive of the service or information they represent included the “GTA Weekly Pass” which we changed to “GTA Multi-Transit Weekly Pass” and “TTC Times Two” which we changed to “TTC/GO Transit Transfers”.

Other problems we discovered using the cognitive walkthrough, many of which involved the Trip Planner results page, did not have such simple solutions. Based on the quantity and detail of the content of a given results page, which would have up to three separate routes with each route potentially having several parts to it (walking to TTC, riding TTC, transferring to other TTC routes, walking to destination, etc.), there was a significant chance that the user could miss or mis-interpret important information. This could happen if the user did not scroll all the way through the results, did not click on the link to look at more detailed information, or in some other way misread the results.

The difficulty in solving the results page problems is that the solution to one problem frequently had a negative impact on another. If, for example, we included more of the additional detail and map information, users would be less likely to miss it by not selecting the link to it. However, it would also make the page longer and more cluttered, potentially confusing the user or making her less likely to scroll through all the results. In building the prototype, we attempted to prioritize the clear presentation of what we determined to be the most important information and creatively balance the negative effects of the problems that remained. For example, we decided that it was important to have an overall map of each complete route included on the main page of the results, as opposed as being just a detail to select. We made the map relatively small, and therefore potentially more difficult to read than a larger map, but made a clear indication that one could enlarge the map by selecting it or an adjacent link. Making the map small minimized the extra clutter and length added to the page but also provided a clearer indication that there was a map than would a purely textual link. This will help to prevent users from missing the more readable version of the maps.

Lessons Learned

From designing, doing cognitive walkthroughs, and building this prototype, we learned a number of important lessons. Most importantly, we learned how difficult it is to manage the information architecture of a site with such a large amount of content. In order to do an effective job of managing such a project, we now realize that it would take a great deal of time and testing to develop a taxonomy and vocabulary that would be meaningful to a diverse range of people, such as the users of the TTC. We also learned how useful a content audit and card sorting exercise can be in creating an information architecture. Using these tools was a convenient way to re-classify and prioritize existing links as well as to add in missing links to content we deemed important. Also helpful for our process of creating the prototype was an evaluation of best practices in the area. We discovered that by examining existing trip planner functions on other public transit web sites (Washington, D.C's.

WMATA and Vancouver, B.C.'s TransLink), selecting the best functions from each site, and adding in our own ideas we were able to design a much better prototype than we could have with our ideas alone.

Recommendations for further re-design of the interface

We have several recommendations for further re-design of the interface. First and foremost would be to complete a great deal of user testing of the information architecture, particularly the categorization, naming schemas, and taxonomies. To complement this process, we would suggest an in-depth content analysis and audit. Additionally, conducting additional user interviews and creating more personas and scenarios would be critical to achieving a usable site. Specifically we recommend exploring the needs and preferences of non-native English speakers who may use the multilingual content, riders with physical disabilities and limitations, riders who live in areas of the GTA outside of the downtown core, users of varying ages, users who commute via TTC combined with another transit system, and tourists.

Our final recommendations are less about site content and more about the Commission’s organizational and information handling practices. From our examination of the website, we have come to believe that many of the inconsistencies and inadequacies of the site may be symptomatic of disorganized information management processes, conflicts in or lack of information ownership, and possibly stakeholder conflicts within the organization. This conclusion is drawn from our experiences of trying to find information on the current site, and experiencing an unusually large number of inconsistencies, errors, missing information and navigation problems. We believe that if a truly functional, comprehensive, well-designed, navigable, consistent and usable site is to be implemented by the TTC, it will be crucial to clarify organizational and web site goals, centralize the design and implementation processes, and commit significant resources to the project.

References

Theofanos, M.F. and Redish, J. (2003) Guidelines for accessible – and usabile – web sites: Observing users who work with screenreaders. Interactions 10 (6), 38-51.