What I don’t understand (based on my lack of knowledge regarding Scrivener’s code):
Usually users seem to have no problem accessing their project’s Binder / index file (“.scrivx”). And then one of two problems occur,
The (Windows-) user just copied the .scrivx file, thinking that’s the actual project and all the other files are just decoration of some sort.
The cloud storage software thinks it wants to sell more expensive storage subscriptions, so it moves the actual files… well, into the cloud. And leaves some empty placeholders on the local drive.
Both cases have one thing in common: Scrivener “knows” which files in a project should be accessible. The second scenario is a bit more insidious, because they appear to be. But aren’t. At that moment.
The .scrivx file stores different data for each document, date created, date modified, selection, etc. It doesn’t seem to store the (expected) size, a checksum or at least just a flag if it should be empty or not.
Why?
This information would allow Scrivener to fail more gracefully. Or… trip over someone else’s fail more gracefully. Like in telling the user there’s something wrong, the two most likely reasons and how to fix the problem.
It doesn’t even have to be that specific. It could just say: “Hey, I know you’re on the way to the forum, telling everyone your magnum opus is somehow gone. Tell them which files are missing / which files are unintentionally empty: …”
(I’m aware that checking “all” documents on launch could be a bit… well, taxing. But maybe when they are about to be loaded into the editor anyways?)
How about a warning when creating a new project? ‘Be sure the folder you create this project in has Cloud Optimisation OFF!!! And BTW, turn off “Optimise Mac Storage!” YOU HAVE BEEN WARNED.’ In whatever more diplomatic form L&L deem appropriate.
Really, it’s a problem of user education, and this point is not driven home in ANY of the the documentation. It’s not driven home in the app for sure. The manual is all about being able to do cloud connection and yes, details how to do so safely, but gives no warning about “optimised storage” by whatever name it’s called. If the cloud service in question will arbitrarily remove “old” files from the local disk, it’s a danger. Period.
The problem is that this is a third party app, not Scrivener. It is up to you - the user - to know what your third party app is doing. Dropbox was the first of the apps to change how and where it stores things and did not tell anyone that it was changing unless you read the update notes every time it changes things (finding those notes can be a real pain). Gotta know your own computer and what is installed and how it runs and know that Apple or Windows will make changes with every update regardless of what you told it to do the last time they changed something and you had to fix it. And they make it so that you are constantly checking for updates (no you can’t tell it not to) and apply them automatically (but you can pause it, maybe) so that you are ready for the next round of updates that break something that breaks a different program. All you really wanted to do was read your email…
Unless L&L really wants to bubble wrap its users (and put on a full racing harness, leathers, and helmet) I don’t think this is a good idea. Problem is, I don’t have any ideas on how to make things better for the users either.
Yeah, that’s true. What’s also true is that this happens so frequently. It just doesn’t look good, no matter the true reason. At the end of the day (and often even at the beginning of the day) users end up knocking not at (insert cloud provider’s name) door, but here.
Perhaps Lit&Lat should consider including in the download package (like so many other apps do) an “Important! Readme First!” file. I don’t imagine may newcomers go to the support advisory before starting to use Scrivener, but if the advice is there in such a Readme, there’s more chance they will actually read it.
The Readme could explain clearly about the package/folder structure of a Scrivener project, that all elements need to be accessible locally on their machine, and the perils of the various cloud services potentially manipulating the data unbeknownst to the user, and to make sure such processes are turned off.
I know there is a possibility that many people don’t bother to read the Readmes, but if they haven’t they have less grounds for complaint.
Yeah, okay, L&L should definitely get their lawyers (solicitors?) on board. But still, the fact that all of a live project’s files need to be local … that’s something that new users just don’t seem to pick up on. And with Apple and Microsoft emphasizing their respective integrated cloud services it’s not a thing that users are accustomed to thinking about – “Just leave it on defaults. It all just works, right?”
Really. Better user education / warnings. Better detection, if possible, of dangerous situations. Because if you have a Mac, you don’t challenge your system defaults (“optimise Mac storage” “Desktop and Documents Folders”), and you stick your projects in the default location (“Documents”) you’re heading for Pain.
You’re right. That’s why I think a really, really good introduction won’t hurt. But. Let’s also deal with the fact that people (or the third party software / OS they trust) will mess around.
User sees an empty document. User panics. User comes online and thinks Scrivener swallowed it (that’s the best case scenario, cause we can fix this together here). So why not let Scrivener be a tad more smart and say: “Don’t panic. It’s not what it looks like. Sit down. Breathe. Let’s try this or that.”
Love it. I deeply agree, but like @Vincent_Vincent above, I have to think that the devs have already considered this and rejected it for whatever reason, most likely (in my own outdated opinion) performance.
