The screens, before the code

Tahoe Backcountry Radio is a community FRS radio program run by the Patrol: each zone has a shared channel so groups can trade hazard reports and call for help. This site shows every screen of the program's application as a wireframe, before it is built. Stewards, patrollers and the community read a page and answer one short form; Jamie and Chuck read the same pages and the progress. The application behind the screens is drawn on the architecture page, twelve components and three seams.

The journey

Reading order, grouped by who is acting, in the launch order Jamie set on 2026-10-14 PT: after the live import, the event list read only, then sign-in and event sign-up, then the simplest install record, then sign tickets. Progress is function points per screen (1 per state, 2 per form, 1 per server rule, 3 per outside source or offline behaviour, 2 per email), closed tickets over the total plus a one-fifth allowance for points not yet seen, refreshed by scripts/journey_progress.py when a pull request merges.

Overall: 3% of the launch points built (6 of 188, allowance included); 3 of 11 launch screens have a closed ticket behind them.

How to read this

Each page is one screen: the story in three sentences, the flow, a wireframe with invented people, three effort levels with the committed one marked, what its tests prove, the measurements, and the open questions in a violet box. Read the screens you would use, then answer the form.

What we want to learn from user testing

The five answers Jamie wants (2026-10-14 PT). Each page's measurements strip is wired to the usage compartment, which records opened, form started, saved offline, sent, abandoned and the time between, keyed by a random per-phone id, never by email, with no third-party script.

1. Do skiers finish a check-in in the cold? Time from scan to sent, and where they stop.
2. Do they trust the channel they read? Do they open the planning page before a trip?
3. Do installers finish an install record at the trailhead with no signal? Saved, then sent.
4. Do stewards sign in from the email link and come back?
5. Which fields are left blank every time? Candidates for removal.

Measurements

Placeholders until the screens are live; they then fill from the usage compartment, summarized per screen beside the function points.

Testing

Every pull request runs the tests, the lint and the seam check before it merges (#75). The counts below are for the last merge on main, 8db4e5a, filled by hand on 2026-10-14 PT.

What the tests prove, one line per launch screen; the January pages carry their own lines.

• Planning pagean expired forecast never renders a rating; the page says so and links to SAC.
• Check-in page300 m from a sign matches it; 900 m asks the person to pick.
• Sign-in by email linkone link or code signs one phone in until June 1 PT and refuses after it.
• Steward's own pagea person sees only their own check-ins, never another's.
• Events: list and sign-upthe list needs no sign-in.
• Install recordan install recorded offline arrives once when the page reopens with signal.
• Sign tickets and pickupcreates install work for exactly the signs without an installed sign or an active ticket.
• Admin map and work listonly an admin opens these pages; everyone else is sent to sign in.
• One sign location's recordthe AHJ's contacts and address appear here and nowhere public, nor on the read API.
• People and steward approvalan anonymous check-in never counts; a check-in by email from an approved steward counts.
• The six emailsno email lists another recipient, and none prints a phone number or street address of a person.