It would be nice if we could change the order of the adaptive naming source list, so the text could be before synopsis.
Use case: having a heading as title in the text (that would be the only place where the title is changed), but also want to have a synopsis.
It could be an on/off button in preferences to change general behavior in the project that says: Adaptive Naming source order: text before synopsis: On/Off
You could use placeholders to have your title and your synopsis printed/compiled anywhere you want them to appear in the text, but then, just like in the previous reply, you’d have to have your title be your document’s name in the binder, and use the dedicated synopsis tab from the inspector.
Anyways, here are the two concerned placeholders :
If you want your synopsis after the body text (or anywhere, for that matter), that second placeholder will definitely work. (Whatever character attributes you apply to the placeholder tag – bold, italics etc, or even a style assignation – will reflect in the compiled output. <$synopsis> will be replaced by your actual document’s synopsis, which’s text will then be formatted to look the way <$synopsis> looked in the editor.)
As for your wish regarding the header’s placement, how could Scrivener know that this is actually what you want for a title (and not the actual real title/document’s title – or both) ?
And where to compile it to ?
Using a header like you are doing, you are limiting yourself in this situation.
Much better to name your documents what you want them to be titled, in the binder.
Or, if that doesn’t suit you, use custom metadata and the proper placeholder. (Although which, on the other hand, doesn’t by any mean fix your alternative placement wish.) → I can’t think of anyway to make it happen without using styles + unnecessarily complicated compile formats. (Not to mention that your title would need to be referenced (directly typed in, or through a placeholder) everywhere you’d potentially want it compiled.)
Any other which way I can think of, you’ll have to manually move it to where you want it to be. (In all documents.)
I definitely understand the idea behind wanting the priority flipped for this particular way of working. I do also agree entirely with the sentiments expressed above: that the reason it does work this way, and doesn’t have an option for flipping it, goes straight to the point of Scrivener’s intended design approach:
Binder titles can be made into functional headings automatically by choosing Section Layouts in the compiler that generate headings. There are few reasons to work otherwise, particularly where we are speaking of one heading per section (and that’s all that would be relevant to this discussion anyway).
The main reason one might not work that way is if they have some preferential reason to not outline as much as the document’s text has a hierarchy to it, and prefer subheads within the text—but like I say, at that point we aren’t talking about drivers for what you see in the binder anyway.
Given the compiler is a better tool for generating heading policies (like automatic numbering, separating elements such as page breaks and so forth) and text, the need to put headings into the text editor like one would have to do in a word processor is greatly diminished.
And to further bolster that workflow, the View â–¸ Text Editing â–¸ Show Titles in Scrivenings setting is perfect for those that use binder titles as functional headings in the output (though it can be useful beyond that as well).
And similarly, the editor header bar is not only a navigation tool, but a place where this heading can be printed at the top of the section, regardless of scroll position. You always know where you are from that, you don’t have to scroll back up to the top if you come back three days later and forget. You can rename a section as its scope changes while writing, without scrolling around like a Word user would have to.
There are likely edge cases, and maybe some I’m not thinking of, but most of the common cases, as well as preferential (like seeing and editing headings in the text editor rather than “in the interface”), are covered by the designed features mentioned above.
From this it might sound like adaptive titles have no purpose, but I am limiting the response to the machinery that drives headings that remain functional in the output (otherwise there is zero need to type them into the editor anyway). For all kinds of outline elements that do not generate headings, adaptive titles are a fantastic tool, and given how they are meant to elevate descriptive text into listing views, work hand in glove with “short form” descriptions provided in synopsis, falling back to the introductory text of the output itself if none is provided.
To return to the beginning, I don’t think this idea is a bad one. I can see good arguments for having a toggle (probably project-specific, like something in the View ▸ Outline submenu) that branch from uses of the software that aren’t going against the grain of its design as described above. But hopefully you can see why it works the way it does, at this point. That specific use you describe isn’t something we ever intended to overly encourage with Scrivener’s design (concessions are made, yes, such as the built-in stylesheet, but concessions shouldn’t be confused with encouragement).
Thanks to everyone for the answers and thanks AmberV, that was an amazing one, I appreciate it.
I am working on a non-fiction project and changing titles quite very often, and it feels more natural, so to say, to change the titles in the text. Also I like to have the title in the text I am working on, it puts me in the mood or so.
Anyway, it is ok now and it’s due to a couple of things AmberV said and some features I didn’t now:
Showing titles in scrivenings did some of the trick, but to be able to edit the titles directly in the Scrivenings is amazing and gives me what I wanted.
Then I changed the font of the editor header bar to a bigger bolder font and that gave me the presence of the title I wanted. Also to be able to edit the title in the editor header bar is chefkiss
So those two things made it for me also now I have the titles where they meant to be, in the binder
Yes! The key to a consistent, organized document appearance is enforcing appropriate policies.
Yes! Scrivenings view can look as if headers were placed in the text, without putting them there.
I think you mean displayed, not printed, but yes! If headers are at the top of the document, they’re only visible when working at the top of the document.