How do I use Scrivener 3 with two authors

Write out any set of actions one must take to accomplish something, and it will look “insane.”

How to drive a car:

1. Walk up to the car
2. Pull up/squeeze the door handle until the door unlatches. If it does not unlatch, see #3, if it does, skip to 4
3. Unlock the door and go to 2.
4. Pull the door fully open.
5. Carefully climb into the driver’s seat, careful not to bump your head on the door frame.
6. Put the key in the ignition
   6a. If you have a location for your phone to charge and/or connect to your stereo, arrange that now.
7. Fasten your seatbelt.
8. Check your mirrors, adjust as needed
9. Make sure your seat is adjusted correctly; especially important if you share the car with another driver
10. Press down on the break pedal. If driving a manual transmission vehicle, also press down on the clutch pedal
11. …

Insane, isn’t it! Yet people do it every day without thinking about all those steps (and more, for some vehicles).

When writing out technical instructions, one must break down the steps, and take alternatives into account, or risk the recipient’s confusion or frustration. I could have just said, “Do a Save As, don’t edit the project (or at least don’t edit anything the other author will touch), then use the import function when they return the copy. Trash the save-as copies, and create another as needed for your collaborator.” Does that sound “insane”? If so, the compile process will break your mind and send your soul into the abyss!

We both have Scrivener 3 on Mac, how can I do what I need.

Follow Lunk’s instructions:

You could use the Scrivener file as a repository using a versioning system, updating it on a schedule to avoid conflicts and otherwise writing in something else or another Scriv. project, committing finished parts to the repository.

Or not.

Collaborative writing comes in at least two modes:

1. Real-time working together, and seeing each others modifications at the moment that they are made;
2. Independently working together on one’s own copy, and merging the results as soon as you are done writing (or any other moment you feel an update is required)

Regarding ease of integration into Scrivener, from the perspective of a software architect and engineer, i.c., myself, I consider the second mode of working together far more easy to integrate in Scrivener, and agree that the first mode of collaboration is quite a complicated functionality that makes the term “ambitious” a rather understatement.

Regarding what to wish for, for me, a scientist who write together with or as co-author, I’m not that much interested in the real-time mode of collaboration. I think it even distracts from your own line of thinking and we therefore should introduce what is called a [i]separation of concerns /i where one concern is the ability to focus on your own work, and another concern is to have multiple individuals to contribute to the result, such as reviews or modifications. A third concern would be to assure that merging texts do not mess-up the texts as we need to combine the first two concerns together.

The second concern calls for a master document that represents the current stable stage of what has been written by the mutual brains so far; the first concern demands the existence of several copies and versions of the master document, one for each of the individuals to work on separately and independently; the third concern calls for a means to assure, under any circumstance, that merging (different versions together into an updated version of the master document) does not introduce text conflicts, and when conflicts emerge (they do), have a proper tool to support a user in the resolution of the conflict in a seamless way and produce the new and stable version of the master document.

These demands for this second mode of independently working together is not new. In fact, in software engineering this is a rather established way of collaborative software development, denoted as version control, source code control, and several other terms. And although there is quite a difference in what is being produced (a highly structured piece of source code, versus a “structureless” piece of text which can be formulated in ever so many variations), the foundations of the process are identical. So it is no surprise that several collaborative writing tools exist that are based on Git (e.g., draftin.com, overleaf), and I don;t see any reason why Scrivener could not introduce such relatively simple collaborative process with a dedicated Git server in the background. Indeed, such an approach does not support the real-time mode of collaborative work, but introducing the feature to independently working together is definitely a highly welcomed functionality for Scrivener’s user community.

Although the members of the community are of course the judge of that, so please give your opinion!

Best
Paul

I see two main issues that would make Git integration with Scrivener more trouble than it’s worth:

1. Git’s conflict detection and resolution is predicated on having plain-text documents for it to analyze. Scrivener’s project format is based of RTF, for multiple reasons that have been clearly articulated elsewhere, As a result, Git could not detect whether there were changes within a document, only whether the document had been changed, and that would add more overhead to users who were merging changes.

2. Git assumes that users have visibility into – and want/need to know about – every file contained within a project. A Scrivener project has lots of files that users do not normally need to be aware of and should not be manually messed with. They can’t be ignored by Git – they need to be synced – but their contents are linked to the contents of the various RTF files, so there is a very real risk of the contents getting out of sync in a situation where multiple users work on the same document(s) at the same time and merge back to the same branch. Git would either need to be enhanced to understand how Scrivener works, or Scrivener would have to have exhaustive knowledge of how Git handled merges and programmatically handle some of the inevitable conflicts and hide them from the user. Both approaches would require far more work than would be practical.

Both systems are good, but they are built on incompatible assumptions about how a project is handled.

I don’t know if it’s fully implemented in the Windows beta yet, but Scrivener 3 supports an Import and Merge mechanism designed specifically for scenario #2.

