Confirm MDX placeholder context in block-party.mdx

[MaggieAppleton]

Parent plan

#111

What to build

Read src/content/essays/block-party.mdx and produce a reference doc (comment on this issue) that lists every bare-text placeholder, its exact line number, the surrounding prose that explains what the diagram needs to show, and the placeholder's role in the argument flow. This gives the Figma auditor (and later the diagram creator) clear acceptance criteria for each asset without having to re-read the full essay.

Known placeholders already identified:

• Line 329: [spectrum of simple to complex blocks]
• Line 377: [visual for drag and drop]
• Line 420: [diagram of content and view being separated]
• Line 426: [visual for swapping blocks]
• Line 588: [annotated diagram of swapping blocks and dragging and dropping blocks]

The comment should also flag which of these are in scope for #111 vs. any extras that may need separate tracking.

Acceptance criteria

• All placeholder markers found and listed with exact line numbers
• 1–2 sentence description per placeholder capturing what the diagram must convey (derived from surrounding prose)
• Scope clarified: which placeholders are covered by Audit Figma file: confirm spectrum diagram and swap-blocks visual status #111 vs. extras needing new issues
• Comment posted on this issue with the findings

Blocked by

None — can start immediately
Related to #111

Generated by Plan issue → sub-issues for issue #111 · ● 91.8K · ◷

[MaggieAppleton]

Sub-issues created

This plan has been sliced into three sequential sub-issues:

#	Title	Label
#203	Audit block-party.mdx: catalog all placeholder markers with line numbers — Verify the 5 known placeholders and scan the full file for any additional [...] markers; output a structured inventory with exact line numbers.	ready-to-implement
#204	Document prose context for every placeholder — For each placeholder in the #203 inventory, write a 1–2 sentence description of what the diagram must convey and its role in the argument flow. Blocked by #203.	ready-to-implement
#205	Classify placeholders by scope and post reference comment on #139 — Using #203 + #204 findings, tag each placeholder as in-scope for #111, needing a new issue, or candidate for deletion; post the final reference doc as a comment here. Blocked by #203 and #204.	ready-to-implement

All three are ready-to-implement — no blocking questions need human input before work can start.

Note from reading the file: Beyond the 5 known placeholders, I identified ~9 additional [...] markers in the file (in the "What Blocks are Not" section at ~513, the Benefits section at ~569, the History section at ~648/654/666/672/680, and the Future section at ~761). The full census is the job of #203, and scope classification of all of them — including which extras may be candidates for deletion rather than new diagram work — is the job of #205.

Generated by Plan issue → sub-issues for issue #139 · ● 137.4K · ◷

[MaggieAppleton]

Block Party MDX — Placeholder Reference Doc

Full scan of src/content/essays/block-party.mdx for bare-text [placeholder] markers. Covers exact line numbers, surrounding prose context, what each diagram must convey, and scope vs. #111.

---

Placeholders in scope for #111 (Figma audit: spectrum diagram + swap-blocks/content-view)

Line 329 — [spectrum of simple to complex blocks]

Immediately follows: "There seems to be no ceiling to the complexity level we're willing to wrap up into a single block. Some could be standalone apps in their own right. Kanban boards, image galleries, live coding environments, and fully decked-out spreadsheets that function as relational databases can all be encapsulated into a 'block'. This extends to embeds which allow users to stick the whole of Google Maps, Figma, or Airtable into a document."

What it must convey: A linear spectrum or axis arranging block types from the simplest (text, header, divider) to the most complex (relational database, live coding environment, full app embed), making the breadth of what counts as a "block" visually concrete.

Role in argument: Supports Pattern #3's claim about the wide and unbounded variety of block types; the main visual payoff for the preceding paragraph.

---

Line 420 — [diagram of content and view being separated]

