A weather dashboard can be beautifully designed and still be useless if it picked the wrong city. My Weather Dashboard starts with a simple rule: location should be explicit.
The application uses latitude and longitude as the authoritative location. City and state labels help people read the results, while ZIP and city searches help with setup or a temporary lookup. A familiar city name alone is not enough to identify a unique place.
The page shows current temperature, feels-like conditions, high and low values, and other current weather information from OpenWeather. It can also sort locations by distance when browser location access is allowed. If access is declined, the original order remains.
Updates use a server-side cache, and an open browser page refreshes periodically. Per-city JSON history retains observations without requiring a database or a background scheduler for the basic workflow. The API key belongs in private server configuration.
Temporary searches are kept separate from the configured base cities. Trying a location should not quietly rewrite the saved dashboard. That distinction makes experimentation less likely to change the view someone expects to see the next time they open it.
The project is small, but it highlights something I care about across my tools: the data must deserve the confidence of the interface. A precise-looking temperature for the wrong location is worse than a clear request to fix the location.
The useful result is a readable view of selected places, with fewer assumptions hiding behind their names.