As Devinganger notes, Git is not really a good alternative because RTF files are less human readable to a writer than code is to a programmer.

Katherine

Indeed, Devinganger describes a clear problem which needs to be addressed:

while Katherine presents the key to its solution exactly the way that I intended but failed to mention:

Having already the capability to base its synchronization on text files only, as opposed to the project’s RTF-base, Scrivener can avoid the RTF issues explained by Devinganger’s 1st issue. And since Scrivener in this way is already capable of synchronizing only the contents of the project without taking the files for the application’s internal operations and state into account, the sync-issues as explained in the 2nd issue can be circumvented as well.

This approach would result in a loosely-coupled synchronization mechanism between two instances of Scrivener, or one Scrivener instance and any another application (that supports text file based writing) through git. This requires the Scrivener application to plug some specific script on when and how to sync/merge and how to combine that with git’s pull / update / branch / mergetool and push operations.

Or do I overlook something?

Best
Paul

Scrivener’s base use of the RTF format for the actual document content is what allows many of the key features and functionality of the program to exist. It’s one of the core design principles of the program, not a flaw or problem to be solved.

The import and merge functionality is not based on exporting text files; it’s designed to work with two separate Scrivener projects (RTF and supporting files) and allow you to selectively merge their contents together.

If you want pure text files so you can use your editor with Git, look for some other editor to use. Don’t demand that KB re-design and re-write Scrivener from the ground up.

This statement is not accurate.

Scrivener does not create or manipulate plain text files unless you explicitly tell it to as part of an export operation. The internal project files containing your work are always RTF.

Moreover, the Import and Merge feature emphatically does consider the metadata that defines, for example, the structure of the Binder. That information is part of the “contents” of the project. If you attempt to manipulate the RTF files independent of those structural files, you are almost guaranteed to render the project non-functional.

Katherine

I while I do still hava a license, I think I would no longer use Scrivener until it would use native markdown format. Using markdown would sort the GIT issue and also play well with other tools/platforms.
I may be biased because I need it only for technical writing in a collaborative manner, where multiple people could change it.
PS. I know enough about RTF format to want to run from it at any cost

We’ll miss you, but this is unlikely to happen.

Katherine

Is there a modding community? Is this a possibility?

No, and no.

Yep, rdale. It would’ve been easier had you said that. And yes, I still think it is insane.
In 2006, Apple had a slogan that said: “It just works.” Now, anyone who used Apple products knew that wasn’t totally true. But they certainly held up far better than the competition.

Sure, what you tell us to do so that co-authors can work on a document together isn’t difficult to achieve. But the end result isn’t very effective. It’s also a pain in the a$$. Especially when there is another piece of software out there that can collaborate very effectively. Is it the same as Scrivener? Nope. Will it allow me to collaborate with my writing partner? Yep.
Hmm… which will I choose… Hmmm…

The fact is, the simple answer to “How do I use Scrivener 3 with two authors?” is: You don’t. I’m pretty sure Keith would agree with that evaluation.

Don’t presume to speak for Keith, none of the rest of us do.

Your statement as such is incorrect. There are a a few people who are members of the forums who use Scrivener 3 to work on projects with other authors.

They just don’t do so simultaneously without understanding the project structure, limitations, benefits, and remediation steps.

Dev is correct.

My co-writer and I have developed a method using DropBox that works pretty well.

But it’s still tricky. We have a master Scriv file in a DB shared folder. To edit/write/revise we copy it inside that folder, and immediately drag the copy to a local folder.

Once revised locally, we text, alerting that the master file will be updated (this keeps the other person from opening it independently), then open the master file, drag the new docs into the master, and move the older docs to an ‘Older’ folder inside the master.

We also initial and date the new docs in the doc title (Scriv updates the mod date if you only look at the doc funny, which is not helpful at all).

Also, revisions by me are labeled with a red icon, by her with a yellow one.

Then the revising author closes the master file on the shared folder. That saves it, and the mod date changes. Then the other person knows the change is complete, by checking the mod date of the Scriv file.

Indeed!

In March of this year I used Scrivener 3 to work on a creative writing project with 72 other authors. We wrote seven books together in a single day, including all writing every single word of prose, and compiling all seven versions into epub, kindle and pdf finished products. Scapple was used for some of the plot development, but the only other software used on the day was Photoshop to produce the front cover images.

So in response to the assertion that Scrivener isn’t good for collaboration, my response is is simple: It works exceptionally well for me.

That sounds like a complex case study! Would you mind briefly sharing how you coordinated, synthesized, and deconflicted the authorial inputs using Scrivener? Cheers!

I’m afraid it was nothing more complex than using compile to get materials out and import to get materials in.

The trick is not to confuse collaborating on writing a book with collaborating on writing a sentence. It’s all about dividing the tasks up so people are working to bring different things into the mix, not trying to do the same task at the same time. The former is like two people each grabbing an end of a sofa to help carry it up some stairs. The latter is like both people grabbing the same end! Not only is it not helping, you’re actually making it harder.