Thanks!
I realise this topic is ancient, but since ScrivWin3 is so new, I thought perhaps a couple of real world use-cases might be of interest.
I use two main approaches. One is for collecting and organising fragments, drafts, notes, etc., in one huge hierarchical structure. This is never compiled, and is frequently rearranged. When stories, articles, essays, etc., reach some “readable” stage, they are color-coded and marked for “removal.” Anything that’s removed is left in its last incarnation, and then worked on elsewhere (another Scriv, a SmartEditWriter doc, a Google Doc, or – if it’s close to finished – InDesign).
The other main approach is a single topic – story, article, essay, book, etc. These would be compiled if I could get the Compiler to work in a predictable manner. I have an extensive computer background, but to this day I’ve never been able to explain why the Compiler does what it does. (E.g., some paragraphs get the Compiler override (e.g., indenting an excerpt) while other paragraphs in the same tree item do not, but I can’t find out why.) There are so many possible strategies for compiling that I have spent an inordinate amount of time trying to determine empirically what approach fulfills my needs.
As I currently see it, there are two likely structures for Compiler-prioritised manuscripts: highly structured and locally formatted. In the first structure, I follow the idea that each object in the tree is formatted separately – a chapter title, a heading, a sub-heading, an indented quote, a numbered list, etc. This produces a project tree that has many items within a chapter, and a lengthy block assignment list with many bespoke formats. It reminds me of Lotus Manuscript, a brilliant “text block” oriented document manager from the 1990’s. It was based on a a very simple hierarchy, but surprisingly covered a broad range of document layouts and appearances. Unfortunately, I have yet to fathom the behavior of Scrivener using this approach, because there appear to be bits of hidden metadata assigned to paragraphs that affect the compiled appearance but are not accessible. If a para has been pasted from one tree item to another, this may drastically affect how it displays in the editor, or how it compiles, yet the para exposes no properties to account for this.
The second structure is to use internal local style formatting within a Chapter, including everything except the chapter title. This is similar to designing a document in InDesign or Word, although style sheets are handled somewhat differently in Scrivener. It seems to work well enough, except for anomalies mentioned above, and it greatly simplifies the Compiler UX. Unfortunately, this approach eliminates some of the unique capabilities of the Compiler, and doesn’t take into account many of Scrivener’s powerful content-management features.
I hope this report is of some use. I’m returning to Scrivener Win3 after having given up for a couple of years waiting for it. I continued to use Scrivener for the massive “collection” use-case mentioned above, but could never make it meet my requirements for compiled output. The templates provided are far too complex for my needs, but the underlying mechanisms remained too arcane to justify the amount of empirical research required to gain full control. I’m sliding back to that experience now, despite the MANY wonderful improvements that have me excited about Scrivener all over again.
Allen / a@acobb.com
2 Likes
Thank you for your interesting post. I am in pretty much in the same situation. Scrivener Win3 and a technical writer. Although my documents are highly structured, I find myself right in the middle of the two strategies you mentioned. Putting all the structure information into a fine grained arrangement of snippets (sections), each with its own section type, makes the project very complex and places all the bets on the compiler – which is hard to figure out and allegedly unreliable . On the other hand, using RTF formatting tools and disabling the option “Override text and notes formatting” is easier at first, but feels kind of against the Scrivener philosophy of separation of content and formatting. Although I have not explored all the options yet, I see myself ending up with producing Markdown and then post-processing my documents. That is also what the authors of the Scrivener Manual apparently have done.
I am somewhat disappointed that the Scrivener Manual could apparently not have been produced using Scrivener tools alone.
Please don’t get me wrong. I think that Scrivener as a product is a brilliant idea and really fills a gap in the market. After my first steps with Scrivener, I come to believe that it is much more suited for relatively unstructured text documents like novels, essays, etc… And it is brilliant as an outlining tool. Technical writing with lots of diagrams, complex formatting, sophisticated table of contents and index, seem not to be Scrivener’s strengths though.
I would really be interested to see the way, the Scrivener Manual was produced, i.e. which conventions used, which paragraph and section styles, and how the post-processing was done. Perhaps the developer team could publish this as kind of example at the end of the tutorial or in a chapter of the manual. That would certainly help writers like me getting a better grip at authoring complex documents with Scrivener.
2 Likes
Why not simply download it? All the info you need is found on the page “User Manuals”
https://www.literatureandlatte.com/learn-and-support/user-guides
1 Like
Ah, it’s in the Extras Pack! Thanks for this valuable hint.
Lots of good youtube vids about how users structure projects, and what their fav bits of scriv.
Ok, I hope I haven’t already replied to the old post like ages ago or anything… but I did go to the forums with a thought/question and this might be a good place to explain why I have it.
The way I structure my Scrivener projects is by series rather than by books - I have a “wiki” folder in which I keep the character sheets, world/place descriptions, and even sections on technology and factions, and I have my Draft folder set up with subfolders marked to look like differently-colored books for each of, well, the books in the series.
The only issue I’ve been having with this is that, every time I compile a book, I have to remember to go in and change all the compiling metadata or all of my compiled books have the same name. I don’t know if there is a way, in Scrivener, to designate a “compile section” and have it use different metadata for each one, so that I don’t have to go change the book name and information each time I compile a different folder.
I am frankly impressed and pleased with Scrivener’s ability to have me keep multiple volumes of a series in the same project along with all the research. But it may be possible to make the compilation part of the process just a little easier for multi-book projects.
2 Likes
Would a little utility program be any good if it could change all your metadata settings. When the program would start up it would let you choose the book for which you want to compile. Then it would do all the metadata changes you had configured for this book in a configuration dialog. I think, such a little utility program should not be too hard to write. And if Scrivener will one day offer an interface to extensions or plug ins, it could even be started from within Scrivener. Just as thought…
And if Scrivener will one day offer an interface to extensions or plug ins, it could even be started from within Scrivener.
AutoHotKey would be useful here. And it wouldn’t a require direct interface between Scriv and AHK.
Having AHK “send” the appropriate key sequences to Scrivener to open the appropriate dialogs, then navigate to and set the various setting controls, should be able to accomplish it.
1 Like
Organization varies by project, for me.
Each of my novel series get one main mega-project file apiece, on my desktop - each mega-file is then divided up by the number of books in that series, and each book is divided up by whatever is appropriate for that book - some get plain chapters, some get bigger sections with chapters inside.
The easiest thing of all would be if Compile simply labeled the sections and subsections and files and whatnot the way I have them named in the project. So like if a project goes:
Series
Book 1
Day 1
Chapter 1
Chapter 2
etc
I would like Compile to show me THOSE names rather than “Section” and “File” and whatnot
I would like the option to select only one book at a time, and then adjust the formatting within that book (without applying that formatting to every other book, which might not need it).
Folders are purely an organization thing for me, like a tab in a physical binder. Sometimes I want that tab/folder to compile as a page in its own right - like a paper book would have a page saying “Day 1” with nothing else - and sometimes I want it to kind of “disappear” (everything within it will still compile, but there will be no acknowledgement of the “behind the scenes” organizational break).
1 Like
“How do you scrivener?”
I write fiction, so that colors my entire reply.
I started a new thing with my current project: at the same level as “Characters” and “Draft folder”, I made a folder called “Journal”. Inside it’s grouped first by year, then by month. There are only entries there for the days I open my project. Instead of editing what was in a previous day’s journal, I can copy forward to today’s journal entry and continue working, while still preserving my thought processes.
It’s a variant of rubber-ducking that keeps me from “muddying” the storyline by talking to hubby (again and again and again…). As I mentioned in another recent post, I bring over from my universe bible the bits and pieces I need for this book.
When it comes to formatting, since I don’t intend to compile my journal entries, I’ve chosen to format them more than my fiction text. I haven’t spent any time yet deleting styles I don’t use. I name my styles with an “A.” prefix, so I know that’s one of mine. (I’ve “deleted” styles by “redefining style” and renaming it at the same time.)
The last thing I do that might be different than others is meant to keep me from losing track of what’s “keep” and what’s not. I found/edited some icons to represent this. A red X is no longer in use (and/or no longer “canon” for this book). A red exclamation means “incomplete canon” and a green exclamation means “complete canon”. When I have a document that is no longer in use but NOT actual fiction writing, there’s a folder inside my Research folder called “Not in use”, with a red X icon. This folder holds previous iterations of my plot, characters, whatever. It’s there, if I need it, but it’s not mucking up my thought processes.
1 Like
Great question, and I’m happy to reply although I feel like something of a noob when it comes to Scrivener. But I love the program, and I’m committed to adapting my own processes to deal with its weaknesses and quirks.
I write my body text (in the Editor) in Courier New, and let Compile handle all the formatting details of the text. That works just fine, except for front matter, which is almost entirely compiled to format “as-is,” because I need the added flexibility. (Even if the compiler could give me what I need for different front matter pages, I just find it much faster to format those to suit and compile those pages as-is.) I found that the compiler does not give me as much control over the header text for end matter, so I’ve moved most of the end matter into the manuscript body to have the desired control.
My writing uses footnotes, many of them. Sometimes endnotes too, along with footnotes. Unfortunately compiling to PDF fails completely: the footnotes will overlap the body text. To be fair, I may have half a dozen or more footnotes per page, but it should handle that. So, I am forced to compile to DOCX and then “print” to PDF. That works for the footnotes. However, the endnotes end up at the end of the Word document because DOCX compilations don’t allow the use of <$ENDNOTES> to position them where I would like. (That is, I think due to Word’s limitations.) So, right now I grumble but live with it. (There is another option in Word to reposition those endnotes at the end of a section, but that is the wrong place, given how I organize my writing.) And with EPUB3 compiles, the endnotes and footnotes get merged, argh. I’m not sure whether that is an EPUB limitation or a Scrivener limitation, but the best workaround I could think of was to put [ref] with another footnote reference in the text for ebooks, so the reader would know that when clicking on THAT footnote, they’re really getting an endnote. Unfortunately, that means that my body manuscripts for ebooks and trade books must differ, and that’s very unfortunate.