Web or mobile app: what should you choose for a field team?
A team working on the move may need a simple tool on a phone without needing a native app. The right choice depends on where it is used: available connectivity, actions to perform, equipment and data recovery.
06 chapters
Observe a site visit before choosing the platform
Observe a task from start to finish
Follow an entire task: find the case, read instructions, take a photo, record information and finish the report. Note where the person is, what they are holding and what interrupts them. A large-screen mock-up does not reveal these constraints.
Example: a visit with poor connectivity
In a fictional example, a technician reads the job file before leaving, takes readings in a building with poor coverage and sends the report on returning. The central need is continuity of data entry. The choice cannot be settled solely by the presence of a phone.
List the devices in use
Record the devices and versions actually used. Personal or company phones, tablets, scanners and desktop computers need different management. Also ask who installs, updates and replaces the devices.
- Place of use and network quality.
- A complete task, including possible interruptions.
- Devices, operating systems and versions in use.
- Someone responsible for the device fleet and support.
Compare web apps, PWAs and mobile apps
Web application
A web application runs in a browser. It can be designed for phones and computers with suitable interfaces. It is particularly useful when the required features are available in the target browsers and sharing a link makes access easier.
PWA
A PWA is a web application that uses additional platform capabilities, such as installation or some offline functions. These capabilities need to be designed and tested; they do not come automatically with the name. The browser and operating system remain constraints to check.
Installed mobile application
An installed mobile application may be appropriate for deeper hardware or operating-system integration. It adds its own distribution method, versions and maintenance cycle. The native or cross-platform choice comes next, based on the functions and devices to cover.
Choose by the access and integration required
MDN distinguishes web applications, platform-specific applications and the capabilities added by a PWA.
- Web
Access through a browser
Share a URL and adapt the interface to the target screens.
- PWA
Additional web capabilities
Design the functions available on the target systems.
- Mobile
An installed application
Assess distribution and operating-system integration.
Describe what must work without a network
Specify the offline actions
“Works offline” is too broad to scope a project. Distinguish viewing a previously loaded case, saving a reading and approving an operation that depends on a server. An installed app may also need connectivity for part of its work.
Separate local input from transmission
Choose which data will be available before departure and which actions are allowed during the outage. The interface should distinguish saved on the device, waiting to send and accepted by the server. A person should not confuse local input with an up-to-date shared case.
Test when connectivity returns
Plan for connectivity returning, concurrent changes and the app being closed. MDN documentation details PWA offline mechanisms; the business rules for recovery still need defining. The tool integration guide also covers incomplete or repeated exchanges.
Recovery is part of the feature
MDN explains how a PWA can retain resources and handle some deferred operations. Their availability depends on the platform.
- Before
Prepare the resources
Identify what must remain available without a connection.
- During
Keep the work
Distinguish local data from data already shared.
- After
Resume the exchanges
Check deferred operations on the intended devices.
Test the hardware functions that determine the choice
Try the functions on target devices
- Use the photo, scan or location function actually needed for the work.
- Test it on the target devices with permissions denied, then granted.
- A documented feature does not guarantee its behaviour in your context.
Validate hardware constraints
A specialised reader, communication with a device or a background-processing requirement may influence the choice. Ask for a short trial of that function before building every screen. The test needs to reproduce the hardware, interruptions and usage frequency.
Specify frequency and accuracy
Separate required accuracy from desired convenience. Taking an occasional photo and scanning items in batches call for different interaction design. Mobile app development is justified by these observed constraints, not the idea that an icon looks more professional.
Keep actions short and make progress visible
Preserve interrupted input
In the field, a long form may be interrupted by a call or a move to another location. Group input by task, preserve the work and show what is missing. Distinguish essential fields from information that can be completed later.
Name statuses clearly
A status needs words: waiting to send, sent, error to resolve. Colour alone is insufficient in bright conditions or for every reader. Also check the keyboard, touch targets and readability with enlarged text.
Include the return to the office
Returning to the office is part of the journey. The person processing the readings should find the right attachments, see any uncertainties and make traceable corrections. A business web application can share these rules with an interface designed for field work.
Compare long-term costs and try it in context
Compare the same scope
Compare options for the same use: permissions, data, offline work, equipment and the office interface. Add distribution, updates, support and device tests. A shared codebase does not remove these checks.
Test a real site visit
- A pilot should accompany a real visit with poor connectivity, an interruption and a return to the office.
- Check that input is preserved and reaches the shared case.
- A successful journey on a perfect network does not settle a field-work decision.
Decide against written criteria
Decide after this trial and keep the criteria written down. The price guide helps prepare the budget; the return calculation helps examine what the team actually gains.
The remaining decisions
Can a web application be used on a phone?
Yes, if the interface is designed and tested for that screen. The need for an installed app then depends on connectivity, hardware and operating-system integration.
Does a PWA always work offline?
No. The available content and actions allowed without connectivity need to be developed. The mechanisms used need checking in the target browsers and operating systems.
Does a native app solve synchronisation conflicts?
No. Recovery rules and concurrent changes are data and business decisions, regardless of the application’s format.
What is the best test before choosing?
Complete an entire task on the target devices, including a network outage and an interruption, then check the data processed back at the office.
Put the guide against a real project.
A few lines are enough: context, the main constraint, and the expected result.