# The Fixed Page
# Book: Language
# Chapter URL: https://programmer.ie/books/language/04-chapter/
# Prose fingerprint (sha256, normalized): 893c9ba13cf721c7c82d1db54621a919e006435e0b4a6f2fd0c82011db1991c0
# Snapshot generated at build time by Hugo. This is the complete rendered prose
# of the chapter; it is not a transcript of the source file.

Imagine three people consulting the same twenty-page clinical guideline on suspected stroke. This is a constructed example, not a description of an actual protocol. A paramedic in an ambulance needs to find the current, locally authorised triage and escalation pathway quickly, without losing its exceptions. A junior doctor needs to compare the exact treatment instructions, contraindications and version-specific cautions in their full context. A medical student revising that evening wants an explanation of why the thresholds and pathways exist. All three start from the same document, but they need different routes through it. A conventional linear presentation makes each perform some work of finding, comparing and reconstructing. It may already contain an excellent quick-reference chart; it may not. In clinical use, a generated view cannot be allowed to substitute for the authoritative, current protocol merely because it is faster to read. That is precisely what makes this a demanding example of reader-time rendering.
The last two chapters argued that a receiver reconstructs meaning from a representation and that different forms make different relations easier or harder to recover. The guideline now raises a design question. Can one identified source version support several task-specific views without losing its obligations, qualifications or authority? This chapter asks why so much of the form is chosen before the reader arrives, what that stability buys, and what we would have to prove before replacing it.
The fixed page and its bargain Call it the fixed page: a particular arrangement of material chosen before the current reader and task are known. “Fixed” describes the representation decision, not necessarily the underlying information. A page can be republished, resized or searched and still present substantially the same authored ordering and grouping of evidence.
AUTHOR ↓ chooses one representation ↓ publishes it ↓ many recipients · many purposes · many contexts ↓ the same representation for all of them It was a sensible bargain. Printing made identical or comparable layouts economical at scale. A stable edition supports citation, shared discussion, teaching, review and accountability: a reader can identify the same passage that another reader saw, and changes between editions can be examined. The author or publisher takes responsibility for an arrangement rather than leaving its construction to every reader. Digital systems did not simply reproduce paper. PDFs can contain links, forms and accessible structure; web pages can reflow, personalise and support powerful interaction. Yet a great deal of digital reading still begins with an authored selection and ordering of material. The useful distinction is not paper versus software. It is between a view whose structure was decided for a broad audience in advance and one assembled for a particular declared task at reading time.
The cost is the one the guideline makes visible. An author can design well for likely readers, but cannot anticipate every future task, constraint or point of confusion. That is not evidence that most fixed pages fail most readers; no such rate has been established here. It is a structural limit on how specifically an author-time arrangement can fit an unknown reader:
one source ≠ one universally best rendering Conceptual comparison. The fixed page buys stability and accountability; a reader-time view buys task fit at the cost of latency, variability and new error. Neither guarantees understanding. Open full-size diagram. Authors and designers have long worked against this limit. Abstracts, indexes, executive summaries, quick-reference cards, cross-references, search, filters and responsive layouts provide alternative routes. Some are fixed at publication; others are generated by ordinary deterministic software from structured data. These are serious baselines, not primitive obstacles waiting for AI. The remaining question is whether a system can construct a useful new arrangement for a task that was not explicitly anticipated, and whether the gain justifies its extra cost and risk.
What stayed fixed in software Software engineering separated application state from presentation long before generative models. In the Model–View–Controller tradition (Krasner and Pope, 1988), views present a model and controllers interpret interaction; related model-based interface work made the separation a design method. Your calendar’s month grid, agenda list and notification card can all display the same events. Those views already disprove the notion that software must show one fixed page. The new question is who defines the next view, and what happens when its structure is not specified in the application beforehand.
In many conventional applications, the schema and supported view repertoire are designed in advance even while the data changes continually. Other systems let users build custom views, compose dashboards or run ad hoc queries. What Cao, Jiang and Xia identify is a narrower remaining problem: people often have to coordinate several application-specific models to complete an evolving, cross-application information task. A spreadsheet assembled beside a dashboard is one familiar symptom. The limitation is not that all models and views are frozen; it is that inventing a new task structure and turning it into a usable interface still often requires design or programming work.
What would have to change Suppose the next view need not be selected from a catalogue of authored screens. The system needs at least a statement of the current task, an account of the available information, a way to generate a candidate structure and a renderer that can present it. Search engines, filters, adaptive systems and end-user programming already cover parts of that sequence. Generative models change the practical range of tasks and structures that can be proposed from ordinary language. They do not remove the need to verify the proposal.
The proposed shift is therefore from choosing among known views to constructing a candidate view from a task description. The intermediate task model may describe entities, attributes, relationships and dependencies; the rendering system then chooses components and interactions. But task structure and source truth are different objects. A model can invent a perfectly coherent interface around a relation the document never asserted. Two research systems make the generation path concrete. Neither, on its own, closes that source-preservation gap.
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 structured task-driven model between a user’s request and the rendered interface. In Jelly, an LLM produces an object-relational schema and dependency graph, with data organised under that structure; UI specifications map the model to a constrained set of established display patterns. Users can modify the resulting information space by language or direct manipulation, and inspect the model rather than endlessly re-prompting an opaque layout. The technical evaluation assessed schema relevance and dependency accuracy, not the correctness of arbitrary underlying source documents. Its user study involved eight participants completing open-ended information tasks; it documented enthusiasm and flexibility, but also limits in visual expressiveness and cases where requested changes were not made. This is evidence that a task-to-model-to-interface-to-revision loop can run and be manipulated. It is not a controlled demonstration of superior task accuracy, transfer or time against a strong conventional interface, nor a demonstration that the underlying data is faithfully sourced.
Interfaces generated from ordinary queries. Chen, Zhang, Zhang, Shao and Yang’s “Generative Interfaces for Language Models” (Findings of the ACL 2026) asks when an ordinary language-model query is better served by an interactive interface than by a conversational answer. Their GenUI framework produces a structured interface description, turns it into an interface and iteratively refines the result. Its evaluation separates functional, interactive and emotional aspects of experience. In one real-user comparison covering 380 self-authored queries from 76 participants, GenUI received 50.8% wins, 41.1% losses and 8.2% ties against the conversational comparison. Preferences varied by query and comparison system; detailed, information-dense requests offered a clearer opportunity than simple ones. The study also shows why a single headline preference number is insufficient: an attractive, interactive answer is not automatically a better-supported or more accurately understood answer. For this book, GenUI is evidence about interface generation and user preference, not measured preservation of source claims or improvement in comprehension and transfer.
Together, Jelly and GenUI establish a narrow but important possibility: a task can drive the construction and revision of an interface at use time. Their intermediate structures also expose different choices—Jelly centres an evolving task-data model; GenUI centres an interface-specific representation and refinement process. Neither study establishes that a generated view preserves an independently authored source, that it improves correct decisions over a strong fixed baseline, or that it chooses the best representation for a particular receiver. Generated successfully and communicated faithfully remain separate outcomes.
What reader-time rendering means With that on the table, four separations describe the design space. They are requirements for the Language system proposed by this book, not guarantees delivered by either research prototype.
Source and view. A source is an identified body of material in a particular version: a guideline edition, incident report revision or dataset snapshot. A view is a derived arrangement for a declared purpose. A task model describes what the reader wants to do; a source-grounded representation must separately record what the material actually supports. The two can meet in an intermediate specification, but must not be mistaken for each other. For example, “show contraindications beside doses” is a task request; the actual contraindications, their scope and their source locations are evidence obligations. A generated view can be regenerated or discarded. The identified source version, its provenance and any corrections remain independently recoverable.
Author time and reader time. An author-time view amortises editorial and validation effort across readers; it does not literally cost nothing to produce, distribute or maintain. A reader-time view may fit an immediate purpose better, but adds generation latency, review work, variability and possible error. The comparison must include a strong fixed page with its existing navigation, search and authored aids—not a deliberately inconvenient wall of text. The research establishes that reader-time construction is feasible. Whether it is worth doing for this task and reader remains an experimental question.
Task-driven and document-driven. The cited prototypes organise interface construction around user requests; they are not demonstrations of verified transformation of clinical documents. For the proposed Semantic Browser, the task specifies which questions to answer and which relationships to expose, while the document constrains which claims the view may make. In our constructed guideline example, a checklist would have to retain the conditions, exceptions, applicability and source version that make each item safe to interpret. A declared purpose is preferable to silently guessing one, but it does not authorise the system to omit required context.
Generated and malleable. Generation produces a candidate, not an accepted interface. Jelly demonstrates user-visible structural editing; GenUI uses iterative refinement. Those are different forms of control, and neither alone establishes factual correctness. In Language, the reader must also be able to reject a view, correct a source-to-claim mapping, inspect relevant exclusions and return to the identified original. A changed layout is not evidence that a mistaken relation has been repaired. Correction requires a fresh check against the same preservation obligations.
The escape hatch is part of the design One rule follows for the system this book proposes: a generated view must provide a route to the exact source version from which its claims were derived. Where the source is available, the reader should be able to open the original passage in context, not merely see a citation-like label. Where access is restricted, that limitation must be visible rather than silently replaced by a reconstruction. Provenance needs a source identity, version or retrieval time as appropriate, stable locations, and a record of the transformation. A link alone is not proof that the source is current or that the view is faithful; it is the beginning of a check. For high-stakes use, a failed source or preservation check must block the derived view’s use as decision authority, even if the interface itself renders beautifully.
The fixed page retains two jobs. It is a strong baseline view for evaluation and often the best view to use. It can also be an inspectable record of what a particular source edition asserted. But it is not automatically ground truth about the world: a published document can be outdated, incomplete or wrong. The distinction matters. Source fidelity asks whether a derived view matches that edition; external correctness asks whether the edition itself remains authoritative and accurate. Passing the first does not settle the second.
A first preservation test Before asking the Semantic Browser to generate dozens of possible views, freeze one non-clinical source—for example, an incident report containing a timeline, competing outage hypotheses, disputed evidence and a proposed fix. Give readers the same decision task and compare three conditions: the original document with normal search and navigation, a carefully authored fixed brief, and a generated task-specific view. Randomise or counterbalance which readers see which condition, and keep source version and questions fixed.
Declare the preservation obligations before generation: the hypotheses and their status; the evidence for and against each; the exception that rules out one candidate; uncertainty in the proposed fix; and a working link from each important claim to the passage that supports it. Score unsupported additions, omissions, reversals and broken provenance separately from task accuracy, decision time, effort, preference and later recall. Record generation and checking cost as well. A generated view that is faster but reverses the disputed causal claim fails preservation. A view that preserves every claim but improves no measured outcome may still fail the cost comparison. The experiment is proposed, not a result of this book.
The system must be allowed a fourth answer: do not transform. If it cannot establish the required source relationship, the unchanged document and its authored aids may be the better interface.
What this does not claim The limits are worth stating plainly. Neither cited study establishes source-faithful document transformation or a general improvement in comprehension, recall, transfer or decision quality. A reader’s declared task is not the same as a verified model of that reader, and a successful generation is not evidence of permission to infer further preferences or act. Even the preservation test above can establish only agreement with specified claims, conditions and relations in a pinned source—not complete recovery of the author’s private intent. The programme must separately test presentation quality, source preservation, the receiver’s observed performance, and whether the system was authorised to use the supplied task context. Those are different measurements, and none should stand in for the others.
Where this leaves us The fixed page remains a valuable solution: stable, inspectable and often carefully optimised. It cannot anticipate every future reader and task. Current systems demonstrate that a new interface structure can be generated or revised during use, but they do not demonstrate that a document’s meaning survives the transformation or that the result improves a reader’s work. The proposed alternative therefore needs a contract: a declared task, a pinned source, explicit preservation obligations, a checkable derived view, a route back to the source, and a comparison with a strong fixed baseline. Only the experiment can say whether the extra mediation earned its place.
The next chapter starts with a smaller, more testable decision than constructing a whole interface. Before reading a document, a person usually sees a title, snippet, abstract or preview and decides whether the full source deserves attention. That preview is already a transformation with a preservation problem of its own: it can attract the right reader, mislead them, or hide the one qualification they needed. What would count as a better preview—not merely a more persuasive one?
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.