Creativity Hacker

So, you’ve emerged from your MSWord-induced fever dream and discovered the natural wonders of Scrivener. You relish it’s ability to help you process ideas, not just words, and you revel in exploring all that it can do for you. You have character fact sheets at your fingertips. You’ve dropped all your reference notes into your research folder. The inspirational photographs are all in place. You’ve chopped up, reordered, and reorganized your chapters and scenes a hundred different ways. In short, you are rocking your Scrivener existence.

Love it as you do, however, there are still some things that Scrivener won’t do for you. It won’t sync itself across the four computers you use for writing. It won’t facilitate your interactions with editors and beta readers. And it won’t manage the dozens of historical revisions and drafts you produce along your path from empty page to published masterpiece.

And it’s not just you. It’s me, too. And it’s many of the other authors I have spoken too in recent weeks. So in this article, I am setting out to develop a sort of “best practices” guide on how to facilitate an author’s life, with the tools we have at hand today. This won’t be a whiny rant on all the things that can’t yet be done. I’m just going to try to pull together the best advice I can find on how to build a credible creative writing workflow, centered on Scrivener as the main tool, and employing other tools, as necessary.

Before we dive into the details, I should say a word about my computing environment. For the record, I run a Linux shop around here, but you don’t have to. Everything I’m about to share with you will work just as well on a Windows platform, and should do on Mac as well, although Mac users will have access to some more advanced features in Scrivener than we lesser mortals do.

As the title of this posting suggests, I am going to focus on how to use Scrivener in the context of the cloud, to add a few elements to your workflow that are not directly supported within Scrivener itself. If you’re looking for a best practices guide to writing in Scrivener, this article by Gwen Hernandez is a great overview.

Synchronizing Copies

For authors who only ever use a single computer for their writing will not have much need to sync their manuscript across multiple computers. Or if you only write at home, and you happen to know something about network configuration, you can easily set up a network filing system that allows you to access your writing files from on central location, regardless of which computer you happen to sit down at. But by far the easiest thing to do is to make use of cloud storage.

In this article, writer David Earle walks us through the pros and cons of two of the more prominent players in synchronizing cloud storage: Dropbox and Google Drive. In the article, which was written in April 2012, David  assesses the various features of the two systems, and points out their advantages and disadvantages for users with different needs. For the purposes of synchronizing a central manuscript among multiple computers, David gives the nod to Dropbox and the better tool. His reasoning is based on a somewhat special case situation in which it is possible to make changes to the same document from two different computers before they get synchronized back to the cloud. When this happens, David judges Dropbox to be better at helping you to detect and manage the problem without losing any of your work, and I agree with him.

So even though Google Drive gives you more storage for free – 5 GB as compared to 2 from Dropbox – Dropbox is the better tool for storing your work. All you have to do is move your .scriv folder from where you have it now, and put it in a folder somewhere in your Dropbox folder, and everything should just begin syncing like magic.

Update Feb 2014: I have recently been advised by the folks at Scrivener that Google Drive is not recommended for hosting live production files. Apparently, GD does not play nicely when many small files are being updated frequently, which is the case with a Scrivener project. So you may want to focus your live sync hosting on Dropbox, or explore other cloud storage solutions.

Backups and/or Revision Control

In addition to storage of your working copy, there is another concept that we also need to look at: backups. We’ve all had the painful experience of losing a file, and then hunting desperately around our drive, hoping against hope that somewhere, you might have saved a temporary draft. It seems that the more desperate you are, the less likely it is that you have such a backup, or that you’ll be able to find it. Another, similar problem that can haunt an author is when you make a decision to change something in your novel, and you spend a month making all the necessary changes, only to discover later that you _hate_ the change and you want to go back. But when you made the decision, you were certain it was a good idea, so you didn’t actually make a special backup copy. You just went ahead and made the change.

So, from a strict data security point of view, you should only ever need a backup of the most current version of your work, in case the computer gets stolen or the file gets corrupted. But from the change management point of view, it would be a good idea to have backups of various key points along the history of your project too, and this is a concept known as revision control.

It turns out that Google Drive and Dropbox both offer revision management features, which David Earle’s article also examines. David’s advice is that Google Drive wins on this score, because Dropbox only keeps revisions for the most recent 30 day period, unless you upgrade to the pro account. But I’m going to disagree with David here. In a subsequent article, David talks about how to unscramble a Scrivener document in the unfortunate case where you happen to get things out of sync on your cloud storage system. I don’t think you should rely on your cloud storage tool to provide your revision control service (RCS) for you with Scrivener. Most RSC systems work best when they are managing changes to a single file, but Scrivener breaks your project up into dozens or even hundreds of files, all contained within a single, root folder. RCS tools handle this kind of thing as well, but using them is far, far beyond the ken of most authors.

