The Fixed Page

Three people open the same document on the same morning. It is a twenty-page national guideline on managing suspected stroke: symptoms, triage thresholds, drug doses, contraindications, referral pathways. A paramedic in an ambulance needs one thing: the three exclusion checks that decide whether to divert to the thrombectomy centre, readable in ninety seconds, in gloves. A junior doctor on the ward needs another: the dosing table with its renal exceptions, placed beside the contraindication list so the two can be checked against each other. A medical student revising in the evening needs a third: the causal story — why each threshold exists, what happens when it is missed — with the numbers present but subordinate. The document contains everything all three need. The page, as rendered, serves none of them well. Each performs the same labour: hunting through a linear encoding optimised for nobody’s current task.

This is the fixed page: representation frozen at author time, delivered identically to every reader regardless of purpose. It was a reasonable bargain under print economics — one layout, pressed in thousands — and software inherited it without re-examining the terms. A PDF is a photograph of paper. Most web pages are paper with hyperlinks. Even the “dynamic” application is usually fixed in the ways that matter: the designer chose the layout months ago, for a generic user, performing a generic task, and every real user bends themselves around that guess.

This chapter earns one narrow claim, and it protects the boundary around it carefully:

The representation presented to a reader no longer has to be fixed at author time. Current generative-interface systems demonstrate that interfaces can be synthesised or altered from structured task context.

It does not earn the stronger claim — AI can determine the best representation for a reader — which belongs to Chapters 4 and 5 at the earliest, and in its personal form to Part III. Possibility first; optimality later, with measurement. The distinction between those two sentences is the load-bearing discipline of this chapter. Everything that follows establishes the former and refuses the latter.

The inherited split, and what it left out

Software engineering has separated underlying information from its display for decades. The Model–View–Controller pattern (Krasner and colleagues, late 1980s) and the model-based UI research tradition of the 1990s (Puerta, Eisenstein, Myers, Szekely and others) both start from the canonical picture: an application holds a data model describing its domain, and views render that model for interaction. Change the model and the views update; the same model can feed several views. Your calendar’s month grid, agenda list, and notification card are views over one store of events.

But notice what stayed fixed in that tradition. The models were fixed at design time, modelling the designer’s conception of predefined tasks, and the views were fixed layouts authored against those models. The user who needed something the designer had not foreseen did the integration labour themselves: copying figures between applications, maintaining a shadow spreadsheet, keeping the real workflow in their head while the software displayed its own. As Cao, Jiang and Xia observe in their CHI 2025 paper, the onus sat on users to piece together separate application models to match actual workflows. The source/view split existed, but both sides were frozen before the reader arrived.

What changed is who can now produce the model. If a system can infer a structured representation of the current task — the entities involved, their relationships, the dependencies between them — then it can synthesise a view for that task rather than retrieving a pre-authored one. The page stops being a photograph and becomes a rendering decision made at reading time. That is the entire thesis of this chapter, and two recent research systems show it is technically real.

Precedent 1: task-driven models that generate interfaces

Cao, Jiang and Xia’s “Generative and Malleable User Interfaces with Generative and Evolving Task-Driven Data Model” (CHI 2025, Yokohama; DOI 10.1145/3706598.3713285; preprint arXiv:2503.04084) proposes exactly the missing piece: a task-driven data model standing between the user’s stated intent and the rendered interface. Their prototype, Jelly, works in three stages. First, a large language model interprets the user’s prompt and generates a data model with three components: an object–relational schema (the entity types, attributes, and relationships the task needs), a dependency graph (how entities constrain each other), and structured data instantiating the schema. Second, the model is translated into a UI specification — composition, components, state management — using pattern-informed mapping rules drawn from established UI design practice rather than free-form code generation. Third, the interface renders, and stays malleable: follow-up natural-language requests and direct manipulation both translate back into operations on the underlying model (add an entity, change an attribute, rewire a dependency), which re-render the view.

Three properties matter for this book. First, the model represents the task, not the document: entities, relationships, and constraints needed to accomplish something, deliberately not a prescribed interaction sequence, so users can form their own workflows. Second, generation is specification-mediated rather than raw code emission, which is how the system keeps quality and consistency instead of hallucinating a fresh layout aesthetic per prompt. Third, and most important for our agency principle, the model is inspectable: users can look at the task structure the system inferred and correct it directly, rather than re-prompting blindly until the pixels look right.

The authors report a technical evaluation (LLMs generate relatively high-quality task models) and a user evaluation (participants could develop and adapt interfaces to evolving needs). Treat both as feasibility evidence with the usual prototype-study limits: small samples, tasks chosen by the researchers, no comparison against the strongest fixed-interface baseline on transfer or time. What the paper establishes — and all this chapter needs — is that the pipeline from stated intent → structured task model → rendered interface → user-correctable model runs end to end. Rendering is no longer author-time destiny. It is a compilation step, and compilation targets can change.

