Simplify the formatting options.

The only part of Scrivener I seem to have trouble with is the format options in the compile window.
I think the main problem is that the list is flat and it’s trying to represent a hiearchy. I’m not sure that’s intuitive. The plus signs next to the deeper elements don’t really help (though highlighting matching items in the binder helps a lot).

Would it be simpler to do away with that layout and just show a cut-down, heirarchical version of the binder?

You wouldn’t have to show every item, just a representation of each document type that occurs at each level. Then just set the style for each one. If a new level is added to the binder, this should be added the next time the compile window is opened, along with a big pointy thing reminding the user that styles need to be set for it.

I may need to draw this . . .

That’s not really possible, since the compile format doesn’t know anything about your project and is intended to create generic formatting that can be applied to any project. And even if that weren’t the case, presenting some representation of the binder could be even more confusing, because the user might try to set different formatting for two folders at the same level and wonder why changing one has affected the other.

In fact, I have spent a lot of time redesigning Compile for a future version to make it easier for everyone, and to make it less necessary to use the advanced formatting options, being able instead to more easily pick different settings from presets. (This is all on paper with a great deal of coding ahead of me.) Users will be able to tell Scrivener what each document represents (“Chapter”, “Scene”, whatever - these can be anything) and then tell Compile to apply certain formatting based on these types.

However, to save the user from having to set these types for every document, it is still necessary to be able to set default types (which can be overridden by setting them per-document) in a level-based fashion. So no matter, what, there needs to be a way of telling Scrivener, “Folders at this level should be of this format/type”, “Text documents at this level should be of this format/type”, and so on. And so far, I have not been able to think of any better representation of this than the one already used in the Compile panel. (In this new setup it won’t be possible to show an abstracted from of the binder either, because just as the current Compile formats don’t know about any particular binder, in this new setup these default level-based settings can be set up before there’s anything in the binder at all.)

So, no matter what, there has to be some way of telling Scrivener what a certain type+level represents or should look like, in a completely abstract way without any knowledge of a specific binder structure.

I don’t disagree that it can be difficult to get your head around how those levels work, but I have yet to find a better solution, not for want of trying. (The list isn’t entirely flat, by the way: when you add levels, they are indented.)

That’s why I was thinking that the representation should only show one of each document type at each level. So if my binder contains:

[chapter]
    [scene]
    [scene]
    [segue]
    [scene]
    [picture_page]
    [scene]
[chapter]
    [scene]
    [scene]
    [radio_script]

The formatting page would show:

[chapter]
    [scene]
    [segue]
    [picture_page]
    [scene]
    [radio_script]

I think I see what you’re getting at.

My idea would allow the type of each document to be implicitly derived from hierarchy, but in the case above, I would still need to distinguish between the [segue] and the [scene] at the same level. My plan for that was to attach a type to the document (or perhaps attach a different icon to it).

But if that’s the case then I don’t really need a hierarchy in the formatting page at all. I could just do away with levels altogether and just say:

[chapter] --> [new_chapter_style]
[scene] --> [scene_style]
[segue] --> [segue_style]
[picture_page] --> [picture_page_style]
[radio_script] --> [radio_script_style]

And then somewhere else:

[ebook]
         [new_chapter_style]
         [scene_style]
         [segue_style]
         [picture_page_style]
         [radio_script_style] 
[manuscript submission]
         [new_chapter_style]
         [scene_style]
         [segue_style]
         [picture_page_style]
         [radio_script_style]
[createspace]
         [new_chapter_style]
         [scene_style]
         [segue_style]
         [picture_page_style]
         [radio_script_style] 

The binder and the formatting are now completely divorced. I’m free to arrange everything however I want in the binder without having to worry about how the binder layout affects the compilation.

You are already attaching a type to each document, so the definition of a document type from the binder’s perspective is:

[type (chapter or scene or segue etc)]
[next document type]

You put the cursor on the document in the binder and press ‘New’ and Scrivener can now pick the next document type based on the one the cursor is sitting on: if I’m resting on a chapter folder then the next document will be a scene inside it; if I’m resting on a scene then the new document is a scene underneath it. If there are multiple choices then perhaps a list of possible options to select from.
And the binder is still divorced from the compilation.

So how does that solve my confusion with the levels? It gets rid of levels altogether by keeping the binder layout and the compilation layout separate.

Just an idea … :wink:

Funnily enough, the solution at which I have arrived is very similar to what you are suggesting - the ability to assign documents arbitrary types and the complete separation of Compile from project structure, with compile formatting being applied by type.

The main difference is that the project will still have some level-based settings to determine the types that get assigned to documents by default: the default types will be dynamic and determined by level rather than static and determined by the document that was selected when another document is created. This way, for example, you could create folder at level 1 and it would be considered a “Part”, but when you indent it to level 2 it is then considered a “Chapter”. But you could easily override this and set the type explicitly so that it is fixed and doesn’t change depending on structure. In other words, you get the best of both worlds.

Most users will then only need to explicitly set the type for documents that are the exception. In your example, most text documents will automatically be “Scene” documents at that level, as the Project Settings will be set up to tell Scrivener that level 1 folders are of the type “Chapter” and level 2 text documents are of the type “Scene” by default, but for some you would switch them to “Picture Page” or “Segue” or whatever. Users who don’t understand where the default types are coming from (the type settings in the Project Settings - although these will be easily discoverable) and can’t be bothered to take the time to learn can just manually set the types as they want.

I hasten to add that none of this has been coded yet, just planned out and written up in a design document, so it will be many months before any of this makes it into a release version (most likely next year some time).

I think this is definitely the way to go. :smiley:

Ah, that sounds like a very good idea. It should be much easier to set up from the UI too (I’m guessing). So if I have two different document types on the same level:

[chapter]
    [scene]
    [diary_entry]
[chapter]
    [scene]
    [scene]
    [scene]

If I move the [scene] to the left then the document type becomes a chapter. Okay, so the location of the document in the hierarchy will still affect the compilation output, but with the new stylesheet system then it should be much easier to get the output right.

But how would the system pick between a [scene] and a [diary_entry] when I’m creating a document inside [chapter]?

Okay, that answers my previous question. It sounds fair enough since the [segue] elements are few and far between.

Right, I’d better let you get on then :blush: