Work on the future Silver Spring Transit Center has progressed to the point that it has actually begun to look like a bus terminal, and I eagerly await its opening. Soon (hopefully), work will start on fitting out the interior of the transit center, including signage and information systems. The transit center will serve major bus operators like Metrobus and Ride On, as well as smaller operations like Shuttle-UM. The transit center will also provide access to Metrorail, MARC, a new Greyhound terminal, and the future Purple Line. And while the distinctions between these agencies may be perfectly clear to transit nerds, for the average passenger, a bus is a bus. So, one of the important things to get right for the transit center is a uniform signage and information system. We want to avoid another situation like what exists at New York Penn Station, where there are three distinct and disjoint signage systems—one for Amtrak, one for the Long Island Rail Road, and one for NJ Transit. In addition, since almost all of the agencies which will be operating at the Silver Spring Transit Center offer some kind of real-time information, it should be presented to passengers in a consolidated format.

This mockup, from an AMT solicitation, shows the general idea:

It's fortunate that's only a mockup, because the design, information architecture, and typography are poor, but it gets the point across. Instead of being confronted by an array of screens, each one offering information for just one operator, passengers should have a single, centralized, unified source for information on all of the transit options available at the transit center.
So, having established the desired outcome, how do we get there? Once again, the answer is open standards like GTFS and SIRI. For example, WMATA uses NextBus (though not for the full stack, since they OrbCAD rather than NextBus's hardware), while Ride-On is deploying the full stack from Orbital (although there's no public AVL yet). Shuttle-UM uses NextBus, but I'm not sure if they expose the XML API. Either way, the point is that buses from a number of transit agencies, each with their own system, will be serving the Silver Spring Transit Center. In order to provide a unified and seamless passenger experience, information from all of those agencies should be readily available through a single passenger information system. Rather than building a custom system with interfaces for each of the agencies serving the transit center, it's a lot easier if those agencies provide their information (whether real-time or scheduled) using open formats.

Anyway, there's no way for me to be certain that the Silver Spring Transit Center will even be equipped with a decent passenger information system, but if it is, I would hope that it will be built on open standards, in order to make it possible to easily incorporate data from a variety of sources, including the future Purple Line, once it's complete. It's also important to point out that dynamic signage provided by a passenger information system like what is described here is really only one part of a comprehensive signage system. There will be static signage, too, and it must be both competently designed and flexible. One of the more grievous errors made at many bus terminals in the area is to install (very) permanent, custom signage which lists specific bus routes and destinations. While that may seem like a good idea, the reality is that bus routes change relatively frequently, and so you often end up with a mess of out-of-date signage and hand-written addenda plastered on top. The Silver Spring Transit Center will also need a well-designed wayfinding scheme which recognizes the connections passengers will need to make within the transit center and with the surrounding area; it cannot be broken up into a handful of fiefdoms each run by a separate transit agency.