Well to that part at least, you should know is very difficult to actually end up in that position. There is nothing within this whole pipeline that is static, or that can only be set once, and most everything can be reverted or overhauled with either batch commands or high-level changes.
Perhaps a good analogy, given your experience, is that this is far less like programming and far more like cascading style sheets. I don’t know how much you know of HTML and CSS, but with a little knowledge of the basics, you can almost better think of Section Types as being like the HTML side of things, where we use different elements to give the text structure and meaning. Compile settings are like the CSS, where we take the classes and elements we used in the HTML and give them formatting.
To apply this to Scrivener, I suppose you could consider manually assigned Section Types as being analogous to <div class="something">, and a Section Layout assigned to it as a line in the CSS like, .something { stuff }. Automatically assigned Section Types are then more like using stock HTML and doing most of the design from the CSS with selectors such as p { stuff } and h2 { stuff }.
With this way of thinking of it then, changing our minds about whether chapters should have page breaks or not is a “CSS” or compile layout decision. We didn’t screw ourselves up by going down another path initially more suitable for long articles. And like CSS, compile settings are applied to the structure. Thus one .css file can make the website look radically different from another .css file, perhaps without changing a single line of the .html file (the project’s Section Type structure).
With programming you have to be a lot more careful most of the time, and think things through before you start, or do several rewrites of a class before it is well understood, and such rewrites can involve laborious refactoring and such elsewhere. It’s a lot more difficult to get yourself into a pickle like that with Scrivener.
If the HTML/CSS analogy is of no help to you, then think of it more directly: your Project Settings: Section Types rule can start out saying “Level 1 folders are chapters”, but if you get a few months into the writing and realise you want to split things into major Parts, that’s no big deal. You nest the folders in the binder into part folders, and then go into your Project Settings and say, “Level 1 folders are parts, and level 2 folders are chapters”. If you can do that, it’s almost impossible to make a mistake that costs you significant amounts of time.
I am going through the tutorial now (just updated to v.3 Windows). What sections of the tutorial address all this, and are there any threads you can recommend that highlight some of the (non-standard? alternative?) uses of Scriveners tools for organizing/sorting, and “labeling” text, sections etc in a massive project with extensive citations, tables, figures, and custom “styles” required by the publisher? (This will be published in small bites, so that is a consideration)
As for further materials, well the tutorial’s “Getting it Out” folder will of course go over both of these tools, section types and compile settings, in a very simple manner, using the tutorial itself as a data set which starts off without much structure at all.
But on this post you responded to itself, and the concepts within, there isn’t a lot of discussion on how Section Types themselves can be used as a tool. As I posit there, a lot of this is probably down to educational practices, which don’t address them at all until the “Getting it Out” type section comes up. So if that is how everyone is learning of their existence, to leap to them being something you could start benefiting from on day one of a project is not spelled out anywhere, save perhaps in the user manual itself. Section Types are introduced very early on, in the Introduction, under the chapter about what binder items even are. But as it is reference rather than a practical advice column, it doesn’t go to heavily into these concepts and mainly just spells out how agile they can be, and the benefits of working with them early on in your project rather than ignoring them until the last minute.
Now one last thing I have to mention, since you do speak on your work being more on the technical end of the spectrum, at least in terms of what you will need from the structure of the text itself (citations, tables, figures, etc.). I’d definitely at least consider using Scrivener’s Markdown side of things. Chiefly this way of working is much better suited toward these kinds of texts, because the systems built for it are more mindful what what technical writing needs (strong support for citation workflows, cross-references directly to an equation or table for example, something Scrivener itself is completely incapable of doing on its own, or building a list of figures somewhere even).
But beyond those practical considerations Markdown is itself inherently structured text, you get a lot of things for free that otherwise take manual effort in Scrivener. The example I used above is a good one in fact. If we do not use a structural format to compile to, we have to make up structure for ourselves, and say things like “Level 1 folders are parts”. With Markdown you don’t have to worry about any of that, and indeed many projects could be boiled down to three simple concepts:
- Does this section need a heading, any kind of heading at all?
- Does this section need text content output?
- Does this section need both a heading and text?
In Markdown the answers to these questions very simple, no matter if we are talking about a Part or a sub-sub-section. Thus, Section Types become less about defining basic structure and more about describing exceptional structure that doesn’t fit into those three queries above.
But Markdown usage is a whole different topic, and probably one worth spinning off to other threads.
(oh crap!)
I never worked in html or CSS, but I do understand the basic concepts.