In school they taught us to outline the term paper first, then write from the outline. It’s an ideal no one achieves, to have the product arrive in finished form in our mind before we start exploring.
Instead we wrote the paper first, then the outline.
And that was correct, because it was the only way that worked. But it didn’t get us much more than a slide show presentation of our work. It’s different when you have a structure editor, an outliner. Because you can revise both the text and its organization after the initial burst of writing.
Here’s how I do it today, in my outliner. I write from top to bottom. Then I review. If I find structure, I add it.
Then I have a structure to work with, I add more ideas become apparent, more things I have to record, to tell the reader. The order might change. The process of each little project is to iterate both the work product and the narration until I feel I’m ready to move on to the next thing.
Of course I might start two or more things at the same time. For example I have two worknotes open now, and this blog post.
In a blog post I play with order more than structure. They are meant to be read from top to bottom, as a story.
But worknotes offer different things to different people. I write them for today’s users and hopefully tomorrow’s too. But I also write them for developers, including myself, who will continue to work on the code behind the notes. I find it very useful to be able to open my notes from a previous project, while working on something related, and find it all neatly organized, so I can skip right to the part that’s relevent to me.
I thought it would be interesting to take a screen shot of my worknotes outline so you can see what projects in various states of completion look like. At the same time here’s one of my blog outline. See how they’re different?
Outlining works on a computer, as long as you revise. It doesn’t work on paper because revision, especially of structure, is hard.