This application serves real-time information to all of our browser-based screens posted at stops and stations around the system.
If you're looking for the applications that control the LED countdown clocks and the in-station PA system, please see mbta/realtime_signs and mbta/signs_ui.
Some examples of the various client apps, as of January 2023:
screen type (click for a sample screenshot) | description |
---|---|
Bus E-Ink | solar-powered E-Ink screens at bus stops |
Green Line E-Ink | solar-powered E-Ink screens at surface-level Green Line stops |
Bus corridor LCD | currently used at stops on the Columbus Ave bus corridor |
Multimodal LCD | used at high-traffic transfer stations served by many routes/modes |
Pre-fare duo LCD | posted outside of fare gates at rapid transit stations; content is split across two portrait-oriented 1080p physical displays |
"Digital Urban Panel" LCD | content appears in rotation with ads on screens posted outside rapid transit station entrances |
Triptych trio LCD | (:construction: WIP!) posted across the tracks from platforms at major stations; content is split across three portrait-oriented 1080p physical displays and appears in rotation with ads |
and more to come!
You have two options to set up the project environment for development:
- Run on your local machine, with dependencies installed locally.
- Pros: Runs fast; use the code editor of your choice
- Cons: Requires building Erlang from source; makes version upgrades more difficult
- 🆕✨ Run inside a Docker container using VS Code's Devcontainer extension.
- Pros: Simple, one-click build process; easy version upgrades; integrated-ish development environment; host-OS-agnostic
- Cons: Restricted to VS Code as an editor; file read/write is a bit slower
On almost all of our screen types, we use a common "framework" to fetch relevant real-time info for the screen's location, and then determine which pieces of info are most important to riders from moment to moment.
Check out ARCHITECTURE.md for an overview of the application architecture, as well as links to further more detailed documentation.
The DUP and Triptych screens require the client app to be packaged into a single HTML file rather than dynamically served from our Phoenix server.
You can find instructions on the DUP packaging process here, the triptych packaging process here.
You can find some hopefully useful notes on upgrading the project's Elixir version, and possibly other upgrades, here.