Last week, author Charlie Stross posted his review of the process of writing using Scrivener, a specialized story-based word processor I’ve mentioned a few times. Stross has a good overview of the program’s strengths and weaknesses from the point of view of a professionally-published writer.

The program’s biggest weakness, he finds, is that it essentially becomes useless at the point a novel is finished and submitted to the publisher—because the Word document output isn’t quite ideal for submission, and then the publisher will send revisions in the form of Word documents, and expect them to be processed accordingly. Since Scrivener can’t do anything with the revisions, Stross has to use LibreOffice from then on.

This isn’t a formal review: it’s just a comment to the effect that Scrivener works pretty much from the moment of conception to the hour before final submission of a finished manuscript. It doesn’t completely replace the word processor in my workflow, but it relegates it to a markup and proofing tool rather than being a central element of the process of creating a book. And that’s about as major a change as the author’s job has undergone since WYSIWYG word processing came along in the late 80s (actually the late 70s if you were a researcher at Xerox PARC, but the rest of us had to wait). My suspicion is that if this sort of tool spreads, the long-term result may be better structured novels with fewer dangling plot threads and internal inconsistencies. But time will tell.

Stross also notes that Scrivener produces “some of the cleanest EPUB files that [he’s] ever seen,” which makes it a little puzzling that the help file comes as a PDF instead. (Someone in the comments points out that’s probably because almost everyone has a PDF reader on their desktop but few people have EPUB readers there.)

I’ve lately been using Scrivener for writing stories in a collaborative Internet fiction setting a friend and I have come up with between us. I’ve found it works great for writing the story, and for producing output files in several different formats if you’re not going to be sending them any further than out to the Internet for other people to read. The scene-based nature of it works great if you want to edit or rewrite just one specific scene—you don’t find yourself pressing control-end and then jumping all the way to the end of the document.

I’ve only run across a couple of major problems for me.

First, in my experience it’s really difficult to get things written elsewhere imported into the program such that you don’t lose any italics you’ve got. Either it pastes in the wrong font, or if you force it to match the style you lose the italics. I’m not too sure what to do about that. I may need to do more experimentation to see if I can figure out a way to make it work better. This is problematic if I’m doing any sort of collaborative work, like writing out a scene with someone using Etherpad.

The other problem is that it can be tricky to get your work to output properly into formats that aren’t standard markups. For example, I needed to post my stories to the Shifti transformation stories wiki. But in order to do that I had to pass them through Word or RTF output, open them in LibreOffice, copy and paste them into the WikEd wysywig-conversion text editor to wikify them, then copy and paste them into an Emacs clone to remove all the extra line spacing and do some final wiki markup cleanup (such as formatting the chapter titles as wikicode section titles), then copy and paste them back into WikEd for full wiki conversion. (In fact, I had to copy and paste it back and forth several times to do a Wiki preview and see if it looked right.) I did get the stories posted all right, but there’s got to be an easier way!