Default section type; By Structure (from: manually set parent document)

I don’t know how this would be accomplished, but I was wondering if the children-of-children of a manually assigned section type could follow the heirarchy set up in the default structure based assignments set up in the master list of section types.

For instance, in the master list, I’ve got level 1 docs assigned to the “Chapter” section type. Level 2: “Section”, Level 3: “Subsection”, etc….

When I manually set a particular level 2 document as a Chapter, I can “manually” specify what its sub-documents are assigned, so I set them (level 3) to “section”. That works as expected for the sub-documents of the manually assigned “chapter”. Unfortunately, when I add a sub-document to a “section”, it also inherits the “section” from it’s “grand-parent” document. I then have to manually set the section documents type and tell it to assign “subsection” to its sub-documents and all sibling documents that get their own child documents.

Could there be a future enhancement that lets us specify that the default structure based hierarchy is used (but treat the manually-assigned one as starting point) when manually assigning a section type to a parent document, so all it’s child documents, and all their child documents, etc… For instance:

Default by structure:
Chapter (level 1)
-section (level 2)
–subsection (level 3)
—sub-subsection (level 4)

Manually assigning a level 3 document to “Chapter” and selecting the new feature would, for sub-documents of the manually-assigned chapter, make it look like this:
Chapter (level 1)
-section (level 2)
–subsection (level 3)
—sub-subsection (level 4)

Chapter (level 1)
-section (level 2)

Chapter (level 3, manually-assigned; sub-documents follow default hierarchy from here)
—section (level 4)
----subsection (level 5)
-----sub-subsection (level 6)

Chapter (level 1)
-section (level 2)
–subsection (level 3)
—sub-subsection (level 4)

The only way I could think of for this to work is by having some way of telling a particular document to be treated as a different level - for instance, telling a folder that it should be treated as level 1, so that it’s section type and child section types are based off that. That would require some extra complexity and settings, though, so I’d have to think about it.

My solution for this isn’t elegant, for the case you are describing, but I use document templates to create non-default level based structure where necessary. In the example project’s Templates folder, you’ll find a sample structure all set up:

  • The “Chapter” level sets its own Section Type to Chapter, and its child override to “Section”.
  • The “Section” level sets its child override to “Subsection” (and so on).
  • Each of the document templates has its relevant child document template assigned as its default subdocument type. Hence if you create a new item in a “Chapter” template folder you’ll get a new item using the “Section” document template, and so on.

Of course one downside to the method is that it only works for newly created items within the structure, and so long as they are not moved off of that level. If you create a text file in a non-override chapter folder and then drag it into here as a subsection, the way things are set up, that item will correctly be a subsection, but its child items will not automatically become subsubsections until you set the child override manually. Likewise if in the course of outlining a subsection becomes a section, then its settings will need to be fixed (and forgetting to do so may cause formatting mayhem later on).

So it doesn’t remove all labour & thought from the equation, and is probably advanced technique in that it requires maintenance, but for general outlining it should make things easier than doing all of this 100% by hand, at any rate. :slight_smile:
localised_section_type_structures.zip (99.3 KB)

Thanks. Unfortunately, what I’m doing is experimenting with existing documents to see if I want a particular sub-section to actually be a chapter unto itself. This experimentation would be easier if I could just set one document to a different section type and let that change cascade to all documents that lack manual section type settings.

I think the best alternative for me is to temporarily move my “chapter” to a level of the binder that makes it and its sub-documents behave the way I want to try out; I just fear I’ll accidentally re-order everything and get myself confused.

But you know the old saying; with great flexibility comes great complexity. Overall, I prefer not HAVING to move my binder items around to try things like this out (as was required in v2), and the fact that I can affect 2 levels of documents (“this” document and it’s child documents) while modifying the section type of a single document is a great help.

Yeah, that was my first reaction as well. Or if moving things around feels risky, one can always duplicate the chapter structure, move the duplicate to where it will work as intended. If it’s a bad call, delete the duplicate. If it’s a good call, delete the original.

Something I’ve felt would be useful, but haven’t come up with a non-confusing and complicated way of presenting it, is an acknowledgement that if outline structure can be semantically tagged, then it follows that multi-level definitions can be themselves units by which we of think of things in a more articulated but yet still holistic fashion.

In your case, you’re rightly thinking of this folder and the structure beneath it, as being “a chapter”, with all that entails to the bottom of its relative hierarchy, no matter where you put it. It’s not so much that you want to use different level numbers to kind of bend the default definition of where it is permissible for chapters to be placed—you just want that thing to be a chapter because that is what it is no matter where it goes (well in this case you want to see what a section looks like as a chapter, but “same diff”, as we used to say).

