PTPL 118 · My Simple, Sensible Plain Text to Proprietary App Workflow

Plus a thank you to the encouraging souls who patiently teach us the tricky things

These thoughts continue on from where I left off last week. The topic: being mindful about how you store your thought babies in the digital realm.

No AI here; all words, ideas and faults 100% human made. While paid subscribers are enormously encouraging and help me to keep writing, non-subscribers are always welcome to read for free.

Where’s your home base?

We may be required to use Word / Google Docs / Notion / InDesign / Affinity Publisher / Slack, but that’s no place to give birth to our word-creations!

There’s a better way.

It’s called the plain text workflow, and it’s both simple and profoundly sensible.

1. Write in an open format (plain text)
2. Copy/paste or export to the required closed format
3. Update the text file if changes are made in step 2

Sure, not every social media post needs archiving in an open format for posterity, but think about how you’d feel if it disappeared before — or shortly after — you’d finished writing it.

If it’s a shoulder shrug, writing directly into the end destination is probably fine. If your eyes are wide and your mouth forming a silent Nooooo!! at the thought, you really, really need to keep the draft in a locally stored, open format. TextEdit, VS Code, Taio, iA Writer, Notepad — there’s no lack of options (many are free) and therefore zero excuses.

Case Study: My plain text to proprietary app workflow

I use Affinity Publisher and Affinity Designer in my day job to prepare text-heavy documents. Whether written by me or provided by a client, significant chunks of text always start in plain text. 

Here is the pattern I’m following for a new music theory game I’m designing for a client:

• Create a new note for the project in open format app (Obsidian), and add a link to this project page in the relevant section of my Johnny Decimal Admin Index
• As documents and resources in various formats and locations build up, add a Hookmark link for each of them to the project page
• Paste the text into closed format app (usually Affinity Publisher or Designer)
• Keep a log of the creation process on the project page, under its own Markdown heading
• If changes are made to the text in the closed format app, I copy it above the original in Obsidian, prefacing each version with a reference number (time/date stamp)

Learning the tricky stuff (from kindly souls)

Exporting directly from plain text to other less open formats is a more technical option. I am easily scared by technical options. That’s why I love seeing things like this — 

Yes, pandoc is a command-line tool. There is no graphical user interface, no menu system, no point-and-click to pandoc. It’s a blinking cursor, waiting for you to type a command. But do not be afraid. We will work through a simple example, which most of the time will be all that you need. — Richard A. Lent 🔗

Whether or not I ever end up using pandoc, Richard has made me feel like I could. Like I can! This kind of encouragement stirs up gratitude for all the teachers I’ve had who’ve done this: taken something tough but important (to me), and made it accessible.

May you someday be that patient person who makes something seem doable for someone else (like Johnny did for me with the command line), whatever it may be.

Thank you, Wired Magazine, for giving some airplay to open formats.

Follow my RSS feed, or sign up to receive posts in your inbox  

My posts cost you nothing to read, but a goodly amount of effort on my part to put together. If you’ve found value here I invite you to share this post with someone you think will appreciate it, or to make a contribution to my support jar.