Collaborating With Scrivener

[bmcraec]

Having done some serious research recently into the various realities of collaborating via Cloud filing systems, my experience suggests we can't have all the toys at once. It's like playing golf and hockey at the same time. Or something. There will always be compromises, until somebody decides to re-engineer the cloud collaboration experience. My worry is that we may be consolidating services before there has been enough experimentation possible, and every large organization ends up getting stuck in previous decisions. Doing the primary investigation of how creation and production work, could work, or will want to work is a huge but very valuable project. For now, I shall take small joy in things like Focus mode. I really like this focus mode. Even though I can see Facebook to the left on my other screen, I have to cross a big black expanse in order to get to FaceBook. And black expanses scare us. Nice one, Scrivener.

[root]

Not a total redesign to be a tool that has a different focus, just an acceptance that edit conflicts are not just a mistake to be avoided that can be handled as a clumsy error, but rather a regular thing that happens and should have some tools for it. That literally would be enough for me to use it for collaboration effectively.

Perhaps once 3.0 is out cross-platform and stabilized, KB might have time to consider the minimum viable product for such a feature that would work with the Scrivener philosophy -- but to do so, one would need a realistic set of scenarios painted out, not just the "it needs to be like Google Docs" that most people lead with.

What would such a conflict resolution experience in Scrivener look like to you?

This collaboration thread makes for highly amusing reading. Never before have I seen support staff explaining lack of features by comparing the size of other companies support staff. (Not development teams!) Also very entertaining with the Lambacopter: Such a funny metaphor, but a totally flawed argument in this context.

As more of the posters seem to be Minimum Viable Software Developers as opposed to writers, here's a little gold nugget of information: Most writing outside of the lonely researcher or the ditto poet is a highly collaborative activity. In fiction we collaborate weekly with our editor, in tv drama I collaborate daily with episode cowriters and directors.

In other words, adding collaboration isn't an odd feature that would turn a writing software into a Swiss Army Knife. It's an ability that's at the core of the craft. Also, one would have thought it's a feature that software developers should recognise the value of. Millions of GitHub repos tell a compelling story. And since a couple of years, large enterprises set up their own internal version of GitHub for code sharing and increased productivity for cross-functional teams.

And, of course, the apparently dreaded Google Docs. A great example of software that kind of suck (What, why do we need menus like a 1990:s version of Word?) but is hugely popular due to a central feature - collaboration. The need to collaborate is so high, that writers around the world stomach the rest.

As for complexity and resources, Google Docs is actually a really interesting case. Here Katharine is very much off with facts, because it wasn't 'the immense resources of Google' that built the collaboration feature. A team smaller than Scrivener's developed something called Etherpad which had non of the font et cetera glitch of Docs, but live collaboration. This was bought by Google.

But before you go on saying 'Aha - immense monies!', the Etherpad team open sourced the collaboration engine. This was in turn picked up by another little group of enthusiasts who tweaked the open source version into something beautiful called Hackpad. Which in turn was snapped up by Dropbox and is now - tada! - Dropbox Paper. True story.

So, to conclude, the open source engine is still - uhm, open source - and lying around for pickings. Git is of course also open source, and there are already people who have hacked Scrivener into syncing with repos. (https://github.com/carsomyr/scrivener_starter) When I say people, I mean single individuals. Without of the vast resources of Google.

Obviously, I have the highest of understandings of the complexity imbued in software development, But let's give paying customers the right arguments. I mean, if the thread is still there, you could see this one as a dead ringer for the one requesting an iOS version! (Short summary: No, we can't do it. Software people chiming in and comparing it to different kinds of flying vehicles. Scrivener coming back after many moons and announcing it, but also being honest about the time frame.)

What have we learned?
- When it comes to writing, collaboration is so central that it's not a strange 'add-on' feature transforming the app into a flying machine, but at the core of people in the trade are doing on a regular basis.
- Collaboration is also the top driving force behind much of the current tech development, fostering everything from the move to the cloud to the record user penetration of Slack. That's also why many players already sitting around the table are going all in on collaboration, like Dropbox with Dropbox Paper.
- There are tools that could be appropriated, so the feature doesn't necessarily need to be developed from the ground up,
- Actually, there's already a MVP out with GitHub sync for Scrivener that could be interesting to look at and learn from. (I already hear the naysayers complaining that it would require a GitHub account, but then they forget that syncing with the iOS version demands a Dropbox account.
- Obviously, in a couple of years there won't be any writing software left that acts like an isolated island, because even more work will be done online with collaborators from all over. And nobody will accept sending versions back and forth. In the Septic's land on the other side of the pond, production companies are already talking about ditching the long time industry standard Final Draft because of the lack of collaboration.

