Handing real-time information to bus staff

Public transit agencies and private sector tech firms have been using technology to radically simplify how passengers plan their transit trips since at least 2005, when Google Transit launched. Public agencies in particular have grown their role in recent years, shifting from simply providing open data to third-party app developers to creating reciprocal agreements with companies like Transit App or – in the case of larger agencies – building their own robust, dynamic tools for giving riders real-time schedules and information alerts. After a series of major winter storms severely hampered operations in 2015, the Massachusetts Bay Transportation Authority (MBTA) created the Customer Technology Department to apply modern principles of research, design and technology to digital tools that inform and empower MBTA passengers. This included rebuilding its website based on user research and feedback, and overhauling the real-time data systems that drive the website, in-station screens and third-party apps.

What about apps for ops?

As the MBTA modernised rider-facing tools, it became increasingly clear that operations-facing tools could benefit from this approach, too. The MBTA Bus Operations Department wanted to give its field staff a way of tracking the real-time status of bus services, especially since passengers increasingly had such easy access to bus tracking information on their own phones. But the MBTA’s vendor-provided dispatch software could only run on specially configured Windows tablet PCs. The tablets were expensive and heavy, and the software was cumbersome for touchscreen use. This existing solution was hard to support and train on, let alone scale to all bus officials. Many bus inspectors continued to rely primarily on paper schedules to manage services.

To better serve their staff, Bus Operations partnered with the Customer Technology Department to investigate other vendor solutions to give bus officials real-time information. However, these tools tended to be either a package deal with a larger bus dispatch stack (i.e. using the app would mean replacing the entire bus dispatch environment, including equipment on 1,000-plus buses) or not useful or intuitive, according to bus inspectors.

Meet Skate

Instead of settling for a “just okay” vendor, the MBTA decided to build an in-house app for bus inspectors in the field using the same team and agile principles it used to rebuild the agency’s official rider tools. These principles included:

• Early and continuous design research with users (in this case, bus officials)
• Open-source software engineering built on standard data formats and application programming interfaces (APIs)
• Agile product management so features are delivered quickly and tweaked based on actual user feedback.

This also matched the MBTA’s overall technology strategy to reduce reliance on monolithic black box vendors and move towards a modular, open and flexible architecture where the agency can pick and choose the best tools for a given problem, whether they are vendor-developed or in-house.

The joint Customer Technology and Bus Operations team began work on that web app, Skate, in April 2019, and the first version was on tablets in bus officials’ hands by July. The MBTA has around 200 bus officials, and every week around 130 of them log in to Skate. While in-house development sounds scary and slow, with the right staff, architecture and processes it can deliver value faster than a vendor contract can even be signed.

Skate’s core, initial feature is displaying buses on ‘route ladders’, a standard abstraction of transit service that makes it easy for an inspector to see how many routes are performing at once. Each ‘rung’ on the route ladder is a timepoint, or a major bus stop. Each triangle is a bus drawn near the timepoint closest to where the bus is. The line stemming from the bus shows where it should be based on the schedule. Early buses show up in red, late buses in blue, and on-time buses in green. Incoming buses (on the bottom) show vehicles laying over or coming onto the route from a different part of the system.

User research leads the way

Developing a deep understanding of how bus inspectors work and what technology resonated with them was important to quickly and successfully deploy Skate. All bus officials began their careers as bus operators, and many said they were not comfortable with office technology. MBTA designers talked to more than 35 individual bus officials in stations, duty vehicles and garages to hear about the demands of their job and to gain feedback on Skate’s design and features. These individual conversations helped keep the Skate team focused on inspectors’ needs and also built trust and word of mouth enthusiasm that fuelled adoption rates.

The tight-knit partnership between Bus Operations and Customer Technology was also important. Operations managers helped set priorities and interpret feedback from staff-level users, and ensured staff were comfortable with their Android tablets for Skate. Being able to routinely go into the field and talk to users was an advantage for the in-house transit agency digital team, but was only possible and successful because of support from operations partners at the leadership and staff levels.

Open APIs, not black boxes

Another reason the MBTA could deploy Skate so quickly was because it used existing APIs and open data streams. Past work on rider-facing tools meant that the MBTA had already done extensive work to securely pull relevant data (e.g. bus locations, assignments) out of the dispatch system into an in-house API. Tweaking those processes to also handle information relevant for operations staff was straightforward.

In addition, the MBTA had recently engaged Swiftly as its real-time bus predictions vendor and was able to use Swiftly’s APIs as a source for information such as real-time bunching and schedule adherence. This meant the MBTA did not have to recreate those calculations within Skate. Building on an open, flexible and existing architecture allowed the Skate team to focus on the front-end work to craft a web-based application that responded directly to inspector needs.

Pivoting quickly based on agency priorities

One of the most useful things about Skate is that it gives the MBTA a platform where it can quickly build and adapt features – big or small – that respond to current conditions. For example, bus officials wanted to be able to get driving directions to a bus if it became disabled in an unfamiliar area. During market research, vendors seemed reluctant to commit to this feature, but passing a ‘hot link’ to directions in Google Maps only required a few lines of code in Skate.

On a bigger scale, MBTA Operations wanted to give its officials tools to help them manage rail replacement bus service. As part of the Building a Better T initiative, the MBTA is accelerating capital projects, which means more planned subway shutdowns and associated bus shuttling. However, the MBTA’s vendor-provided bus dispatch system is not capable of providing the same kind of information for bus shuttles that riders and operations have come to expect on scheduled bus service (e.g. next stop announcements, on-time performance status).

In just a few months during Autumn 2019, the Skate team built a shuttle tracking map that gives officials a display of all buses running shuttle services and their relative location along the route. While Skate couldn’t replace all the missing features in the dispatch system, it provided field staff direct views of shuttle performance in time for Autumn construction. Meanwhile, the MBTA’s dispatch vendor has only recently been able to begin work on shuttle‑related improvements.

A tool for riders, too

While the premise of Skate is applying experience from building rider tools to the needs of operations staff, the app may help the MBTA provide better information to passengers as well. The MBTA recently invested in better vehicle tracking technology and algorithms for calculating arrival predictions but many of passengers’ biggest frustrations are related to human interventions in service – no algorithm can guess when a bus inspector is holding a bus to even out headways, or when officials need to cancel a trip to triage service during an emergency disruption.

Skate is currently a ‘read-only’ tool, but the MBTA is investigating how it could help the agency capture these kinds of interventions in service – and potentially communicate them to riders. For example, bus inspectors adjusting schedules on the fly currently fill out a paper form. Building a feature into Skate to record this adjustment would be an easier process for the inspector, and would also enable the MBTA to let riders know about that very granular change in service. This would supplement the broader delay and disruption alerts that dispatchers already provide to passengers.

The good that Skate can do isn’t limited to the MBTA and Boston. The agency released Skate as open-source code and has already talked with a number of transit agencies and private companies about building a community of users. Skate is the latest addition to a growing array of open-source tools that transit agencies can wield. It can help the MBTA and other agencies push vendors to deliver open and modular technology for transit authorities to build, adapt or procure the best tools for their passengers and staff. 

Biography 

Logan Nash is Director of Transit Technology at the Massachusetts Bay Transportation Authority’s Customer Technology Department. He manages the agency’s real-time and static open data that allows riders to plan their trips on mbta.com and third-party apps. He also manages the real-time dispatch technologies that help bus operations staff deliver service to riders.