I am a writer who hates MS Word. Sounds paradoxical, you say? Not really. I won’t drag you through all of my reasons, but suffice it to say that as a creative writer, rather than a business writer, my job isn’t about word processing – it’s about world processing. Creative writers are like composers wrangling a symphony of ideas, all of which must be represented and interwoven textually. Word is great at allowing me to put my text in a pleasing form for output, but it has absolutely no features whatsoever to help me figure out what that text should say. And that is where the features of a well designed creative writing tool should be focused.
Trust me when I say that this is a matter I’ve given a lot of thought to. I’ve written academic papers on what features a true, creatively supportive writing tool should have. I taught a graduate class on the subject, and I’ve even designed a better system. On paper. But I haven’t actually built one yet.
Fortunately, others have, and I now realize that I may not have to. So recently, I began exploring some of the contenders as possible replacements for the series of jury-rigged and hand-cobbled tools I’ve been using for the last couple of years in my own work.
This is a first in a series of articles in which I will review some of these contenders and share my thoughts about how they stack up. In particular, I’ll be considering their support for the early-stage writing process, and I’ll be looking for tools that will run on my OS of choice (Linux), and permit me to continue writing from a variety of devices, as I move around throughout my day.
If that sounds like fun, follow me past the fold and check out my first review: StoryBook.
When talking about writing tool design, I find it helpful to break the discussion down into two sections: 1) the way the designers think about the art of writing and about how the tool should work, and 2) how well they delivered on that plan. Those will be covered in two sections: Feature Set and Implementation.
I’m also going to focus on the early-stage features – things a writer would start using right away, at the beginning of a project. Since I haven’t yet used StoryBook to complete a project, it would be unfair of me to assess it for those later capabilities.
Feature Set
The first thing I want to say is that I love the conceptual model StoryBook uses. It’s designers think very much like I do about book structure and the writing process. To them, books are broken into parts, then chapters, and then scenes, which is exactly how I think about them. I love that I can create individual records for characters, objects, locations etc., allowing me to keep backstory notes, reference pictures and all kinds of goodies, which don’t necessarily appear in the actual text.
I love that each scene can be tagged with the date and time, the list of participating characters, settings and objects. I can even create records that describe when an object moves from one location to another, or into the possession of a character. This is simply fabulous for keeping track of potential continuity flaws. Even better, I can then create day timers for my characters, to show me who is doing what, with whom, and where, at any point. These are some of the things that I have been talking about in my theoretical designs for tools, and now here they are, already implemented. The StoryBook team got inside my head and built a tool that has exactly the kinds of features I want.
So what’s the downside? Well, to begin with, not everybody wants to work the way I do. Before I could recommend an editor to the general community of writers, I would have to be confident that it would support other approaches to writing, too. Not just my own. Hell, I don’t even know if I will still approach writing in another year or three the way I do now. What if I decide that story beats are a better fundamental building block, instead of scenes? Oops. Too bad. StoryBook won’t let me work that way. Sure, I could probably force-fit a workaround, but it would be awkward and I’d always be having to ignore the quirks – which is exactly equal to death of creativity. As soon as you start noticing the tool instead of the work, creativity is over. So it’s their way or the highway.
In the end, that’s my biggest problem with StoryBook’s conceptual framework – there can be only one. There is no fluidity. And this one-way-only viewpoint is pervasive throughout the system. If I create an item record in the early stages of my process and then later decide that this item might more accurately be conceptualized as a character, I’m hooped. (Think Bilbo’s ring, or Jimmy the Magic Flute from H.R. Puffinstuff.) StoryBook won’t let me treat an object as a character. Or what about the Millenium Falcon? Have a ship in a spacedock that is both an object and a location? Sorry, pick one. You can’t have both. Or you can, but you would have to do it with two different records, which defeats the whole purpose.
Another feature I liked is that they’ve given me the ability to track attributes on characters, such as a birth date, occupation, gender, etc. And if those attributes aren’t enough, they also provide the ability to add my own attributes. If I want to track hair color, or education level, I can add attributes with those labels and then give them values. But why is this feature only on characters? I can’t have attributes on objects, or locations? I can assign my character a mass, but I can’t do so for my weaponry items? That seems oddly short-sighted.
Overall, I was impressed with the feature set, but saddened by the rigidity with which those features were interpretted.
Feature Set Grade: B+
Implementation
The single best implementation feature of StoryBook is the fact that it is maintained as an Open Source project. So if you don’t like something, you’re free to change it, assuming you have the skills and the time. For me, that’s a big bonus.
Now lets get into the meat of the interface. Being able to offer all these entities I mentioned earlier, such as character, location, object, scene, and chapter specifications etc., means that the interface does seem to be a bit busy. The menu and toolbars are not as complex as some versions of Word have been, but I do find the overall layout more than just a little cluttered. But even more than that, I have to question the wisdom of taking up 20% of my precious screen space to show me advertising. (The purple-coded area in the screen capture image.) Granted, I am using the evaluation version, but did they think I wouldn’t notice that missing 20%? Or did they maybe think that losing that much of the screen would not impact my workflow? This point alone gives me the feeling of being slimed. It’s like they’re trying to get my money before I’ve had a chance to examine the goods, and that doesn’t feel right, no matter what kind of business transaction we’re talking about. It’s sad to see this in an Open Source project, and more than just a slightly troubling commentary on their attitude toward customers.
Anyway, like many Java-based interfaces, I find the StoryBook windows and buttons clunky and a bit ugly. And there are so many of them open! I can barely figure out which window does what. And I keep looking in new places and discovering more windows, and buttons to open even more. (Look at them all, which I’ve highlight in red. And I haven’t even included the window slider controls.)
But let’s get down to business and edit some text. You’d think that, in a writing tool, the place where you enter the text of your novel should be fairly big and obvious, right? Hmm. After creating a new project and looking around… Nope. There is nothing on the screen that will currently allow me to start typing my text. I can create characters, locations, items or scenes. Apparently, I have to go through the process of specifying at least one scene before I can start typing it. Oops. And to specify a scene, I have to specify a chapter first. Double oops. And that requires a “part.” Once all that has been done, I can then click on it to open it, and then a text window comes up that I can type into. And for some reason, if I revert to the Default Window Layout, even with a project that has scenes defined, the editor shows up as that tiny green strip down the right side. Collapsed. It’s as though the developers are trying to get in my way.
Eventually, I got it to open, but when that holy text window finally does come into view, it’s only half a screen wide. (That damned advertising window is hogging way too much space, but I’ve already vented on that point.) By rooting around, I figured out that I can undock that window from the main interface, and then hit the maximize button, and it will maximize the edit window. Sort of. Still gotta leave room for the damned advertising window, and I can’t make the menu or toolbar go away. So no, there does not appear to be a big, just-let-me-type mode. The best I could get was about 60% of the screen. Grumble.
Well, the UI might be a bit thick and chunky, but I’m able to look past a lot of clunk if there’s plenty of zip. Or at least, I could. If StoryBook had any. I spent about 1/3 of my time hunting around through the menus, tabs, tool bars, and submenus, trying to find the button or menu items I wanted. I’m sure there’s some kind of logic to how everything is arranged, but to be honest, it seems to be more for the programmer’s convenience than for the users. Once I did find the feature I was looking for, I then spent another long, painful lag time, waiting for StoryBook to do whatever I had just told it to do. Why oh why do people still write creativity tools in Java? Don’t they know that every millisecond of lag time is an impediment to creative flow?
And while we’re on the subject of slow, can I say a word about loading times? I kid you not. It took 20 seconds to load the app to an empty window, and then another 43 seconds to open my project. And that’s a pretty bare-bones project, too – with 2 dummy scenes (one sentence in each), 10 hastily sketched characters and maybe 3 or 4 objects and locations. That’s hands-down the slowest performance I’ve seen from any writing tool on this computer ever. God help you if you actually have a project with content. (And don’t get me started on the time I clicked on the Edit window before I’d created any scene records, and endured 25 minutes of chunking and whirring in the background before I finally had to cold-boot the computer to get my life back.)
One of the big features of StoryBook is that it allows you to draw fancy graphs and day timers of where your characters are and when, or where they’re going, based on all those extra attributes you can track from the character record. Or, to be more accurate, StoryBook Pro does this. It turns out that the features I most wanted to experiment with are not included in the trial version. I wonder how many people actually pony up the cash to evaluate those tools, and I wonder if that generates anywhere near as much money as they are losing by not allowing potential customers to try the entire damned product. Sigh.
But even with all the weaknesses I’ve pointed out, I think StoryBook is exploring an approach to writing tools that has merit, and I could see myself trying to use it further, despite its flaws, if it wasn’t for one cold, inescapable fact.
The files are stored in a proprietary, binary database file. I have lost projects in the past because a program died and I could no longer open the files. Or because something screwed up at file saving time, and the binary file corrupted, taking a portion of my life with it. So in my view, for a project as complex and as time consuming as writing a novel, it is absolutely unacceptable for the tool to store content in anything other than standard text or RTF file formats. If the software dies, I want to be able to open the files in other apps. And if something gets corrupted on save, I can live with losing a single scene, or a single JPG, but I will not tolerate having my entire project tied up in that single corrupted file. And for this point alone, I would never entrust StoryBook with an actual project. My time is too valuable for me to take that kind of risk.
Implementation Grade: D
So what’s the final verdict? I like the approach StoryBook takes, but I’m frustrated by many of the implementation choices. Some people may be able to look beyond the things that I count as weaknesses, and particularly if attribute tracking and continuity problems are what they need help with, StoryBook might be worth a careful, tentative test. Especially if you’re on a fast machine that makes the lag less evident. But for myself (and I presume many others) the cumbersome response times and the in-your-faceness of the UI both conspire to degrade my chances of achieving and maintaining creative flow. And I simply won’t trust my hard work to a tool that I might not be able to get back out of, if things go badly.
Final Grade: C+
