StorYBook gets in the way of plotting fiction

Some people imagine that they could write a novel if only they had the right tool. StorYBook aims to be that tool, but falls short. The problem is not that StorYBook is poorly organized, or that its timeline and reports don’t come in handy. Rather, the problem is that StorYBook has such a rigid structure that it is likely to fit only a minority of writers’ plotting needs. For others, living with the rigidity and searching for ways around it is only likely to distract from planning and make it a chore rather than a creative thrill.

Released under the third version of the GNU General Public License, StorYBook is a dedicated Java database that works well with OpenJDK 6, the free version of Java shipped with distributions such as Fedora 9. Documentation for installation is available on the project Web site, but you are unlikely to need it, since StorYBook installs in a matter of seconds from a shell script.

To use StorYBook for the first time, you create a new project and name it. Later, if you prefer, you can change the application’s opening behavior from File -> Preferences, so that it opens on the last saved project, or simply on the editing window.

Interface struggles

StorYBook’s problems begin at the editing window, which consists of a timeline for chapters on the left with provisions for color-coded strands, and an information pane on the right for strands, locations, and characters.

At first, this organization seems reasonable enough, but as you work, questions start to arise. For instance, although you can divide chapters into parts on the timeline, StorYBook assumes that each chapter has only one plot strand. If you want several plot strands in the same chapter, then StorYBook has no provisions for displaying this structure. A possible workaround, numbering a chapter 6A or 6B, simply returns an error message that prevents you from saving.

Another assumption is that you will have a default strand, rather than two or more subplots of equal weight. Admittedly, you can edit the name of the default strand to remove this assumption, but at that point, you are starting to make adjustments to the tool, instead of the other way around.

Even more importantly, although you can immediately start adding chapters, the division of chapter dialogs into characters, location, and summary means that, if you do, you will only have to go back for further editing once you have entered the characters and locations. Practically speaking, this arrangement puts you in the awkward position of having to start with characters and locations, rather than developing them in conjunction with your story’s events. The ability to edit all the main elements of the story together would be a major enhancement to StorYBook.

Within each story element, you may also find yourself limited by the interface’s assumptions and its required fields. In the chapter dialog, making the chapter number and strand required fields seems reasonable, but the exact date? In many books, the exact date is vague, or limited to the day of the week — and let’s not even get into the alternate calendars of fantasy or science fiction. And why is there no room for the time, which often features even larger than the date in a work of fiction? Similarly, a single field for Summary is sufficient only if you are only thinking in terms of plot. Some writers might want to plan consistent strands of imagery or ideas to go with the action.

The same problem also exists for characters and locations. How many writers worry about birth and death dates and occupation for every character? Or the city and country for each location? As with chapters, the ability to customize descriptions would go a long way toward making StorYBook more practical.

Then there’s the need to give each character and location a unique abbreviation for the timeline view. You don’t need more than half a dozen of each before either the abbreviation becomes meaningless, or the chapter cells on the timeline become too small to display the information. The fact that you can resize the cells brings only temporary relief until the same problem reappears. A mouseover or combo box might allow users to spend less time wrestling with the interface — and losing.

Ways of viewing relationships between story elements

If you manage to work around the problems in the interface design, StorYBook does offer several features. By color-coding strands, you can see at a glance how different plot elements interact. Even more usefully, from the View menu, you can switch between the order in which chapters appear in the book and their chronological order — which, due to flashbacks, may not be the same.

Another winning feature is the reports. In a matter of seconds, you can generate a summary of which chapters each character appears in, where characters and locations are used, what date characters appear on, and the dates used in each plot strand. A particularly useful report is entitled Who is Where When? All these reports can help ensure consistency, and since, by database standards, even an epic trilogy contains relatively little information, the reports are generated in a matter of seconds. And, if you wish, you can print the reports from File -> Export to a number of free formats, including text, PDF, HTML, and RTF.

Limited by rigidness

StorYBook has some potential, especially in its ability to give you visual representations of your plot and structure. But, in its present form, most users are likely to find it more trouble than it’s worth. Even allowing for some time to learn the program, the average writer is probably going to spend as much time working against the limitations of the interface as planning in StorYBook. That situation may be acceptable to wannabes, but all the professional writers I know are pragmatic sorts, and most of them are certain to be irritated by such an application. Too often, StorYBook seems to require you to conform to its needs, rather conforming to yours.

The project developers seem aware that StorYBook is not for everyone. As they acknowledge, great books have been written without such aids. Yet, if they could allow more flexibility to accommodate different work styles, then the application could greatly increase its appeal.