When the student pitches the plan to me, I start by looking at the items in the boxes of the flowchart, to make sure they are all relevant and that no relevant things have been missed. So far, this is no different than looking at a bullet list in a conventional outline. But the next step is the key: if the diagram has A->B->C, for example, I propose some other ordering and ask the student why that couldn't work. And I also ask whether we actually need that B in the middle.
This directed-graph approach can help to reveal a good logical structure for the overall composition, often saving an great deal of time at a later stage, where the pieces being moved around are not just phrases or ideas, but rather paragraphs, sections, or even chapters.
Quite often, the best way to come up with a diagram of this type is to explain the goal of the written work to someone else, drawing the diagram as part of the explanation. If the listener says "I don't see how you got from that idea to the next" then the diagram might need another box.
The other hint I give to students is to keep updating this flowchart as the writing is being done, because the act of writing can so often uncover things that were not envisioned at the start.
PS. when I say "my student", I include myself, for the teacher who is not also a learner is missing an opportunity.
If you are writing a technical document ordering of points like this tends to look like an outline format but the dependencies are not visible in the end product and are often implied.
If you are writing about a report of events/fiction there's often also natural checkpoints or serialization paths. If Alice and Bob go to a casino at the same time, there may be a logical ordering that makes sense to finish some of Alice's and Bob's story individually with them both arriving at the casino. This allows the reader to unload the idea of the action of 'arrive at the casino' and use that as the foundation for new ideas without having to reconsider it. These new 'checkpoints' are places you can refer to, as in 'this thing happened because of how Alice and Bob came to the casino' without re-explaining everything. In Math you can refer to a previous Lemma, in technical writing you can refer to a previous section or figure. This concept also helps the idea that people can only generally keep a handful of things at the top of their head at once and can help collapse multiple individual ideas into a more common concept (similar to refactoring 'extract function' in programming).
So in actual practice this benefits by using a media or tool that's easy to rearrange sections and make dependencies. For physical media I've used blank index cards and for tools I use Emacs and org-mode because I can quickly rearrange outline headers. In this outline I list dependencies to other outline headings and external documents. This should only talk about the structure and not really go into things you'd like to write there, and generally by working through the dependencies you can see how you get from idea a to b to c and can lead the reader exactly where you want them to go. I can see how using a mind mapping software or draw.io to build a flowchart a good method as well but the act of moving things and reordering things needs to be cheap and intuitive to your thought process.
Another way I often approach more creative assignments is figuring out where you want to end up and working backwards until you get where you want to start. Much like going from the end to the start of a maze is often easier I approach writing the same way. It also helps make sure you have a direct line from the first idea to the end idea at least on paper as you assemble what's important. The end here can vary depending on what kind of document I'm writing whether it's a final statement of an argument, a single idea or multiple set of ideas I want to explain to someone, or the climax to a story. The way you find the introduction and start point this way is by thinking of your target reader and what you need to give them to get them naturally and easily to the ending you've already decided on. Because you know where you're going to end up it's easier to manage fanning out to all the supporting ideas that need to get to that end idea without bringing in things that are irrelevant or actively distracting. Because you are thinking about it like a flowchart instead of an outline, it's OK at that point to fan out dozens of ideas, and then fan out the precursors of those supporting ideas, and then fan out the precursors of those ideas until your target reader if they read everything would be able to comfortably reach your final idea. Then you can start doing some of the dependency and checkpoint work that I described earlier and the ordering starts to emerge from the pile. I find this method also helps my writing be more targeted towards the goal and does a better job engaging the reader (where this post is a poor example).
I would not trust my personal knowledge base on something I do not directly control.
TiddlyWiki can be as simple as a single HTML file, but can also work with a server.
There are also quite a few extensions, including TiddlyMap, which adds concept mapping.
Here is a tip that's really helped me over the years. Have the computer read highlighted sections back to you (via Accessibility features on MacOS, for example). I do this so often on my Mac that I have a keyboard shortcut for it; ctrl-esc. I use this feature all the time including for the composition of this comment. It is amazing to me the number of mistakes you can catch in this manner that you would not catch otherwise. The reason is your brain takes the same mental shortcuts in reading aloud (as the article recommends) as when you write.
On Linux I was able to do this with the following shell command:
espeak "$(xclip -o)"
Here is a doc with screenshots for any Mac users that might wan to try this out: https://docs.google.com/document/d/1mApa60zJA8rgEm6T6GF0yIem...
I think that "give yourself some space" is by far the most helpful tip. At any given moment, in any given state of mind, you'll only ever have an imperfect perspective on what it is you're trying to say, and how well you've succeeded in saying it.
Waiting until you're in a different frame of mind, then revisiting the piece, is the best way of "layering" your own ideas – filling in gaps, considering new perspectives, coming to new realizations.
I think it's something that has to be done with every piece of writing. You either get someone else to look at it and do it for you (if you don't have time), or let enough time pass that you have (in a sense) become "someone else" yourself, and read again.
I then spend a day or two, revisiting it, and making tweaks.
I suspect that my biggest issue is overuse of the passive voice. I was pretty much trained into it (long story), and it tends to be my default.
If you don't have a person to edit your stuff, read it over with fresh eyes.
This goes for anything from late-night texts to 100K - word books.
To exist or not, I ask myself.
It has two things that stood out for me:
* It clearly discusses "grammar rules" and "personal style", which helped me locate myself in all this.
* It doesn't just say "avoid the passive voice", but explains when the passive is needed (it has nothing to do with "when we don't want to say who acts", but a lot with "the sentence is easier to understand when X appears at the beginning of the sentence, the easiest way to achieve that is to use passive voice").
Oh, and a third: it has wonderful exercises.
There are many editions of the book (actually there are even three titles, all with "Clarity" and "Style" in them) – it doesn't really matter which one you choose.
Best easiest writing tip 2: The most important word in the sentence is the verb - it should always do the heavy lifting. This means that - when possible - you should avoid the passive voice, but it means much more. When writing, select verbs that pop.
From: Joe walked down the street without direction
To: Joe meandered west.
The problem is that it's often almost impossible to maintain an entirely objective perspective on your own writing. The most reliable method is always having a third party give a document an in depth review in order to avoid sounding stupid.
In fact, a buddy of mine locked in quarantine recently released Edit Mule (https://www.editmule.com) to bridge this gap and make it easy to get a professional editor to do this. There really is way too much bad writing out there--hopefully they can reduce it.
It is comforting to think we can be geniuses with time and effort. But the genius that visits you does not labour.
Not criticizing the content, but the expression in this recent example of overediting: http://paulgraham.com/useful.html Note a paragraph comes to life towards the end, that I would guess is transcribed conversation.
Writing by hand, you can also draw arrows for relationships, little diagrams, mini-drafts etc.
The thing that's missing is that you also need another pair of eyes at least for anything beyond a personal blog post where it's somewhat OK to have mistakes. Obviously you can't get at least a copy editor for anything but you basically can't publish even a short book, report, or something like that without someone else doing a careful read.
Also, journalists work in a different context than other writers. They write for publications with people on staff specifically to edit their copy. Someone writing a blog post, internal company memo, personal essay, documentation, etc may not have access to a paid editor or time to wait on volunteers. Definitely a good practice to get someone else to read something you care a lot about or are getting paid to write. But there are lots of things (arguably!) that fall short of that.
It covers technical issues like ticky sentences, excessive pronouns, and overused words — plus stylistic things.
Besides using a thesaurus for writing, I occasionally also find it useful for naming things when programming.
Now, I see information density as a sign of respect and empathy to the reader, and try to optimize in that direction.
It's ironic, because I greatly enjoy novelists like Turgenev, Storm, Mann and Tolstoi: prolific sewers of purple patches. Although Kosinski, Hemingway, and other such literary minimalists are satisfying, too, in their own ways.
Anyways, here are some informal notes that work for me, in effective communication and documentation, if this philosophy interests you:
- allow the reader to stumble over the diction once (needing to look up one word in a dictionary), than to stumble over the grammar two or three times: convert grammatical complexity into diction complexity at any opportunity. In particular, if you can replace a prepositional phrase with a word, do it: many people stumble on prepositional phrases.
- avoid redundant words or repetitions phrases ("I think", "if you think about it", "plan to think about"), unless you're intentionally expressing deference or uncertainty. This unnecessary "stuttering" creates space to read "between", and makes your language more difficult to parse.
- terseness is an underrated virtue. One can almost always shorten a sentence without sacrificing readability. I find arbitrary char limits (per line) and line limits (per paragraph) to be helpful tools.
- "unliterary" or even "poetic" structures – bulleted lists, quotation marks, crazy line breaks, are underrated tools in the terseness crusade.
- for non-printed documents: 1 sentence per paragarph. If your paragraph has 2 or 3 sentences, only 1 is more than 8 words.
- subjects and verbs close together, ideally adjacent. English is Germanic, but it is thankfully not German: no sense in forcing your reader to buffer a subject whilst searching for a verb, or vice versa. Likewise for adjectives and adverbs.
- avoid leading with "it", only to reveal the subject later in the sentence.
- avoid parentheticals. this is hard for me, because I don't tend to think linearly, but if you have something worth sharing, it deserves to be free of parenthetical prison, and easy to read. (exception is if it's a medium-length sentence, at the end of a paragraph, that you want to draw attention to).
- if the reader wants to know more, and your medium is interactive, they will ask. don't overdo it.
Cole Nussbaumer Knaflic's book "Storytelling with Data" is a good book on technical communication. TLDR: it's a process, and it's not about you, it's about them.