Instead, I recommend using the built-in backup tool in Scrivener itself, with a few key options. First, in Scrivener’s Options window, set it to make backups automatically, and to retain ALL backups. (By default, it only keeps the most recent 10 backups on hand, deleting older ones.) Second, set the backup tool to include the date and time in the filenames it uses for backup files, which will make it easier to find a version from a particular point in time. Third, tell the backup tool to store your backups in a folder that is NOT part of your cloud storage folder. I have a folder called WritingBackups in my home directory, and Scrivener saves all my backups there. And lastly, tell Scrivener to save a backup every time you manually save the file.

By keeping your backups on your home computer, you are now protected in the very unlikely case that Dropbox gets blown up by aliens, or if your entire Google Drive folder gets eaten by a swarm of digital locusts. And since those backups have time/date stamps right in the file name, you also have an easy-to-manage revision control scheme. All you have to do to revert to an old draft is to unpack the backup zip file into a new working folder and open it in Scrivener. And I also like that with this scheme, it is really easy for me to force a backup at a crucial point. All I have to do is hit Ctl-S to manually save the file, and I know that if I later regret the decision to feed cousin Bernie to the Uber-troll in Chapter 17, I can always go back and revert the manuscript to a point in time when Bernie was still alive and undigested.

(In his second article, David Earle recommends creating a different directory in your cloud storage for saving these zipped backups, but because of the threat of digital locusts. I’m not a fan of having all your eggs in one basket. I think it’s better to keep working storage on the cloud, but I want my security blanket right here in my home with me. Call me crazy, but there are limits to my trust in the good intentions of corporations. Especially when it comes to services that I am not paying them for.)

Collaboration

The last point of this version of the best practices guide is how to use Scrivener and the cloud for interacting with other contributors. Maybe you’re working with a single editor, or maybe you’re trying to coordinate input from a dozen beta readers. Some users might be tempted to use the built-in comments and annotation system that Scrivener provides, but I don’t recommend it. (If you’re not sure what these features even are, here’s a short article by Denise Barrett that gives you the quick low-down.) Why don’t I recommend using the built-in system? Because to use it, you would have to share the .scriv file with your collaborator, and Scrivener just wasn’t designed for collaborative editing. Those comment and annotation tools are an excellent place for you to keep notes, but they don’t play nice with multiple authors. And don’t fall victim to the temptation to simply share your cloud-based .scriv file with your collaborator(s) either. You want a quick recipe for munging your files beyond all hope of recovery? Just invite a few other people to be opening and updating the same file with you at the same time. But don’t come crying to me when the locusts come.

No, this is where Google Drive really shines. Google Drive is really just a new name for Google Docs, and one thing Google Docs does well is permit multiple users to edit and comment on one document at the same time. It’s quite similar to the track changes feature in Word, but you don’t have to send the file around to people one at a time. Everybody can play at once.

Now, when it comes to editorial or beta-reader feedback, I like to keep a bit of distance between my working draft and the comments that I get. I personally never want and editor simply marking up my draft and handing it back to me. Even if track changes are on. Call me paranoid, or maybe it’s just that I’ve seen too many problems with technology over the years, but in my world, nobody touches the master draft except me.

So that means I have to prepare a discussion draft to send to my collaborators. In the old days, this might have been a set of printed copies that we mailed around, but in today’s reality, it means that I’m going to export a copy of my manuscript from Scrivener, using RTF format. And then I’m going to post that RTF draft to my Google Drive, and invite my collaborators to mark it up to their hearts’ content. I can choose to post just one copy, and invite all 14 beta readers to mark up the same draft, or I can create a different doc for each collaborator, and keep their changes isolated to just their copy. Once I have all their input, I can then go through the Google Drive doc(s) and copy their notes over to my master draft as I see fit.

Conclusion

Is this a perfect solution? Probably not. But it is what I’m doing, and it is based on what I’ve been able to uncover as best practices from other intrepid explorers who have gone before me. Despite all those conditionals, however, your experience is almost certain to be different, so let me know if you find any other new tricks, or any caveats and I’ll make sure to keep this document up to date. And who knows? By this time next year there will probably be so many new options to consider that I’ll have to rewrite the whole thing from scratch. So stay tuned.