Taking the bus is slow, inconvenient, and limiting. In Boston, only 15% of commuters go via bus [1], despite having access to a dense bus network with frequent service. In most other American cities, the numbers are even lower. Have a look at the fraction of the people that commute by public transit in major american cities:

Derived from this image on wikipedia, which looks like it probably used the 2006 ACS data.

Not that many people take public transit at all, and it's the cities with no subway system where it's especially unpopular. This makes sense: in New York, every transportation option is slow, inconvenient, and limiting, and public transit is usually less so than driving. In Oaklahoma City, cars are fast and convenient, so pretty much the only people who take the bus are people who can't afford to drive.

Real time bus data has the potential to make buses much more convenient, and much more competitive with driving. When I used bus schedules, my average wait time at the bus stop was maybe 8 minutes (usually less, but sometimes I'd miss it or it would be late). Then real time bus data came out, and I started checking the bus status before I left home or work, lowering my average wait to about 3 minutes. Now I have a phone and I check the bus status again as I walk to the stop, and now have an average wait time of about a minute. Not having to wait for the bus, especially in rain or cold weather, is huge.

There are still ways to use this data better, however. If I want to go home, I'd like to be able to ask my phone where and when I should wait for the bus. Even something as limited as "when are the next buses arriving vaguely near me" where then I could look at the list and click on the first one that went near home would be nice. [2] Currently, however, I have to pick a route and a stop, and then get predictions.

There are a lot of trips I could make quickly with bus connections, in theory: a pair of buses can get me almost anywhere nearby. When you actually try to pair them, however, they tend to not match up well. You have to leave yourself a large buffer for the transfer, and if you miss the second bus you have a long wait. Google transit, working off schedules, penalizes transfers, and even then it often suggests pairs that I would be worried about. With real time data you can do better. Consider the map below, showing the bus network between my work and my parents' house (red asterixes):

Bus network, colored by speed, extracted from this cool map. Blue lines added in for subways.

There are a large number of possible routings, and with real time data and a good app I could be taking close to the perfect one every time. Instead I always go the same way when I visit them, because it's currently too much work to do anything else.

This all comes down to a huge routing problem. Existing programs either use only schedules (Google Transit) or leave it up to the user to look up routes, predictions, and route themself (everything else). If an app could solve this routing problem, buses would be much more competitive with cars.

[1] The Census's American Community Survey found 32.8% of Boston commuters took public transportation to work in 2010. The census appears not to have asked about bus vs subway, but the typical weekday urban ridership on the MBTA in 2010 was 33.2% bus (pdf), so we can multiply these. Many people take the bus to the subway to get to work, in which case they are counted as both 'bus' and 'subway' and these numbers are off. So I rounded up from 11% to 15%.

[2] My bus app is not well suited for this use as it's aimed at desktops. It uses too much bandwidth on making pretty maps with moving buses to be good on phones. I suggested adding this as a feature to MbtaInfo, and Andy said he'd look into it.