Solutions
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.
How It Works
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.