It’s the kind of statement that Scrivener already allows for (by manually setting the Type), but on an individual basis alone. That is what I mean by an acknowledgement that a thing might be lots of smaller things as well—just like the Draft folder usually becomes a thing, a document. The child override capability allows for a lot of variation and exceptional outlining behaviour—but it does not entirely address when local areas of the outline are detailed and quite different than the outline around them.

It would also mean not having to put up with the “no defaults below this point” problem that comes with using the child override. Right now you can tell a folder called “Appendix” to force its subdocuments to use the Appendix section type—but what if appendices are as complex as chapters, in need of sections, subsections and so forth? There is no way to say at any level to stop using the override and go back to structural (global) defaults for this and all child items.

But if you had an alternate structure called “Appendix” that looked pretty much just like a “Chapter” save for a different parent type that uses “A”, “B”, “C” style denomination in the compiler, then you aren’t even working with the child override setting anyway. That tool definitely would still have its uses in this system, mainly those uses it is already good for already. If all you want to do is make a folder where the child items are “Glossary Entries”, then that’s all you have to use, no need to head off to Project Settings and build a new structure for this one two-level thing.

A few rough ideas:

  • The Section Types tab allows types to be indented beneath others. This automatically implies a structural unit for the parent. Chapter: Scene, or Chapter: Section: Subsection… whatever the case may be. These are still individual Types, they can be selected independently wherever one is allowed to do so, and they would remain in a flat listing in menus. But what this kind of nesting would do is imply a default structure by level without any help from the other tab.

So what does the other tab do? Well that is where you could set Folder 1+ to “Chapter”, and by simple act of doing so, imply all of the sub-level structure beneath it without having to do so yourself. If you added a new row to make a Folder 2+, then it would by default be “Scene”, in the UI, but you could override it. Thus a “Chapter” could have a predetermined structure unless project settings override it.

The main weakness with this idea is that it muddies the water between the two tabs. Hierarchical type settings should really all be done in the second tab, and having part of it done by implication in a tab that doesn’t distinguish by level or icon type could lead to cases where it feels like you are wrestling with an octopus to get it all working the way you want.

  • And so with that weakness in mind, another idea is a dropdown at the top of the Default Types by Structure tab that just has “Project Defaults” listed, and no entries other than a “Create new structure…” command. Use that, and the table would revert to defaults (just three Root level entries). This alternate structure would not override project defaults, nor would it ever be applied to anything automatically (save through Document Templates naturally). But it would be a thing you could pick from in the Section Types selection menu—probably as a submenu that replaces the “Structure-Based” entry (only in projects that even have alternate structure types), moving “Structure-Based” into it, and providing any other alternate structures in a list.

Then in usage you could select “Chapter” from the list of schemas and its local hierarchy would adopt the alternate structure rather than using the global binder structure, from that parent down. Every file, folder, group and level would be evaluated based on the selected alternate structure.

The nice thing about this approach is that it follows the principle of keeping these flexible and more complicated mechanisms out of sight until you use them. Most people would just see “Structure-Based” followed by a list of Types in their “Section Types” pulldown. Those that create schemas would have a more complex menu.

  • The third idea is more of a UI alternative to the second idea. The principal remains the same, but instead of having a dropdown that lets you flip between structures, they would all be listed in one table with dividers between them, where the structure could be named and each tree remained independent of each other—but visually all in the same alignment, so you can more easily see how they match up at different levels.

I think I like the second idea a little better. It leaves the current UI roughly the way it is—and all of the buttons along the bottom do not need to be changed outside of impacting the current structure. You could export your “Chapter” definition with the button, import it into another alternate structure and modify it, etc.

Overall, what I like about this kind of approach is that it has creative potential beyond what an offset would. A tool that just changed the evaluation of part of the tree’s level number would do what you’re asking for precisely, but would that be terribly useful for other things? Alternate schemas on the other hand would make a few areas of my projects a bit less unwieldy to work within, and conceptually make good sense to me for all of the reasons Types make good sense. It’s not really changing anything about what they are, just acknowledging that often a type might be more than one thing and that being able to tell any part of an outline to act like that whole thing is as useful as saying this one file at the top should be a “Table of Contents”.

Fascinating ideas for version 6, Ioa! :slight_smile:

Proudly serving the distant future since 2006! :smiling_imp: