Maps as text

In session 4 you edited a textarea and a map redrew itself. Nobody mentioned that the textarea was the map, because it did not need mentioning: you indented "Guji short" under "Supply" and it appeared on the Supply branch, which is what indenting means. Every map drawn in this course, including the paper one from session 1, was already an outline waiting to be typed.

• Line one is the centre. There is exactly one line at depth zero. Two lines at depth zero is two maps, and the parser will tell you so by drawing a very confused one.
• Two spaces deeper is a child. The number is a convention; what matters is that every level is the same step deeper than the last. Mixed tabs and spaces is the commonest reason a map draws wrong.
• Same depth is a sibling. "Supply", "Packaging", "Pricing", "Comms" and "Ownership" all sit two spaces in, so they are the five main branches. Move "Comms" four spaces in and it becomes a twig of Pricing, which is a claim about the world you probably did not mean.

The consequence is that the paper map is a rendering, not the source. The source is the tree, and the shortest honest way to write a tree is indentation.

An outline that will be parsed by a machine, or by a colleague six months from now, follows three habits. None of them is about style. Each one removes a way for the tree to be misread.

• One idea per line. "New sleeve, legal sign-off" on one line is one node with two ideas in it, and the bench will count it as one label of four words. Split it and each idea can carry its own twig.
• Consistent indent. Pick two spaces and never mix in a tab. Editors show tabs and spaces identically and parsers do not, so a map that looks right in your editor can draw with a branch missing.
• No trailing sentences. The keyword rule from session 2 applies to the text exactly as it applied to the page. "Guji short" is a node. "Guji supply is still short so the autumn blend leans on Sidamo" is a sentence that happens to be indented, and it will run off the page when drawn, which session 4's second rung measured at seven labels off the edge.

A diff is a list of lines removed and lines added between two versions. Run it on two outlines and the operations of the whole course fall out of it as visible edits.

• A moved idea is a removed line and an added line at a different indent. That is the session 3 fix, one home plus a pointer, made checkable by a colleague who was not in the room.
• A cut to a keyword is a changed line that got shorter. Twelve words became two; the diff shows both versions side by side and you can decide whether the two still bring back the twelve.
• A merged branch is a heading removed and its children re-indented. If the merge was wrong, the diff is the undo button.

Mermaid's mindmap diagram reads this exact shape. Hierarchy comes from indentation, only relative indentation matters, and bracket shapes around a label pick the node's style. It renders on GitLab, on mermaid.live, in VS Code with a preview extension, and on GitHub inside a fenced block. Two lines above your outline are the whole cost of entry:

The word names the diagram, the first indented line is the root, and everything beneath it is your outline unchanged. Node shapes, icons, classes and the rest of the grammar are learn-mermaid-with-phoebe session 5. Markmap does the same job for a Markdown heading-and-list outline; it is named here so you recognise it, not taught.

A map that is drawn once and read for years can live as a picture. A map that is redrawn on a schedule cannot, because the redrawing is the expensive part and a picture makes you pay it every time.

The pattern generalises. Anything with a shape that stays constant and content that churns, a project map, a team map, a risk map, wants to be text with a renderer attached. Anything drawn once for one purpose can stay a drawing.

A map drawn while thinking carries information that never makes it into the tree: the branch you drew first, the twig you crossed out, the arrow you added at the end when two ideas turned out to be one. All of it is legible to you and to nobody else. Send that map to a colleague and they receive the tree with a lot of noise on it.

So the split is by audience first. For yourself, draw; the mess is the thinking. For anyone else, type the tree and render it, because a reader wants the tree and only the tree. Then check frequency. Anything you will make again, even for yourself, is worth typing, because the second time you will want to know what changed since the first.

The honest failure mode runs the other way too. Rendering a map you are still thinking with makes it look finished before it is, and finished-looking maps stop getting edited. Keep it on paper until the branches stop moving, then type it.