COMMUTE LAB
A route comparer for commuters in Kathmandu that simulates many trips and shows how often each route makes you late, instead of a single arrival time.
Choosing between two routes to work usually comes down to gut feel about traffic lights and the odd jam. A single estimated time hides the thing I actually care about: how often a route makes me late. Kathmandu traffic is not a neat signal grid either. Police-directed junctions, sudden bottlenecks and temple crowds come and go.
The key decision was to show a distribution, not a number. Each route gets its average, median and a likely best and worst case, plus how often it beats the other route. When the two are close, the tool says it is a toss-up rather than declaring a winner.
Signals and irregular events are modelled separately. For a signal, you enter its red and green times, and each simulated trip arrives at a random point in the cycle. For irregular problems, you say how many of your last twenty or so rides had one, and how long it usually, at least and at most cost you. Asking for a count of past rides is deliberate: it is easier to remember than to guess a probability.
Routes are drawn on a map with draggable stops, using free, keyless map and routing services. Everything runs in the browser and is stored locally, and each run simulates 1,000, 5,000 or 20,000 trips. The visual design borrows from survey plates and road signage, with a single animation when the histogram recalculates.
The honest limit: the output is only as good as the assumptions you type in, and some of the sample signal timings are still placeholders. Each route is also simulated independently, so a shared cause like rain can't slow both on the same day. When routing fails, the tool falls back to a rough estimate without saying so.
Under its own sample assumptions, the route that wins on average is not the one least likely to make you late against a tight time budget, yet the verdict ranks by average. Next I would add a leave-by mode that answers 'what are my chances of arriving before 10:00?', flag fallbacks and placeholder inputs on screen, and check the simulation against trips I time myself.