A personal digital assistant (PDA) weather page is a small-screen observation, not a second website. Palm OS, Pocket PC, and early Windows Mobile devices offered a few hundred pixels on a side, slow radios, and browsers that choked on desktop tables. The scientific requirement did not shrink with the glass. A complete record still needs station identity, a timestamp with zone, and every quantity paired with its unit. A tiny layout that drops those pieces is a fragment, not a handheld dashboard.
The historical TNET Weather URL /pda-view.php on the main station site served that PDA-oriented view of a Mesa, Arizona station. A recovered capture dated 28 March 2014, 11:37 MST is used below only as a dated example of structure. Those figures are not current weather, and this URL is not a live meter.
This article is not the Cumulus-host mobile site root, which is later responsive HTML after WML. It is not a WAP deck. It is the earlier, device-class problem: how a complete observation survives a screen that can show only a handful of lines at a time.
Historical context
Station operators added compact views in layers as handsets changed. Before smartphones rendered ordinary HTML well, PDAs and “mobile” bookmarks wanted a page that omitted radar widgets, webcam chrome, and multi-column high/low grids. Weather Display sites often published a dedicated PHP view for that class of client: one column, large type, a refresh note, and the same logger packet the desktop used.
/pda-view.php was that view on tnetweather.com. Incoming links treated it as the handheld current-conditions URL, not as a software project and not as a Cumulus /m directory. TNET does not restore the old stylesheet, a device detector, or a live PDA emulator. The useful residue is the contract: reduce chrome, keep the record.
A sister product on the same host was the text bulletin. The bulletin is linear prose for Lynx, screen readers, and archives. The PDA view is still a page—headings, a refresh control, maybe a switch to charts—but it is built for a pocket screen. Both fail in the same way when units and time are treated as optional decoration.
What “PDA” meant as a publishing constraint
A PDA is not a synonym for “phone.” In the era this URL names, it usually meant a stylus device with a small color or grayscale panel, often 240×320 or 320×320 class, sometimes docked to a cellular modem. Practical consequences for a weather page:
- Viewport is a budget. Every decorative row steals a scalar. System statistics, access counters, and browser-IP debug lines that appear in recovered desktop captures do not belong on the first screen.
- Refresh is expensive. “Data is updated once a minute” is an observed-file claim only if the handheld view actually re-reads that file. A meta-refresh that reloads a stale cache is a live costume.
- Input is clumsy. Deep navigation, image maps, and hover tooltips fail. The first screen must already be a complete observation.
- Bandwidth is bursty. Charts behind a second link are acceptable. Auto-loading a graph library on the PDA URL recreates the desktop problem the page existed to avoid.
Later smartphones and a path named /m solved a different generation of that budget with HTML, CSS, and a viewport tag. Keep the URLs distinct. A PDA bookmark that suddenly receives a responsive Cumulus skin is a different product, even if both fit in a pocket.
Completeness does not scale with pixel count
Professional METAR practice packs location, time, wind, visibility, weather, sky, temperature, dew point, and altimeter into one line so a human or a parser can recover the observation without the original layout. A backyard PDA page does not need METAR code. It needs the same information contract as any current-conditions record:
- Station identity and location.
- Timestamp with timezone or offset. Clock time without a zone is not an observation time. The recovered Mesa capture’s
MSTtoken is doing real work. - Air temperature with unit.
- Wind speed, unit, and direction. Calm must be stated as calm (or zero with a unit), not omitted.
- Rain as an amount and a period, or an explicit “none” for that period.
- Pressure with unit, and tendency if you have it.
Derived indices—dew point, wind chill, heat index, humidex, apparent temperature, estimated cloud height, fire index—may follow. They must be labeled as derived so they are not read as thermometer data. Forecast sentences are a different evidence family. If they appear, they need a source and a valid time, or they need to wait behind a link.
A four-line PDA screen that shows 72.9 with no unit and no clock has failed. Enlarging the numeral does not repair the record.
A dated Mesa PDA capture, used as structure
The recovered /pda-view.php snapshot is labeled 28 March 2014, 11:37 MST, for the historical Mesa station. In that capture the outdoor thermometer read 72.9 °F, wind was calm (0, from the SSE), barometer about 30.1 inHg, humidity 31%, and rain today none, with month and year rain totals also listed. Solar, UV, indoor “office” readings, pool temperature, and a fire index appeared on the same page, plus a forecast sentence (mostly sunny, highs 75 to 80) that is not an observation.
Those values illustrate layout pressure. They are not current Mesa weather.
What the capture got right. Time with a zone sits near the top. Temperature carries °F. Pressure carries inHg. Rain is tied to named periods (today, month, year). Calm wind is present as a number rather than a blank.
Where a tiny-screen edit would cut. Logger version, workstation uptime, memory, VP reception, burn-time estimates, and access counters are station diary. They teach nothing about the outdoor air and they push the pressure row off a 320-pixel panel. Indoor and pool sensors are extra instruments; they need their own labels so they are not mistaken for the shelter thermometer.
Observation versus forecast. The snapshot’s forecast clause must not be quoted as “the PDA said it was 75 to 80.” The PDA said the thermometer was 72.9 °F at 11:37 MST. The forecast is a separate product.
Last-hour mini-table. Ten-minute steps of temperature, humidity, dew point, barometer, and rain are a short historical series, not “current” twice. On a PDA they are optional. If shown, the clock of the latest row must match the headline time, or the page is disagreeing with itself.
PDA is not WAP and not /m
Three compact URLs get cited as if they were aliases. They are not.
| URL | Host | Job |
|---|---|---|
| /pda-view.php | tnetweather.com | HTML (or simplified HTML) observation for PDA-class screens |
| /wap.php | cumulus.tnetweather.com | Served WML/XHTML-MP deck from Cumulus files |
| /m | cumulus.tnetweather.com | Later HTML mobile root after WML |
Markup may change. The observation must not. If the PDA view shows °F and a WAP deck shows °C from a different template, you have two stations in one costume. Representations of the same station bind the same fields. Fail visible: if the station file is missing, say so in text. A blank hero panel on a PDA is indistinguishable from a radio failure.
Do not user-agent-sniff a desktop visitor onto /pda-view.php as a “lite” theme while changing numbers. Lite is layout. The record stays.
Practical checklist
- Put identity, time with zone, and unit-bearing scalars on the first screen.
- Label derived indices and keep forecast language in a separate block.
- Omit system stats, access counters, and debug IP lines from the handheld view.
- Refresh against the station file’s age, not against a decorative “LIVE” string.
- Offer charts behind a link; do not load the desktop graph stack on the PDA URL.
- Treat recovered captures as historical. Do not present this path as a live Mesa meter.
- Keep
/pda-view.phpdistinct from Cumulus/mand from WAP endpoints.
Modern relevance
Phones outgrew PDAs. Constrained views did not disappear. A watch face, an SMS alert, a status widget, and a terminal session all reintroduce the same budget: few lines, high cost of a missing unit. Completeness is still identity, time, and labeled quantities.
TNET’s public research distinguishes observed, modelled, and derived information. A PDA page is a test of that distinction under compression: the headline number must remain the sensor, and everything else must say what it is. How those families are described without internal forecast weights is how the service works. Related instrument pages sit on the weather-station hub.
Sources
- World Meteorological Organization, Guide to Instruments and Methods of Observation (WMO-No. 8): community.wmo.int
- National Weather Service, METAR decode key: weather.gov (PDF)
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2: w3.org/TR/WCAG22
- TNET, How the service works
- TNET, Weather-station hub