TransitCamp Ideally: Promote Simplicity and Ubiquitousness

Tara Hunt has a post up about TransitCamp (a camp held in about a month at SocialText with the help of Heyward Robinson, Menlo Park city council, Adina Levin, Co Founder of Social Text and avid Menlo Park community activist, Margaret Okuzumi, from the Bay Rail Alliance and MTC).

I love the idea of transit camp to help people who work on those issues do better for all of us. I can't attend but I wanted to throw out a couple of ideas.

I rarely use public transit here in the Bay Area. I use it all the time on the east coast in Boston, NYC and Washington, as well as Amtrak linking the three. And in European cities like Paris, Barcelona, London, Amsterdam, Rome, as well as Euro-trains linking the continent.

The common thread across all those cities is that the interface, and the metaphor, is simplicity and instant access with little mental overhead. In other words, you don't have to know much to use them, other than to find an outlet and get in. Then after locating a map, you buy a pass and unless it's very late (after midnight or 2am depending) or very early (before 6am), you wait a few minutes and your train, bus or trolley shows up. And you're off. And it works from the airports too! Yipee!

The way Bay Area transit works is: you are a commuter, you already know the complicated and dysfunctional system section you use all the time and the rest is a byzantine mess of mismatched numerous connections, so therefore the regular user only will move say, one leg to get where you are going or maybe two at the most. Oh and you are doing this almost exclusively during commute hours in order to have any efficiency at all.

That's not really great.

I have tried to use public transit. And when I lived in SF, I had a flat rate card, took the bus, muni, BART (just within SF) and the trolleys. But even they really worked most efficiently during commute hours, with long waits before, during the midday, and after or weekend times. Though BART was nice if you were downtown and wanted to hit the mission or somewhere else along that specific line, because so many trains go from all over the BA through SF and out again. So there are a lot of options there for constant movement with little planning.

But from Berkeley, BART takes on a different metaphor, often requiring much more planning. For example, to take a train after hours or on a Sunday, you must change trains to get to SF. Recently, my car needed unexpected servicing in Mountain View, so I dropped it at a recommended shop there. The next day, after being back in Berkeley via a ride from a friend, I needed to retrieve my car.

I thought that it would be easy to go from Berkeley to Mt. View, after reviewing the various websites for about an hour or so to plan my trip. So I optimistically hoped on BART at 6pm. The online info said: "Cross-platform transfers at the Millbrae BART Station." So it turns out that my SF bound train from Berkeley didn't go to Millbrae. I had to change. Twice!

I arrived at Millbrae at 7:40pm, and saw a southbound Caltrain. W00t! I ran out, up the three flights of stairs to the overpass walkway, and just then watched the Caltrain pull out. Damn. They don't coordinate! Even as a bunch of people wanted to get on it. They just move out regardless of BART trains pulling in.
No problem, I thought, there have to be more. So I went downstairs to the Caltrain side, looked at the schedule. Which was difficult to read in interface, but said there was a train in 15 minutes. I bought my ticket to Mt. View, after which I waited, as the rain poured. Sideways too. Shelter was three stories up, so the rain and wind were going everywhere (Way to architect public spaces for people waiting for transit! But it looks pretty in the brochures.)

No train came, and I eventually made my way back to the totally unsheltered schedule. I had read the schedule, on paper, with no AM or PM specified, wrong. I had been looking at an AM schedule, so I looked all the way to the other side, where the PM side was. Next train, 75 minutes. So, I'd already waited 20. Wow. So now I really think Caltrain operators are jerks for pulling out when a BART train arrives from the North that might include riders on their train (there were 10 of us and they could have waited 30 seconds for us!).

I waited a while longer, and then called my friend in Mt. View to come get me as I was soaked and absolutely freezing, even with raincoat and umbrella and lots of scarves and things -- they don't protect you from sideways rain much, nor did the shelter 3 stories up do anything at all for us! I just couldn't see waiting another hour for the train, and then having a 25 min ride down there, and then walking in the rain to get my car (estimated arrival that way: 10pm). Actual arrival: 8:40pm.

It took him 20 minutes to drive. And that's my point.

If you plan for traffic, it's 40-45 minutes from Berkeley to Mt. View or Palo Alto, 20 minutes to SF, 25 minutes to San Bruno. I use Google maps with traffic turned on in my phone in the car, for instant planning after the general plans have been made.

My car, instead of hours on public transit, with many connections that are uncoordinated by the many agencies involved, and impossible to pay for in one lump.

