Fieldnote

A site visit rarely happens beside a reliable connection. Notes can end up split between a camera roll, a voice recording and a checklist that lives somewhere else. Fieldnote is a self-initiated concept for keeping that material together in a mobile app, with the visit as the organising unit.

The proposed experience begins with a local record, not a loading state. Someone should be able to begin a visit, move between capture tasks and leave the app without a successful network request. That constraint changes the architecture: the device has to be useful on its own, and the server becomes a later reconciliation point rather than the permission slip for every action.

The interesting question is not whether a note can eventually upload. It is what the product owes a person while it cannot. A truthful interface must show that a record is safe on the device, distinguish it from a confirmed shared record, and leave uncertainty visible when two people have changed the same visit. This study explores that reasoning. The linked app now provides local capture and storage; synchronisation and shared records are not built.

1. Write the visit record to local storage before any transfer is attempted.
2. Queue the operation while the device is offline, then reconnect when a network path is available.
3. Compare the local and shared versions at reconciliation time.
4. Use the gold route for a clean merge when the changes are compatible.
5. Use the teal exception route for a conflict, preserving the versions for human adjudication.

The diagram makes one product promise deliberately narrow: a connection failure should not erase a local observation. It does not pretend that every edit is mergeable. A checklist item can often be reconciled as an independent fact; a rewritten observation may carry intent, sequence and context that a generic merge cannot safely infer.

• Write locally before attempting sync.

  The proposed architecture uses a local database and a pending-operation queue. A network interruption should delay transfer rather than block a note. The rejected alternative is a server-first form with a cache added later: it is easier to describe, but it makes the moment of poor connectivity the moment a field tool is least trustworthy.

• Keep attachments separate from the visit record.

  Photos and audio would have their own transfer state. Text should not wait for a large file to upload, and an attachment retry should not duplicate the visit. The trade-off is more state to explain in the interface, accepted so that a useful written observation is not held hostage by a slow or interrupted media transfer.

• Surface conflicts instead of silently replacing work.

  Concurrent edits would preserve both versions for review. Automatic merging may suit independent checklist changes, but replacing a written observation without explanation would be a poor default. Last-write-wins was rejected because its apparent simplicity moves the cost of an ambiguous edit onto the person who can no longer see what disappeared.

• Put the next action within reach.

  A short checklist keeps the capture path visible without a dense form. Camera and microphone permissions would be requested when needed, with an alternative path when access is declined. The constraint is one-handed, interrupted work: a full desktop-style form may capture more fields, but it asks for attention the context does not reliably provide.

Try the checklist below. Each item is a real checkbox with a clear checked state, and the message changes when the visit checklist is complete. The interaction works with a keyboard as well as a pointer.

The mockup deliberately stays within that boundary. It contains illustrative tasks, does not access a camera or microphone, and resets when the page is refreshed. This webpage is not the offline-capable app; open Fieldnote for local visits, checklists, photos, voice notes, observations and export. It has no synchronisation, accounts, sharing or server.

Proposed: React Native with TypeScript for the mobile interface, SQLite for local records, and a PostgreSQL-backed API for shared state. A separate object store would hold attachments. These are architecture candidates, not a confirmed implementation. Device testing, background execution limits and conflict behaviour would determine the final choices.

The important boundary is not a framework name. It is whether local mutations have stable identities, whether retries can be made safe, and whether the shared API can reject a stale edit without losing it. Those rules should be exercised with interrupted transfers and competing changes before capture features make the surface area larger.

Local capture is built. The linked self-initiated app creates visits and keeps checklists, text observations, photos and voice notes in the browser on the device. A visit can be exported as one downloadable file. It has no backend, account, sharing, synchronisation, server-side record or conflict resolution. This is not a client commission or a released product.