A personal weather website is a small publication, not a single dashboard. The gauges answer what the instruments reported at the last upload. The station section answers everything else a later reader needs: how the site is configured, who the station is, which scientific sources it trusts, which questions visitors actually ask, and how the data leave the logger. Those supporting pages belong together under one landing address. Mixing them into the live dashboard is how metadata disappears behind a temperature.
The historical TNET Weather URL /weather is treated here as that section landing. It is not a restoration of gauges, not a current Mesa observation, and not a second copy of the dashboard information architecture at /weather.php. TNET Weather does not operate the historical backyard as a live showcase.
Historical context
Mid-2000s personal-weather-station (PWS) sites usually grew two navigations that operators treated as one. The first was the product row: current stats, forecast, radar, a near-real-time packet view. The second was the documentation row: configuration, info, links, published-data notes, notebooks, FAQ. Recovered captures of neighboring pages on this host still show that mixed chrome. The scientific remainder is the split. A dashboard is an evidence map. A section landing is a catalog of the pages that make those numbers interpretable.
/weather without a .php suffix is the natural index for the documentation cluster. Operators and incoming links used short paths as section roots. This rewrite keeps that function. It does not reprint obsolete menus, access counters, or a 2005 format timestamp as if they were observations.
What belongs in the section
A complete station section is a small set of typed pages. Each page has one job. The landing’s job is to name those jobs in one place.
Website configuration is display and template behavior: units shown to the visitor, HTML refresh, which tags the publisher fills, which clock is printed. That is /weather-config.php. It is not hardware siting.
Hardware siting and sensor metadata belong on the configuration record at /configuration.php: exposure, heights, surfaces, logger chain. The section landing points at that record. It does not summarize mast distances in a second essay.
Visitor information is the public fact sheet: place, elevation, sensor list in ordinary language. That is /weather-info.php. It is longer than a four-line identity card and shorter than a WMO siting class worksheet.
Outbound scientific links are an editorial choice about provenance. How to curate them is /weather-links.php. A classified directory of resource categories is /weatherlinks. Keeping that directory from rotting is /weatherlinks.php. Those three URLs are siblings, not aliases.
FAQ is sourced question-and-answer: units, siting, and why a backyard reading is not an airport reading. That is /weatherfaq.php. Rotating unsourced “fun facts” are not an FAQ.
Published-data notes say where files, banners, or network contributions went. Neighboring historical paths such as /weather-published.php and /published.php hold that function. The landing should say that publication is a product with a destination, not paste FTP recipes into the index.
Notebooks, if the site has them, are methods. They are not the section map.
Anything that is a current observation, a forecast valid for a later time, or a radar image with a valid time belongs on the dashboard family, not here. If the landing reprints today’s high, it has stopped being a section index.
Why grouping is a scientific act
Meteorological numbers are not self-explanatory. A temperature is an observation only when a stranger can recover the instrument, the exposure, the units, the timestamp, and the difference between a sensor value and a derived index. National networks keep that information in station histories. A PWS keeps it in a handful of HTML pages. If those pages are scattered under dashboard labels, or duplicated until none of them is canonical, the series is harder to use than the gauges suggest.
Grouping also prevents category errors:
- Configuration of the website is not configuration of the mast.
- A visitor fact sheet is not a Cumulus compact card on another host and not a full siting class.
- A link on the station page is not a directory hub and not a link-rot log.
- An FAQ answer is not a climate extreme copied from a footer file.
The landing is where those distinctions are stated once. Internal links then do the rest. TNET’s public research voice uses the same discipline: observed, modelled, and derived information stay labeled. The plain-language account is how the service works.
Designing the landing
Write the landing as a map, not as a second homepage.
One H1 and a short purpose sentence. The reader should know in two lines that this URL is documentation, not live weather.
A labeled list of children. Each child gets one sentence that states its job and a link. Do not repeat the child’s article.
A clear exit to siting metadata. Many visitors search “station configuration” when they mean either website units or mast height. Send the first to website configuration and the second to the siting record. Do not merge them to save a click.
No live numbers. Observation time, current temperature, and radar thumbnails train the reader to treat the section as a dashboard. Put a single sentence that current conditions live on the dashboard URL, then stop.
No product collage. Banner samples, webcam stills, lightning maps, and forum badges are other products. Link them from the pages that own them.
A hazard line. A personal site is not a warning service. Life-safety decisions belong at the National Weather Service. State that here so every child page does not have to invent a different disclaimer.
A last-reviewed date for the map itself. The landing rots when a child is renamed and the index still points at a 2005 label. The date is editorial metadata, not an observation time.
What the historical mixed nav got right
The recovered neighbor pages still print a row that named Configuration, Published, Notebooks, Links, and Info beside Forecast and Doppler. That row is better scientific indexing than a rotating banner. The failure was treating every label as the same kind of object. Forecast is a future-valid product from an issuing office. Info is station identity. Links are outbound provenance. Published is how files left the site. A section landing exists so those labels are not competing for the same hero cell.
Keep the labels. Drop the implication that clicking Info will show today’s wind.
Practical checklist
- Give the documentation cluster a single public index (
/weatheron this host). - Name each child page’s job in one sentence on that index.
- Keep website configuration separate from hardware siting.
- Keep the visitor fact sheet separate from the dashboard and from a compact software-host card.
- Split link curation, the directory hub, and directory maintenance.
- Write the FAQ as sourced Q&A, not shuffled folklore.
- Point publication notes at the publish URLs; do not duplicate banners here.
- Put current stats, forecast, and imagery on the dashboard family only.
- Link the weather-station hub so the cluster is findable from the legacy library.
- Send hazard users to NWS, not to a personal FAQ.
Modern relevance
Station sites still fail in the same place: a well-built gauge page with no durable map of metadata, sources, and limitations. Researchers, neighboring operators, and later owners of a domain need that map more than they need another copy of the temperature. Connection-intelligence work has the same requirement in a different domain: say which evidence family a page is using, and keep the supporting notes where a stranger can find them.
TNET’s data sources, quality controls, and methodology page is the modern statement of provenance for public records used in research. It does not replace a PWS section landing, and this landing does not describe how any proprietary estimate is assembled.
Related pages in this cluster: website configuration, visitor station facts, curating scientific links, and a scientific station FAQ.
Sources
- National Weather Service: weather.gov
- World Meteorological Organization, Guide to Instruments and Methods of Observation (WMO-No. 8): library.wmo.int
- NOAA National Centers for Environmental Information: ncei.noaa.gov
- TNET, Weather station hub
- TNET, How the service works
- TNET, Data sources, quality controls, and methodology