I'd rather not drive, but how the heck do you manage my typical day of meetings like say, last Thursday?
AM: 9:30 meeting in the mission, 11am in Cole Valley, PM: 12pm in the outer Sunset, 2pm in San Bruno, 6:30pm in SF for dinner, 10pm in Emeryville, 11pm home. All of which I easily made in the car, but with transit in the BA, I'd have to plan two hours between each meeting and an hour home on the last leg. In NYC, each bridge to the next event would be 15-30 minutes (what I'd planned for driving between each thing I needed to get done).

Or for that matter yesterday: Mt View to San Bruno, then San Bruno to Oakland (on Mandella Parkway), then Berkeley, then Oakland, then Emeryville, then Berkeley, then Emeryville, then Berkeley. All between 1pm and 8pm. So you know, there isn't any option between Emeryville and Berkeley. And nothing between Mandella Parkway and Berkeley either that I know of... it would be a disaster if I didn't have a car.

The metaphor for transit in the BA: you use this already and if you don't, you're screwed. And you use transit during commute hours (like 7-9am and 4-6pm -- yeah.. that really works in the tech community and with all the events we all attend each evening). You have all the payments worked out in advance with monthly transit cards (not great for changing systems though some have recently connected better than in the past).

In fact, BART's own website acknowledges this:

Transit Connections to BART

Free Personalized Trip Planning Service!

We know that navigating public transit connections in the Bay Area can be difficult, that's why we're here to help: If you'd like an accurate, personalized trip plan that includes BART and connecting transit, call our Customer Service Department: it's fast, it's easy, and it's tailored just for you! (Emphasis mine)

In other words, it's so hard, they don't even bother to put the info online. They just have you call them to work out the byzantine system's details.

I'd like to see Transit Camp deal with the broken metaphor, the interface and execution (tickets and money, schedules and websites, mismatched transitions), and the assumption that this all happens during rush hour and otherwise there is no need.

Frankly, if you don't provide much after hours, people won't build it into their schedules. If you do, they will.

For me, Tara's picture in her post and at Flickr is more representative of what I see in the transit experience, where nothing quite works unless you live and operate in SF:

I'd like to see transit work holistically for the whole BA, where you just jump on and go where you need to go, up 'til say 2am. That would get me to leave my car behind. :)

The FAA TRACON Information Experience Live

Earlier today I had the delightful experience of touring the FAA's Northern California TRACON facility.

Basically, TRACON, which stands for terminal radar approach control, is the air traffic control center which, in this case, handles Northern California. TRACON handles traffic outside of each local control tower a plane might ultimately deal with as it lands. There are TRACONs all over the US for other regions. We weren't allowed to bring in cameras so I'll instead show you a news photo from SF gate that was representative of what we saw up on the wall of the facility. You get the idea there of what they are seeing on some of their screens.

Chronicle photo by Mark Costantini

This photo only shows traffic into SF, because it's a visualization from SFO traffic control, but just imagine more planes going into San Jose, Sacramento, and other smaller airports like Modesto. Also, these screens are synced between TRACON and the air traffic controllers who are local. And if anything happened to one TRACON, others would instantly fill in, as the system works somewhat like the internet in that sense.

TRACON is housed in a big, windowless building, extremely modern and cool with an air of serious importance about it (I always find that at say, buildings in Washington DC, and I kind of like it even if they do take whatever it is they do a bit too seriously sometimes). Our tour guide, a woman who is a trainer for other air traffic controllers, at one point said, "You have 10 seconds or so to make contract with a plane and move on. If you screw up, there are hundreds of lives on the line." That's pretty serious.

TRACON's building is basically an octopus design, where each leg has 20 or so terminals with about 10 people in each, manning a particular physical area (like planes coming into Sacramento) in order to follow planes as they enter the region first. All commercial flights must fly IFR -- Instrument Flight Rules -- which means they have to be in contact with TRACON, in case they can't see or there is bad weather, or there is simply a pile up of planes that need to be moderated into an airport. Planes that fly VFR -- Visual Flight Rules -- don't have to contact TRACON, but some do anyway for a variety of reasons. TRACON has longer range radar than the local air controllers, but the longer range radar updates more slowly. So that is the trade-off between regional (TRACON) and local control.

Once TRACON has the plane logged, they make a little block of data on their screens (a different type of screen than the one shown above) that shows the flight number, its altitude, and other information that will help them keep planes apart, on track and moderated as they reach the range of the local control towers who then take over moderating the planes.

In the cycle of life for a controller (who has to quit at age 56 and can not be considered after age 31 to start training), they typically have military training or attend a special school after college, and then are trained at the local site. Our host said that for the first few years (maybe up to 10) controllers are pretty tense on the job, but after 10 years they relax some. She said the most dangerous situations come when people are relaxed, and less is going on around them, rather than more. That's when mistakes are made.

