# The grid on a small screen

A grid is a horizontal instrument, and a phone has no horizontal room. On a narrow display the Data screen falls back to a stacked layout: one record at a time, its fields listed down the page, with search and the filters already in force still working. The controls that only make sense across width — resizing, reordering, freezing — are not offered.

- **Status:** Available
- **Audience:** both
- **In the app:** #/data
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/files-data/data-mobile/

## What survives

- **Reading.** Every field of a record is legible, stacked rather than spread.
- **Finding.** Search still runs against the whole sheet, and a filter you set elsewhere is still narrowing it.
- **Opening a saved [view](/docs/files-data/saved-views/).** The filters and the sort come with it; the column arrangement has nothing to arrange.
- **A narrow edit.** Changing one field goes through the owning service exactly as it does on a desktop, with the same validation and the same refusals.

That set is chosen around what people actually do on a phone: check something, correct something small, and move on. It is a reading surface with a pen attached, not a place to restructure a sheet.

## What is dropped, and why

| Control | On a phone | Reason |
|---|---|---|
| Column resize | Not offered | There is one column of content; width is not a variable |
| Column reorder | Not offered | Order is the stacked field order, which is fixed and readable |
| Freeze | Not offered | Nothing scrolls sideways for a frozen column to hold still against |
| Grouping | Not offered | Group headings and collapsed blocks need a table to sit in |
| Side-by-side comparison | Not possible | Comparing rows is what the width was for |
| Bulk selection | Avoid it here | Building an exact set on a small display is where the wrong set gets acted on |

> **Note** Nothing is dropped to make the page lighter. Each of these controls manipulates a two-dimensional layout, and on a narrow display there is only one dimension left to manipulate. A cramped, half-working grid would be worse than an honest list.

## Doing the wide work later

1. On the phone, find the records and note what needs doing.
   - Result: You have the answer you needed without waiting to be at a desk.
2. Make only the single-field corrections that are unambiguous.
   - Result: The change is written through the same service, so nothing needs redoing later.
3. Leave [bulk actions](/docs/files-data/bulk-actions/), [import](/docs/files-data/data-import-export/) and merges for a wide display.
   - Result: The set you act on is one you built with the filter count in front of you rather than one you assembled by thumb.

If a job genuinely has to happen now and only a phone is to hand, the Assistant is often the better route: describing the change in words and confirming a proposal needs no width at all. Its own narrow-display behaviour is covered in [the Assistant on a phone and on a wide screen](/docs/assistant/assistant-responsive/).

## The same fallback for both audiences

The Owner and a customer get the identical layout from the identical code. There is no reduced customer version and no operator-only convenience here — a customer request is rewritten to its own path and checked against the allowlist, and then handled by the same service.

That matters more than it sounds. A screen that behaves differently for one audience is the defect this product has had to correct repeatedly, and the reasoning behind holding to one implementation is set out in [one implementation, two audiences](/research/two-audiences-one-implementation/).

## Questions

### Can I still edit records from my phone?

Yes, one field at a time, through the same service and with the same validation. What you should not do is build a large selection on a small display — the count is harder to verify and the consequences of acting on the wrong set are the same size as they are anywhere else.

### Why not just let the grid scroll sideways on a phone?

Because a table you can only see three columns of at a time is a worse way to read one record than a list of its fields. The fallback is not a smaller grid; it is a different presentation of the same records.

### Do my saved views work on a phone?

Their filters and sort do, which is the part that defines the set. The column arrangement stored in the view has no effect, because there are no columns to arrange.

## Related

- [The Data grid](https://connectbyjbrh.com/docs/files-data/data-grid/)
- [Columns, order and visibility](https://connectbyjbrh.com/docs/files-data/data-columns/)
- [Saved views](https://connectbyjbrh.com/docs/files-data/saved-views/)
- [The Assistant on a phone and on a wide screen](https://connectbyjbrh.com/docs/assistant/assistant-responsive/)
- [One implementation, two audiences](https://connectbyjbrh.com/research/two-audiences-one-implementation/)
- [Editing in the grid](https://connectbyjbrh.com/docs/files-data/inline-edit/)

## What this page is based on

- docs-source/sources/GENERAL.md §9 — the Data grid and its controls
- docs-source/sources/GENERAL.md §1 — one implementation, two audiences
- `webapp/src/` and `FRONTEND-MAP.md` — the responsive layers
- `backend/app/data_workspace.py`