I’d like to simplify my backups. Scrivener has a very convenient project folder. Are there any rules for using it?
I’d like to add a directory called “Scapple” for Scapple files and OPMLs from Scapple.
I’d like to add a directory called “User” to store core images and essential project files unique to the project.
This would allow me to backup the project directory with these essential bits. Is this reasonable?
Will it break anything? Can we agree on this going forward?
Sigurd
I enjoy Scapple and I am trying to add it to my workflow. I call it as an external editor for most of my projects and I’d like updates to be immediately available to Scrivener. Even if partners don’t use Scrivener they may need organizational charts etc… I’d like these backed up with the project but also available to include as a jpg in an email.
My projects include a small amount of business data - adverts, logos, organization that is project specific. The backup is much more useful if that data is included. When I build a new project, I’m pretty sure business cards images or boilerplate data will be needed at some stage. Its a good bet to simply unzip a “User” directory at creation even if I don’t immediately link it into the project. I don’t want to touch the program files.
Keith has said he likes the idea of user defined template directories. I see this as the project creating a controlled space for user customization. Presumably “Scapple” and “User” are bog simple enough that they’re unlikely to be created by accident. However, I am trying to anticipate any problems by asking.
S
You’ll find some information on how the project folder is structured in the appendix G of the user manual, starting on page 352. In the third paragraph on that page:
So a proposed directory structure could look something like this:
Main Project
Main Project.scriv
[shortcut] Main Project.scrivx
Scapple Files
Such and so forth.scap
User
image.jpg
Note that instead of drilling into the actual project folder to open it from the .scrivx, you can do so from outside of the folder with the shortcut, which in effect gives you the same sort of “master folder” feel you’re looking for, without risking anything.
Have you tried putting the Scapple files in the binder itself? You can click a button to open them out of the binder and into Scapple, and when you close and save the updates will be made directly into the project.
Which will happen if you store the stuff in the binder.
I don’t know what that is referring to specifically, but I think it might be in reference to something else entirely. What will be coming of that concept isn’t some sort of file system apparatus around the project folder, but a centralised extension to the document template concept. For example, in addition to putting a starter .scap file in your templates folder in one project, you could put it in a file system folder and make it available to all projects simultaneously.
I think it would be somewhat at odds to have a managed file system around the project when the project itself is meant to act in that capacity.
I include the scapple files as external references stored in the “Scapple” directory of each project. Are you saying I can keep and store the Scapple files in the Binder as part of the Scrivener project? Does Scapple play nice with the Scrivener binder for updated saves etc?
Shortcuts don’t have any data. I’m trying to simplify backup and maintenance. Data may also be imported into the binder, depending on the project, but not necessarily.
So you recommend a container directory for each Scrivener project?
Is it not reasonable to have purposeful sub-directories for simplicity? Even if those directory names are expected and shared with developers?
So.
.\Project001
.\Project001\project001.scriv
.\Project001\scapple
.\Project001\user
Ok.
May I offer a couple of pieces of data that you might not know that may affect your enthusiasm for this proposal?
Now, I’m not Keith, and I don’t work for L&L so feel free to take my conclusion with a grain of salt – but I don’t see L&L encouraging the inclusion of data into the file format that all users can’t get at freely; that’s not, in fact, reasonable. Mac users can’t get at the sub-directories you’re proposing without a spot of bother; iOS users can’t get to it at all. This kind of tinkering only benefits Windows users and it means a lot of extra work has to happen code-wise to benefit only the Windows folks.
I really think the best way to think about a Scrivener project is “this is a single file that happens to look like a folder with child items, but it’s not, it’s a single black box and I don’t mess with it” and come up with any backup or maintenance strategies from there.
Thank you. That makes a lot of sense. I don’t know about Macs - that’s why I was asking.
I can understand maintaining cross compatibility. I’d suggest that be added to the manual.
I’ll put a directory around the project directory.
Exactly my thought. On the Mac and iOS it is a black box.
FWIW, there have been very few cases where I’ve had to help a user whose project was mangled beyond repair. Almost all of those cases involved poking around inside the .scriv folder, either by an overly exuberant user or a misguided software tool. It’s really, really not recommended.
Katherine
Exactly, the project format is designed to be a sort of managed file and folder structure where you can put any kind of file into the project and they will be fully hosted there. You’ll click on a .scap in the binder and then the link in the editor (or just hit Ctrl-F5) to load it out of the project and into Scapple seamlessly (same goes for anything else; spreadsheets, presentations). You work on it, save it (or it autosaves as you work), and it’s just like working with a .scap anywhere else. The difference is you get all of Scrivener’s management layer embedded into the working files of your project. Instead of having a loose collection of files that you have to externally refer to from within the project—presumably through references etc.—they are right there in the mix, sharing the same keywords and labels as your scenes, coming up in project searches, having their own synopsis, notes, and references, being able to organise them into corkboards, all that stuff.
There is a downside to that, in that since Scrivener is managing the resources internally it renames the files on the disk and thus when you load them into external editors you see a kind of generic numbering in the title bar instead of the name you’ve given it in the binder. You can still export these files once you need them exposed to the rest of the system, and in doing so they’ll take on their binder names as files—so it’s only while they are in the project that they act that way.
And yup, devinganger points out exactly why there are no plans to put managed user folders inside the “xxxx.scriv” folder. All of that ends up acting like a self-contained file on the other platforms. That is also mentioned in the appendix I referred to, but since its main purpose is to document the subfolders and files, it only briefly mentions that on a Mac all of this is hidden.
So if the above option of hosting the files in the binder doesn’t appeal, a parallel folder structure is best. Do note you can mix the approaches a bit: make shortcuts of the files and drop the shortcuts into the binder. Now you get all of the benefits of your .scap file being a binder item, but when you load it out of the binder it loads to original resource from your folder structure, name intact. The burden of backing them up is back on you, since Scrivener will obviously only backup the shortcuts, though.