Designed for the field

Light is the default, and that is a decision

A phone held at arm's length in direct sun is legible on white and close to useless on charcoal. So the base scheme is high-contrast light, with status colours that are saturated but dark.

Dark mode exists because the other half of the job is real: fiber crews do night cutovers and emergency restoration, and a white screen at 2am in a bucket ruins your night vision and everyone else's. The app follows the phone by default and can be pinned either way — rather than picking one and being wrong for half the work.

Everything you tap is at least 48 pixels

A gloved thumb is roughly 44–48 px across. That is the floor for every button, row and field a crew touches — collapsing sections use 52 px.

It also decides things that are not buttons. On the map, a span is a 5 px line: requiring a crew to hit it precisely would make the map a toy, so the tap radius is sized for the thumb rather than the line. Where a pole and a span overlap, the pole wins, because it is the smaller target and the one you meant.

Nothing important needs a gesture, hover, or a second hand

A crew wearing gloves is exactly the user who cannot make a precise gesture. Every primary action is a button you can hit, not a drag, a long-press, or a swipe. Where a gesture exists it is a shortcut for something that is also a control.

A number always says what it is counting

The most dangerous thing a field app can show is a production figure whose scope is ambiguous — today, this span, or this job to date. They never share a typeface here, and the scope sits on the number's own line rather than as a caption under it.

This one is borrowed. A competitor generated a support article because their users could not tell which scope a quantity covered. It seemed cheaper to read their article than to repeat it.

The map draws with the radio off

Poles and spans are drawn from what is already on the phone, on a plain background, with no network request on any path. Map tiles are the backdrop; the geometry is the answer.

And when we do not yet know whether there is signal, the app starts on geometry and earns the backdrop — never the other way round. Starting optimistic and falling back shows a crew a grey rectangle at exactly the moment they need the plan.

An error tells you what to do, not what failed

“Upload failed” is not actionable. When a photo's file is gone from the phone, the app says the file is gone and to retake it — and stops retrying, because retrying cannot bring bytes back and a queue that never drains is a crew that is never told.

The same rule covers refusals from the office. “No connection” and “the office declined this” send a crew to two completely different places, so the app never says the first when it means the second.

We would rather show nothing than guess

A screen that renders a confident answer before its data arrives is worse than a screen that waits, because the wrong answer looks exactly like a right one. Several parts of this app are built so that “we don't know yet” and “we know, and the answer is the default” cannot be the same value.

What we have not proven

These are design decisions, taken deliberately and written into the code where they are made. They are not the results of a field study. Nobody has watched a crew use this app in gloves, in direct sun, or at 2am in a bucket, and we are not going to imply otherwise.

We will update this page when that changes — including if it tells us we got something wrong. If you run crews and any of the above does not match your experience of the app, that is the most useful thing you could tell us.