A design proposal from Malang shows how much of a transport app is settled by its data contract.
Riders see an app. Developers see the contract underneath it, and that contract quietly decides which features are even possible. A 2017 proposal for local public transport in Malang is interesting less for its interface and more for the questions it forces a city to answer before code is written.
The proposed interface reads like a list of things a passenger would ask at a terminal. Map each question to a shape of data and the design work is mostly done.
The proposal attaches six indices to every mode: comfortability, security, safety, privacy, availability, and accessibility. Putting those in the payload rather than in prose is a design decision with consequences. Values on a shared scale can be sorted, filtered, and compared across modes, while the same information buried in a description cannot.
It also raises the harder question of where those numbers come from. An index is only as good as the operator willing to maintain it.
The authors describe a draft, and the paper reports no deployed service and no measured result. Questions about authentication, rate limits, and how vehicle positions stay current are not settled here. The transport data itself still has to come from the operator.
Even so, the approach is worth copying. Write the contract first, and every rider app built afterward becomes a client rather than a rewrite.
Agi Putra Kharisma and Aryo Pinandito (2017). Design of REST API for Local Public Transportation Information Services in Malang City. Journal of Information Technology and Computer Science.
