No, it’s reality. 
Scrivener IS a complicated and very capable software. But it’s up to everyone to decide if they want to use it, and if so if they are prepared to get some ”good habits”.
If the answer is no, don’t use it, or risk losing work. It’s a free choice. 
The sync from the Mac to Dropbox should happen whenever Scrivener autosaves. So the autoclose isn’t necessary, but is a useful bit of extra insurance. If the autoclose isn’t closing, that’s a separate issue.
If you fail to synchronize the iPad, then go somewhere without WiFi, I’m not sure how it’s Scrivener’s fault that the iPad doesn’t have the most current version of the project. In this context, “good synchronization habits” would involve being sure to synchronize before you go somewhere that doesn’t have WiFi.
If you do find yourself “stuck” with an unsynced iPad, the safest way to manage it is to duplicate the document you want to work on, and then work in the duplicate. Then when you synchronize again, the server version will update the original (if there are changes), but won’t overwrite the work you did in the duplicate. Even safer would be to use a completely separate “Inbox” project for remote notes only, but that’s probably not practical in all situations.
If Scrivener is crashing without synchronizing, that’s a separate issue. In fact, there’s a known bug that appears to have been fixed in the most recent iOS update. Have you installed it?
Katherine
The fact that Scrivener on the iPad cannot synchronize without a human being involved in the process is a huge problem. Yes, it’s Scrivener fault, not mine: I didn’t design it that way. I cannot even think about an app I used in the last 10-15 years that required “good habits”. In 1998 there were plenty of them, indeed. In 2003, maybe. But in 2021? Not synchronizing on the background? Taking 5-10 min each time, with no possibility to use other apps during synchronization? Really?
Scrivener for iPad has to develop “good habits”, not the users.
Yes, the newest update is 4 months old. Still crashing.
Overall I’m following the advice above and do not use Scrivener on the iPad until I absolutely have to, but every time it’s a huge disappointment (not only because of synchronisation and crashing, there are other issues, too).
1 Like
No, the newest update of iPadOS was just a week ago or so. It solved syncing problems for lots of users.
I can think of plenty of apps that can’t sync without a WiFi connection, though, which is the specific thing you were referring to.
Katherine
“without a human being involved in the process” means on the background, automatically. Plenty of these apps. All of them.
It seems to me that your initial question has been answered, several times.
What is it you still don’t understand?
Well, I still don’t understand how someone dares to blame users for bad design decisions. Like a bad cook blames visitors for not having taste buds developed enough.
Stockholm syndrome is hard to understand, too.
And yes, the last Scrivener update in my App Store is still 4 months old.
Users are not “blamed” for anything. When someone who doesn’t understand something asks a question there are always willing fellow users ready to answer. And if someone says “I don’t like Scrivener” the most common reaction is “good luck with using something else”. If you don’t like Scrivener, don’t use it. It’s as simple as that.
Catherine (and I) referred to iPadOS update, not Scrivener. Have you updated to the latest iPadOS update, which was released a week ago or so?
There is a large difference between “bad design decisions” and design constraints. Many years worth of electrons have lost their little quantum lives here in the forums talking about the designers’ goals and objectives with how Scrivener is designed and how those decisions have consequences on down the line.
In any event, in all of my years in computing (back from CP/M on forward) attempts to user-proof a system have never been a substitute for user education. This notion that a user doesn’t have to know anything about the constraints an application runs under and that the application will magically mitigate (when possible) and resolve (when required) all the potential error conditions under the hood really only applies when that is one of the initial design objectives and, usually, even then, falls short of the mark.
Scrivener is not one of those programs. One does, in fact, have to have a functional understanding of how it works in order to get the best performance from it, and realize that it has constraints. If one cannot (or does not want to) accept those constraints…well, perhaps Scrivener is not the right software for the one. Not every tool is right for every user – if they were, there wouldn’t be so many of them!
I’ve read KB’s detailed explanation above of the hybrid document/shoebox nature of Scrivener. I’ve also read this article. I understand things aren’t quite so simple.
What I don’t understand is how the document structure of Scrivener differs from something like DEVONThink, an app which I’ve been using for years. DT can hold several huge databases inside file packages which can be saved anywhere (like Scrivener), has many different UI elements for showing and handling extra metadata (like Scrivener), only updates specific files on disk when modified instead of saving the entire file (like Scrivener). It also has an iOS client which can handle partial sync of data, doesn’t attempt to offer feature-parity with the desktop app, can do (encrypted) sync via Dropbox, iCloud or WebDAV and handle sync discrepancies gracefully by creating copies of items.
This is not another attempt to say “app X does it, you should do the same”. I am interesting in knowing in what sense Scrivener’s database structure is so different from what I’ve described above. I couldn’t find details about it in KB’s post. Apologies if this specific question has been asked before.
Thank you.
It has been asked and answered. Only Dropbox has provided a sufficiently detailed API to let KB write the necessary sync code.
It’s nothing to do with any difference between DEVONthink databases and Scrivener projects. It is that DEVONthink’s developers spent a LONG time developing their own sync mechanisms. They started this some time in 2015 or 2016 (see https://www.devontechnologies.com/blog/betatestfornewsyncanddevonthinktogo20starts). There are still problems with sync in DT, as one can tell by visiting their forums, though it generally seems to work. It is not great with iCloud, which is one reason why I stopped using it with DT and switched to CloudMe.
You didn’t read his question right. He’s asking out of curiosity what is the difference in how DevonThink works under the hood and Scrivener and how their database looks, where one can do it and the other can’t, while (on the surface) having the same kind of features and way of handling things.
Well, one difference, if I understand correctly, is that Scrivener saves everything in original file formats. It’s not really a database, like Evernote or DT.
I believe that part of the difference is that DEVONthink is macOS and iOS only. It doesn’t have to bend to fit with the needs of Windows.
And Keith has said iCloud sync could be added, but that Scrivener would need to be rebuilt.
If Apple does announce a shift to Arm Macs tomorrow, perhaps changes will have to be made if the underlying tech is altered in any significant way.
Wonder how telling Keith’s final sentence is in the post linked above.
No, that is not correct: DEVONthink saves every file in its original format, too.
This is incorrect, too. DEVONthink “databases” are packages, and they can be navigated using the Finder just like a Scrivener project package. All files remain in their original format, and can be accessed and copied via Finder, or any utility that functions in a similar way (Path Finder, for example).
Errr! Well, one difference that I am aware of is that when you open the DT package, all files are kept in folders according to what type they are. So you get a folder for pdfs, another for rtfs, and so forth. But inside those folders are yet more folders. Like this:
One of the key differences is the .scrivx file, which is the master index file that keeps track of where everything goes in the Binder. The most common Scrivener synchronization errors involve that file being out of sync with the actual contents of the project.
The .scrivx file is essential to what Scrivener does, because it allows you to create the structure of a novel (or whatever), by placing files in an arbitrary order.
DevonThink doesn’t have anything like it. DT allows you to create groups, but the order within a group is completely out of your control: you can sort by name, creation date, etc., but you can’t drag an arbitrary file to an arbitrary location and expect it to stay there.
Because DevonThink doesn’t have a .scrivx file, it doesn’t need to worry about the timing of uploads. In Scrivener, if an updated .scrivx file is transferred but one of the files it refers to is not, you’ll get an “empty” Binder entry with no data. In the reverse case, the file will be there, but invisible, because no entry in the Binder points to it.
In DevonThink, if a file hasn’t transferred – which happens fairly regularly! – it simply isn’t there. No reference to it, no metadata, no indication that it ever existed. And either you go back and resynchronize until it appears, or you do without it until the sync algorithm catches up. Everyone willing to tolerate a missing chapter in the middle of your novel please raise your hand!
Katherine
1 Like