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 and what happens when it is missed, with the numbers present but in the background. The document contains everything all three need. The page, as rendered, serves none of them well. Each does the same labour: hunting through a linear arrangement that was optimised for nobody’s task.

The last two chapters argued that a receiver rebuilds meaning from the evidence a representation gives them, and that different forms give different evidence. The guideline shows what follows from that. One source, three receivers, three purposes, and a single form that the author chose long before any of them arrived. This chapter asks why the form has to be chosen that early, what that choice has been buying, and what it costs.

The fixed page and its bargain

Call it the fixed page: a representation frozen at author time and delivered identically to everyone.

AUTHOR
   ↓
chooses one representation
   ↓
publishes it
   ↓
many recipients · many purposes · many contexts
   ↓
the same representation for all of them

It was a sensible bargain. Under print economics there was no alternative: one layout, pressed in thousands of copies. And it has virtues that are easy to forget until they are gone. Everyone sees the same thing, so people can discuss it. A page can be cited by number, quoted, checked against the original, and compared with a later edition. Nothing in it changes while you are reading it. The author has taken responsibility for how the material is arranged, and the reader knows whose arrangement it is. Software inherited the bargain without re-examining the terms. A PDF is a photograph of paper. Most web pages are paper with hyperlinks. Even the “dynamic” application is fixed in the ways that matter: a designer chose the layout months ago, for a generic user performing a generic task, and every real user bends themselves around that guess.

The cost is the one the guideline shows. The author must guess the receiver, and for any widely read document the guess is wrong for most readers most of the time. The pressure is not that authors are careless. It is structural:

one source  ≠  one universally best rendering

Authors and designers have always worked against this. They write abstracts and executive summaries, build indexes and tables of contents, add tabs, sidebars and “quick start” sections, and design layouts that respond to screen size. Each of these gives the reader more than one route into the material. But every route is still authored in advance. The author decides which three views to offer, and a reader whose task is the fourth one is back to hunting.

What stayed fixed in software

Software engineering has separated information from its display for decades. The Model–View–Controller pattern (Krasner and Pope, 1988) and the model-based user interface research of the 1990s start from the same picture: an application holds a model of its domain, and views render that model for interaction. Change the model and the views update, and the same model can feed several views. Your calendar’s month grid, agenda list and notification card are views over one store of events.

Notice what stayed fixed in that tradition. The models were fixed at design time and described the designer’s idea of a predefined set of tasks. The views were fixed layouts written against those models. A user who needed something the designer had not foreseen did the integration themselves: copying figures between applications, keeping a shadow spreadsheet, holding the real workflow in their head while the software showed its own. As Cao, Jiang and Xia observe, the burden fell on users to piece together separate application models to match their actual workflows. The split between source and view existed, but both sides were frozen before the reader arrived.

What would have to change

Suppose the form did not have to be settled in advance. Something at reading time would have to know what the reader is trying to do, and something would have to be able to produce a view for that purpose from the same source. That is a large demand. Until recently the first part could only be answered by a person, and the second by a designer.

What has changed is who can supply both. If a system can infer a structured picture of the current task, meaning the entities involved, how they relate, and what depends on what, then it can build a view for that task instead of fetching a pre-written one. The page stops being a photograph and becomes a decision made at reading time. Two recent research systems show this is technically real, and each is worth looking at for what it does and does not establish.

Task models that generate interfaces. Cao, Jiang and Xia’s “Generative and Malleable User Interfaces with Generative and Evolving Task-Driven Data Model” (CHI 2025) proposes a task-driven data model that sits between what the user says they want and the interface they see. In their prototype, Jelly, a language model reads the user’s request and builds a model with three parts: a schema of the entities and relationships the task needs, a graph of how they depend on each other, and structured data filling the schema. That model is then turned into an interface specification using established design patterns, not free-form code. The interface stays malleable: follow-up requests and direct manipulation are translated back into changes to the model, which redraws the view. Three features matter here. The model describes the task, not the document. Generation goes through a specification, which keeps the results consistent. And the model can be inspected: users can see the structure the system inferred and correct it directly, instead of re-prompting until the pixels look right. The authors report a technical evaluation and a user study, both feasibility evidence of the usual prototype kind: small samples, researcher-chosen tasks, no comparison against the strongest fixed interface on transfer or time. What the paper shows is that the pipeline from stated intent, to task model, to rendered interface, to user-correctable model runs end to end.

