Thank you. Does Scratchpad produce subfolders? If so are the dot files, meaning doe their names begin with a “.” char? Same questions for Sync-ed folders? These are Mac Finder and mac File System specific questions as document/folder names in the Mac file system that begin with a “.” char are rendered invisible to the user *unless the user toggles the command+shift+period key combination). Perhaps there is another way to hide helper files that I am unaware of. Perhaps Scrivener keeps some sort of record of Sync and Scratchpad designation in a system library file? Anyway I am off to try your suggestion.
All of this is to find a way around the fact that scivener doesn’t offer a means of designating pan-project storage of user created documens (outside of the Skratchpad). And the fact that skratchpad isn’t really set up as a text or content editor in the way that the Scrivener editor is. There isn’t even a way to do a simple string search within Scratchpad!
The ideal solution would be a pan-project area in the binder, in the same way that Scrivener expects (but doesn’t exacly make explicit), the difference between “Draft” (or “Manuscript”) designation and, well, everything else. Imagine a more visually obvious distinction of regions within the binder, one being “Projects” within which would be all of the documents (folders and files) of a given project (hell, there could be several open projects in this region), and then another top level “Desk” (or “Author”) region that would be a pan-project place where an author would place notes and docs and anything that they want present no matter what project they are currently working on. Be best yet if what is currently designated “the binder” would be a two column affair, the first would provide a means of navigating all of the Author’s (current) projects (on top), and below that, the pan-project area, where the author would store any and all info they would like to refer to regardless of the project(s) currently being edited. The next column would be a redesign of the current binder functionality mostly similar to the current binder, but with a clear visual demarcation between what the “compile” functions consider publishable, and the rest (what is refered to as “research”). Also, this project binder column would make clear that front and back matter are in fact a part of the publishable “Draft”, and not a part of the non-publishable matterial (“research”). This distinction should be visual and behavior and should not depend on the Author’s knowlege of the boiler-room workings of Scrivener’s code. All documents everywhere should make use of the same editing and layout and typographic and search and collections and notes and metadata tools Scrivener offers to the “main editor”.
One of the behaviors that makes Scrivener’s Scratchpad interesting (the floating pallet window behavior, and the fact that this floating window follows the user from monitor to monitor and virtual desktop to virtual desktop) has nothing at all to do with a scratchpad and should be generalized as an option to any editor space (as per user selectable settings). If such an option also came with its own binder browser column, any document or document container (folder) could be displayed in the way that Scrivener’s Scratchpad is displayed (with Notes, as files within a folder listed to the left, or top).
Additionally, if Scrivener offered a means of making Aliases of any object, of any binder container (file or folder), and to assign aliased objects to any location in an author’s work space (to a specific project, to a library (series) of projects, or to a pan-project container, etc, a whole new world of posibilities would open up.
Implimenting some rendition of these suggestions would go a long way to make for a more powerful writing environment, and importantly, to eleminate or alievieate many of the most common complaints of Scrivener’s ambiguity and steep learning curve. Specifically, Scrivner users can not help but be confused by the fact that there is no clear way of predicting many of the distinctions between binder objects types (front matter, back matter, manuscript, research, etc.) upon which Scriven’s functionality is programmed. If there is object typing going on, and there clearly is, that typing needs to be clearly represented in the binder, and the binder’s behavior.
If such changes were to be made to the presentation of and designation of user created objects (mulitiple project display, pan-project content, pan-project pointers and inclusion (aliases), etc.), the typing of objects must be made more clear and must be reflected both visually and behaviorally) in the Binder (navigation and browsing) column(s). An important but oftern overlooked rule of software design is that any object typing that is coded into the data model must be made explicitly obvious to the user. If you watch as many Scrivener how-to vids as I have (inclusive of the onces Litterature & Latte have and published produced), you will notice how often the instructors attempt to warn users of the hidden but critical distinctions between binder object and container types.
