The best design journal... ever??

CSS and AJAX and Web 2.0 oh my

Sunday, May 07, 2006

BART maps

Another example from the thrilling world of transit signage!

The recent BART extension saw trains running south to SFO and Milbrae, where it connects with Caltrain. This service has had trouble, and the scehdules have been shifted around a lot so it won't lose so much money.

In some cases, the schedules have become rather complicated. At peak and non-peak hours, there may be different lines available from Daly City to Milbrae and SFO. One problem that arises is visually representing these schedules in a simple, descriptive format. My photos of maps on the trains didn't come out too well, but I cribbed some details of the various iterations of the maps off the Web:


The initial version shows an example of a variable-length line: only during peak hours does the red line extend past Daly City. This doesn't seem like a big impediment to usability, because the information is clearly presented, and the information is also presented in other formats, such as the signs in the station indicating which destination each train is headed for.


Number 2 extends that concept to two lines, which trade off service during peak and non-peak hours. This isn't too, too confusing, except the user has to recognize that only the routes marked by the diagonal lines are affected by the peak changes. What's more confusing about this presentation is that it implies there's a big loop in the BART tracks. In fact, as far as I can tell there is no such loop, nor is there any direct route from San Bruno to Milbrae that does not go through the SFO station. This does not make the map unusable, but it's sort of problematic to misrepresent the track this way.


The third iteration has a different approach to modeling the track. Unlike any of the others seen here, this map accurately reflects the fact that the tracks do not gracefully loop through SFO – instead, they take a sharp detour into the the station to get there, and take another sharp turn out. This makes the conceptual model implied by the map more accurate than the second map – but is that really any use? Really, it doesn't seem to me that the user gains from knowing more details about the track alignment, so this is a seemingly irrelevant change.

This iteration does away with all the peak/non-peak rules, which is nice because it means less information on the map. However, it adds a new purple route for some reason, which tends to increase the overall complexity. There's also the matter of no one ever riding the stupid thing, but that might not be a design issue so much.

4) (current configuration)

Unlike all the others, the final version shows basically a conventional line, with no special features. The extension has been simplified, and switched to a less busy line, so the system will stop hemmoraging money. I think this model feels more natural than the others, because it doesn't have a bunch of weird rules and complicated networks. It also doesn't misrepresent the track layout too much, though it fails to reflect the fact that Milbrae is actually very close to SFO. Overall I'd argue this is a pretty good combination of realism and comprehensibility.