Just put it on the backlog and be honest about when it's picked up into sprints or not. We can wait, as long as we know it's in the works. As we did with iOS, and what a fantastic piece of software that turned out to be!

[lunk]

How could a "development team" be smaller than one person?

[kewms]

As for complexity and resources, Google Docs is actually a really interesting case. Here Katharine is very much off with facts, because it wasn't 'the immense resources of Google' that built the collaboration feature. A team smaller than Scrivener's developed something called Etherpad which had non of the font et cetera glitch of Docs, but live collaboration.

The software that we know today as Google Docs was then almost completely rewritten by Google employees.

In any case, the key issue that comparisons with Google Docs (and other services) miss is that a Scrivener project is not a single document. It is potentially hundreds of component files, and the relationships between those files are just as important -- in some cases more so -- as the files themselves. If it's fair to ask why Scrivener doesn't support Google Docs-style collaboration, it's also fair to ask why Google Docs doesn't have anything resembling Scrivener's Corkboard, Outline, and Compile features.

Katherine

[lunk]

Just put it on the backlog and be honest about when it's picked up into sprints or not. We can wait, as long as we know it's in the works.

And if KB says that it’s not in the works, then what? Will you continue to ask for it, wish for it, demand it, or will you finally accept the "no"?

My experience after following this thread since its birth is quite different from yours. I don’t understand why people who claim to be intelligent just can’t accept the answers given and move on.

[devinganger]

Also very entertaining with the Lambacopter: Such a funny metaphor, but a totally flawed argument in this context.

Merely claiming so does not make it so. You missed the point of the metaphor -- Scrivener was not designed to be thing B, it was designed to be thing A and has grown from that design. Thing B's capabilities may be very hard to graft on without a total core re-design.

As more of the posters seem to be Minimum Viable Software Developers as opposed to writers

Many of us are many things *in addition* to being writers. For example, I'm an IT architect. That gives me a perspective on fads in software and the adoption of tools by specific populations vs. general populations.

Most writing outside of the lonely researcher or the ditto poet is a highly collaborative activity. In fiction we collaborate weekly with our editor, in tv drama I collaborate daily with episode cowriters and directors.

In *your* specific populations those statements are true. They are not universally true. I work for a large media corporation, which includes a large number of writers for all kinds of media. None of your claims are universally true for any of them -- one writer's room will use Google for real-time collaboration while others have a workflow based on Word while others use other tools.

The only ability of writing software that is at the core of the craft is to get words written down. Real-time collaboration is something a lot of people *want* or *think* they need, until they actually try it. It works well for some, it works horrible for others. For the technical books I have written or contributed to, it has never been a requirement (and in fact, would have been a huge hindrance). Most of my friends who are fiction authors who have dabbled with it say that it was a cute toy but at the end of the day, it didn't provide enough benefit to keep it as part of their workflow. Most of my friends who are editors don't care WHAT tools their authors use as long as the copy is clean and revisions are handled with clear professional communication.

[mbbntu]

@root Let me introduce you to a psychological phenomenon that ought to be more widely known: the False Consensus Effect https://en.wikipedia.org/wiki/False_consensus_effect. The internet is awash with examples of it, and I seem fated to encounter it everywhere I go. It is particularly common in threads on wish-lists. I wish I had a Euro for every time I have seen it. In fact, I sometimes wonder if anyone has thought of carrying out a study of the effect using wish-lists as their data source. There is plenty of material.

Cheers.

[mbbntu]

And just to quote from the article cited above (since I can no longer edit the post):

"when confronted with evidence that a consensus does not exist, people often assume that those who do not agree with them are defective in some way. There is no single cause for this cognitive bias; the availability heuristic, self-serving bias, and naïve realism have been suggested as at least partial underlying factors. Maintenance of this cognitive bias may be related to the tendency to make decisions with relatively little information. When faced with uncertainty and a limited sample from which to make decisions, people often "project" themselves onto the situation. When this personal knowledge is used as input to make generalizations, it often results in the false sense of being part of the majority."

Seems a fair summary of what often happens in wish-list threads.

[kewms]

"when confronted with evidence that a consensus does not exist, people often assume that those who do not agree with them are defective in some way.

There's also the No True Scotsman fallacy, in which one decides that people who have different writing requirements aren't "real writers." https://en.wikipedia.org/wiki/No_true_Scotsman