Another thing our host said was that they have to keep the chit chat down, because if there is an accident, they don't want to have some controller chatting away on the transcript, just before it happens. They are pretty businesslike when talking to pilots. She talked pretty fast, she said, due to the edgy situation needed to quickly regulate the flow and placement of all the different planes they are watching, and that's how she trains people. I know from riding in a friend's plane frequently where I can listen to lots of this talk, that they are pretty succinct, and yet both pilots and controllers have a kind of cultural humor that is pretty funny, in those few words they exchange, and this allows some kind of personality to come through often. If you want to check out what happens, here are some example live sound feeds from a bunch of different air control areas.

So.. what were the information systems like? Well, I thought they were fascinating. The premise in building, training for and using them is very different than say, the web based systems I typically work on in my day to day life. In fact in many ways, they had the exact opposite goals and metaphors I use to build systems and interfaces. First, they train their people between 6 months and 5 years on these system -- but our guide said 2-5 years is typical.

Think about that. Training your user for 2 years. What would that mean to interface architecture and design? You could certainly do a lot different with it than what we do now on the web.

Their top menu, interestingly, is literally a series of very-1993 buttons, big squares, in rows, maybe 8 across and 12 down, though all those gorgeous 22 inch screens are touch screens. Each controller has two of them, not horizontally placed, but vertically, in the workspace. Some of those buttons go to pages that help track planes, but I did note one, placed furthest away from the user's sitting position, for that day's cafe menu. It appeared that all possible items were options at the top level. Nothing appeared to be pushed back to a lower level or made less important or secondary in the interface other than two items described below.

When you go into the main menu items, there is little to cue you back, and in fact many of the screens were missing back buttons. Some had them and some didn't. But with that much training before you can even get into a real working station, it doesn't seem to really matter. You know the system inside and out, as well as how and what to do with it and all the planes you have to manage (typically 10 - 20 at one time).

A lot of information is stored in the user's head, and as new plane info comes up, only the abbreviation or shorthand block code describing the plane is on the screen along with various map-based data to place the plane. This means that instead of giving lots of data on one plane on the screen, the data is offloaded to the user and the screen just has the shorthand.

That shorthand for a plane is shown in the middle screen (below the menu in the top screen), which has the map with blocks of data representing planes. Their systems look much like map systems we use online in a way but with way cooler visualizations because they have radar and more info about airspace restrictions and well.. I don't know any web service that has radar. Imagine "Google Radar" overlaid on Google maps? That would be a cool product launch.

So in other words, what the information systems metaphor seemed to be was the exact opposite of what we do in web systems: TRACON systems are built with high mental overhead -- you have to know a lot to use and understand both sets of systems before you start to navigate because nothing in those buttons really helps you know what is below, other than the word on top. During actual use, when you enter and track planes, you get that overhead in the years of training you do before you can operate the system in play. The information systems below those button also have little style that would take any one piece of information and make it more important than any other on the same screen. Information is chunked or grouped a little on those secondary pages, but that's it. So there is no expectation that anything is pushed back or pushed forward, other than the menu, where each little button represents a page/function, and each page has the function represented.

Instead of the software deciding what is most important at the moment of use, and emphasizing it in some formated way, the user just has all of it equally represented and therefore has to decide what's necessary or relevant. In some cases, there was a mini system below a secondary page via a link, to find backup documentation on a plane (if the controller asked the plane to do something, and the plane wasn't built for it, they could check the specs on the plane) or on a small airport (to get backup data on landing strips and landing directions). But these seemed to be relatively rare use cases that allowed the backup information to be lower down to a third level.

Our other tour guide, a man who'd checked us in, did an introduction presentation in power point to explain the basics, and then finished up at the end. He told a couple of stories like what happened on 9/11. He said they grounded every plane everywhere coming and going anywhere in the country. It was eerie, because all their screens (which we were seeing, depending on scope, with somewhere between 20 and thousands of planes) were almost completely empty. Black. With little white map lines showing various air, altitude or other restrictions and weather. They spent three days watching military jets fly around, and that was it. Nothing else.

My take on this sort of system was that it could stand visual and architectural improvement, but that without a lot of study and planning, it would be dangerous to change it. And, the users are so adept at the system they have now, and have so much responsibility and pressure to perform quickly, that changes would likely be unwelcome. Extensive study of user behavior and needs would have to happen, and then extensive testing would have to follow before anything could be put into practice. I can see why they maintain the same system (it's not from 1993 though.. it's much more recent), and just update it with new air space data and plane info, and don't do much to mess with a working system.

But it was still fascinating to see the TRACON information and understand the motivations for its construction and use. And comparing that to what we do building web systems? The best!