Method

Designing field applications for operational conditions

Field applications are typically specified last and are the component that determines whether the remainder of the system produces an outcome. Low-specification devices and absent connectivity are primary design constraints.

6 min read

Procurement for a monitoring system is written around the platform. The models, the dashboard, the reporting. The mobile application usually appears as one line near the end.

It is the component that determines whether the programme works. Everything upstream produces a detection; the app is where a detection becomes a finding. If the officer cannot use it, the system produces alerts and no outcomes, and no amount of model accuracy compensates.

The device is not the one in the specification

The phone in the field is the officer's own, is two or three generations old, has limited storage, and is shared with everything else in their life. An application built and tested on current hardware, on office wifi, will be installed once and abandoned.

Which means the constraints are: install size, cold start on a slow device, memory headroom while the camera is open, and battery cost across a working day of GPS. These are not performance nice-to-haves. They are the difference between adoption and a pilot report.

Offline is the normal case

The places worth monitoring are the places with no signal. That is not a coincidence — remoteness is why satellite monitoring is the right tool there in the first place.

So connectivity cannot be a precondition for any step. Assignments and basemaps have to be on the device before the officer leaves. Capture has to complete and persist locally. Submissions queue and sync when the phone is back in range, and the officer has to be able to see that the queue exists and is draining — a silent queue is indistinguishable from lost work, and one officer's lost day of evidence ends the programme's credibility faster than any model error.

Assignments and basemaps cache before the officer leaves; submissions queue and sync on return.

Capture the things the device already knows

Every field taxonomy the office designs is longer than the one the field will complete. The reliable rule: capture automatically what the device can capture automatically, and ask the human only for what only a human can supply.

  • Position, time and device come from the device. Never typed, never editable.
  • Photographs are geo-tagged at capture, not attached afterwards from a gallery.
  • A voice note replaces a paragraph nobody will type standing in a field.
  • Structured remarks stay short and closed-vocabulary, because free text is where field data goes to die.

It fits a working day or it does not happen

The realistic budget for a single verification, including walking to the point, is a few minutes. Design against that number. Anything that turns a visit into a paperwork exercise will be completed at the end of the week from memory, and at that moment the record stops being evidence and becomes recollection.

The field officer determines whether the system produces an outcome. Every other component is upstream of that point.