Aura Weather

Weather apps can become visually busy while still failing at the basic question: what does the user need to know right now? A second, deeper issue is data trust. When APIs return partial or missing values, the interface must not silently display fake readings that the user will act on.

Still to validate: real user behavior around saved cities, location permissions, and which weather panels people use most often.

• People who want a fast, readable weather snapshot before making daily decisions.
• Mobile users scanning current conditions, hourly changes, rain guidance, and alerts.
• Technical reviewers evaluating async data handling, API boundaries, and fallback states.

• Make the current day understandable quickly without burying the answer in decoration.
• Keep forecast, air quality, alerts, and climate context resilient when one source is slow or unavailable.
• Represent missing data as missing, never as a confident zero.
• Keep the responsive layout useful from desktop down to small mobile screens.

Sole frontend engineer. I built the dashboard layout, the keyboard combobox search, saved- and startup-location behavior, the weather API orchestration across three sources, the nullish-rejection data contracts, missing-data rendering, responsive CSS in plain stylesheets, the interface states, and the full QA suite that locks the trust contract.

• Start with a usable fallback forecast instead of blocking the first load on geolocation permission.
• Prioritize the hero summary, rain guidance, and hourly trend for fast scanning.
• Use labelled unsupported or unavailable states instead of vague failure copy.
• Add touch-friendly mobile sample controls for dense timelines that would otherwise rely on hover.

• Independent fetch lifecycles. Forecast, supplemental data, and the climate archive are requested separately, so a secondary provider problem never blocks the core forecast.
• Nullish-rejection at the boundary. Provider data is normalized with strict numeric handling so a missing value stays null end to end and is rendered as unavailable, never as 0.
• Last-known recovery. Forecasts are cached with freshness limits so an offline start can restore the last-known view without presenting stale data as fresh.
• Audit-and-lock. An internal audit surfaced a class of stability bugs in how partial provider responses flowed through the UI; each fix shipped with a regression test, so the same bug class cannot quietly return.
• Co-located CSS. Styles live with their components in plain CSS so dashboard surfaces stay maintainable as they evolve — no UI framework required.

• Constraint

  Weather data can be partial, delayed, or unavailable from individual provider endpoints.

• Decision

  Normalize values at the API boundary with a nullish-rejection contract and render unavailable data explicitly instead of forcing fallback zeros.

• Tradeoff

  The interface stays trustworthy, but the UI has to carry more clear empty and unsupported states — and the QA suite has to lock that contract so it can't regress.

• Automated in CI: Playwright runs axe against the app's primary states as part of the end-to-end suite.
• City search uses keyboard-friendly combobox and listbox behavior with an abortable request lifecycle.
• Loading, refresh, error, and missing-data states use live status messaging where it helps.
• Missing values include assistive text such as "no data available" instead of relying only on an em dash.
• Preference-aware effects and mobile touch-target work are marked for continued interface QA.

• Lighthouse budgets run in CI alongside the test suite, so regressions in the budgeted metrics are caught before merge.
• Core forecast content loads before lower-priority supplemental panels; lazy panels and deferred mounting cut the work for the first useful screen.
• Unit toggles are handled client-side, so changing F/C does not trigger unnecessary provider requests.
• Service worker support is limited to the app shell; live weather data remains a network truth source.

• The signature story: an internal audit caught a class of stability bugs around partial and missing provider data; each was fixed and then locked with a regression test, so the trust contract cannot silently regress.
• Test pyramid: unit and integration tests, end-to-end coverage with Playwright + axe, visual regression, and Lighthouse budgets — the breadth is deliberate for a data-driven UI.
• Evidence standard: missing-data behavior is described as a trust decision without inventing reliability metrics.
• Still to validate: fresh production Lighthouse profiling, reverse-geocoding edge cases, and saved-city behavior with real users.

Aura Weather is a working portfolio project with real multi-API integration, resilient loading/error behavior, defensive data contracts, and documented limitations. It should not be described as a full production weather platform.

Data products need honest absence states as much as polished success states. Keeping null, unavailable, and delayed provider responses visible makes the interface more trustworthy than a cleaner-looking screen with misleading fallback values — and a regression test is what keeps that honesty from eroding over time.

• Capture deployed Lighthouse field numbers, then tune image and paint cost from real data.
• Improve reverse-geocoding for raw device coordinates.
• Revisit saved-city sync if the project needs account-level trust rather than lightweight optional sync.
• Use product analytics or user testing to decide which panels deserve the most visual priority.