|
The San Francisco Bay Area Rapid Transit (BART) trains were rolling efficiently, but customers were derailing on the Web site. BART figured out what users wanted, and gave it to them.
March 12, 2002
URL:http://www.drdobbs.com/from-complaints-to-awards/184414506
In the late '90s, a lot of people who rode the train in San Francisco and the East Bay area were getting lost. Not on the trains, but on the Web site for the San Francisco Bay Area Rapid Transit (BART) District. BART was receiving complaints, questions, and suggestions about its Web site (www.bart.gov) and was prepared to make some changes.
BART runs automated electric trains on 95 miles of track, and serves over 3 million people in one of the most Internet-connected areas in the country. According to a poll conducted by a local advocacy group, the Bay Area Council, 72 percent of Bay Area residents use the Internet, compared to a national average of about 59 percent.
"Our customer base includes a lot of savvy Internet users," notes BART Webmaster Timothy Moore. "They come to our site expecting something comparable to Amazon.com or Yahoo. We need to meet those expectations to achieve the business goals of the site."
BART wanted to redesign its Web site, and its main goal was to improve the site's usability, giving people easier access to train schedules, fares, station locations, track work, future plans—whatever people might need to know to ride the train. As a government agency, BART also has legal accessibility requirements for public information under the Americans with Disabilities Act (ADA). Finally, the agency wanted to make schedules available on wireless devices.
"The version of the site that we were running had been built in early 1998, before we had significant numbers of Web customers," says Moore. "It reflected how we saw ourselves from the inside, not how our customers [saw] us."
However, traffic skyrocketed in the late '90s, growing 100 percent per year until, by 2000, and the site was getting more traffic than it could handle. Customers had access problems during peak periods when thousands of users tried to plan BART trips simultaneously.
One 1998 PC on Windows NT 4.0 struggled to keep up. The PC was running Microsoft Internet Information Server (IIS), and a Microsoft SQL Server database to hold scheduling information and other data for the site. A 1998 version of Allaire's ColdFusion (now owned by Macromedia), generated HTML pages based on the data in the database.
The number of pages that needed to be updated regularly was growing with the site. Except for two sections of the site—job postings, and agendas and minutes for the board of directors—all content was emailed to Moore, who put it into templates and published it (sometimes working with a contractor). This one task was eating away about half of his time.
For pages relating to job postings and board agendas and minutes, people in appropriate departments submitted content via ColdFusion, which generated the pages. This decentralized approach was clearly more efficient than funneling everything through Moore, and the process needed to be implemented for other pages. However, the aging version of ColdFusion could barely handle its current load. The site needed an efficient content management system (CMS) in short order.
Thus began a research and strategic planning initiative to decide how best to address the problems. About 25 stakeholders were involved within BART. These were mostly content managers, with one or two people from each of several different business units—including public relations, the district secretary's office, human resources, several planning groups, and marketing (the department ultimately responsible for the Web site).
Planning for the back end and the user-facing aspects of the site proceeded simultaneously. One element of the research involved finding out what customers wanted. BART prioritized thousands of email suggestions, looked at log trends to find out what customers were and weren't using on the current site, conducted focus groups, and asked for people's reactions to various user interfaces. All of this information eventually informed decisions about the design and site organization.
Formalizing and quantifying this research was important, because each internal stakeholder naturally believed that his or her area of concern should have priority on the home page. Clearly some compromises were necessary. Decisions had to accommodate the site's customer-focused mission.
Web log analysis, polls, focus groups, and email comments showed that riders were coming to the site primarily for scheduling information. A lot of their frustration stemmed from the fact that the scheduling application wasn't on the main page, and it wasn't crystal clear from the navigation system how to reach it. Figure 1 shows the current homepage. The schedule planner is the only function that's directly and immediately available.
Other items, dear to the hearts of various departments (including marketing), are represented by brief teasers and are a click away should one catch the customer's eye.
On the back end, BART considered implementing a heavy-duty CMS from a vendor like Interwoven or Vignette. However, it determined that the CMS products available in early 2000 were overkill for its needs.
"BART is firmly ensconced in the middle market," says Moore. "That's a market that is just now catching the attention of the big CMS companies."
BART might have selected an off-the-shelf CMS tool aimed at the middle market, had one been available. Instead, BART decided that a custom solution based on standards like JavaScript and Active Server Pages (ASP) would be more cost-effective initially, and entail less maintenance over the life of the CMS.
BART selected San Francisco Web developer 415 (www.415.com) to do the work. On the front end, 415 proposed a new display engine based on ASP, JavaScript, DHTML, XML, and XSL. (DHTML is used only for navigational elements, not for content. Therefore, it doesn't play any role in the CMS.) On the back end, 415 proposed a new CMS, based on ASP, JavaScript, the SQL Server database, and a little bit of Perl scripting.
415 started talking to BART in April 2000 and began intensive work on the site in August. Over the life of the project, the core development team at 415 consisted of six to eight people. It took around nine months to complete, with the internal launch taking place in April 2001, and the public launch in May. However, 415 continued to flesh out the CMS, adding new forms as late as July.
BART decided to partner with managed hosting provider DellHost, headquartered
in Round Rock, Texas. "They offered us a fully managed custom configuration," notes Moore. Many of the other hosting providers offered cookie cutter packages, and the BART team decided it would be difficult
to work within those constraints. "We
have total control over all of the boxes," Moore says.
The machines reside in a data center near Vienna, Virginia. Thus, if a disaster such as an earthquake strikes San Francisco, BART's servers are well out of harm's way.
Now that the new system is in place, updating the site is much more convenient. The process of changing Web site content begins when a specific BART business unit writes a newsletter or announcement in Microsoft Word or Adobe's PDF format. Content managers then use dynamically generated browser-based forms and menus to add and remove Web site pages, update navigational elements, upload files, and cut and paste content into the CMS.
Individual files (like PDFs or GIFs) are uploaded to the Web server and handled like any other file under NT. Text is usually cut and pasted into forms and stored in a database. Some page elements are also stored in the database or as separate files under NT.
When a form is required, server-side JScript in an ASP page reads all the attributes of the form from a database table and builds the form dynamically. As the user makes changes, the changes are temporarily saved to the database.
When the user is ready to preview the page, server-side JScript in an ASP page creates an ActiveX Data Objects (ADO) recordset with all of the data necessary to create the page. The ADO object saves the data to an XML object, which transforms it via XSLT into a temporary HTML file on a staging server. The fact that the user is only changing the raw content, while the presentation format is determined by the XSLT template, ensures that all pages conform to site style guidelines.
The user can edit and preview any number of times without submitting. At any point in this process, he or she can hit Cancel and all of the changes in the database will be erased. Once the user submits, changes are saved to the database, but aren't published on the staging server right away. The user can log out, and someone else can come and review his or her changes or do more editing.
During this process, changes reside on the staging server. The production server runs a previous version of the page. There is some simple workflow built into the system, to show when a section has been modified, and to let certain users publish sections. It also requires that sections be approved before they're published.
When the employee with proper authorization decides that it's time to publish—that is, to move the information to the production server—he or she goes to the publishing module and initiates the action. The CMS determines what has been updated and publishes the necessary pages.
Publishing is initiated by section, such as Stations and Schedules, Tickets, Rider Guide, and so on.
All connections take place through Secure Socket Layer using a tunneling protocol and other security procedures. Permissions in the CMS are based on usernames and passwords assigned by Moore and stored in the database.
This system makes it possible to decentralize and delegate authority for updates, while still keeping tight control over style and content. As a result, updates happen in a timely manner, without Moore's aid.
Although this system allows timely updates, there is currently no real-time
information on the site to notify customers about service delays. BART train schedules typically change less than once a year, and BART doesn't operate 24 hours a day, so track work and maintenance can be performed during down hours and seldom affect schedules. However, users can register to receive email notifications of schedule changes.
One of the biggest challenges for 415 was to create a flexible and extensible CMS. They did this by putting much of the functionality in generic JScript modules, which weren't specific to the task at hand. This had the added advantage of making the code reusable in other projects. In addition, they separated the display engine cleanly from the CMS.
The underlying database structure also had to be extensible. Even though it was based on previous work, the database design was a lengthy process, taking about a month. The team attributes much of the project's success in their care in perfecting the crucial database infrastructure.
Doing that required a lot of communication between 415 and BART. Because so many people were involved on both sides, there was a tremendous potential for confusion and crosstalk. The companies addressed this problem by limiting cross-team communication to 415 producer Leslie Bamburg and Moore, a rule that Moore says made the whole process move much more smoothly.
BART paid a lot of attention to accessibility considerations when developing the site. For instance, it included a text-only site for people whose computers couldn't handle graphics. The CMS publishes the graphical and text versions of the site simultaneously.
The text-based site conforms to the highest accessibility level (Triple-A) of version 1.0 Web content accessibility guidelines published by the W3C (www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html). Even the graphics-based side conforms to the lowest W3C accessibility level (A).
Another aspect of accessibility was cultural accessibility, namely, making at least a limited amount of information available in several languages other than English—including French, German, Spanish, Italian, Japanese, and both traditional and simplified Chinese.
BART also wanted to enhance accessibility by providing access to scheduling information via various types of devices. BART commissioned Oakland, CA Web and mobile developer Bear River Associates (www.bearriver.com) to create a scheduling application that users can download to a Palm PDA.
The biggest challenge in creating the Palm application was compressing the data to run on the low-powered Palm device. In the server application, the scheduling database is about 2MB. Bear River managed to reduce that to about 16KB.
"There was a lot of regularity to the data," explains Bear River Senior Consulting Engineer Jim Morris. For instance, trains typically run at regular intervals, perhaps with one interval for peak and one for
off-peak hours. Just as with ordinary file compression, more repetition means more potential for compression. The special rules for bicycles created a modest challenge. In addition, BART's grand meet policy—which says that you should be able to take the last train out of any station and arrive anywhere in the system—proved "interesting" from an algorithmic perspective, says Morris.
Reducing the database to 16KB meant Bear River could implement the entire application, including the executable, the database, and a bitmap of the BART system, in under 160KB. Zipped, even including 20K of user manual and license agreement, it's just a 75KB download. The development was done in C++, using Bear River's open source framework for the Palm, "paf" (www.bearriver.com/developer/palm).
Bear River also created some utilities for people who manage scheduling at BART, to make it easy for them to update schedules.
The whole development process lasted about twelve weeks with two people working on it, Morris and Senior Consulting Engineer Alan Clute.
All of these new features meant a system overhaul as well. Today, the site is hosted on two Dell PowerEdge 2450 Web servers running Microsoft Windows NT 4.0 and IIS, and two Dell PowerEdge 2450 database servers running Microsoft Windows NT 4.0 and SQL Server. Each server has two 866MHz Pentium III processors, two 10GB hard drives in a RAID 5 configuration, and 1GB of RAM. A fifth server is dedicated to log storage and analysis.
The entire project so far, including planning, hardware, software, development, and hosting, has cost about $250,000. What return has BART seen on this investment?
Since the April 2001 launch of the new site, BART has seen an impressive 60 percent drop in email and help-desk calls relating to the site. Questions about navigation or how to use the site are rare, and comments are now weighted more toward compliments than criticisms.
Another good sign is traffic growth, which continues to increase by 100 percent a year, despite plateauing growth in Internet use and a weakened economy (which adversely affects ridership because fewer people are working). People are spending 30 percent more time on the site too, putting the average visit in the eight-minute range.
Online job applications have increased significantly, as well. More than 60 percent of applications come in over the Net now, a 20 percent increase. This creates several internal efficiencies in areas such as data entry and postal mailings. Finally, traffic in news and features sections has increased nearly 25 percent, in part, Moore believes, due to the teasers on the homepage.
And customers aren't the only ones who have reacted well to the site overhaul. 415 received a Standard of Excellence WebAward for its work with BART. In October 2001, BART.gov was honored as the best public transportation Web site in the nation by the American Public Transportation Association.
BART doesn't plan any immediate software
or hardware upgrades to improve the performance or reliability of the existing system. It is possible, however, that an off-the-shelf CMS package will eventually replace the current custom one—possibly in as little as two years, says Moore, depending upon BART's needs.
Even 415 is shifting away from building custom CMSs as a company focus, because it recognizes that there are now several good ones on the market at reasonable prices.
BART is also looking at expanding its customer relationship management (CRM) capabilities to give customers a more individualized experience on the Web site. Research into CRM is just beginning, however.
Another possible enhancement is support for real-time information. "We're still at the research phase when it comes to real-time information," says Moore. "We have to make sure that we're delivering something that customers will use."
To that end, BART is looking into a few options for delivering real-time information, many having nothing to do with the Web. These include: telephone-based automatic voice recognition (AVR); short-range AM radio broadcasts in stations, similar to systems used in Federal parks; short message service (SMS) that would send short text messages to a variety of devices, including cell phones; Wireless Application Protocol (WAP), which would allow Web access over cell phones; and even old standbys like email and instant messaging.
Real-time information could cover not just delays, but information like construction in a station, or an elevator that isn't working.
One hopeful direction that BART has
put on hold for the moment is WAP. "The penetration of WAP is a lot less than we anticipated," says Moore. BART's research shows that people tend to buy a WAP phone and initially think it's great, but then quickly become disenchanted by the limited choices in content and awkward UI (for example, the tiny screen and keypad).
BART is monitoring Pocket PC 2000. However, research conducted in August
2000 indicated that, although one in five BART customers owns a PDA, 70 percent of them are Palm devices. So for now, BART's plans focus on the Palm device.
"We target consumers, and the Pocket PC doesn't seem to be playing in that space," notes Moore. He adds that the Palm may continue to be the consumer PDA of choice, given its expanding capabilities and falling prices.
While BART continues researching possible improvements, 415 and Bear River Associates are working jointly to integrate the scheduling applications that Bear River created with the one that 415 adapted from the previous site. Currently, the Web application and the Palm application use two different algorithms to build schedules and plan trips. In the future, both will use the Palm application algorithm. A single ActiveX control, to be developed by 415 using Bear River's algorithm, will manage scheduling on the Web site and build the database for the Palm application. In fact, it will even provide input for the Quark page layout program for print-based publishing. Testing was expected to begin in mid-March.
Finally, the Web site will need to accommodate BART's planned service expansion to the San Francisco International airport, the nation's fifth busiest Airport. The project will add 8.7 miles of new track and four new stations, including one located inside the new international terminal. Scheduled for completion this year, the extension is expected to have a ridership of nearly 70,000 per year by 2010. It will radically change schedules. For a while, it will require BART to have two sets of schedules available—one with the current routes, and one with the planned routes. New software to ease the shift should launch in the second quarter of this year.
Michael is a freelance writer based in East Sound, Washington. Contact him at [email protected] or visit his Web site at www.hurwicz.com.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.
Solutions
How It Works
Content Management
Accessibility
Palm App
Hardware
Return On Investment
Future
