Behind the Build

A tiny observation with a map-shaped answer

The project started on foot: biscuit jars on porch rails, stick libraries under trees, and water bowls outside shops. The interesting part was not any one stop. It was that the network existed without a shared record.

The first product decision was also the most important: make the map the product. No account wall, no feed, no separate app to install. A walker should be able to open a link, see what is nearby, and understand which reports someone has actually checked.

A lightweight publishing pipeline

The app separates public suggestions from trusted map data. A Google Form collects reports into a submissions sheet. Review and verification happen before an approved stop reaches the published CSV consumed by the map.

This design is intentionally modest. The spreadsheet is readable by a non-developer, the static site has no deployment server to maintain, and the verification state remains visible instead of being hidden behind a generic pin.

The useful trickery

Static site, live data

Leaflet renders the interface while Papa Parse turns a published Sheet into structured stop data in the browser. The map can change without rebuilding the site, but the production surface stays portable HTML, CSS, and JavaScript.

Progressive enhancement

Location, sharing, installation, subscriptions, and write-back endpoints are treated as enhancements. When an API or endpoint is unavailable, the core map still loads and several actions fall back to plain links or email.

Geospatial logic without a platform backend

The browser calculates distances, finds the nearest stop, groups neighborhood collections, builds suggested walks, and handles deep links. OpenStreetMap supplies the geographic canvas; the project’s own data supplies the local meaning.

Trust expressed as interface

Verified, unverified, and seasonal states are not back-office fields. They control pin rings, badges, filters, and copy. The data model and visual system say the same thing: a report is useful, but a checked report is different.

A field notebook over a stock map

The visual system uses parchment, near-black ink, hard offset shadows, and small radii. Fraunces carries the personality; Inter handles conversation; JetBrains Mono labels metadata like notes in the margin.

OpenStreetMap tiles are warmed and slightly desaturated so the base geography recedes. Stop colors and status rings remain clear above it. On small screens, interface text gives way to defined icons while accessible names and tooltips preserve meaning.

The voice follows the same rules as the verification model: casual, specific, and honest about what is automated, what is manual, and what still needs a walk.

What the build made clear

• Small systems can still have real architecture; the best boundary here is between suggestion and publication.
• A spreadsheet can be a sensible operational database when the scale, editor, and review process are explicit.
• Graceful fallbacks matter more than feature count for a neighborhood utility opened outdoors on a phone.
• Accessibility works best when it is structural: semantic buttons, keyboard-safe controls, readable contrast, and labels that survive icon-only layouts.
• A visible “unverified” state is more trustworthy than pretending every crowdsourced point has equal certainty.

What it uses