“Project Already Open” could be way more helpful and less scary

Scrivener Scrivener for macOS
1

For an app that autosaves your work and touts Dropbox support, Scrivener’s “Project Already Open” warning dialog is pretty objectionable. Scrivener has been open on my always-online home Mac without me touching it for several days, yet trying to edit it at work gets me three paragraphs of small text warning of data loss.

I can think of several possibilities for making this more elegant. The most obvious seems to be that if the computer sits idle for ten minutes or is put into sleep mode, Scrivener could delete all open projects’ lockfiles. It can immediately restore them as soon as it detects computer use (or better yet, only restore them when a Scrivener window is focused).

I know that sync status is kind of related to this. The thing is, if Dropbox sync fails, then it doesn’t really matter whether the Scrivener project is open or closed; you’re still going to have problems. But if you want to be super careful, perhaps instead of deleting lockfiles on idle, you could instead add a file to indicate it. So when a user opens a project on another computer, if Scrivener sees that idle file, it knows that the latest changes have been synced, and it can then delete both files and add its own new lockfile.

At the very very least, the dialog should be less scary (and, if possible, less wordy). If you don’t do any of the above, it should say that this is normal in syncing scenarios, and that you can proceed as long as no one else is working on it and all the changes have synced. If you do some of the above (and it works as I’m speculating), then the presence of the idle file should produce no dialog at all, and the absence of it should make a dialog that says that either the project has failed to sync or it hasn’t been long enough since they stopped working at another computer.

At this point I should say that Scrivener is completely awesome except for this one dialog that has me irked. And also I’m an idiot, so my above suggestions might not work the way I’m envisioning them or at all, and I will gladly accept people pointing out all my mistakes.

2

Are you on V3?

There’s a setting which closes the project after so many minutes not being used - default is 30 I think, but you can alter it.

Sounds like it would help with your situation.

3

Maybe close Scrivener when you’re away from the computer?

The warning is supposed to be scary. Editing a project on one computer while it’s open on another is a bad idea and has a lot of potential for data loss. Just because it hasn’t happened to you (yet) doesn’t mean we should allow our users to ignore the risk.

Katherine

4

Ahh, that will help very much. Thank you! I still think something more like what I suggested should be default behavior, though. And I wonder if this works if I manually lock the computer before the idle time elapses?

What I’m saying is, an app that autosaves and explicitly supports a syncing service should be more friendly in extremely common sync scenarios like the one I describe. So far as I understand, if I did tell the scary dialog to open the project anyway, I’d be totally fine, so long as my latest changes on the remote computer had finished syncing. The problem would be if someone else had it open and was currently typing into it, or if Dropbox sync had failed to catch up by the time I opened the project on the second Mac.

If an extremely common scenario using supported app features results in scary warnings that probably don’t apply most of the time, then some part of the whole situation could use improvement.

5

The potential problem arises when you return to the original computer, sit down, and start typing. The still-open copy of Scrivener will NOT automatically reload the open file, and therefore will NOT see any changes that were made on the remote computer.

Moreover, the “problem” scenarios that you describe are extremely common. What if the original computer is accessible by a five year old, who decides to be “just like Mommy and Daddy?” (Don’t laugh. I helped someone to whom this actually happened.) What if, unknown to the user, Dropbox sync had stopped working on the original computer? (This happened, too, when a Mac OS upgrade back in December disabled all startup items.)

Shutting down Scrivener when you expect to be away from the computer for an extended period will minimize synchronization-related risks and keep the scary message from appearing.

Katherine

6

I would test it. If you sleep the computer – for instance by closing the lid – Scrivener will remain in its current state until you wake it up. Manually locking the computer should allow Scrivener to time out and auto-close normally. Logging out will shut Scrivener down completely.

Katherine

7

Editing a Scrivener project on two computers at the same time is not a supported feature.

Katherine

8

