I often advise students to start with a sort of flowchart of ideas, instead of an outline. This consists of boxes with ideas, keywords, phrases, or diagrams, connected with arrows in a sequential order.
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.
Sounds like a great idea. Is it too much to ask you for an example so that many others (me included) might have a concrete understanding of the approach?
I use a similar methodology when I write as I am often writing technical documentation and not as much fiction these days. In technical writing it is easier as there's a fundamental understanding that any base concept that's involved must be defined and explained before it is applied. This introduces a natural dependency chain of things that have to happen and can be used to help sketch out a basic order. Since you have the constraint of linear top to bottom text this often at least makes ordering beginning, middle, and end talking points obvious.
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 haven't used roam, but the screenshots made me wonder if there might be some overlap with TiddlyWiki, "a unique non-linear notebook for capturing, organising and sharing complex information."
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[1], which adds concept mapping.
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.