Collaborating With Scrivener

“Now, sure, you can go all Mythbusters on that Lamborghini and figure out a series of modifications that could be applied to the car that would allow it, technically, to be a helicopter. You could brute-force it and get something that manages to get off the ground. However, it’s not going to be a GOOD helicopter. It won’t do the kinds of things that you can do with a real helicopter. It won’t have the range, the safety features, the cargo capacity, the passenger capacity, and all the other features and requirements a real helicopter is designed to meet. It’s a one-off hack that is not usable on a regular basis.”

This was exactly the same sort of argument used when I suggested in another forum that you add integration with ProWriting Aid. Now, I’m not anyone special. Just a writer, a professional writer that has to churn out lots of words daily to keep my little freelancing business going. I’m not doing it for a lark, or fun, or sheer enjoyment of putting words to page. It’s my job, and therefore anything I can use to do my job better, I take it, shake it, and work it to get the results I need. But here’s the thing. I’m your customer. I’m telling you what I need. And as fabulous as Scrivener for organizing writing projects, it is not the sole need I have.

In other words, it’s just fine for the writer producing a few manuscripts in their lifetime. But it simply does not offer the features to make those words a professional product.

The biggest frustration I have as an indie producer of books is that while Scrivener has an awesome program for file converter to any book format I need, I cannot rely on Scrivener to produce the quality of editing needed for the final product. I end up having to switch between other products to achieve this.

I need a decent grammar editor. Sorry. Scrivener is not it. Grammarly comes close to being the perfect grammar editor, and thought it is not 100%, it is close enough that I can contract it as a standard with my clients. I need a really, really good online thesaurus like Master Writer.and a word editing program like Pro Writing Aid or Auto Crit. I need a consistency checker like Perfect-It (which I’m beta testing and it shows promise.) I also need a lexical density checker like what you find for free on Analyze My Writing. You might consider this all above the paygrade of Scrivener and at its current price point, you are probably right. But a professional package like the above, fully integrated, and appropriately priced would be worth it to a professional writer like me. Then Scrivener would be a Lamborghini instead of the very nice Cadillac it is. The time saved between switching programs would make it worth the money.

The fact is ProWriting Aid did take your multi-file structure and instead of thinking of it as the big obstacle to integration, made it its strength. I can close up my Scrivener file, open up the ProWriting Aid desktop app, and edit an entire book chapter by chapter in a single day. Think of it. One day and essential style edits are complete. But to catch the grammar I have to copy and paste then edit it all in Grammarly, then copy and past it back into Scrivener, then work ProWriting Aid. You see what a small headache that is.

I adore Scrivener, but it’s not enough to help a writer to get out professional quality work on a timely basis. And if your customers say they need collaboration integration, then they’ll go somewhere to get it. The days of the lone writer working for two or three years on a manuscript and submitting it to a publisher is gone. Now publishing is writing a book, editing and, formatting then uploading it inside a month. Someone is going to provide a writing and editing platform to do this and when that happens, if it isn’t Scrivener, it will be someone else. Then Scrivener users will be like the Mac users of today, (of which I’m one) who cling to a platform they adore but seems to be sinking into obsolescence.

Just saying.

Yes, you are a customer and as such you are free to buy or not buy whatever you want or need, whether it is for pleasure or joy.

Your logic is in my eyes equivalent to me saying:
"I read what you wrote and I don’t like that genre. I want you to write what I like. And here’s the thing. I’m your customer. I’m telling you what I need. And as fabulous as your writing might be, it is not the need I have. "

L&L is a commercial company, selling a product. Their success depends on a sufficient number or people thinking that their product is good enough to make them buy it. When KB considers changing the product, he has to think about how such a change would affect current and future customers. If 20% of the customers would applaud a certain change and 80% would dump the product, it would be stupid to do that change, right?

Another professional writer here, and a professional editor to boot, busily churning out professional quality work on Scrivener for, hmmmm, the past dozen years? And a couple dozen before that using Word. Though admittedly I’m not writing and editing and formatting and uploading a book in a month. Mine typically take two or three years. I hope no one tells my publishers those days are gone.

Different tools for different uses–and users… For my purposes, and for many other professional writers of my acquaintance, Scrivener is the lobster’s waistcoat.

Just saying.

The irony here is that you are posting in a thread that is seeking to find a way to make Scrivener the very antithesis of what you firmly believe to be the only and one true way toward the future of writing software. You’re not only way off-topic, you are demonstrating the fundamental problem with software design that tries to cater, as you put, to the customer in all things.

