The MBTA provides a real-time feed for commuter rail departures; as the service is in beta, they exhort developers to make use of the complementary T-Alerts feed, which is likely to provide useful information during disruptions that the real-time departures feed cannot convey. But transit alerts are hard to get right—something WMATA found out as riders started howling about useless Tweets like “Red Line: Alert cleared.”. So, while it’s good that the MBTA provides a feed of alerts, it’s important to make sure that those alerts are actually useful. Part of that means keeping in mind that developers are likely to use the information in a very wide variety of ways, and there’s no such thing as a one-size-fits-all transit alert.
Applications which are displaying alerts on mobile devices or digital signage, or feeding them into a text-to-speech engine, need simple, concise text. Text like “click here” which works when the alert is displayed in a Web browser becomes irrelevant filler when displayed on digital signage or rendered through a text-to-speech engine.
Let’s look at a few sample alerts from the MBTA and see how they can be improved:
Greenbush Line Weekend Service Suspended Beginning Saturday April 30th Beginning Saturday April 30th through December 31, 2011, the Greenbush Line will be out of service for tie replacement on Saturdays and Sundays. During the weekend out of service period no train service will be available on the Greenbush Line. There will be no alternative bus service provided during the weekend outages. For further information please click here http://www.mbta.com/about_the_mbta/t_projects/default.asp?id=19461 We apologize for any inconvenience this may cause.
This alert can be made considerably simpler:
No service on Saturday or Sunday due to construction. No replacement bus service provided.
You’ll note that information about the line affected, as well as dates of applicability, have been removed from the message. This information should be supplied as metadata, rather than being provided in the text of the message, because different interfaces may need to render it differently. In addition, links to additional information should be provided as metadata for Web-enabled devices; as mentioned above, it’s inappropriate to have them in the body of the alert. Listening to a text-to-speech engine try to read a URL borders on painful: “h-t-t-p-colon-slash-slash-m-b-t-a-dot-c-o-m…”.
The revised alert is short enough to serve as a Tweet or SMS message, with room to spare. It’s also appropriate for use on the Web, on mobile devices, and on digital signage. On the Web and on mobile devices, it could be used as a ‘headline’, where clicking on it would take the viewer to a more detailed description (similar to the original alert). Yet the revised alert still provides the essential information riders need to know: there’s no weekend service, and no replacement bus service.
Here’s another example:
GREEN LINE SHUTTLE BUS REPLACEMENT Attention customers, beginning on Saturday April 30, 2011 through December 2011, a bus shuttle will replace Green Line trains between North Station and Lechmere Stations. This service change will be in place as work is completed as part of the Science Park/West End station elevator project. For complete bus shuttle details and project information, please visit : http://www.mbta.com/about_the_mbta/t_projects/default.asp?id=14747. MBTA Personnel will be available to provide information and customer service.
Like the previous alert, this one can be made considerably simpler without losing valuable information:
No service between Lechmere and North Station due to construction. Shuttle bus serves Lechmere, Science Park, and North Station.
As verbose as the original alert was, it didn’t actually tell you where the stops for the shuttle bus are! Yet this information doesn’t really need to be in the alert; we’d expect there to be signage and announcements at each affected station guiding riders to and from the shuttle buses. Again, the rewritten alert is short enough for use on Twitter and in SMS messages, and can be displayed on digital signage without monopolizing the display.
Finally, it seems like every transit system has problems with elevators and escalators, so here’s an elevator alert:
Starting on March 21, 2011, elevator 820 (Lobby to Red Line) at Porter Sq Station will be out of service for approximately one year while it is being replaced. During this time, an accessible bus shuttle will be provided between Porter Sq. and Davis Sq. Stations. Customers exiting the Red Line at Porter Sq. should instead exit at Davis Sq. and take the shuttle bus. Customers boarding the Red Line at Porter Sq. can take the shuttle bus to Davis, or route 77 or 96 to Harvard Sq. At Porter Sq: Use intercom next to elevator on Somerville Ave. or see station official to request the shuttle bus. Board in bus stop on Somerville Ave. At Davis Sq: Board shuttle bus in busway or see station official to request the shuttle bus. We apologize for any inconvenience. For more information, contact the MBTA Customer Communications Department at (617) 222-3200, TTY: (617) 222-5146.
Can we make this shorter? Of course:
Elevator out of service due to modernization. Shuttle from Davis Sq. station. See station staff for assistance.
We don’t need to include the contact information, because that should be prominently available throughout the system; there’s no need to include it in the text of every alert. In addition, information on specific steps for riders to take at each station can be omitted; that should be conveyed through station-specific signage and announcements, or a long-form message on the agency’s Web site. As mentioned before, the name of the affected station would still be included, but as metadata rather than in the body of the alert. If the alerts are being displayed in groups by station, for example, then it’s not necessary to include the name of the station in each alert. An SMS alert, on the other hand, might look like “PORTER SQ: Elevator out of service due to modernization. Shuttle from Davis Sq. station. See station staff for assistance.”
These rewritten messages aren’t just more flexible, they’re easier to read, too. There’s no reason to wade through a paragraph of text to get to the essential information, and the reality is that most riders won’t do so. They’ll ignore the wall of text, and so they’ll remain uninformed about disruptions which may affect their trip.
The alert text itself, though, is only part of the problem. The MBTA has chosen to disseminate alerts using RSS 2.0 plus some nonstandard elements. The IDs used in the feed to identify affected routes and stations don’t match those used by NextBus or in the GTFS feed. In addition, there’s no hierarchy; as an example, each elevator has its own ID, which bears no relation to the station in which it is located. This makes it difficult to find, for example, all alerts for a given station (including elevators), or all alerts for a given rail line (whether they’re attached to the line itself or a particular station along the line). In addition, as mentioned previously, all of the text gets dumped in the
<description> element; there’s no effort made to provide a short-form summary of the alert along with long-form text for places where it can be used effectively.
The CTA‘s Customer Alerts API solves many of these problems; the identifiers used match those used in other CTA APIs and the GTFS feed; the feed provides headlines, short descriptions, and long descriptions for each event, and a rich data structure is used to identify the stations and lines affected by each alert. The only thing that’s missing is the ability to look up alerts by stop ID (a feature which is particularly useful for bus stops).
Without the ability to look up alerts by stop ID, you must know in advance the rail lines or bus routes which serve a particular stop, in order to prepare a list of alerts affecting only those routes at that stop. However, the CTA Bus Tracker API does provide a method for retrieving “service bulletins” by stop ID; the information is the same as what is provided by the Customer Alerts API, but in a different format, necessitating more programming work to consume those alerts.
In conclusion, providing effective transit alerts is a two-part process: you must first have an infrastructure in place which makes it easy to disseminate alerts with rich metadata, and which makes it easy for developers to identify alerts of interest, by using common, consistent identifiers. You must then have communications staff who take full advantage of that infrastructure. This means, for example, ensuring that alert messages are formatted consistently, that short and long versions are available, and that metadata fields are correctly populated. Providing developers with a feed of paragraph-long alerts, though, isn’t very useful. It may work for Web sites and some mobile apps, but for many applications the alerts are simply not useful. More broadly, though, it’s poor customer service. When people read an alert message, they want a fast answer to a simple question: “how does this affect my trip?”. If the message doesn’t answer that question in the first few words, then it won’t be read.
This is, once again, a case where it is important to consider the externalities of decisions made by transit authorities. When transit riders—especially discretionary riders—perceive a transit authority to communicate poorly, it lowers their opinion of the transit service and makes them less likely to ride in the future, supposing they have other options available. Whether it’s rerouting a bus or taking an elevator out of service, riders need to know what’s going on, and they need to know through clear, consistent messaging that provides the information they need to know quickly.