Skip to main content

Mobile and Field Context

TuffOps is a responsive web app, not a native iOS or Android app. Field techs use it through a phone or tablet browser. This page describes what that means in practice — what works well, what doesn't, and which permissions matter.

What TuffOps is, on a phone​

A standard browser at a standard URL. There's no app store install, no native push, no background sync. The technician opens the same https://... URL the office uses and signs in with the same credentials. The layout adapts to the screen size.

Two consequences are worth being explicit about:

  • No offline mode. A network connection is required to load and save. Photos and notes can't queue locally and sync later. If the cell signal at a job site is unreliable, that's a real constraint — the tech needs to wait for signal to save, or do the data entry in the truck where signal is better.
  • No native push notifications. Status changes, override decisions, and alerts surface inside the app on next page load (or when the alerts feed polls). Critical notifications are also sent by email; the email is the reliable channel for "you need to know now."

Phone vs. tablet vs. laptop​

The same pages render on every device. The right device for the moment depends on the task:

TaskPhoneTabletLaptop
Find your jobs (list or schedule)GoodGoodGood
Scan a QR codeBestGoodN/A
Start / pause / resume / submitGoodGoodGood
Add a photo from the cameraBestGoodGood (webcam)
Add many items via the pickerCrampedBestGood
Fill a long checklistCrampedBestGood
Capture a customer signatureOKBestOK
Office-side work (approve, bill, invoice)N/AOKBest

The phone shines for capture (QR, camera, GPS, single status changes). The tablet shines for entry (items list, checklists, signatures). The laptop is for the office.

A common pattern: phone in pocket for QR scans and signatures, tablet on the truck for the bulk of the work. Both are signed into the same account; the work order is the same record.

Browser permissions​

Three browser-level permissions matter on a field device. Each is requested the first time TuffOps needs it; the prompt is the OS prompt, not a TuffOps UI element.

Location​

Required for:

  • Capturing GPS coordinates on Start Work Order, Pause Work Order, Complete Work Order, and other status transitions.
  • The GPS pin shown next to each entry in the work order's History.

How it works in the app:

  • TuffOps requests location with a 10-second timeout.
  • If the user denies, or the timeout expires, the status transition still proceeds — without coordinates. The history entry shows no GPS.
  • The browser remembers the choice. On iOS Safari, Settings → Safari → Location controls per-site permission.

Camera​

Required for:

  • Photo upload via the Files card. The browser presents a file picker that includes a "Take Photo" option on mobile.
  • QR code scanning, if the device's camera is used in a field tool. (TuffOps QR scanning is the OS camera or a dedicated QR app, not an in-app reader, so the camera permission is per-app, not per-site.)

Notifications​

TuffOps does not request browser notifications. Critical alerts go through email, and the in-app alert feed updates on poll. If a tech wants real-time alerting, set up email forwarding to the device's mail app and use the OS notification system.

What "works" on a small screen​

The Docusaurus side and the TuffOps app both have responsive layouts. Specific things that work well at phone width:

  • The Status widget on the work order page collapses cleanly and stays at the top.
  • The Work Orders list collapses to a card layout with the most relevant fields stacked.
  • The Schedule card on Home scrolls horizontally; the day grid is the same dimensions, just narrower.
  • Modal dialogs (item picker, charge event panel, customer signature) take full screen.

What's harder at phone width:

  • The items table on a work order with many rows requires horizontal scrolling.
  • The Filter card on list pages collapses, requiring a tap to expand.
  • Side-by-side comparisons (e.g., the History panel and the form) don't fit; the panel slides over.

Offline workarounds​

Since TuffOps doesn't have offline mode, real workarounds for spotty signal:

  • Pre-load on signal — open the work order in the truck before walking up, while you have signal. The form stays loaded while you walk in. Saves require signal again.
  • Stage data in notes — type into the notes field (text) and copy-paste into items when signal returns. The notes input is local until you save.
  • Take photos in the camera roll — use the OS camera. Upload from the Files card when signal returns. The photos are tagged by the OS with their capture time, which the office sees.
  • Submit for approval indoors — the customer signature step needs network; do it in the truck or in the office, not at the unit.

For organizations with many remote sites, a Wi-Fi hotspot per truck is a more reliable solution than relying on cell signal.

What we deliberately don't do​

A few things people sometimes ask for that TuffOps doesn't ship:

  • PWA install / "Add to Home Screen" — supported by the browser, not customized by TuffOps. The icon is the favicon; the launcher behaves like a bookmark.
  • In-app camera reader — using the OS camera and the OS QR handler is more reliable across devices.
  • Local data cache — risk of stale or conflicting state outweighs the benefit; the rules around four-eyes and compliance gating need a single source of truth.
  • Native iOS / Android apps — the maintenance cost would shift effort away from the compliance and lifecycle features that differentiate TuffOps. The web app meets the field need.