What the paper does not establish is equally important, and the chapter states it plainly: nothing in these results shows the generated views preserve the source information faithfully, improve comprehension or task outcomes against a strong fixed baseline, or choose correctly among candidate representations. Feasibility of generation is not evidence of communication gain. Chapters 4 through 9 exist because that gap is real.

Precedent 2: generating interfaces from language-model queries

Where Jelly starts from task prompts, Chen, Zhang, Zhang, Shao and Yang’s “Generative Interfaces for Language Models” (Findings of the ACL 2026, pp. 1499–1519; DOI 10.18653/v1/2026.findings-acl.74; preprint arXiv:2508.19227; system and data at github.com/SALT-NLP/GenUI) starts from ordinary LLM queries and asks when the answer should be an interface rather than a paragraph. Their GenUI pipeline maps a query into a structured interface-specific representation, decodes it into UI code on top of an OpenCanvas-style scaffold (backbone Claude 3.7 in the reported build), and iteratively refines it against an adaptive reward function. The evaluation is unusually careful about dimensions: rather than one success score, they compare generative versus conversational responses across functional, interactive, and emotional aspects, over diverse tasks and query types.

The headline result is preference: GenUI beats a plain chat baseline with win rates up to 84% (against a Claude-based conversational UI), around 72% improvement in human preference in the paper’s headline framing, and — most informatively — 50.8% wins against 41.1% losses with 8.2% ties across 380 real-user self-authored queries from 76 participants. The ablation studies isolate why: structured representations beat natural-language-only descriptions of the UI, and iterative refinement adds roughly 14 points of win rate over one-shot generation. And the honest details cut both ways, which is why this chapter leans on the paper: GPT-4o’s well-structured text answers were notably more competitive than Claude’s, suggesting presentation quality does much of the work; GenUI’s edge concentrates in detailed, structured, information-dense queries while simple queries are often served fine by prose; and the primary drivers of the wins are emotional appeal and interactivity — preference, in this book’s vocabulary, not measured comprehension or transfer.

That last point is load-bearing, so the chapter repeats the rule from Chapter 2: preference is not performance. Chen and colleagues measured what they measured — multidimensional preference, carefully — and their paper is exemplary in saying so. This book takes the result at exactly that value: users often want task-specific interfaces, especially for complex queries, and current systems can generate them well enough to be preferred. Whether those interfaces communicate faithfully and teach effectively is unmeasured here, and Chapters 5 and 9 will supply the missing instruments rather than assume the answer.

What “reader-time rendering” actually means

With both precedents on the table, the chapter can state its mechanism precisely, using only vocabulary that stays on the safe side of the Chapter 6 line. Four separations:

Source versus view. The source is the received material as authored — the guideline PDF, the incident report, the dataset. A view is one rendering compiled for one purpose. The source is canonical; views are disposable. Nothing in this chapter defines the derived interpretation sitting between them — that machinery belongs to Chapter 6, which will earn the semantic record properly. Here it suffices that something structured must mediate, as it does in both Jelly (task model) and GenUI (interface representation).

Author time versus reader time. Author-time decisions (what the designer fixed months ago) trade away fit for predictability and zero marginal cost. Reader-time decisions (what gets compiled when the paramedic, the junior doctor, and the student each arrive) buy fit at the price of inference risk, latency, and variability. The book’s position is not that reader-time always wins — the fixed page remains the right baseline, cheap and predictable — but that the trade is now available. Availability is the earned claim; superiority is the open experiment.

Task-driven versus document-driven. Both precedents organise around the task, not the document: Jelly’s schema models entities and dependencies for accomplishing something; GenUI’s representations model the interaction the query calls for. The stroke guideline renders as exclusion checklist, dosing table, or causal story depending on which task is declared — not as three excerpts of one text. The declared task is the safest first personalisation variable this book has (Part II will lean on it heavily in Chapter 14), precisely because it is stated rather than inferred.

Generated versus malleable. Generation without correction is a lottery with good typography. Both systems pair synthesis with user control — Jelly through model inspection and direct manipulation, GenUI through iterative refinement loops — and this chapter adopts that pairing as a requirement, not a nicety. Every reader-time view the book proposes from here on must be correctable, dismissible, and traceable to the source it was compiled from.

The escape hatch is part of the architecture

One component is non-negotiable, and the chapter states it as a design rule binding all later capstones: every generated view must expose the unchanged source. The raw document — full text, original layout, unmodified numbers — stays one click away, alongside whatever the system compiled. This is not nostalgia. It is the precondition that makes every other claim in the book testable: the reader can check the rendering against the original, the experimenter can score preservation, the sceptic can bypass the machinery entirely. A semantic renderer without a source view is a mediator that cannot be audited, and this book does not build those. The Semantic Browser (Chapter 10), the Radar (Chapter 20), and the Personal AI (Chapter 29) all inherit this requirement from here.