Immediately follows: "The content a block holds and the way it displays that data isn't firmly tied together. This makes blocks interchangeable." (Pattern #5 heading: "Separation of data and formatting")

What it must convey: A conceptual diagram showing a block's data/content layer and its view/display layer as distinct, separable components — analogous to the MVC framing introduced at line 283.

Role in argument: This is the core illustration for Pattern #5; without it, the decoupling claim is purely abstract.

---

Line 426 — [visual for swapping blocks]

Immediately follows: "Checklists can become blockquotes. Headers can become collapsible toggles. Tables can become kanban boards."

What it must convey: A before/after or transition sequence showing the same content surviving a block-type change — e.g., a checklist transforming into a blockquote with its text intact.

Role in argument: Provides the concrete proof-of-concept for the content/view separation claim at line 416; intended as a paired visual with the line 420 diagram. The plan note in #111 suggests these two may be combinable into a single screenshot or GIF.

---

Known placeholders NOT in scope for #111 — need separate tracking

Line 377 — [visual for drag and drop]

Immediately follows: "Blocks are easy to copy, paste, and duplicate. Using direct manipulation you can drag and drop them into new positions, making it quick to restructure a document without faffing about with precise text selection." (Pattern #4: "Direct manipulation of blocks")

What it must convey: An animation or screenshot sequence showing a block being grabbed and repositioned within a document, illustrating the drag-and-drop direct-manipulation interaction in action.

Role in argument: Visual proof of the "direct manipulation" claim for Pattern #4; likely best as a GIF or short video loop.

---

Line 588 — [annotated diagram of swapping blocks and dragging and dropping blocks]

Immediately follows: "A block can be dragged and dropped into a new position on the page. It can be swapped for another type of block without changing its content. It can be copied and pasted into a different document without losing its content and structure."

What it must convey: A single annotated illustration combining both interactions — drag-and-drop repositioning and block-type swap — with labels pointing to what's happening in each step; acts as a synthesis visual.

Role in argument: Summary visual in the "What do blocks give us that linear text can't?" section. Broader in scope than lines 420/426 (which are inline Pattern illustrations); this one consolidates multiple block capabilities in one place.

---

Additional placeholders found during full scan — not in the known list, not in #111

All of the following would need separate tracking if the essay is finished.

Line	Placeholder	Section	What it needs
285	[diagram]	Pattern #3 — MVC component	Diagram showing the model/view/controller parts of a single block
513	[cartoon sketch of a block as a higher interface concept, possibly implemented in WC/React/etc, but not concerned with implementation. And nothing to do with the blockchain]	"What Blocks are Not"	Clarifying illustration distinguishing the interface concept from any specific technical implementation
569	[description of how block-based documents are different to rich text editors]	"What do blocks give us that linear text can't?"	Writing placeholder / content note, not a diagram — marks a section of prose that still needs to be drafted
648	[image of xanadu's parts]	History — Xanadu / Ted Nelson	Historical screenshot or reproduction of Xanadu's "parts" system
654	[image of NLS]	History — Engelbart NLS	Historical screenshot of NLS interface
666	[image of hypercard]	History — Hypercard	Historical screenshot of HyperCard
672	[OLE diagram]	History — Microsoft OLE	Diagram of the OLE copy-embed workflow across Office apps
680	[OpenDoc diagram]	History — Apple OpenDoc	Diagram of OpenDoc's compound-document / "parts" model
761	[ diagram ]	Future — Block Protocol	Diagram illustrating standardized block-to-editor communication (Block Protocol)

There are also two <RemoteImage src="(via.placeholder.com/redacted) alt="" /> JSX components at lines 327 and 586 — actual placeholder-image service URLs indicating images that haven't been sourced yet. These sit adjacent to lines 329 and 588 respectively.

---

Scope summary

Scope	Lines
In #111 (Figma audit target)	329, 420, 426
Known, not in #111 — need new issues	377, 588
Additional extras — need new issues if essay is finished	285, 513, 569, 648, 654, 666, 672, 680, 761
Placeholder image components (via.placeholder.com)	327, 586

Generated by Implement sub-issue → PR for issue #139 · ● 88.7K · ◷