Receiving reports from the public
Let trail users report a fallen tree or a broken plank, with no account and no email — and choose what they can consult in return.
Your trail users see problems before you do. They ride your trails every day, and when a tree comes down across one, they know that same morning — while your crew will find out next week.
The obstacle was never their goodwill. It was the form. Creating an account, remembering a password, finding the right page: nobody does that standing in a trail holding a bike.
Public reports remove all of it. The user opens the app, takes a photo, sends. No account, no email, no password. You receive a geolocated report, with the photo, in an inbox waiting to be triaged.
Where: left navigation bar, under Trails → Public reports for the settings. The inbox is under General → Public reports.
What the user sees
On the very first launch, the app asks one question. It does not assume the person is on your crew: it asks whether they are here to report a problem, or to sign in to an account. The choice is remembered on the device and never comes back.
The first launch, before anything else.
- 1What your club does, in one sentence. This is what someone opening the app for the first time reads.
- 2The user's path: no account, no email.
- 3Your crew's path, kept quiet. It stays reachable from the façade.
Then the app explains what it needs on the phone — before asking for it. Four screens, one per permission, each saying what it is for and what still works without it:
| Permission | What it brings to a report |
|---|---|
| Location | The exact spot of the problem, and recognising your network. It is the only one the app cannot do without |
| Camera | The photo taken on site |
| Photos | A photo taken earlier, when the user reports from the parking lot |
| Microphone | A voice memo, for what the photo does not show |
The first of the four steps.
- 1The progress bar: four steps, never more.
- 2What Sentinel does with the position, written right before the request.
- 3The button leads to the phone's own dialog. That is where the user accepts or declines.
The last three permissions are optional, and the screen says so. A permission that is already granted is not explained again.
Location, though, is not negotiable. A report with no coordinates would be no use to you: you would know something is wrong somewhere, without knowing where to go. So the app refuses to send it, and says so plainly instead of letting the user push a button that does nothing.
The façade when the user has declined location.
- 1The network is still recognised — the code from your sign is enough for that.
- 2The reason, written right above the button it switches off.
- 3The report button is off. It leads nowhere, and it shows.
- 4The only way out: turning location back on in the phone's settings.
- 5Consulting stays allowed. Reporting is what needs a position, not looking.
So the code from your sign is still useful without location — it gets your network recognised, and the user can consult your map and your conditions. But it does not stand in for a position, and the report button stays off until location is turned on.
There are two ways to end up without a position, and the app no longer treats them as one. The first is a refusal: the user answered no to Sentinel's request. The second is the phone itself — its location service is off for every app, and however granted Sentinel's permission may be, nothing will ever be computed.
The second case is the more baffling one for the user, because nothing points to it. So the app names it plainly, and sends them to the right place.
The façade when it is the phone itself that has location switched off.
- 1The cause, named: this is not a refused permission, it is the phone's own service.
- 2The report button is off, just as in the other case.
- 3The way out changes: it opens the phone's settings, not the permission request — that request would do nothing, since the permission is already granted.
Either way, as soon as the user comes back to the app after sorting out their phone, it picks its search back up on its own. There is nothing to restart.
After these screens, they land on a façade stripped to the essentials: your network's name, and one button.
The public façade, once the network is recognised.
- 1Your network's name and its trail count. The app recognised it — from the trailhead QR code, from the code, or from the user's position.
- 2The report button. It is the only path, deliberately.
- 3Your trail map, if you allow it.
- 4Your published trail conditions, if you allow them.
The two tiles at the bottom are not mandatory: you decide on each in the settings. A network that does not publish conditions does not show the tile.
How the app finds your network. Three paths, in this order:
| Path | When it helps |
|---|---|
| The trailhead QR code | The normal case. One scan, and the user lands on your network's façade without typing anything |
| The six-character code | When the camera will not cooperate, or the sign is damaged |
| Position | The app offers the networks around the user |
The QR code and the code come from the same settings page, ready to print.
Through position, the user does not land straight on your façade: they see a list, and you appear on it with your name, your town, your distance and your number of trails.
The list of networks, when the user is looking for yours.
- 1The sign code, always within reach from the header.
- 2Search by name, for someone who knows your club without standing in front of the sign.
- 3Around you: the networks within reach, nearest first.
- 4Already visited: the networks the user has been to. A regular finds yours without typing anything, and without waiting for their position.
If position does not come through — a temperamental GPS, no signal under the canopy — the app says so and offers to try again, instead of leaving the user in front of an empty list.
Recognising the network needs a connection. Whichever path is used — QR code, code or position — the app has to reach Sentinel once to work out which network this is. It is the only step that requires it: after that, reporting works offline and the submission goes out as soon as coverage comes back. So a sign planted where there is no signal at all will not get the user in on the spot.
Scanning also works when the app is already open. A user arriving from another network, or in the middle of looking one up in the list, switches over to yours and lands straight back on the façade, ready to report. And if the code on the sign leads nowhere — a closed network's sign, a damaged sticker — the app says so instead of staying silent.
The report itself
Three things, only one of which is mandatory.
The submission screen, user side.
- 1The position, taken from GPS. The user can correct it on the map if the problem is a few metres away.
- 2The photos. This is what makes a report usable.
- 3The description, free text.
- 4Sending. With no coverage, the report goes out on its own as soon as the connection returns.
We do not ask for the problem type. That is a decision, not an oversight. Asking a trail user to choose between "erosion", "drainage" and "structure" asks them to do your classification work — and they will choose badly, which costs you more time than asking nothing. A photo and a position are enough: you classify at triage, knowing what you are looking at.
The first name is optional, and it is all we ask for. No email, no phone, no last name. You cannot contact a reporter back — that is the price of no-account, and it is also why people actually send.
It works with no coverage. The report is queued on the device with its photos and goes out when coverage returns. The user sees right away that it is saved.
What the user learns next
A report that vanishes into the void does not get repeated. So the user can follow theirs from My reports, and they get a notification whenever you move it forward:
| What you do | What the user receives |
|---|---|
| You accept the report | "Work is planned" |
| Work starts | "The crew is on it" |
| The task is finished | "It's fixed" |
| You refuse | The reason, if you choose to share it |
| You attach it to an already-fixed problem | "It was already fixed" |
These notices are deliberately thin on detail. The user has no access to your planning, your assignments or your discussions — they only know where their report stands.
Those notices need a permission, and it isn't asked for up front. The four screens at the start say nothing about notifications: as long as the user hasn't sent anything, the question would mean nothing to them. It is put to them right after their first report, on the confirmation screen — the moment they have just handed you something and want to know what becomes of it.
The send confirmation, with the notification offer right below it.
- 1The confirmation, immediate: the report is saved, even with no signal.
- 2What notifications will bring, in one sentence.
- 3The button leads to the phone's own request. It's the only moment it is offered on its own.
- 4Declining here closes nothing: the offer comes back on the next report.
If they answer "Later", the offer comes back on the next send. And if they change their mind in between, the switch stays in My reports, under the bell icon. Worth knowing on your side: a user who never allowed notifications will only see your progress by reopening My reports. The follow-up isn't lost — it just goes quiet.
The settings
Everything is decided on one page, and nothing is active until you turn it on.
The public report settings.
- 1The master switch. Off, the public can send nothing and the rest of the page is greyed out.
- 2Photo required, and first name asked or not.
- 3What the public can consult: the trail map and your published conditions.
- 4Nothing is saved until Save.
Leave photo required on. A report without a photo is almost always unusable: "there's a tree" says nothing about the size, whether a handsaw is enough, or whether it takes two people. You can make it optional, but you will harvest noise.
Your network's visibility is set here too, in three steps:
| Step | Who can report to you |
|---|---|
| By invitation | Only those with the QR code or the code |
| Found on site | Those physically inside your zone |
| Listed | Anyone who finds you in the network list |
Start on By invitation long enough to see the volume, then widen. That is easier than the reverse.
A daily cap limits the number of reports per device per day. It exists so one frustrated user cannot fill your inbox.
Turning "Trail map" off also clears the cache. If you allowed it and then withdrew it, the trail lines already downloaded to phones are erased on the next opening. The setting does more than hide a button.
Your code and its QR
They are not created along with your account: your sign code and its QR are born the first time you open up — that is, the first time you turn the master switch on and save. Until then, the bottom of the page shows you the spot waiting for them.
The trailhead sign block, before you first open up.
- 1The spot for the QR, still empty. Nothing is hidden behind it: the code does not exist yet.
- 2What is left to do to get it. The sentence changes as soon as you turn the switch on: all that remains is to save.
One save is enough. The code and its QR appear in that same spot, with what you need to carry them to your sign.
The same block, once your network is open.
- 1The QR to put on your trailhead sign. That is the normal path: one scan, and the user is on your network.
- 2The six-character code, for whoever would rather type — or when the sticker is damaged.
- 3Download the QR at print size, or change the code.
Changing the code takes the signs already posted out of service. A new code is drawn and the old one leads nowhere: do it only when you have to kill a display that got away from you, and reprint right after.
When you close up, the block greys out. The QR and the code fade, and the page says why: the opening is closed, so they lead nowhere. Nothing is lost for all that — when you reopen, it is the same code, and the signs already planted start working again without you reprinting anything. Downloading the QR stays available meanwhile: preparing your signage before opening is the normal case.
When you close up, phones notice. Turning off the master switch — or tightening visibility back to By invitation — does not leave your users facing a button that no longer answers. The app rechecks your network every time it opens and every time it comes back to the screen; as soon as your network stops accepting it, the reporting button goes dark and the reason appears right above it.
The front screen, once the network no longer accepts this device.
- 1Your network name stays on screen: the user knows which network this is about.
- 2The reason, written above the button it turns off.
- 3The reporting button is off. Just like without a location, it leads nowhere, and it shows.
- 4Whatever the user already downloaded stays readable offline.
The "Change network" link just below stays their way out: they can join another one without reinstalling anything.
Three things to know before you close up:
- Count half an hour, not an instant. A user already inside the app may carry on for a few minutes, until their current visit expires. That delay is not something to fear: it is the same grace that keeps a dropped signal from throwing them out in the middle of the woods.
- A report taken but not yet sent does not wait forever. It turns to "Not sent" and the user sees it. Honest bad news beats a report that spins for good.
- What is already on the phone stays readable. Your downloaded map and conditions remain available offline. Reporting is what needs an open network, not looking.
If you open up again, everything comes back without your users having to download anything twice.
Once they start coming in
Reports arrive in an inbox separate from your tasks, because a report is not a task: it is information to verify. What comes next — triaging, creating the task, grouping what repeats — is in Triaging reports from the public.