The documentation is public, and updates are yours to take

Shipped the week of August 31.

A long week. The documentation came out from behind the login, the field app stopped deciding for itself when a crew gets a new version, and the engine that judges whether a trail is too wet to walk started counting rain that was measured rather than predicted.

The documentation is public

Forty-two articles and about eighty-seven thousand words — everything from importing a GPX file to how the trail-conditions engine decides what to recommend — are now readable at trailsiq.com/docs with no account.

They were always there; they were behind a login, which meant the most substantial writing about this product was invisible to anybody deciding whether to use it. If you want to know exactly what TrailsIQ does before you sign up, or send a colleague a link to the part that answers their question, you can.

They stay in step with the app. Publish an article in the morning and it is on the public site the same day.

You decide when the crew updates

The field app no longer installs a new version on anybody's phone on its own. Every version is available the day it ships for anybody who goes looking, nothing installs itself, and we choose when your crew is told.

That one got a post of its own — read it here.

Trail conditions count the rain that fell

Whether a trail is too wet to walk is a question about the last five days as much as the next three, and those five days have already happened. So for organizations in the United States they are read from what the National Weather Service measured — the gauge-corrected estimates its River Forecast Centers publish for rain that actually fell. Only the days still ahead come from a forecast, which is what a forecast is for.

Coverage is good and it is not uniform. Where no measurement is available for a day, that day keeps the figure it had, and everything else about the score is unchanged.

There is nothing to turn on and nothing to choose. Open a network's trail conditions and the five days behind it are the weather that happened.

A recording starts where you are standing

When you start a recording you are always exactly where you want the trail to begin. So that is where the line begins now — the moment you tap Start becomes the trail's first point, and it is drawing from your first step rather than catching up with you.

Start also unlocks at exactly the accuracy at which a fix can be recorded, so the button is available precisely when it will do something. The warmup screen holds it until your receiver is ready and then hands it straight over.

Trail inspections, finished off

Last week's inspections gained the parts that make them a record rather than a form:

• The questions are yours to word. Add your own, phrase them how your crew talks, and set which answers mean caution or closed. Editing them never changes what is already recorded — every past inspection keeps the questions as they were worded on the day.
• Trails → Inspections, a list across every trail at once, with filters and both exports.
• The history on the phone, on the trail itself: every walk, what changed since the one before it, and the photographs from each.

An inspection that knows what a counter is for

A trail counter can look perfect and be useless, so inspecting one now asks about the instrument rather than the object: power, what the sensor is looking at, the post, inside the case, signs of tampering — and the one thing you cannot see from the trail, has it counted since the last visit?

Answering nothing recorded fails the counter outright, whatever the rest of the answers say. It is the only place in an inspection where something straight, dry and unmarked is graded as failed, and it is deliberate: a counter that has recorded nothing for six weeks is a post. Better to find that on the trail in September than in the season's numbers in December.

Bridges, gates and signs already had questions written for them. Counters make four, and everything else still starts from a general set you can rewrite.

The work report reads as three charts

Work report now puts three charts across one row — Hours by Member, Top Task Creators and Top Task Completers — so who put the time in, who is filing the work and who is closing it out are one glance rather than three readings of one table.

Hover any bar and its number arrives in a chip beside the pointer, with the other bars dimmed so the one under your cursor is the one you are reading. Hours read as hours.

By issue type and By trail sit side by side above them, and where a column heading needs a definition there is now a small i beside it that gives you one.

Also this week

One definition of climb, everywhere. Length, climb, descent, average and maximum grade are measured the same way on every screen that reports them — the planner, the trail page, an imported GPX and the phone. Ask any of them about the same trail and you get the same answer.

Trail-quality scoring measures over a fixed distance. Grade and direction are read over a set baseline rather than over whatever gap your receiver happened to leave between points, so a trail scores on what it is rather than on how it was captured — and a line you walked and a line you drew are judged alike.

Suggest reports on the line it is offering you. The grade, side-slope and fall-line figures beside a suggested route are measured on the route itself, so they are the numbers the trail page will show once you save it.

Editing a recorded line happens on the map. Cleanup opens with the map filling the screen and Cancel, Undo and Save along the bottom; the stats are one drag up, and the sheet goes back where you had it when you leave.

A report from a trail user is filed once. Sent from a spot with one bar, and sent again by a phone that could not tell whether the first one arrived, it still reaches you as a single report to review.