The right goal is not to compromise halfway between Word and Markdown. It is to separate the document’s meaning from both its editing interface and its final rendering.
A document can have one semantic source of truth while offering several projections:
- a clean, familiar writing page
- a keyboard-oriented plain-text view
- an outline or structural view
- an annotated editorial view
- rendered HTML, PDF, ebook, or manuscript previews
The writer chooses the representation appropriate to the task.
A semantic document underneath
Internally, the harness should store meaningful elements rather than simulated sheets of paper:
- title
- section and subsection
- paragraph
- block quotation
- list
- footnote
- citation
- figure and caption
- aside
- scene break
- comment
- unresolved note
- emphasis and links
This could serialize to Markdown, AsciiDoc, or another inspectable text format, with a sidecar file for information that plain text cannot conveniently hold, such as comments, provenance, and branches.
The important properties are:
- no opaque binary format
- stable, deterministic files
- clean diffs and version control
- reliable import and export
- no formatting corruption caused by copy and paste
- access to the document without the original application
But nontechnical users should never need to know that an abstract syntax tree or text serialization exists.
A familiar surface, without Word’s page simulation
The default view could resemble a conventional word processor: a centered column, ordinary text selection, familiar shortcuts, and a restrained toolbar. But it should edit content, not page geometry.
A writer selects a heading because it is a heading—not because it is 18-point bold Helvetica with extra space below it. A quotation is marked as a quotation, a citation as a citation, and an aside as an aside. The publishing theme decides how those things appear.
This eliminates much of the fragility of WYSIWYG:
- headings do not become inconsistent
- pasted text does not import a nest of hidden styles
- indentation is not made from spaces
- page breaks do not move unpredictably during composition
- changing the publication format does not require reformatting the draft
The interface can still show headings, italics, lists, and quotations attractively. It would be better described as WYSIWYM—“what you see is what you mean”—with a true output preview available when needed.
Pagination should generally remain off while drafting. A continuous text column is better for composition; page layout belongs to a preview or production mode.
Multiple views of the same document
A single shortcut could cycle among a few deliberate views.
Compose
Only the prose is visible. No page furniture, AI controls, diagnostics, comment balloons, or permanent formatting ribbon.
This should feel more like WordStar or a good typewriter than a modern productivity dashboard: fast startup, low latency, strong keyboard navigation, and nothing moving unexpectedly.
Source
A plain-text representation for people who want it. Markdown syntax is visible, files are directly editable, and external tools can operate on them.
This should be a first-class view, not a risky “advanced mode.” Changes in source view and compose view operate on the same document and round-trip reliably.
Structure
The document is folded into headings, paragraph summaries, first sentences, claims, or rhetorical roles. Sections can be moved without cutting and pasting large spans of text.
Inspect
Comments, citations, provenance, repetition maps, factual checks, and editorial diagnostics become visible only when summoned.
Preview
The same content is rendered using a target profile:
- web article
- academic paper
- print manuscript
- newsletter
- ebook
- PDF
- publication-specific house style
Preview is not the editing surface, so visual production concerns cannot constantly interfere with composition.
Two interaction vocabularies
The harness should support both direct manipulation and keyboard composition without forcing either community to adopt the other’s habits.
A nontechnical user could:
- Select a passage.
- Click Quotation.
- Add a source through a familiar dialog.
- Drag a section in the outline.
- Choose Export as PDF.
A keyboard-oriented user could perform the same operations through commands:
quote paragraph
cite selection
move section after "Objections"
export web
fold to first sentences
Markdown-like input can act as a shortcut without remaining visible. Typing ## at the beginning of a line could create a heading block; typing > could create a quotation. The interface might briefly acknowledge the transformation and then return to clean prose.
A command palette provides discoverability between toolbar and memorized shortcut. The user can search ordinary verbs such as “add footnote,” “compare versions,” or “show only quotations.” Recent commands gradually become keyboard shortcuts for frequent users.
The system should not describe this as “learning commands.” It is simply a faster way to use the same features.
Precision without programmer aesthetics
Plain text feels precise partly because it has predictable behavior. The product should preserve that precision in the visual editor:
- keystrokes never lag
- selections never jump
- undo is complete and trustworthy
- formatting never changes by inference
- smart quotes and other substitutions are controllable
- keyboard commands compose predictably
- clipboard behavior is explicit
- every transformation has a visible diff
- files save continuously and locally
- the application works without a network
- every document can be exported without an account
It should also support more useful textual scopes than ordinary word processors:
- word
- sentence
- paragraph
- section
- quotation
- claim
- all uses of a term
- all passages linked to a source
A user could select with the mouse, while an expert could say, in effect:
Compress → this paragraph → preserve the example.
That brings the precision of modal editing to ordinary users without requiring them to learn Vim’s notation.
Styles should express roles, not decoration
Modern word processors technically have styles, but they make ad hoc formatting so easy that documents often become inconsistent. The harness should make the semantic path easier than the decorative one.
Instead of showing dozens of fonts and spacing controls during composition, it might offer:
- body
- heading
- quotation
- epigraph
- caption
- note
- aside
Visual themes then render those roles. If a user genuinely needs custom presentation, a separate design mode can expose typography, margins, and layout. Those decisions should apply systematically rather than become invisible local overrides.
This is the same separation programmers get from HTML and CSS, presented without asking writers to understand either.
AI should obey the same separation
AI interaction should not live in a chat window beside the draft or continuously decorate the page with suggestions. It should operate as explicit, scoped commands over the semantic document.
For example:
- diagnose this paragraph
- challenge this claim
- find support for this assertion
- compare these two sections
- show internal repetition
- propose three transitions
- shorten by 15% without changing the examples
The result should appear as a diff, annotation, or alternative “take,” never as an unexplained replacement. Pressing Escape returns immediately to an unannotated page.
A useful interaction contract would be:
- Draft: no unsolicited intervention.
- Inspect: reveal a chosen editorial lens.
- Act: apply a specific operation to a selected scope.
This matters especially given Graham’s and Zinsser’s observations. The system should not interrupt the difficult work of formulating thought with easy generic prose. It can remove clerical friction while preserving the struggle over what a sentence actually means.
A concrete experience
A new user opens the application and sees a blank, continuous page. They type as they would in any word processor. A small, familiar toolbar appears only when text is selected. Headings and quotations look formatted, but the writer is manipulating semantic elements.
As they become more proficient, they discover:
Ctrl/Cmd-K opens a command palette.
Ctrl/Cmd-. reveals the structural outline.
- A shortcut changes from paragraph view to one-sentence-per-line view.
- Another hides everything except the first sentence of each paragraph.
- Escape always returns to the clean draft.
- Any passage can be inspected, transformed, or compared without opening a chat.
- The underlying files can be opened in a text editor and placed in Git.
- Export profiles produce publication-ready artifacts.
The crucial design principle is progressive disclosure. The default experience should be as approachable as a stripped-down word processor. Precision, programmability, source access, custom workflows, and agents should reveal themselves as the writer needs them.
That would combine the strongest qualities of both traditions:
- from old writing programs: focus, speed, stability, and keyboard fluency
- from plain text: portability, inspectability, composability, and separation of concerns
- from modern visual tools: familiarity, selection, direct manipulation, and immediate feedback
- from agent harnesses: project awareness, configurable operations, verification, and reversible automation
The result should not feel like an IDE disguised as Word. It should feel like a very calm writing instrument that happens to have a rigorous textual system underneath it.