The logical way Westerners look at this window is from left to right and from top to bottom.
I’ve no problem with the Compile for: list box or the Formats column on the left.
I think the other two columns should be swapped.
I think it would be more logical to decide what to Compile and to Select a Section Type before Assigning a Section Layout to a Section Type. What to Compile is of higher order than the formatting a Section Type will get. How can you Assign Section Layouts if Section Types are not set properly?
After Assigning the Section Layouts the formatting of my manuscript is done and I’d like to see the Compile button beneath this the start that process and end up with a output document.
2 Likes
Section Types would normally be assigned as you create the manuscript – either manually or automatically, based on the hierarchy – and therefore shouldn’t need more than a quick check at Compile time. Moreover, Section Types should only need to be assigned once, regardless of how many different formats you use for the output document.
The Assign Section Layouts area is where most of the Compile customization takes place, which is why it is centrally located.
1 Like
I respecfully disagree. Section Types are of little to no use while writing a document, and Section Types Based on Binder structure are great, but practical nor logical. Following the Scrivener philosophy, Layout Types get far too much attention during writing. Their only use is to connect sections to formatting, which is a Compile issue and not a Create or Edit issue. They should not get as much attention as, say Labels or Status during writing.
1 Like
Many users find that Section Types based on Binder structure suit their needs perfectly, and they don’t need to assign types manually at all. That’s especially true for projects based on the templates Scrivener supplies, as they come pre-configured with appropriate Types and Layouts.
A Section Type defines what a document is: a chapter, a scene, a copyright page. Making that decision as a natural part of developing the manuscript seems much easier to me than trying to do it en masse at the end.
The first counter-point I would have to the approach you are describing, @AntoniDol, is practical in that what you are describing does not scale terribly well. Deferring the type assignment process to the very end may work okay if you have a few dozen binder items and a simple hierarchy, but it wouldn’t make much sense once you get over a hundred in an outline that has a fair amount of intended structure to it (like part - chapter - section - subsection, etc.).
The second issue I would have with this argument is that Section Types can be very useful in all phases of the project. I view them as having a similar role in the outline as styles to do text. They are a way of bring structural clarity to the outline, and as such they are a form of metadata that can be useful in and of itself—no less useful than the Label or Status flags, for instance, in searches and so forth. I even use them for roles that do not particularly have to do with compiling, such as marking different kinds of notes. This is what is meant when we refer to Scrivener as a typed outliner, where nodes have semantic meaning—and to me that is just as if not more important than the label.
While that does not mean everyone should work that way, it does demonstrate how thinking of Types earlier in the process can be beneficial—much by the same argument that thinking about Styles during the writing process can be beneficial, even though we may not be considering what they look like until they compile. To my mind anyway, having no firm concept of what I’m writing into, as a structural point of detailing, would be difficult.
In short: there are good reasons why we made Section Types a fundamental part of the project, rather than being simply compile settings. Indeed if they had no role in the project, it probably would have been more straight-forward to dispense with Types entirely, and map Layouts directly to binder items (either through structural mappings right in the compiler, or manually).
As Katherine notes, the listing in the Contents tab of the compiler is, by design anyway, meant to be more of a reference than anything. It is a way of making sure that the Layout assignments you are making correlate properly with the outline. That you can edit them here is more of a “well, that would be nice to add to the design” thing, than meant to be the core interface where one does this. It’s a pretty bad place to be doing it, given you really have no way of knowing what is going on save but binder titles. The Outliner in the main editor is much better, as you can open items and make sure you remember it correctly, etc.
Theory stuff aside—as far as how people use Scrivener—I go so far as to say that by a very large percentage, most writers using Scrivener do not give much of a thought to Section Type assignments in any sense at all, least of all to the degree of manually making assignments one by one. Most will start using Scrivener with one of the built-in templates, which has an example hierarchical setup that works well most of the time, and has simple instructions in its help file to switch things up if you prefer another way of working (like chapter-length files instead of folders with multiple sections or scenes).
About that, the amount of times I see people painfully coercing their writings into an uncomfortable hierarchy just to suit the sample structure provided in the template is enough evidence to the fact that there are a lot of people that could make life easier for themselves by learning what they are. Logically and from a standpoint of efficiency and ease of use, there is no reason at all to have 25 folders, one for each chapter, each with one single file in it—except if one is not learning how to use Section Types and thinking they have to follow the “rules” as described in the Default Types by Structure tab.
Now does all of that mean the preview column should be second or last? I don’t know, I don’t actually have a really strong feeling on that—but where I do feel there is a good argument for having options on the right side, in the same sort of position that the inspector is in. The preview of the document, driven primarily by the adjacent Format list, makes sense in the middle especially once you click on other tabs on the right. At that point, I think it would be a little strange to have settings for metadata and such in the middle.
1 Like
Thanks Katherine and Amber for your detailed replies to my wish for swapping columns in the Compile Window.
Don’t you think it’s more logical to determine what you’re compiling before you determine how the result will look like? The logical order of the Compile windows is wrong.
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.
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.
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.
As to metadata and settings, I do agree they best in the right hand side column. It needs a small layout change to keep them there.
May it suggest making swapping columns optional in an Options/Appearance/Compile tab?
2 Likes
Again, users who start with one of our supplied templates will have Section Types assigned for them.
I want my chapters to look the same regardless of which chapters are included. While many of our users write books, we also have a lot of journalists, short story writers, poets, and others who Compile much more often. Most generalizations about the writing and publication habits of “Scrivener users” are false.
1 Like
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.
6 Likes
That’s precisely why section types should go first (or early on). You can’t know what you’re compiling if you don’t know what the documents are — that is, what their roles/meanings are — and that’s where a section type comes in.
Among other practical reasons already mentioned, consider the benefits of putting the structure of a chapter in Document Templates.
In each of my chapters I have documents of several types: “epigraph”, “setting” (info in the title and compiled with <$title>), “first scene” (no 1st line indent + a number of words in small caps), “scenes with separators” (and no 1st line indent), “other scenes” (no visible distinction). Each has a section type and a section layout. When I create a chapter, I push a single keystroke using Keyboard Maestro (or use the menus) to add that structure in one Scrivener command. Now the chapter folder and each subdocument already has the formatting, section type, label, status, custom icon, and other metadata I want.
Then I write the chapter.
1 Like
True enough… but I’ve given a great deal of thought to types, and use them to make pacing my novels easy.
Many fiction authors want events to happen at a certain point in the novel—if you use the “save the cat” structure, those would be theme exposition, catalyst, break to act 2, midpoint of act 2, etc. They struggle with placing them using the chapter/scene paradigm. I use another section type which I’ve invented, called (unimaginatively) “chunks”.
Underneath the top level, I have four folders for acts, which have the section type “chunk”. Beneath those, I have various pacing folders (opening to theme exposition, theme to catalyst, etc.) which also have the type “chunk”. Finally, inside the pacing folders, I have my chapter folders. Thus, my chapter folders are actually 3 levels down. I have my “default types by structure” set to provide this automatically.
When it comes to compiling, I search for the “chunk” section type and turn off “include in compile” for all those folders. Thus, these folders never affect my final output. But while I’m writing, I leave them in. I assign word count targets only to the pacing-level “chunks.” These then sum to the correct targets for each act. In the outliner, I can easily see actual word counts and total word counts up the chain, as it were, and can see that my first act is 20% over target, and all the fat is in the Setup chunk, which has 3 chapters, two of which I should really pare down. Maybe those scenes with that one character should come later… or could they be combined? Maybe just cut…
This kind of at-a-glance “oh that’s why that section is dragging” analysis is challenging to impossible with any other software besides Scrivener. My editors criticise many things about my writing, but I rarely hear complaints about my pacing. Using section types imaginatively makes it much easier.
8 Likes
I may not be understanding you correctly, but have you ever tried assembling your chapter folder skeleton directly into the Templates folder, as it should be arranged, and then selecting the master folder itself when creating a new doc template? It may feel weird because you’ll be selecting a submenu rather than menu end-node, but try it. 
I may have worded that a poorly, because absolutely, I don’t think this particular feature set excludes any form of writing that one would use Scrivener for. While a novel may be structurally simpler, in terms of the variety and quantity of layout and typesetting considerations, as a technical document—the entire crux of my argument above is that Section Types are not only for compiling. Even if you only need two Types to properly format your work, or even just one (for the flat-list chapter sorts), that doesn’t mean there are no creative ways to use internal types, as you describe—in or out of the Draft folder.
So yes, thanks for sharing how you handling pacing with this mechanism. That is a very interesting approach.
Oh, I concede that fiction has much lower formatting complexity than non-fiction, generally speaking. That’s why I seldom answer questions about compiling on the forum.
Better you than me. That’s why I ignored L&L’s recent job posting. I’d lose my temper fast and ruin L&L’s reputation.
But seriously, yes, I agree that people should learn about this as they go along… but they probably won’t unless Scrivener adopts a game paradigm, putting mini-tutorials in that one has to pass before a given feature is unlocked, and rewarding them with cute puppy gifs when they get it right.
My, I’m cynical today. I’d best step away from the forum before someone gets hurt.
1 Like
Yes, I know. The Keyboard Maestro macro adds a chapter folder containing epigraph, setting, and scene documents.
BY THE WAY, this discussion/concept of “types” is a vital point missing from many users’ understanding of Scrivener. If there’s a way to make it clear early on in the user experience, you need to do that.
1 Like
“Things that users understand” and “things that are documented” have some overlap, but not as much as one might hope.
1 Like
Okay, we may be talking about different things, because to my mind you definitely do not need a macro to get this result from a single document template command use:
BY THE WAY, this discussion/concept of “types” is a vital point missing from many users’ understanding of Scrivener. If there’s a way to make it clear early on in the user experience, you need to do that.
Right, they are introduced in the Introduction, where binder items themselves are introduced, even before metadata is brought up—but I don’t think many people read the manual front to back.
True. Information is an unruly beast at best. Still, we need to preach far and wide the idea that Scrivener supports a hierarchy of formatting chunks at different levels:
- Purpose-targeted Compile formats
Users need to know that Scrivener (unlike Word) can compile radically different products from the same content, as demonstrated at the Synopsis/Epigraph link. It’s a primary advantage of the Scrivener paradigm, and most users don’t have a clue.
- Types and layouts at the level of documents
Competent Word users structure their writing using styles, but they don’t understand using section types for the very same purpose at a higher level.
- Paragraph styles
- Character styles
- Fonts
- Type faces (italics, bold, bold+italics)
I didn’t say I need a macro.
