Establishing trust in bus transit

About seven months ago, I was sitting in the lounge area in my university with my friend, and we were talking about school and homework; you know the typical discussion students make with each other. I believe we were talking about our computational geometry course, and of course assignments...yea.

Anyways it was soon time for him to head home and the conversation shifted to transportation - specifically the transit system in the city, and how unreliable it has become. As a side note I think close to sixty percent of students who went to that school actually relied on the bus transit system to commute to and from the university. I am not sure what the actual number of students are, but according to a 2018 report, 23% transit customers are students. According to the same report: The primary concerns of customers were related to operators arriving early, arriving late, their driving, or driving by a stop. In simple terms, the transit system was broken, but we have all just accepted the broken system as the norm.

...23% of transit customers are students.

This talk of unreliability soon shifted to brainstorming a solution to the problem. We soon began to come up with some What if ideas:

• What if the bus stops have a way of notifying people of the status of a bus; complete with mitigation plan for the commuters in the case a bus breaks down.
• What if the stop itself had a way of alerting the patrons of delays and close-to-accurate real-time estimates of when the next bus will arrive at a particular stop. As it stands now, the only notification system available to patrons of the transit system are in the form of paper notices which had to be printed on real paper 🙈, by a real person, and placed at the affected stop by that person who may or may not show up (I've never seen this person myself). i.e. someone is being paid to actually do this, but is failing.

Seeing as were were comp sci students, the solutions we had were heavily software based. The conclusion of the matter was that in order to make transportation more reliable, we needed to improve the system for communicating with the patrons of the transportation system.

A number of months later, I have come up with a prototype application which I hope will be a stepping stone for the rest of the dream we have for bus transportation in Saskatoon.
Here are a couple screenshots of the prototype, and I will attempt to describe some of its features.

Transit Notification

...the transit system was broken, but we have all just accepted the broken system as the norm

Firstly the idea behind this system is that it needs to run on a device which will be installed at every stop in the city. The device is should be quite durable and able to survive prairies temperatures (freezing and hot). Now we can describe what the software brings:

Starting from the top we have:

• The current time: This is important so that patrons can know that you are running on the same time as they are
• The name of a route for this stop: As there can be multiple routes arriving at a given stop, we want to show the rider the name of the route for which the rest of the information below, is for.
• The next arrival of a vehicle for this route: This shows the next time a transit bus is going to be at this stop, for the given route. With this information, the rider is able to correctly infer if the bus is running late, early or on time. The best case scenario is that the bus is on time as this implies an efficient system. Early/late is unpredictable and we want to avoid this.
• The previous arrival of a vehicle for this route: It is valuable to show the last time a vehicle was at the given stop because it shows true accountability. If the bus left early from the stop then a "late" passenger who was actually on time will know this.
• A notice for the current route: Finally, we want to be able to notify the waiting passengers of any disruptions to the flow of the network. We use this part of the display to show the status of the vehicles for the route. We can show things like:
• Cause of delay i.e. in the case where next arrival is later than usual
• Mitigation plans i.e. what measures are in currently in place to reduce the impact of a delay. This could be in the form of a new vehicle being dispatched in the case all the vehicles for this route are unavailable. If all else fails, we should inform the passengers of this, and kindly ask them to find another option for their travel needs, although we would want to avoid this last option at all costs.
• Display of routes for this stop: This list below will show all the routes which service the current stop. At the moment, new transit passengers have to go to a transit station and to find a manual that lists all the routes for each stop. We want to make this discovery easier by having at every stop, a big bold display that shows each route number and name of the route.

Conclusion

And there we have it. In one self-explanatory interface, we have shown how a transit system can establish trust with its customers, and it all hinges on communication. If the communication channels are wide open and the patrons are made aware of the kind of plans the system tends to propose when problems arise, it leads to creating a mutual understanding between the transit system and its riders, of the risks/rewards associated with this relationship.

Leave a Comment programming, transportation