Creating a Compile Tutorial. What would you like to know?


I am creating a compile tutorial that’s specifically based on Scrivener for Windows. What sort of thing are ScrivWin users struggling with, and how basic would you like me to go? I believe I will definitely need to cover having different level types in Scrivener, but do I also need to cover the differences between the file types: files, folder, and file group?

Any input is welcome on what you would like in an easy to understand compile tutorial, especially those who are struggling to use compile.

Thanks in advance,


Great idea Stacey.

Things from my perspective that I’d have welcomed a bit extra support on include:

  • the many different ways to choose which items are included in the compile, from picking the documents, to including synopsis etc.
  • How to change the formatting of the compile by levels - including how to turn off things like titles for folders in the default settings.
  • using placeholders (eg <$w> etc) and other things to leave as many decisions on how things are formatted to as late as possible in the process.

How to format vertically. I am at my wit’s end trying to get the title and a quote on its own page to load in the middle of the page. When I use the e-Book compilation or a custom one, they always load at the top of the page. At least I don’t have the page break issue the other fellow was having :neutral_face:

Formatting vertically has always been a pain in HTML. It was never designed to have a concept of height in the layout flow, only width, with vertical usage being determined by the stacking of data relative to each component’s height. It is trivial to get something in the horizontal middle, but not the vertical middle—especially if you wish to be a “good citizen” and avoid using tables for anything other than tabular data. In e-readers, which often have even fewer CSS and HTML tools allowed, the problem can be even more difficult, especially since many suffer from a distinct lack of good table support, so even that old fallback is unreliable.

You can play around with padding in the Formatting pane, but that’s not something you should use to try and find a “middle”. Eight lines may be the middle on a Kindle Gen. 2, but not an iPhone.

There will always be questions as each of us approaches things differently with varying results.
As we see here and in many endeavors of life these results are not always the most desirable.
Once one gets to the the compile stage all past decisions add up to a series of functions that either mesh or go awry.

I would go as basic as you feel will help the most folks while circumventing as many questions as possible.

Good luck

Jim Curts

I’m struggling with fonts. I customized the editor to show the text how I like it but no matter what preset or custom link I use for compiling, the final version uses the same fonts as what displays in the editor.

I’m flummoxed because my understanding is that this should be happening–that the compile process should override whatever is set in the document.

Kelly, have you contacted us for support yet? We could probably help you figure out this problem, but I’d rather not clutter up this thread with that.

I’m pretty flummoxed by the vast array of compile options full stop.
The tutorial sort of works but I don’t understand why it works. So I’d appreciate a slower tutorial. So more ‘if oyu click this, then press compile, this will happen’ type of thing. Also I’d like to know how to compile to multiple linked html documents rather than just the one big document.

We’re working on a set of tutorials that focus more tightly on certain topics; compilation will definitely be the topic of a few of them. We do have some video tutorials for the Mac on the topic, you might wish to check them out for basic theory.

I think a lot of people struggle with the basics. Levels, for instance, flummox more people than anything, especially since some compile presets seem to exclude a “level 2” in the formatting presets (see the E-book compile settings).

Also, the difference between a file (often referred to on the forums as a document/sub-document*) and a folder is confusing for new users. When they get to the compile stage, that confusion begins to compound as they try to understand how compiling a folder is different than compiling a file in a folder, or a file outside of any folders, or if the Draft folder counts as a “level 1” folder, or what happens to the levels if you chose a folder within your Draft as a compile target…

  • Shouldn’t there be a single name used throughout all of Scrivenerdom for a not-a-folder? The interface for converting a folder refers to a “file”, but many tutorial sources call them “documents” and “sub-documents”. That’s just confusing until you realize that there are folders and not-folders, and the only real difference is how the cork board view, scrivenings mode, and compile settings treat folders vs. files/documents.

Especially when you add in grouped files as well…

One thing I don’t as much like about the file designation is that while it is kind of true, I think it leads people to be less generous in making them than they might otherwise be. Making a file is small chore on your computer. You only do it when you need to and you tend to keep lots of related data together within a single file. These are concepts that are obsolete in Scrivener. It is easy to make them, and thus easy to group smaller bits of data together into clusters that would others be saved as a “file” on the computer using some kind of internal textual structure (like headings). So I think in a way calling them “files” and “documents” leads to the wrong impression, but most people seem to get eventually. I just wonder how much of the initial learning hump is over the filesystem related terminology. The only problem is, there isn’t a really good non-technical term, item is the best I’ve been able to think of; certainly preferable to being all out geeky and calling them data nodes or something. Even to a degree, calling things folders is misleading. It would be a good word if it didn’t have the filesystem connotation it has. But, these things are easily recognisable; most people know what they are, so I use them.

I try to stay away from calling generic things “subdocuments”, I’m not aware of anything in the manuals anyway that uses “subdocuments” to refer to non-folders exclusively. When I do use that term, I use it to mean both files and folders, whose only distinction is that they fall beneath another item in the hierarchy; as a synonym for descendants. I prefer child/descendant terminology, but that is distinctly outliner jargon that a lot of people are unfamiliar with.

Anyway, the terms that exist now are an attempt at natural language, so that a chapter on terminology is not required. But maybe such a chapter would be helpful despite.

The sub-document term I’ve heard in a video tutorial, I’m almost certain. It could have been a pre-2.0 tutorial, but I do remember the term being used.

But the problem of finding good, descriptive natural-language terms for various UI elements in Scrivener is a thorny problem; it’s breadth of features necessarily shrinks the pool of available terms. Consistency is still needed however; On windows, I see the term “text”, and “file” without looking too far. Project->New Text is the first, and Documents->Convert->Convert to File is the other. Then there’s “text document” in the interactive tutorial (Step 1: Beginnings).

To your point that finding a name for the documents/files/texts is tricky, I absolutely see that, and do not envy anyone trying to make each term illustrative, unique and consistent, but I hope it’s clear that these various terms for the same object are going to be difficult for some. A tutorial that goes over the various ways these things are referenced could possibly help those people. Making the terms more consistent across all UI and documentation elements would go a long way to reducing the terms to be confused over.

I wish there was a good word for the file/text/document (vs. the folder), but the only thing I’ve been able to get my brain to divulge is “snippet”, which implies that it has to be small. Obviously an unbiased term would be better, but I think once people “get” Scrivener, the term you use for those text chunks/snippets/sections/scenes/items/thingies is mostly irrelevant.

Yeah, exactly, opposite problem of file. And you have to avoid Draft-biased terminology too, like “section”, because it 9 times out of 10 won’t be a “section” of any sort in the Research folder.

Well there is one term, but it’s doesn’t roll off of the fingers and isn’t used much, “scrivenings”; mostly within the context of the draft though.

Anyway, a big terminology clean-up in the user manual is something I have on my “Misc. Daydreams” list, and it has been there for about a year, not because I don’t want to do it, but because I’ve only barely had time to keep the user manual up to date with the software evolution on both platforms. Fortunately I have more time these days, so making time to pontificate, let alone execute, a consistency sweep is back on the list.

That’s a problem on the Mac as well.

I’d like some help on how to make it show chapter headings at the beg of each chapter. That always gave me grief.