The Firehouse — A Public Home for Fire Weather Social Science

Fire weather social science asks a practical question: what do forecasters, incident staff and land managers actually need from weather information when a decision can't wait? A lot of good work has answered parts of it — DESI studies, Fire Weather Testbed evaluations, projects run by individual teams. The findings tended to stay inside the report that carried them. If you wanted to know what was already known, you asked around.

Two NOAA GSL social scientists had already done the hard part. In an internal report called FireHouse 1.0, they ran a thematic analysis across nine completed projects and organized the needs and recommendations into four areas: observations, forecasts, warnings, and governance. My job was to turn that report into a public website, open to researchers outside GSL, that the two of them could keep current on their own.

The brief came with real constraints. The site is a federal resource, so WCAG 2.1 AA and Section 508 are requirements. It launches at the AMS Annual Meeting, which means people will open it on a phone, between sessions. And the audience is mixed — researchers who want the evidence, and leadership who want to see what the program has produced — so it has to read plainly for both.

I started from what existed: the FireHouse 1.0 report, the researchers' written requirements, early mock-ups from a designer on the IDSS team, a rough prototype one of the researchers had put together, and the concept slides from the ST Council. I wrote these into a creative brief in July that settled the audiences, the pages, and the open risks — chief among them that an AI tool sorting free-text submissions into topics was unproven and needed a person reviewing it before anything went public.

The most useful research was the walkthrough. In September the two researchers and I walked through the design screen by screen. One comment reorganized the site: projects span multiple topics. The early build filed each project under a topic area, the way the mock-ups had, and a single study about warning coordination genuinely belongs to warnings, governance and forecasts all at once. Filing it under one was wrong; filing it under all of them turned the page into the same handful of reports repeated four times.

So topic areas became a synthesis, not a tag. Projects carry no topic at all. Instead, every need a researcher records is read across the whole collection, grouped into the four areas, and ranked by how many separate entries raise it. The walkthrough set two more rules that shaped everything after: researchers' own words are preserved verbatim on project pages, with the synthesized wording used only where the site speaks for the collection; and every project needs its own address, because researchers cite things.

There was no API to design against. Survey responses live in Qualtrics; the site is a static build. So the boundary between the two is a file contract: an export goes through an import script and comes out as the same JSON the site already reads. Anyone replacing the manual export with a live feed later swaps the left side of that line and nothing a visitor sees changes. The import script is also where the privacy rules live, because it is the one place every answer passes through: contact details are never read, one internal-only survey question never reaches the site at all, a project without IRB approval is reported rather than quietly skipped, and every imported record waits as unpublished until a person publishes it.

The design system arrived as a set of components from the landing page design, and I ported thirteen of them to typed React without changing how they look. What I did change was how they behave. The header was one row that overflowed below about 900 pixels, so it gained a mobile drawer. The project detail panel became a real dialog with focus moved in, trapped, and returned. Route changes move focus to the main content — except on first load, where doing so would put the skip link behind the reader and make it unreachable.

The visual direction is translucent panels over a warm, bounded backdrop, and that is exactly where contrast usually fails quietly. The rule I held to was that glass provides depth, never contrast: every panel's opacity is chosen so text passes against the worst-case composite, and reduced transparency, increased contrast, and browsers without backdrop blur all fall back to opaque surfaces. Two audits check it — a script over the token palette, and a walk of the live page that reads computed colours off real elements — and they catch different things. One was a bug no token audit could see: a light-mode fix that leaked into dark mode through equal CSS specificity, painting every caption on the site below 2.8:1.

The landing page leads with the answer. Below a short introduction and three live stats sit the four topic areas, each showing its top five needs with how many times each came up. The stats are computed from published content rather than typed into it: an editor controls the wording, but can't put the project count out of step with the projects actually on the site. A label beside the needs says they are AI-synthesized, how many projects they draw on, and — until a person on the team signs off — that they are a draft.

Each topic page carries the same five needs with the projects each one draws on, linked. Each project page is the researcher's record in their own words: abstract, takeaways, needs and recommendations, and papers resolved from their DOIs, with an at-a-glance sidebar and a citation block in APA 7, Chicago or BibTeX, ready to copy. The explorer searches title, abstract, needs and takeaways with typo tolerance and no third-party library, filters by fire phase, coordination area, year and project type, and keeps every choice in the address bar so a filtered view can be pasted into an email.

The coverage map shows where the research comes from, by Geographic Area Coordination Center. Regions are stored as the survey's codes rather than its labels, so rewording a label can never break the map. There are fourteen values, not ten: Hawaii and the Pacific have their own because the official boundary file folds them into Northern California, and National, International and Not sure exist so a researcher can pick the true answer instead of the nearest wrong one. The list beside the map is the operable surface — real buttons with real counts — and the map canvas is hidden from assistive technology rather than offering a screen reader a pile of unlabelled shapes.

The most important design work here was deciding what the site is about. The brief described a hub of projects. The walkthrough showed that a reader doesn't come for a project; they come with a question about warnings, or forecasts, and want to know what the evidence says. Moving from filing projects to synthesizing needs changed the information architecture, the data model and the landing page, and it is the reason the site is more useful than the folder of reports it replaces.

The second lesson is about putting AI-made content in front of the public. The synthesis is genuinely useful and genuinely unreviewed, and both of those facts belong on the page. Labelling it as AI-synthesized, counting what it was drawn from, marking it as a draft until a named person reviews it, and linking every need back to the researchers' own words costs a line of interface and earns the trust a government research site depends on.

Next is launch. GSL is settling where the site will live, the researchers are choosing a CMS behind content adapters that are already written, and the first synthesis pass is waiting on their review. A full screen-reader audit and the remaining federal checks come before the site goes public at AMS in January.