Folders vs. Document Stacks, etc.

I decided to go back to the manual and make sure I was understanding the full significance of files, folders, etc. but it didn’t really help me. Perhaps the answer to these questions will make everything clear to me.

  1. The manual says that when converting a folder to a file … “the only thing that changed is the underlying type of the item, which is really primarily a visual change.”

So a document stack is exactly like a folder, except that it looks different in the binder? Is a document stack any different from a folder with text associated with it?

  1. I understand the binder when I think of it as being like file explorer. That is, folders with files in them. But the manual suggests that I’m limiting myself if I see I that way.

So here’s the question: why would someone want to have a folder with text associated with it rather than just a folder with text documents in it?

They are functionally equivalent, albeit with a different icon in the binder.
The advantage of having two functionally equivalent types is that you can distinguish between them in your Compile settings.

Because you can assign different Compile settings to it then.

I’m not sure which section you are referring to from the manual, where it says that is the only difference (maybe the Quick Tour, where things are necessarily brief?). At any rate, There are altogether three differences, though only two are really worth mentioning since one is “they look different”: :slight_smile:

  1. By default, stacked files don’t act like groups when you click on them, they act like text files. You have to load Corkboard or Scrivenings by hand after clicking on them. Folders on the other hand always act like groups when you click on them. So that distinction right there can be useful in that you can choose what happens when you click on a section. This difference can be removed in the Navigation options, causing stacks to act like folders and always use the current group view mode.
  2. The visual difference. It’s minor and obvious, but having something different around like a folder icon helps one to break up long outlines and draw the eye to key parent nodes. True, we’ve got custom icons now, but if all you need is the basics, folders are easier to use than custom icons. We can also use the difference as a form of internal semantics. I might reserve folders for major structural components of the book, for instance—what will be visible to the reader in the form of headings, page breaks and other conventions.
  3. When compiling you can treat file stacks and folders differently, when it comes to Formatting, and stacks are treated a bit more “invisibly” in terms of how the outline can be turned into book structure. They don’t have entries in the Separators pane, so often they can be used as “silent” grouping mechanisms in the draft—when you want to associate a few sections together without actually turning them into a formal group with a folder, that would in turn cause them to be a chapter (assuming that is what you are doing with folders). So at this level, it’s all about giving you a little extra flexibility, and that is what makes Scrivener a general purpose tool. We do not have a “chapter” object in the software, instead we define what a chapter is with the outline and its relationship to the compiler. Having stacks as well as folders around means we can have two different “types” of constructive objects going on at the same indent level.

Only in the sense of point #1 above: when you click on a stack you’ll go straight to that text, with a folder you’ll need to turn off a group view first (unless you’ve already done that for another folder).

At risk of seeming glib, I’d say the answer to that question is why would you want any component of the outline to be something you can’t write into? What purpose would it serve to have a type of outline node that merely doesn’t have as many features available to it as the rest? This gets into the concept of the program—that of being a pure multi-pane outliner rather than an embedded outline such as in most word processors, or, as you put, something more like a database or file manager.

Like I say, I don’t mean to just invert your question, mine is a serious one as well, it’s the question behind much of the design premise of Scrivener: shouldn’t text be capable of “ownership” of other pieces of text, and to be owned likewise. What “ownership” means is entirely arbitrary and will not likely be the same for every writer, or even every book, but fundamentally and beneath any implementation, it means that the text we write can also act as its own structural skeleton.

That’s the grand theory—but what does it mean practically? A few common examples:

  • That’s where you put your chapter title. For those that don’t really care to use the Compiler in-depth (they just select Original and choose a file type then click “Compile”), it’s a convenient place to put the chapter title if you’re using the folder for a chapter break anyway. That way you don’t have a chapter title in the first scene, which must be cut and pasted whenever you rearrange scenes.
  • Section notes. In most of our presets and templates, folders do not actually export their text, meaning that any folder is a safe place to stash notes—and it’s also a very convenient place to do so, since folders insert themselves into a Scrivenings stream. You get your section notes at the very top—scroll up whenever you want to reference them, then return to where you were writing.
  • And as talked of above: where folders are perhaps used more reactively, after the fact, than up front, as a mechanism (i.e. I am making a chapter folder now vs. all right I’ve made the outline, now let’s convert the important stuff to folders).

Of course, I’m just providing a few examples off of the top of my head. The point of the matter is that Scrivener’s Draft is a full outline, where everything in that outline is a “node” that is capable of storing two different text documents (Main Text and Document Notes, three if you count the Synopsis) a Title and some meta-data. Thus, calling things strictly folders or files is a bit limiting, especially since you can at will just convert them back and forth with a simple right-click.

