How I would design a real time bus & train information system

San Francisco's Muni has a system that lets people know when the next bus is coming. Unfortunately it's full of gaps and difficulties that make it hard to use in practice. The good news is that Muni is designing a new system. Here's how I'd redesign it:

Why have real time information?

The point of real time displays is so that people can gather and understand information faster and better. The 4 key times & places when people need information are:

  1. At a stop (how long will I have to wait?)
  2. Before leaving home/work/etc... (when should I leave home so I don't need to wait outside?)
  3. Making a transportation decision (how long will it take by bus compared to by Lyft?)
  4. On a bus or a train (how long until I need to get off?)

An effective system should have the following:

A display at every single stop

Every stop needs a display, not just major stops. No display, no stop. This is an essential part of a modern transit experience. This display should display wait times for every line that serves that stop. This information should fit on a single display so that it doesn't have to rotate. (helps #1)

In locations with fare gates, an additional display should be placed before the fare gate so that riders can make an informed decision (helps #3).

For underground or elevated locations there should be an additional display placed at the entrance to the station so that people can avoid rushing when it's not their train that's arriving. (helps #2)

Here's what this display could look like:

A display in every vehicle

Buses and trains need a display that helps people solve #4. This display is different from the display at each stop. It needs to show the upcoming stops and time estimates for each stop. Just like the display at each stop, the information should all fit onscreen at the same time and not require rotation. 

Here's what this onboard display could look like:

An open API

A dedicated Muni app is not the correct place to show transit information because Muni is only one small part of a larger transportation system. Apps like Google Maps and Lyft are better places to show transit information because they can solve #2 and #3 better than a standalone app can.

An open API will allow these integrations to flourish and will provide the best experience for potential Muni riders. This API needs to have both real time predictions, but also crucially the real time and historical locations of every vehicle in the system so that 3rd parties can develop better algorithms for prediction that incorporate additional sources of data such as traffic. Allowing for additional sources of predictions will also result in better validation of Muni's own predictions.

Ideally this API has centimeter level and minute-level precision.

No additional services

Services like the standalone Muni app, nextmuni.com, SMS, and phone predictions should be discontinued. These are better provided by 3rd parties using platforms like Google Maps and Lyft. Any cost savings should be redirected into the addition of displays at every stop and on every train.