I’m a little curious. Serial collaboration is a term I’ve never run across, so I’m not sure how that works. I get the concept behind real time collaboration— but I think real time collaboration might be an overreach as a request by the original poster at present since you can’t always be sure a collaborator would be available for, well, real time collaboration at all times. Add in that from all I can tell L&L doesn’t have the staff needed to even set something like that into the program anyway, and it seems like it might be asking too much from the program, at least as it stands. If L&L got more people to work on it, maybe it could work. But I somehow don’t think that will ever be a consideration unless they get some kind of massive and unexpected windfall that would allow for that.

I’m assuming that ‘serial collaboration’ means just writing in something, saving it in dropbox (or emailing it, assuming that files sent by email don’t get screwed up by being emailed), having your collaborator/co-author/whatever then do their work on it and send it back the same way. I honestly see nothing wrong with that concept, as again, you can’t always be sure that you’d have someone else on hand who could work on a manuscript with you in real time. Am I the only one who feels that way? I mean, real time collabs are a nice idea, but even with Google Docs, I’ve never seen collaboration genuinely happen in real time.

Just my two cents.

Real time collaboration involves two or more people working on a document at the same time. From the software point of view, it doesn’t really matter whether a team is working all day, every day, or a couple of collaborators are getting together to review one set of edits one time. The software problem is more or less the same, and Scrivener can’t do it.

Serial collaboration – as I used the term – is as you describe, person A sends a file off to person B for review, then incorporates their changes later. I was referring specifically to the Import and Merge feature in Scrivener 3.

Katherine

Ahh. Cool. Thanks for the clarification. 8)

I collaborate serially with a friend in China simply by having our various projects in a shared Sync (Dropbox being blocked over there) folder. Fortunately we are 8 hours apart, which is a PITA for other purposes, but really good for our collaborating as we are rarely able to access any current project at the same time. If your collaborator is in (nearly) the same time zone, you have to schedule access to the project or rely on the merge facility in Scrivener 3 as mentioned by Katherine.

As for real-time collaboration in Scrivener, I think if you could find out how many person-hours it took for Google to get Google Docs ironed out, or for Apple to get it to work in Pages—assuming it does—and how much it cost, then factored those up for the complexities that Scrivener’s package format brings to the task … doesn’t seem a viable proposition to me. If L&L sold out to Adobe, it might happen, but God forbid!

Mark

It would be nice if desktop Scrivener could at least include a semaphore file inside the package, basically saying “this project is opened on this computer”, so that other Scrivener instances (whether my own on other computers or those of a collaborator) that were syncing with it could alert the user(s) that someone else has the project actively opened.

Well that it does.

Project_Root.scriv Files/ user.lock

Open that up in a text editor and you’ll see everything that is needed to determine whether the thing opening the project is the same thing (scenario: post crash) or a different thing (including other compatible software, like Aeon Timeline). If it is a different thing, this info is used to describe the details of what appears to be using the project at the time, in a warning.

The warning gives you the option to either continue—safe to do if you’re positive it is a false positive—duplicate the project and work on a copy, or cancel out and go close it on the other machine or whatever you need to do.

Creating a copy when someone else has the project open is a more viable option in v3 than it was in the past. The copy will be created directly alongside the original—and so if real-time syncing is in use, both instances will be in the same place.

When you are done editing the fork, they can use the File ▸ Import ▸ Scrivener Project… menu command, if the importing project has the same internal origination tags as the imported project you will have the opportunity to merge the two forks. The merge uses much of the same logic that is used to merge iOS projects, and the result is much the same—very seamless so long as the two parties did not edit the same items (and then one gets duplicated conflicts they can easily resolve). It is typically very clean, and once done the fork can be deleted.

A procedure, specifically designed for parallel (not purely sequential) collaboration, using this very method is outlined in the user manual starting on page 69, within §5.1.7, Merging Projects.

It’s not real time editing, but as many have pointed out above, that’s like asking your local tractor mechanic to fix your Porsche (or turn it into a helicopter). I’d say parallel “check out” and “check in” style editing is a pretty good alternative to that, and not altogether too different from what you would get, mechanically speaking, from something like git. The difference of course is that as devinganger pointed out, with git you need a Scrivener expert on your staff to handle merges—and by expert I mean someone that can rebuild a project by hand using text editors. With file import you have that expert.

Hot damn. I guess I don’t break Scrivener nearly often enough!

Quakified is the typo of the day. Thank you!

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.

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. (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!

How could a “development team” be smaller than one person?

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

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.

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.

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.

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.

@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.

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.