Drone Weather — three frontend proposals
Three isolated prototypes of the same data. All of them read one live capture taken
from the running app's own /api/forecast and /api/weather_limits endpoints,
so every value, status, cause and threshold shown is the real backend output. No weather logic,
threshold, API call or stored file was changed, and the production frontend is untouched.
PROPOSAL A
Operational command dashboard
Built around one question: where and when can we fly? The answer is
the first thing on screen, before any table.
- Answer bar: next flyable night, which sites, what is blocking
- Night timeline with go/caution/no-go counts per window
- One row per site: verdict, deciding metric with its limit, all 7 metrics, 5-night strip
- Detail drawer for the full source comparison
Open Proposal A
PROPOSAL B
Map-first planning
Geography first. Pins carry the verdict and the deciding number, so a
dispatcher sees regional weather patterns instead of reading a list.
- Full-bleed map, one labelled pin per site for the selected night
- Pin shape and pattern repeat the state; label can be switched to any metric
- Day scrubber above the map, ranked site rail beside it
- New sites are placed by clicking the map directly
Open Proposal B
PROPOSAL C
Refined professional table
The existing site × day grid, kept familiar but made precise:
one verdict and one named cause per cell instead of a wall of chips.
- Sticky site column, sticky date headers with per-night counts
- Three density modes: Summary, Metrics, Compare (both sources side by side)
- Sortable date columns, as today
- Collapses to per-site cards on mobile rather than scrolling sideways
Open Proposal C
| A — Command | B — Map | C — Table |
|---|
| Answers "when" | Explicitly, in a headline | Day scrubber above map | Next-flyable KPI + column counts |
| Answers "where" | Ranked site list | Geographic pins | Row per site |
| Cause visibility | Metric + value + limit on every row | On pin label and in rail | Metric + value + limit in every cell |
| Scan speed, 8 sites | Fastest for a single night | Fastest for regional patterns | Fastest for the whole 5×8 matrix |
| Learning cost | New layout | New layout | Near zero — same grid |
| Mobile | Stacked rows | Map + sheet | Per-site cards |
| Best when | Deciding tonight's dispatch | Planning across regions | Comparing everything at once |
Non-colour status encoding, in all three. Every state is carried four ways at once:
a text code (●GO
▲CAU
■NO-GO), a distinct glyph shape,
a fill pattern (plain / diagonal hatch / cross-hatch) and a left-edge weight
(thin / medium / thick). The prototypes stay fully readable in greyscale and for
colour-blind pilots.
Everything preserved. Source comparison including divergence flags, the three filters,
the three sort modes plus date-column sorting, city add and remove, site comments, the
threshold viewer and editor, observed 24 h rain, and all seven metrics
(Temp Low, Temp High, RH, Rain, Wind Avg, Gust Max, KP).
Prototype limits. These pages are static: buttons re-render the captured snapshot rather
than re-fetching, and Save is inert. The Add City dialog and the per-city hourly popup are
represented but not rebuilt. Proposal B loads map tiles from the internet.