Katherine

[xiamenese]

"when confronted with evidence that a consensus does not exist, people often assume that those who do not agree with them are defective in some way.

There's also the No True Scotsman fallacy, in which one decides that people who have different writing requirements aren't "real writers." https://en.wikipedia.org/wiki/No_true_Scotsman

Katherine

Reminds me of the post from about a decade ago which demanded that Scrivener should have white characters on a blue background, as "real writers" only work in that environment.



Mark

[JimRac]

There were a few references in root's post to GIT, which made me curious.

Is there anyone here who has successfully and regularly used GIT to collaborate with others in Scrivener? Or does anyone here know anyone who has?

If Scrivener collaboration using GIT actually works, why aren't all the people for whom collaboration is a requirement actively using it?

I don't have a need for collaboration now, but I can foresee a time when I might. If GIT works with Scrivener, that's wonderful, I'll have a look at it if the need arises. But if GIT doesn't work with Scrivener, then why is it being brought into the conversation?

[JimRac]

ETA: And If Scrivener collaboration using GIT actually works, then L&L doesn't really need to change Scrivener, right?

[jg76]

There were a few references in root's post to GIT, which made me curious.

Is there anyone here who has successfully and regularly used GIT to collaborate with others in Scrivener? Or does anyone here know anyone who has?

If Scrivener collaboration using GIT actually works, why aren't all the people for whom collaboration is a requirement actively using it?

I don't have a need for collaboration now, but I can foresee a time when I might. If GIT works with Scrivener, that's wonderful, I'll have a look at it if the need arises. But if GIT doesn't work with Scrivener, then why is it being brought into the conversation?

The challenge of using Git with Scrivener is that Scrivener relies on a series of RTF files mediated by the SCRIX project file. In theory, there's no reason why I couldn't save all of my Scrivener projects to a local repository and periodically commit it back to GitHub or perhaps my own GitLab CE server. But why? The value of using a version-control system for collaborative development is that the files being version controlled are intrinsically human-readable in plain text. Have you ever inspected an RTF file in a text editor? It's exactly the opposite of human-readable. You can use Git (or Subversion, or Mercurial, or whatever) but you're really requiring the collaborators to download the file, edit it, then recommit it. Editing source online won't really work well. In a sense, you're merely subbing Git for Dropbox with file-version history. Fun stuff, like diff and blame, are more complex in an RTF.

(Someone correct me if I'm wrong, but even if you write in MarkDown, the files still save as RTF. Correct?)

Let me preface the comments below with a disclaimer: I'm a fan of Scrivener and I often recommend it to emerging authors when I speak at writers' conferences. For a long time, I've relied on it almost exclusively for my writing work. That said, in recent years I've migrated away from writing mostly solitary fiction to writing collaborative textbooks. And as others have mentioned before, the use case for Scrivener isn't (a) multi-user or (b) technical non-fiction. (Well, at least, not without some advanced skills.) The L&L team gets mega props for developing a multi-platform authoring environment that does many things well. Of course, no application can meet all use cases simultaneously. I dread to consider the beast that might result if someone actually tried.

Right now, the killer features I need are:

• Plain-text files (not an RTF simulating a plain-text file) to make optimal use of a VCS like Git
• Support for AsciiDoc — my current work needs to convert to DocBook; MarkDown or MMD is good, but not great, for technical long-form work
• No central database file to mediate subfiles within a project — the file tree is the only mediation I require, so I need to rename files within the project at will
• A full-screen mode that works cleanly (sorry, L&L -- the one thing Scrivener sucks at is full-screen writing)
• Several documents open simultaneously in non-overlapping panes, without switching

My solution has been to abandon Scrivener for my own writing. Again, Scrivener is good -- but not for the particular use cases I need at this point in my writing career. I've instead migrated exclusively to Visual Studio Code with a few choice extensions to support long-form writing and AsciiDoc linting. And I use GitHub, creating private repositories for each of my major projects. When I've got something to kick to the VCS, I just commit the project.

As long as L&L doubles down on a SCRIVX-mediated collection of numbered RTF files, I cannot envision a scenario where Scrivener will be effective for multi-user collaboration.

Then again, it wasn't intended to be.

[JimRac]

Thank you for your thoughts, jg76, which give me a bit more insight into the practical challenges involved for using GIT with Scrivener.

[krastev]

(Someone correct me if I'm wrong, but even if you write in MarkDown, the files still save as RTF. Correct?)

No. It's plain text.