The rule also keeps the fixed page honest in its reduced role. Author-time rendering is not abolished; it becomes the default view and the ground truth at once — the thing you see when you ask for nothing special, and the thing you check everything else against. That is a dignified retirement for a five-century technology, not a demolition.

What this chapter does not claim

A short list, because the temptation to overclaim is the main failure mode at this point in the book’s arc:

• It does not claim generated views preserve source information. Preservation is unmeasured until Chapter 9 builds the instrument.
• It does not claim the system knows which representation is best. Selection among representations is Chapters 4–5, personal conditioning is Part III.
• It does not claim preference results (Chen et al.) transfer to comprehension, recall, or decision quality. Chapter 2’s separation stands.
• It does not claim task inference is reliable. The experiments below start from declared tasks; inferred objectives arrive in Chapter 14 with their own error bars.
• It does not claim the word “meaning” as a technical achievement. The systems above manipulate source information and structured task context into derived representations. Whether that counts as capturing what the author intended to communicate is exactly what the preservation methodology must test, claim by claim. Chapters 1–3 use “meaning” only in this loose, pre-operational sense — a deliberate promissory note Chapter 6 redeems.

What this chapter earned

The representation a reader encounters no longer has to be fixed before the reader arrives. Two current systems demonstrate the compilation step running end to end: from task context to structured model to rendered, correctable interface (Cao et al.), and from language-model queries to preferred task-specific interfaces for complex needs (Chen et al.). Both establish technical possibility and user appetite; neither establishes communication gain. The fixed page survives as baseline, default, and ground truth — with the raw-source escape hatch as a permanent architectural requirement.

The first concrete transformation is visual compression: a page becomes a fast preview of its own content.

References

• Cao, Y., Jiang, P. & Xia, H. (2025). Generative and Malleable User Interfaces with Generative and Evolving Task-Driven Data Model. Proc. CHI 2025, Yokohama. DOI 10.1145/3706598.3713285. Preprint arXiv:2503.04084. Prototype Jelly: prompt → task-driven data model (object–relational schema + dependency graph + structured data) → UI specification → rendered interface; NL and direct-manipulation edits map back to model operations. Used for feasibility of task-to-interface compilation and the inspectable-model requirement. Evaluation limits (prototype scale, researcher-chosen tasks) noted; no preservation or transfer claims taken.
• Chen, J., Zhang, Y., Zhang, Y., Shao, Y. & Yang, D. (2026). Generative Interfaces for Language Models. Findings of the ACL 2026, pp. 1499–1519. DOI 10.18653/v1/2026.findings-acl.74. Preprint arXiv:2508.19227. Code/data: github.com/SALT-NLP/GenUI. GenUI vs conversational UI: up to ~84% win rate (vs Claude ConvUI), ~72% headline preference gain; real-user study 380 queries / 76 participants: 50.8% win, 8.2% tie, 41.1% loss; structured representations + iterative refinement ablated; GPT-4o text competitive; edge concentrates in detailed/structured queries; drivers emotional/interactive. Used strictly as preference + feasibility evidence, not comprehension evidence.
• Krasner, G.E. & Pope, S.T. (1988). A cookbook for using the model-view-controller user interface paradigm. J. Object-Oriented Programming. Cited as historical source of the model/view separation.
• Model-based UI development tradition (e.g. Puerta; Myers; Szekely, 1990s): cited via Cao et al.’s framing for the fixed-model limitation. Primary reads deferred to revision; used only for lineage, not for any quantitative claim.

Proposed experiment EXP-03: one source, three task views

Status: PROPOSED. Hypothesis: genuinely different task-specific views can be compiled from one frozen source while exposing it. Source: one self-contained technical document (e.g. a clinical-style guideline or deployment runbook with procedures, tables, exceptions). Conditions: three declared tasks — SCAN (triage in under two minutes), LEARN (explain causal structure to a newcomer), IMPLEMENT (execute the procedure stepwise) — each rendered as a distinct view plus the mandatory raw-source view. Control/baseline: the fixed document alone. View-distinctness check (pre-registered): a blind judge receiving each view without its task label must match views to tasks above chance, and pairwise element overlap across views must stay below a stated threshold — otherwise the “different views” premise fails regardless of task scores. Measurements: task completion and accuracy per task, time, source-consultation rate (did readers check the original?), correction actions taken, and a preservation spot-check on numbers/exceptions per view. Failure criteria: views are cosmetic re-skins with no task-completion difference; or task completion rises while preservation spot-checks fail (speed bought with infidelity — a substantive negative result the book keeps). Artifacts expected: source pack, three view specifications, scoring sheets. What a positive result would not justify: that the system selected the right representation unaided (tasks are declared here); representation selection is EXP-05’s question.