LLOS.ai
App Layout
📱 App Layout · Module 1 of 6

The Stage, Not the Page

An app is a stage you operate, not a page you read. This series is the contract, felt one module at a time.

1 Stage2 Stability3 Zones4 Glance5 Density6 Contract
One viewport · no scroll in tasksCentre · contentEdges · controls

Everything in the Layout & Grids series assumed a page — a document the eye travels down. Apps break that assumption on purpose. A tool, a game, a monitor, a quiz: these are stages. The frame stays put, the content performs inside it, and the user operates rather than reads.

The tell is the scrollbar. The moment a task-surface grows one, it has quietly become an article — and the eye starts commuting instead of working. This module makes the difference felt in the hands: the same tool built both ways, controls that wander versus controls that wait, and content that grows versus content that becomes scenes.

01 · The contract

One viewport, operated

App mode is a behavioural contract, not a visual style. Its clauses: the surface fills one viewport and never scrolls during an active task; the centre belongs to content and the edges to actions; when more must fit, the layout grids more scenes together — tabs, swipes, pages — instead of growing into a document; and the frame never jumps.

The reward is cognitive: a fixed stage means the eye learns the territory once and then stops paying for it. Every glanceable dashboard, every game, every instrument panel you have ever used without thinking is this contract, honoured.

The law

Scrolling is the tell of an article. An app fills the frame — and when more must fit, it grids more scenes, never grows.

02 · Feel it

The same tool, twice

Below is a tiny task: tap the three amber targets inside the framed screen. First as a page — the targets scattered through a document. Then as a stage. The counters do the arguing.

The same tool, twice
Start on Page and feel the commute; then switch to Stage.
scrolls 0targets 0/3
03 · Centre and edges

Controls that wait

The second clause: content in the centre, actions at the edges. The wrong version is everywhere — buttons living in the content stream, so they move whenever content changes. Press Next five times in each mode; the stage counts your misses.

Wandering vs pinned
Same button, same job. One relocates after every press; one never moves from its edge.
presses 0/5misses 0
The law

A control that never moves stops needing to be seen.

04 · When content outgrows the stage

Grid, don’t grow

Real content overflows — that is not the failure. The failure is answering overflow with a scrollbar. The app answer is scenes: the same twelve cards as two pages of a fixed grid, navigated by dots, every state one-viewport complete. Find card 09 both ways.

Scenes vs the scrollbar
Twelve cards, two philosophies. The frame is identical; only the physics change.
1
viewport per task, always
0
scrollbars during operation
scenes, if the content needs them
05 · The craft

Naming the surface

The skill this module leaves you with is a naming reflex. Before designing anything, ask: is this surface read or operated? Articles, docs and feeds are read — they scroll, and should. Tools, games, monitors, quizzes and wizards are operated — they stage. Every hybrid disaster you have used (the tool buried mid-article, the article trapped in a pager) is a surface whose designer never answered that one question.

Once named, the physics follow: the read surface inherits everything Layout & Grids taught. The operated surface inherits this series — and the next module adds its second clause: nothing jumps.

The law

Name the surface first — read or operated — and its physics name themselves.

What people get wrong

Where app layout dies

“Fullscreen makes it an app”Fullscreen is a size. A fullscreen surface that scrolls mid-task and moves its controls is still a page — just a bigger one.FixApp mode is behaviour: fixed stage, edge controls, scenes, nothing jumping. Judge the physics, not the pixels.
“It doesn’t fit — add a scrollbar”The reflex answer to overflow, and the exact moment a tool becomes an article.FixOverflow becomes scenes: a tab, a swipe, a paged grid. Every state stays one-viewport complete.
“Put the button near the thing it affects”Locally logical, globally fatal: in-content controls move whenever content changes, so the hand can never learn them.FixActions live in fixed edge zones; the content they affect lives in the centre. Feedback appears near the action — the control itself never travels.
“More visible controls = more usable”A stage crowded with loud buttons feels powerful in a demo and exhausting by the tenth use.FixFrequency sets the volume: the more often an action repeats, the quieter its control — big hit areas, small pixels, muscle memory over signage.
The real references

Where the field agrees

Four sources worth reading in full — the platforms and research this module stands on.

Cast your vote

Stage or page?

Five face-offs. Two surfaces — one is a stage you operate, one is a page you scroll. Pick the stage, then see what makes it one.

Round 1 of 5Score 0
The vocabulary

The Stage glossary

Six words for surfaces you operate. Tap a card to flip it.

The nuance

Questions you actually ask

Train the eye

Run the numbers

Ten questions in mixed formats — multiple choice, multi-correct, fill-in, match, order, read-think-connect and write-your-own — each with layered hints: a nudge, the reasoning, then a deeper connection. Served from the question bank, never hardcoded.

Loading the question bank…
Question 1 of 10
Multiple choice
Keep going

Where this connects