The Interface That Won't Load on Mobile
A field-service app built as a single Appian interface is used by technicians on tablets over cellular. The interface renders a dashboard with a 30-column editable grid, a chart, and a detail form, all on one page. Technicians report 8–12 second load times and frequent timeouts when connectivity drops. The grid pulls 5,000 rows from a record type on load. Most technicians only need to update 3–5 rows per visit and rarely use the chart. The product owner wants a faster experience without rebuilding the app. Analytics show 90% of sessions are on tablets, and the median visit touches fewer than 10 records.
1. Identify the main performance drivers and propose a redesign that preserves functionality.
Read the worked answer
The load cost is dominated by three things: a 5,000-row grid query on every page load, a 30-column editable grid rendered eagerly, and a chart computed alongside the form. On cellular, payload and render time compound.
Redesign around the actual usage pattern (3–5 rows per visit):
- Push filtering to the query. Load only the technician's assigned rows for the current visit (a filtered record query), not 5,000. Expect ~10 rows.
- Split the page. Make the dashboard a landing view; the detail form loads on selection. Use a record action / related action rather than one monolithic interface.
- Lazy-load the chart behind a tab or a 'show chart' toggle, or move it to a separate analytics view used by supervisors.
- Reduce grid columns to the editable essentials; put the rest in the detail form.
- Add a save-per-row or save-batch action with optimistic UI so a dropped connection does not lose the whole page.
This keeps every feature but stops paying for 5,000 rows and a 30-column render on a cellular link.
2. Connectivity drops mid-edit. What interface and process changes reduce data loss?
Read the worked answer
Design for small, frequent, recoverable writes:
- Save each row on edit (or on a short debounce) via a record action rather than a single page-level submit, so a drop loses at most one row.
- Show clear per-row save state (saved / pending / error) so the technician knows what persisted.
- On reconnect, re-query the assigned rows and reconcile; do not rely on in-memory state.
- For multi-row visits, wrap the batch in a process that writes each row independently and records failures, so a partial submit is recoverable.
- Keep a local draft indicator where the platform supports it, but treat server persistence as the source of truth.
Avoid the anti-pattern of holding all edits in a single form variable submitted at the end - that maximizes loss on a flaky link.