Yes, as Katherine says, the problem here is that your assumption that you would be fine if you carried on editing it is actually wrong. Suppose you do this:

  1. On computer A, type “Hello world” into a document.

  2. Open the project on computer B and type “Hello universe” after “Hello world” and wait for Dropbox to sync.

  3. Return to computer A and let Dropbox sync. It will still only say “Hello world”. So if you carry on typing and save, you will lose the data created in (2).

Scrivener supports live Dropbox sync between iOS and a desktop version; it does not support live Dropbox sync between two versions of the same project on two different desktop machines. (And iOS has to do this by “checking out” a version of the project which the desktop version has to merge back in… It is very tricky.)

The problem is that the data Scrivener is working with isn’t as straightforward as something like a single Word or Pages document, which can be synced live between computers. Because a single project is actually a folder full of interdependent files, of which there can be hundreds or even thousands, an impartial sync or working on a project before it has fully synced could cause serious data loss and mess up an important writing project; it also makes live syncing all of that data into the hundreds of UI elements very, very technically challenging (especially for a single coder such as myself!). Thus the “Project Already Open” warning has to be scary because it has to impress on users that they should not continue using the project if it is open elsewhere.

What I recommend doing, by the way, if you work between machines like this, is turning on the “Automatic Quit” feature in the “General” pane of Preferences. You can tell Scrivener to quit automatically if it hasn’t been used for say, ten or twenty or however many minutes. This way, if you forget to close your project before leaving for work, by the time you are at work it should have closed automatically anyway and you will be able to access it without any problems.

Thanks for the kind words, by the way!

All the best,
Keith

9

I just want to chime in with support for the OP. Being able to configure the locking behavior would be a nice feature.

Since I don’t use Scrivener sync, and instead sync my entire home directory between machines using a different mechanism, I can easily work around the lock. I know I am accepting the risk in doing so.

OP’s suggestion to provide a better user experience and allow us to control it seems reasonable to me. I know it’s a hard problem to solve without risk, but some users are willing to accept risk for the simplicity. (We don’t all share equipment, or allow rampant children to access our work computers.)

OP also thought through the problem, and I think the suggestion of creating a second file (or possibly simpler, adding an attribute to the original lockfile) noting idle time doesn’t seem far-fetched.

Then the messaging to the user can be more along the lines of “It looks like this is already open on . Your work was last saved at <date/time>. If this sounds right, you can open the file and transfer the lock to this machine; otherwise, we can create a copy for you.”

You can still be safe with user data AND provide a good user experience. They don’t have to be mutually exclusive.

10

Again, editing a project on two devices simultaneously is not a supported feature.

If you choose to work around the lock and do it anyway, that’s your data and your decision. But we’re not going to make it easier for less capable users than yourself to create a mess that they will then ask us to help them fix.

Katherine

11

Well the developer is very nice, but the support person is exceedingly blunt, so I will be slightly more blunt than I was last year:

SubEthaEdit came out in 2003, Google Docs née Writely in 2005, Git in 2006. I know that sync is the quintessential hard problem, I know that Scrivener documents are more complex than single text or even word processing documents, etc., etc.

But it’s almost 2020. Gracefully handling multiple devices is table stakes for a document-based app these days. I fervently hope that this issue is at or near the top of the priority list for Scrivener 4, if not a point release of 3.

12

Unless there is a magical breakthrough in technology for syncing complex multi-document rich text documents between platforms, the year is immaterial. Git expects source code and other strictly formatted documents, can’t handle the RTF format, and relies on the last-checked-in-resolve-conflict model to resolve any edits that happen on the same chunk. Google Docs was developed by a multi-million dollar corporation that took years to build a word processor UI over what is essentially a multi-access editing engine, and I don’t know enough about SubEthaEdit to say why that as an example doesn’t match the Scrivener model.

KB has very clearly laid out the design goals for Scrivener. “Multiple users simultaneously editing the same project” (aka simultaneous collaboration) has never been on that list. “Multiple Scrivener instances open at the same time but seamlessly editing the same project serially” isn’t even on the list. Which of the existing design goals and features do you think that Scrivener should give up in order to make simultaneous collaboration technically feasible, and do you have your hands on the sales data that would show you what percentage of users rely on those features that you would be alienating with such a move?