I’d say that in the end, whether all of that seems useful to you is all that really matters. I believe I basically do state the same thing in the manual: that we’re just giving you as much flexibility as possible, and part of that flexibility is the choice to only use as much of it as you (or the subject) requires.

Where I do feel that there is a limit to thinking in terms of “Windows Explorer” with a folder tree and files is when it comes to how useful it can be to express your book with a detailed outline (nothing new to anyone that has gone out of their way to learn outlining in word processors, but Scrivener can take it so much further since its outline can opt to be invisible to the final output). If every section of the book is broken down into the smallest topical entry, then the whole programs opens up to you. Project search becomes more precise, meta-data less vague (a keyword slapped onto an entire chapter is less meaningful than a keyword attached to a single beat, or a subsection pertaining only to the use of different vinegars in cooking). You also have more precision in your navigation and less scrolling through long sections—you get the point.

Thinking in terms of “files” fosters the habits acquired from using a file system and how most software handles opening two different files, where maintaining individual files means a hard separation between the content of those two files (you can open the both at once, but they do not cooperate). This leads to using long stretches of text in each file, because who wants to have 850 DOC files comprising their book, right? That would be a nightmare.

Nothing really earth-shattering there, but this is why the manual proposes the similarities between files and folders in the fashion that it does: it’s presenting a concept that is likely new to most people, that of the indented digital outliner, and trying to show that can be used to construct documents. That we’re not looking at a “list of documents”, in Scrivener, but rather the spine, or the map, of a single document. The more nodes you use, the better the map becomes.

I use the “folder txt” for headings, summary, etc. Then when I’m doing a scrivening mode I don’t need to see it. Yes I could just put it in a doc at the top, but then I’d need to remember to not include that doc. It also makes it easy to see the summary of all my folders.

But that’s just my preference.

Blah blah.

They’re functionally equivalent, but look different. So you can treat 'me differently when you compile.

You professional types don’t 'alf put a premium on being thorough and helpful.

I’m using it differently. I’m in the process of recreating in Scrivener one of a friend’s books on Indian cookery, as the publisher won’t reprint, lots of people want to get hold of it, and the copyright has been returned absolutely to the author — except for many of the photos, which for various reasons are actually irrelevant! So the plan is to produce e-versions for Kindle, iBooks etc.

Each chapter, is preceded by a brief introduction, so I put that in the folder text for that chapter. That way, when I compile it can be in a different font or size or whatever, separate from the recipes themselves. It could of course be a separate document within the folder, but it’s more economical to put it as folder text and include it in the compile.

Mr X

So, if I have a folder with text in it, as opposed to a folder with files in it, it’s like, to extend the analogy, a manila folder with text written on it. Yes?

And a document stack would similar: it would be a stack of documents with a description of that stack written on the top sheet.

Brilliant! By Jove, Martha … I think he’s got it!

Ummm … thanks for that, actually. It finally cleared it up in my head, also … too many years thinking of “folders” as containers and “files” as objects, and we were never able to put a post-it note on the folder, you know … or convert an object to a container … or … me achin’ head!

Yep, a manila folder with text on it, with a number of documents inside the folder … including also, if you want, manila sub-folders with text on them, containing a number of documents.

And document stacks as you say are like a stack of documents with with whatever you want to write on the top sheet.

Hugely flexible.

Mr X

Just thinking out loud here:

I’m understanding that I could do the same thing by having the standard folder and documents inside it, but for the folder, writing something in the Document Notes in the inspector. If that’s the case, then Scrivener is flexible, it’s giving me two ways of doing the same thing.

But by adding the flexibility, it’s also adding complexity, and a need to document the different methods in the manual. That would contribute to a new user saying “This program is too complex and hard to use.”

Let’s say you designed a car with two different starter motors and two ways to start the engine. It’s flexible, but more complex than necessary.

Just something to consider in the future–there are downsides to having two ways to do the same thing.

And on a tangent, in the real world, if you are in an office, and you say to the secretary, “Bring me the Johnson file,” she will most likely bring you a folder. That is, a folder from the filing cabinet containing documents about Mr. Johnson. This is also known as a “file folder.” So, it’s Microsoft’s fault, but the whole naming convention is screwed up.

Of you could ignore the added flexibility and use things in the traditional manner.

Your car example is a largely inapplicable as you are comparing apple to jet planes. All you are really talking about here is the secretary bringing you the Johnson file in either a manila or red folder. The “complexity” is someone would need to understand why a manila or red folder should be used.

You might be over thinking this a bit…