Designing Screens
Screens are what the app shows, and they are designed in the platform rather than written in code.
Where to find it
Architect Panel → Mobile Apps:
- Mobile Canvas — the app, its screens and its settings
- App Builds & Releases — building and submitting
- Mobile Devices — the devices that have installed it
What a screen carries
- A key and a title, and an icon.
- A type, deciding how it behaves.
- Navigation — whether it appears in the app’s navigation and in what order.
- Data binding — the datastore, the browse view or input view it uses.
- Filter, sort field, sort direction and page size.
- Layout — the arrangement of its components.
- Permission and group requirements.
- Offline caching for that screen.
- Minimum app version.
Bind to a view, not a raw table
A screen bound to a browse view inherits that view’s columns, filtering and ordering, and stays in step when the view changes. Binding to a table means rebuilding all of that per screen.
Filter and page size matter more on a phone
A list of eight hundred records is unusable on a small screen and slow on a mobile connection. Filter to what this user needs — their jobs, today’s work, their region — and keep the page size modest.
The instinct to show everything and let people search is a desktop instinct.
Fewer screens in navigation
Mobile navigation has room for about five items. Put the daily tasks there and reach everything else from within a screen.
An app whose navigation lists twelve screens is one where people cannot find the two they need.
Sort for the task
Most recent first, or nearest due first, or by distance. The default order on a phone matters far more than on a desktop, because nobody scrolls to find something and nobody re-sorts.
Minimum app version protects you
A screen using something only newer builds understand can name the version it needs, so older installs simply do not receive it rather than receiving something they cannot render.
Screens ship immediately
Changing a screen reaches installed apps without a rebuild or a store release. That is what makes this practical — you can improve the app weekly.
It also means a mistake reaches everybody immediately, so treat a screen change as a live change.
Test on a real phone
Not a simulator on a large monitor. Text size, tap targets, list density and how much is visible without scrolling are all different, and all decide whether the app is usable in the field.
Worked example
A field app has four screens in navigation — today’s jobs, my week, scan, and profile — each bound to a browse view filtered to the signed-in engineer, sorted by scheduled time, twenty per page. Everything else is reached from within a job.
Recommendations
- Bind to browse views, not raw tables.
- Five navigation items at most.
- Filter hard — a phone is not a desktop.
- Test on a real device in real conditions.