Not every tool has to be everything to everybody. If your top priority is simultaneous collaboration, or even just the ability to always keep your apps open on multiple devices and have the edits show up on other devices most of the time, then you should probably look at something other than Scrivener unless Keith shows up and announces that he’s changed his mind from the last time he talked about this in depth. But you should also be aware what you’re giving up by doing so. There’s a reason none of those other tools that can handle that particular capability have many of the capabilities that Scrivener does have.

13

This. Scrivener does not attempt to compete with Google Docs any more than it attempts to compete with Word. It is a different tool, designed for different tasks. If a tool other than Scrivener meets your needs more effectively, you should use it.

Katherine

14

My broader point wasn’t about the specific technologies being directly applied, just the time frame of bits and pieces of related problems’ solutions being generally known.

Google Docs was an acquisition of a web app called Writely, which was written by three people. And Google Docs today is definitely not 14 years more advanced than what they bought.

Plain text real time collaborative editing. Yes: vastly, incalculably simpler than a Scrivener package. Also 16 years ago, though.

I am extremely interested in reading these posts/docs and will go looking for them as soon as I finish writing this comment in blissful ignorance.

I don’t want any of the current features gone! I want it all to sync, ALL OF IT! MWAHAHA — but yes, your point is good; my priorities probably don’t reflect the broader user base. But my point with the examples and the years and the phrase “table stakes” is that the current situation with the incredibly verbose and scary warning is antiquated, youngsters looking at Scrivener are going to think the same, and any improvements in this area might broaden the user base in a way that “sales data” don’t show because the people who would fall in love with it are currently not buying the app.

But yes, that is still conjecture; yes, it is still biased by my own personal wishes, which would give up 100% of the rich text capabilities in Scrivener for Markdown plus syncing. I’m sitting here thinking how incredibly awesome collaborative Scrivener would be, while maybe there are hundreds of 50-year-old serious authors who want better indent options, or something. (That sounds more sarcastic than I mean it.)

Oh, come now. It’s not my top priority for a writing app, it’s my top priority after all the awesome stuff Scrivener already does.

Once again I would love to read every word he’s written on this topic and I will go looking for it right after I’m done ranting stupidly

Oh, Google Docs could be blowing Scrivener out of the water today if they cared the slightest bit. Or even if they barely cared enough to assign three or four of their 100,000 employees to improve it as a writing app for the last 13 years. Just like Numbers could blow Excel out of the water if Apple cared, or Windows could blow MacOS out of the water if Microsoft cared (that one’s more of a stretch, I admit). Unfortunately, it’s only indie developers like Keith who care, which is why idiots like me are bugging guys like him and pointing at these mammoth corporations for inspiration.

Anyway, I hope I’ve put enough self-deprecation in here (and it’s sincere, mind you) to serve as an apology for indulging my own bluntness. I very much appreciate Scrivener as-is, and if my grand vision for its possible future isn’t in the same direction as its developer’s, so be it.

15

It’s one thing for an enthusiastic forum member to conflate my strong desire for improved functionality in an app I’ve already said I love with a threat to move to an inferior one; it’s another for an official support person to do so.

16

Threat? Who said anything about threats? It has long been L&L’s position that we want our users to be happy with their tools, even if that means that they choose tools other than Scrivener.

Real time collaboration is an extremely difficult technical problem that may not be solvable without significant changes to Scrivener’s other functionality, but it is that other functionality that is the basis of our success.

Katherine

17

Not on the surface, no, but I’ve actually talked to friends inside Google, and there was a large behind-the-scenes struggle to get Google Docs up to a point of stability and robustness that a three-person team didn’t have for a product that basically relies on storing your data in someone else’s cloud at anything involving real world scale. Realtime collaboration products quickly stretch existing protocols and technologies to their breaking points and uncover all of the hidden assumptions that have been buried all up and down the network and OS stack, and you have to come up with solutions for every single one. That requires a serious investment of time, money, and capital.