Draft in plain text, format in the CMS

Write where nothing interrupts

Drafting content directly in a CMS invites distraction. You stop mid-sentence to adjust heading levels, worry about image placement, or fix formatting inherited from a paste operation. The cognitive cost is real.

Open a plain text editor instead. Write the content as continuous prose. No formatting, no structure markup, no decisions about where the sidebar callout should go. Just the information in the order it needs to be said.

This separation matters because writing and structuring are different tasks that require different attention. Trying to do both simultaneously produces worse results for both.

Mark structure with consistent conventions

Once the draft exists, add minimal structural markers before moving to the CMS. Use whatever convention keeps you moving:

• Double hash for main headings, triple for subheadings
• Asterisks for list items
• Blank lines between sections
• Brackets around notes about images or callouts

The exact syntax doesn't matter. Consistency does. You're creating a intermediate format that translates cleanly into CMS fields without requiring you to think about CMS fields while writing.

This step takes three minutes. It clarifies where section breaks belong and whether your headings actually represent the structure you intended.

Transfer to CMS as mechanical work

Moving structured text into the CMS becomes data entry, not composition. Each marked heading maps to a heading field or style. Each bracketed note becomes an image block or callout. No writing decisions remain.

This mechanical quality is the goal. You're not wondering whether this paragraph needs to be its own section. You're not debating image placement while trying to remember what comes next. The content is settled. You're simply putting it in the container.

If the transfer process reveals structural problems, note them and continue. Fix them in the plain text file, then update the CMS. Don't iterate inside the CMS where every change involves clicking through formatting options.

What this prevents

Drafting in plain text eliminates several recurring problems:

You won't produce formatting inconsistencies from copying between applications. Plain text has no formatting to paste incorrectly.

You won't lose work to CMS timeouts or browser crashes. Plain text files save instantly and don't depend on server sessions.

You won't interrupt writing flow to make presentational decisions that don't affect meaning. Those decisions happen later, when you're in structure mode rather than composition mode.

You won't produce pages where the content structure and the CMS structure fight each other. The structure gets marked explicitly before the CMS sees it.

File naming that works

Save drafts with the page slug and today's date: `about-page-2024-01-15.txt`. When you revise, save a new file with the new date. Don't version-number. Don't use "final" or "revised" in filenames.

Date-based naming creates automatic history. You can see what changed between drafts. You can recover earlier phrasing without undo archaeology. You can tell at a glance which draft is current.

Keep these files. Storage is cheap. The ability to review how a page evolved is worth the few kilobytes.

The formatting you actually need

Most pages need four formatting elements: headings, paragraphs, lists, and links. Occasionally bold for genuine emphasis. Almost never anything else.

If your draft requires more formatting than that, question whether you're solving a content problem with presentation. Usually you're not.

Plain text drafting makes this obvious. When the content works as unmarked text, it'll work in the CMS. When it doesn't work as plain text, formatting won't fix it.

Start tomorrow

Next time you sit down to write a page, open a text editor first. Not the CMS, not a word processor. Just text.

Write the content. Mark the structure. Then open the CMS.

You'll finish faster and produce cleaner pages. The method is boring. That's why it works.