Thanks Katherine and Amber for your detailed replies to my wish for swapping columns in the Compile Window.
And thank you for the discussion!
I will reconsider Section Types as a means to semantically give sections a certain meaning, even thought I still think it only matters when Compiling.
There are definite practical uses for Types before compiling, again as a piece of metadata that is associated with an item, giving it a kind that we can think of and use in the software’s organisational tools as such. But I will come back to that, because I think it is good to first address what Types should be thought of as an elemental ingredient in the project.
I think it is useful to set aside thoughts of compile entirely for a moment, and consider what they are purely for what they are at the project level. I don’t think what they provide is an unusual or advanced way of thinking, because we have long seen evidence of people of all stripes striving towards types of things in the binder, through whatever mechanisms they had available at the time, and with varying degrees of success.
For example we would see people using custom icons to give a thing a concept of a kind, and struggle after doing so to find them useful. An icon does not actually add anything to the capabilities of an item, it just changes how it looks. You can not search for icon names, you can not sort by them, etc.
Another feature people gravitated toward for this purpose is document templates. You could kind of think of an item created from a template as being of a kind—a “character sheet” for example. Indeed when the feature was first introduced in 2010, the menu command to set a default template for a folder was, Documents ▸ Default New Subdocument Type
(we changed it when formal types were finally added to the software, to avoid confusion). But as with custom icons, there really is no formal meaning to that beyond whatever forms of configuration the document template establishes when you create an item with it. After that point, it has no connection whatsoever to the template that created it, and nothing that would bind it together with other items that were created from that template—unless you use some form of additional metadata configuration to make that connection yourself.
Document templates are still very interesting for the fact that they can set the Section Type for new items, which is meaningful in terms of the organisational feature set. With one click, you can get the custom icon you want, boilerplate starter text, metadata settings and a hard formal concept of kind, all at once.
Through you answers I’ve gathered that you think Section Types should be set during writing, but I think users seldom do, until they are ready to Compile (which may be a year off writing a novel). I’ve started polls on Scrivener Facebook groups to hear what the members think about that.
Well I don’t know if I would quite put it that way, but this may go back to the concept of whether or not it is generally best to let structural settings handle that problem for you automatically, rather than manually setting everything yourself. One reason for why the compiler is an inefficient place to be doing this is because all you can do is change each item’s individual setting, one by one. So I would not advocate for that downside being moved elsewhere—or another way of putting it, manually setting items as the primary mode of usage is the problem, rather than where you do it.
Since most works can be structurally outlined in a way that is formal and predictable, like nesting items to indicate a part-chapter-section flow, if there is a tool that lets us say “make all level one items parts” and “all level two items chapters”, and so on, then we should use it.
Thus, for most things, I would not think of it in terms of this being something one would set while writing—rather it is something one would be generally aware of, when it is useful to be aware of it. It may not always be, sure, but for those cases where you do need it to be, it is very easy to see the structural meaning behind the outline—however it got to be that way.
When we put this idea together though, we recognised there would be exceptions to a purely structural approach, and that is why there is a toggle in the inspector, outliner and contextual menus for items. It is why there is a structural default override for containers, where you can say: for this folder, make all of its descendant items “Glossary Entries” instead of the global default “Subsections”. It is why there is a single-use manual override, so we can do stuff like copyright pages or a colophon without having to come up with structural hacks (like we did in v2/1). It also means that for those whom outlining is a more organic tool than rigidly structural, we can more loosely assign types as we go.
I will reconsider Section Types as a means to semantically give sections a certain meaning, even thought I still think it only matters when Compiling.
Let’s look at the practical application of having a tool like this in the project interface. Earlier I drew a comparison between Styles and Types, which I’ll return to again. There are many cases where it is of importance that we understand the intended purpose of a thing, even if we haven’t gotten around to defining what that purpose will manifest as. Compiling is the process of taking marked up text along with a marked up outline, which by itself is purely semantic, and saying: this is what these things now look like once I click this button.
So I would lean toward agreeing with you if we confine the concept of purpose to being purely and wholly tied to what a thing looks like—but for myself anyway, I hardly recognise that as being a useful way of working for anything at all. Down that path leads the way to using no styles at all or any kind of embedded declaration of type—into the realm of just changing the font to a different variant (like italics) as a way of indicating meaning. We are no longer thinking of text in terms of “Film Title” (expressed as italics), but the inverse: italics means film title.
Now someone might argue that there is no need to have a “Film Title” text span assignment while writing. Why would anyone need to bother with setting tagged text like that, when it only matters how it looks when you compile? This is essentially the argument being made, if I understand you correctly.
In answer to that question, I would say there are all kinds of good reasons to have text tagged as “Film Title”, even if we never actually compile text tagged that way in a manner that the reader will even be aware of. A style can be made purely for one’s own internal use as a writer—as a way of finding these strings of text, or to facilitate the editing process, etc.
I assume you would agree with that in principle. Again it is not a capability everyone needs, but for those that do, being able to quickly scan through their block quotes even if separated by thousands of words, or to search for a piece of text that is only found in block quotes can be thought of as useful capabilities. These are things that could save one many hours of labour.
And of course, when we do start to think about the implementation of purpose into format, one of the common points of advocacy for the separation of purpose and format is that we can express this object in many different ways without hours of overhaul. Our “block quote”, which is just tagged text in the writing environment, can look radically different depending on how we Format it, from one compile to the next.
The parallels between this concept and how the outline itself is thought of as having a purpose, as tagged text does, should be a natural progression in the argument. Nothing that I stated above is missing from the Section Type implementation—and in fact I would say that given Scrivener’s bias toward item level organisation over text level organisation, the tool set for section types is overall richer and more useful.
How does all of this map to the writing and editing process itself?
Earlier I mentioned you can jump through block quotes one by one, and search for text within only them—well that’s about all you can do with tagged text in Scrivener. With Section Types on the other hand, I can build an automated search for chunks of the outline that have a designated purpose and display those chunks on a topically arranged corkboard (using Labels as topics and Arrange by Label view). I can of course search for text within items of a designated purpose. I can pull out a list of all the tables and arrange them in a freeform manner on a corkboard. I can filter out all such items that are older than 3 years—et cetera. The full weight of Scrivener’s power as a large-scale outliner and outline node level management tool can be brought to bear against kinds of things.
We can also think of things in a more integrated fashion, where an awareness of kinds and how they compile complement one another. Maybe you have a folder that generates a chapter heading and page break when compiled, and within that folder there are “Chapter Notes”, “Epigraph” and “Summary” section types to start off the folder. The first three are manually set, with the notes being invisible to output, the epigraph printing a stylised quotation beneath the chapter heading, and the summary having a standardised “In this Chapter…” subheading generated by the compiler, with a bullet list of what we’ll learn in the chapter. After that point we have a loose hierarchy of files nested within one another that use the global defaults, to generate sections, subsections and so forth. Perhaps interspersed among them are Table type documents, and Figure documents—created by using document templates that have the Type preset along with an icon (and whatever else). These are all useful components of the text as larger level structural elements to be aware of, and useful selections that we make while constructing the work, as part of the writing process, even if we aren’t yet thinking at all of how this will compile—how it will look to the reader.
Explaining Scrivener to others, I never mention Layout Types, because they’re confusing and of no help to users until it’s time to give folders, documents and sub documents a meaning as parts, chapters, sections and scenes in an output document. Even if there are hundreds.
So far this has all been a mostly abstract discussion on design theory, and to a degree that is not relevant to the learning process—save for in thinking of what sort of things we can teach that will make other things easier to understand later on. One such thing we have to keep in mind is that many people who are coming to Scrivener have never before used an outliner style program to write, and have no idea what that even means. Maybe they’ve blundered into that view in Word and quickly backed out of it to return to the printed page view, and that’s about it.
It’s undeniable that there are certain concepts that need to be learned before any of this starts to make sense—before the usefulness of having a semantic outline can be seen, you have to know certain basic building blocks to understand more compound ideas built upon them. The question is, are there things this tool can make easier for more writers, that is perhaps being overlooked because it is brushed aside as a compile level tool?
It is probably true to say there are forms of writing where these techniques never become super useful in an of themselves. A very simple and common example of that is the Novel starter template. If you create a test project with that and examine its Default Types by Structure setup, it’s very simple: folders act as hard chapter breaks wherever they appear and by nature of how any files put into them will be level 2 and deeper, all text items act as scenes. There is a little more to it than that as you’ll see, but for how most people will use that template, this is all that matters—and for most people they will never need to touch the settings or give much thought to Types.
That said, when it comes to learning how the software ticks though, does that mean one should never learn about what these things are until they compile? Or might they not benefit from having an understanding of this before they get to that point. What I see a lot of is what you describe—people don’t know about it until they hit compile, and suddenly it’s “complicated” because they don’t know where these things came from, what they are, or even how easy it is to pop open the assignment list to change what a chapter break looks like. Why do my chapters act like scenes and have no headings? Etc.
I do have to wonder, if an awareness of Types were pushed earlier into the learning process, so that one knows that their folder functions as a chapter break, and the files within it function as a scene—if it would not be easier to navigate the compile overview and understand that Layouts are now how we choose to express these functions—rather than learning both at once and wondering why there are two different things doing essentially the same thing (as a matter of perspective, because we are only looking at the point where these two completely different things converge).
And to return to the concept of this being a writer/editing level task, if one wishes to structure their outline a certain way because that is how their mind best works, or because their book requires a certain approach, would they not be benefited by knowing how to manipulate Types as they write? If it were more well known that this is a possibility, would we see less of people using pointless single-file folders, who would if they knew how easy it was to work otherwise, keeping a simple flat list of files in the Draft. These are fundamentally writing oriented processes that do not have to do with compiling. Having a nice corkboard of chapters with summary text when you click on Draft is something that benefits the writing process, not compiling, but you aren’t going to get to that point from our templates, without learning at least a little about Section Types.