In short: you’d be taking a fairly broadly featured application and intentionally restricting its power down to a sub-set. That might be what you are want, though. A few illustrations:
You’d lose the ability to organise things within other things—the hallmark of an outliner, because all collections are flat lists. But you can use freeform corkboards to provide a little “meta structure” to a collection beyond a-z ordering. To clarify, you can outline from a collection. You can select a file, turn on the Outliner, and start building child structure into it—and then turn around and drag all of those items back into the Collection if you want. So you aren’t wholly shut off from deeper organisation strategies—its just in the primary list you’ll be stuck with a linear list of documents; sub-sub-sections will have the same prominence as the prologue or a chapter. To mitigate this, you could achieve a clustering effect by using multiple collections, say, one for each chapter—but then you are starting to get into what is conceptually and better expressed with a folder in an outliner, really.
You’d be able to create new items while working in this collection (into the collection list itself—not using the above trick of opening up a Corkboard or Outliner for a selected item, that follows ordinary rules and outliner hierarchy); they will be created into a new folder in the binder, named by that collection, so finding them in the future will be easy.
You can organise things in a collection back into the binder. So say you have 10 files from various places in the Binder—but they are all related and listed in the collection. To gather them together into one spot in the Binder, you’d select the ten files and drag them to the Binder tab (you need the tab interface turned on for this trick), hold for a second to allow the tab to activate, then drop them on any folder—they will be gathered to that spot from all of their respective original locations. So that might be a good “end game” for when you are ready to start organising these pieces in the draft folder.
Otherwise, you’ll be giving up a little power by working this way. Many of the tools in Scrivener relate back to the Binder. For example if you have somehow arrived at a file and you have no idea where it is located (following references or links, for instance), there is a handy tool for highlighting the item in the Binder—no such tool for collections. You’ll always have to manually find them in the list.
Another problem in the longer term would be organising things in the draft when you are ready to do so. Working entirely within a collection would probably result in a huge mess of files in no useful order. It depends on how far you adopt Scrivener’s ethos of writing in small chunks, but it is not at all uncommon to see 150 to 500 individual pieces within a mature draft folder. That’s a ton of reorganisation and would be a penalty for using collections this way—not so much enforced by the interface or anything like that—but a practical penalty which would cause you to use fewer files in the long run (or at least, I would certainly be in the back of my mind worried about the prospect of re-organising 500 pieces of my book that are so shuffled up, I might as well have dropped a manuscript printout that didn’t have page numbers printed on it) and so hence I would artificially restrain myself from fully using Scrivener’s philosophy, and using larger files that are less flexible.
You would lose the scoping ability of the Scrivenings tool. One of the things that makes it easy to work in a 500 piece draft is that you can click on a sub-section stack of say, three pieces, and read it as a whole—or click on its parent folder to read the entire section—and on its parent to see the chapter. Working in a hierarchal outline in conjunction with small pieces means you can exercise the ability to focus, or step back to a larger context with a single click. In a flat list of larger files, you’d lose much of that as you’d have to manually locate, parse, and select groups of items in the flat list in order to “see a chapter”—in the Binder that’s a single folder click. In a non-linear collection, it could be 80 files scattered in any old random order amongst many. Hence, a practical limitation: faced with that—one would probably just write the entire chapter in one file, or maybe just two or three files—and suddenly you’ve lost a big chunk of Scrivener’s power.
I have no idea how important any of these are to you, so I’m just listing them out. I’m sure many people don’t have 250 piece draft folders, so that aspect might not be important to them. And the fewer files you have, the less useful scoping becomes and the more important scrolling through long documents and text bookmarks are (more like working in a word processor at that point).
In my summary opinion: I would think the cons outweigh the pros. Collections, as a special purpose feature, work great for what they do, but they were never designed to fully replace the binder—and this will be evident in the program from larger things to even small things, like the way to quickly clear a Project Search by hitting the Esc key. In a normal workflow, that’s a nice little trick to get back to where you were—in this workflow it wouldn’t, it takes you back to the Binder so you’d have to go and open the tabs or use the menus to get back to your collection after every single project search. Lots of little things like that would, for me anyway, be the death by a thousand small cuts for this idea.
But, for a very focussed and specific workflow, it could work. I’d say give it a shot: like most things in Scrivener, its very hard to make a usage choice that will be hard to change your mind on later. If you try it out and you agree there are just too many small cuts, it would be very easy to transition back over to using the Binder as a primary organiser; like I pointed out above, there is a good endgame where you can quickly gather a collection into a single spot and organise it in the Binder. It’s not something I’ve given a lot of thought before, so I’m probably not thinking of some neat tricks that could make this way of working a curious and interesting alternative to a Binder centric way of working; would be interested to hear any ideas.