Interfaces generated from ordinary queries. Chen, Zhang, Zhang, Shao and Yang’s “Generative Interfaces for Language Models” (Findings of the ACL 2026) starts from ordinary questions put to a language model and asks when the best answer is an interface instead of a paragraph. Their system maps a query to a structured interface description, turns it into code, and refines it against an adaptive measure of quality. They compare generated interfaces with plain conversational answers on several dimensions: functional, interactive and emotional. Generated interfaces won more often than they lost, by 50.8% to 41.1% with 8.2% ties across 380 real user queries from 76 participants, and the edge concentrated in detailed, structured, information-dense queries. Structured intermediate descriptions beat plain-language ones, and iterative refinement helped. The details cut both ways, which is why the paper is useful: well-structured text from one strong model was highly competitive, simple queries were often served fine by prose, and the wins were driven mainly by emotional appeal and interactivity. That is preference, in the sense of the previous chapter, not measured comprehension or transfer.

Together the two systems establish something narrow and real. The representation a reader meets can be produced, or altered, at reading time from structured information about the task, and people often want it. They do not establish that the generated views preserve what the source said, that they improve understanding against a strong fixed baseline, or that the system picks the right form. Feasibility of generation is not evidence of communicative gain.

What reader-time rendering means

With that on the table the mechanism can be stated precisely. Four distinctions do the work.

Source and view. The source is the material as authored: the guideline, the incident report, the dataset. A view is one rendering compiled for one purpose. The source stays canonical and views are disposable. Something structured has to sit between them, as the task model does in Jelly and the interface description does in GenUI. What that intermediate should contain, and how to check it, comes later.

Author time and reader time. Author-time decisions trade fit for predictability and cost nothing per reader. Reader-time decisions buy fit at the price of inference risk, delay and variability. The fixed page remains the right baseline: cheap, predictable and checkable. The change is that the trade is now available. What is established is availability. Whether the reader-time choice is better is an open question.

Task-driven and document-driven. Both systems organise around the task, not the document. The stroke guideline renders as an exclusion checklist, a dosing table or a causal story depending on which task is declared, not as three excerpts of one text. A declared task is the safest first thing to condition on, precisely because it is stated by the reader and not guessed about them.

Generated and malleable. Generation without correction is a lottery with good typography. Both systems pair synthesis with control: Jelly through an inspectable model and direct manipulation, GenUI through iterative refinement. Any reader-time view worth trusting must be correctable, dismissible and traceable to the source it was made from.

The escape hatch is part of the design

One rule follows from all this, and it binds everything later in the book: every generated view must expose the unchanged source. The raw document, with its full text, original layout and unaltered numbers, stays one step away from anything compiled from it. This is not nostalgia. It is what makes every other claim checkable. The reader can compare a rendering with the original, a researcher can score what survived, and a sceptic can bypass the machinery altogether. A mediator without a source view cannot be audited.

The rule also gives the fixed page a dignified reduced role. Author-time rendering is not abolished. It becomes the default view and the ground truth at once: what you see when you ask for nothing special, and what you check everything else against.

What this does not claim

The temptation to overclaim is strongest at exactly this point, so the limits are worth stating plainly. Nothing here says generated views preserve source information; that has to be shown. Nothing says the system knows the best representation; at this stage the task is declared by the reader, and inferring it comes later with its own error bars. Nothing says the preference results in the GenUI study carry over to comprehension, recall or decision quality. And nothing says a machine has captured what the author meant. The systems above manipulate source information and structured task context to produce derived representations. Whether that preserves the author’s intent is exactly what needs testing, claim by claim.

Where this leaves us

The fixed page was a good solution to a real constraint, and it left one cost standing: a single form, chosen in advance, for readers and tasks the author could not know. Current systems show that this constraint is no longer absolute. The form can be produced at reading time from structured information about the task, correctably and with the unchanged source always available. What they do not show is that doing so improves communication. That has to be tested transformation by transformation.

The first and simplest transformation is also the most familiar. Before anyone reads a page, they have to decide whether to read it, and that decision is made on a handful of cues. What would it mean to turn the page into a better preview of itself?

References

• Krasner, G.E. & Pope, S.T. (1988). A cookbook for using the model-view-controller user interface paradigm in Smalltalk-80. Journal of Object-Oriented Programming, 1(3), 26–49.
• Cao, Y., Jiang, P. & Xia, H. (2025). Generative and Malleable User Interfaces with Generative and Evolving Task-Driven Data Model. Proceedings of CHI 2025, Yokohama. DOI 10.1145/3706598.3713285. Preprint arXiv:2503.04084.
• Chen, J., Zhang, Y., Zhang, Y., Shao, Y. & Yang, D. (2026). Generative Interfaces for Language Models. Findings of the Association for Computational Linguistics: ACL 2026. DOI 10.18653/v1/2026.findings-acl.74. Preprint arXiv:2508.19227.