Happy Independence Day!

Publetariat is taking the day off on Monday, July 5 in observance of Independence Day. Site members can still post to their blogs and use the Publetariat Forum during this time.

See you back here on the 6th!             – Editor

Storyist Software Offers Easy ePub to Self-Publishers

About a month ago I came across the software Storyist for the first time. I was taken by Storyist’s idiosyncratic interface and knew right away that it had to be the work of a single individual. You don’t often get quirky hybrid software from a committee.

The man behind Storyist is Steve Shepard, a high-tech entrepreneur and writer who created it to solve his own dissatisfaction with the software tools for writers that were available.

 
It’s really an immersive environment, and if you find the Storyist interface to your liking, it will probably become addictive, because no other program I know provides this type of interaction with your writing project.
 
The complete Storyist set of modules or features includes:
  • Word processor
  • Page layout
  • Outliner
  • Storyboard
  • Manuscript and Screenplay formatting
  • Style sheets, style editor, project wide searching, links, etc.
storyist epub files self-publishing

Click to see the Storyist interface full size

Storyist isn’t only a word processor, it has the ability to track your plot, your characters, even the settings in your book or screenplay. Storyist handles screenplay formatting and straight narrative formatting, producing what it calls “submission-ready” files for output.

However, none of that, even though it’s interesting, is what made me stop and take a second look.
 

Storyist: ePub Conversion for the Masses?
What really attracted me to Storyist was the announcement a few weeks ago that they had added support for ePub conversion right inside the program. As ePub becomes more prevalent, I think we’ll see more and more consumer level tools with the ability to “Save as” or export files direct to ePub without the need for a separate program, or for an outside contractor.
 
ePub conversions are notoriously uneven. The format also has critical limitations in its ability to deal with graphics, tables, charts and other non-text elements.
 
But after watching Shepherd’s video demo of how to create an ePub, I just had to try it. It’s a terrific demo and I really sat up and paid attention when I saw how easy it was.
 
I’m not going to repeat the steps that Steve Sheperd outlines in the video, I don’t think I could improve on it. But in brief, here’s what I did, and what you can do too.
You’ll have to be the judge of whether it makes sense for you to try to do your own ePub conversions. Depending on how complex your books are, and how good you are at techie stuff, learning how to do this properly is going to take time and energy. Should you work on your writing or marketing instead? Maybe. Having said that, the promise of an ePub export that’s as easy as creating a PDF is pretty enticing. That’s the origin of this story.
Step by Step to the iBookstore (sort of)
I grabbed the first part of a manuscript I’m editing for publication. It’s a lecture from the 1980s and it seemed perfect for ePub because it’s got virtually no formatting, just paragraphs. I might have spruced it up a bit, but I was more interested in whether this super easy ePub conversion could really be as simple as it looked on the demo.
 
I wanted a Report Cover look to go with the text, since the document was only about 10,000 words, and I wanted to see how the iBooks software would render this style of cover instead of a book cover. I created one in Photoshop and saved it as a JPG file. Here’s what happened next:
  1. I dropped the text file into Storyist and applied some basic formatting with the Styles dialog. It was easy to edit these styles for a better appearance. Every paragraph has to be styled for best results, so the easiest way is to assign everything the “Body Text” format, then just change the headings as needed.
     
  2. Then I dropped the cover file into Storyist.
     
  3. After choosing “File/Export” from the menu, I was presented with a series of dialogs which are explained briefly in the demo video and more fully in the Storyist documentation, but there was nothing difficult. You choose your files, make sure they’re in the right order, complete publication information, and add metadata to your file.
    I was struck with the complete list of choices you have for assigning metadata. (Checking the documentation, it turns out the metadata fields correspond to the fields specified by the Dublin Core Metadata initiative. Controlling this metadata is critical to self-publishers in the digital space, and bears more discussion than I have room for here.)

     

    storyist epub metadata self-publishing

    Click to see the metadata record filled in
     

  4. Storyist wrote the book files in ePub format to my drive.
     
  5. I dropped the ePub file into iTunes and plugged in my iPad. iTunes, recognizing the ePub format as that used by iBookstore, automatically loaded my brand new eBook into the iBooks Library, ready for reading, as you can see in the screenshot at the top of this article.
iTunes metadata self-publishing

Click to see the metadata in iTunes

Not including the time it took me to work out the Storyist interface, stumble over technical obstacles I simply didn’t understand, email back and forth with Steve Shepard to get help for my newbie questions, create the cover file in Photoshop, this whole process was incredibly fast, well under an hour.

Of course, with all those things, I’ve been working on this about three weeks.

Self-Publishing In the Age of Instant Gratification
Granted, in my process my “book” only ended up in my iBooks library. But this is the file format you need to submit your book to the iBookstore, or to an aggregator for listing on your behalf. It’s the same file type used by Sony Reader, B&N Nook, and other eBook readers. I opened the file without a problem in Calibre as well.
 
What I was struck by at the end of this experiment was the speed with which you can put a book together and publish it in eBook form. I could sit at my Mac right now and start typing, and when I finished I could have the resulting book, along with a graphic cover, online and potentially available within an hour.
 
I was amazed at the speed, flexibility and ability to radically reduce the financial risk of publishing you gain from using digital printing and print on demand distribution. But this was a different order of magnitude. This was the closest I had come to feeling like I was Being the Media, publishing a product—not a blog post or a story—so directly and immediately.
 
I’d like to say what the implications of this are, but I’m curious about you. What do you think of this ability to quickly and easily “publish” right from your desktop? Will it affect you?
 
Ed. note: Cheryl Anne Gardner points out in the comments that I failed to mention whether the ePub files that I created in Storyist were epubcheck compliant. I created two ePub files when I was preparing this article, and ran them both through the epubcheck software. One passed inspection and one did not. Walt Shiel tells me that this error refers to duplicate entries in one of the ePub files. I have no idea how Storyist would handle more complex formatting, or what percentage of files it produces are epubcheck compliant. To be accepted into the iBookstore, your files will have to pass this same compliance test. I would encourage anyone who wants to make use of this tool for ePub formatting to download the free sample and try it and, if you have problems see whether they can be resolved by Storyist support.
 
Ed. note number 2: I received a note from Steve Shepard about what likely caused the error on my ePub file that wouldn’t verify. It was a simple fix and turned out to be something I simply forgot when making the file. After correcting it—putting the cover in the proper order in the file list—the resulting ePub passed epubcheck 1.0.5 with no errors. Your mileage may vary.

 

This is a reprint from Joel Friedlander’s The Book Designer.

Proofreading Your Own Work

In the previous post I mentioned various proofreading methods I considered for my short story collection, The Year of the Elm (TYOTE). While the objective in all cases was the same — eliminating nagging typos and errors — each method had different strengths and weaknesses.

Because I knew TYOTE would be read by almost no one, and would bring in almost no revenue, I decided to pursue the option that promised to teach me the most about the proofreading process, and about my own ability to spot mistakes. Against all advice, and despite knowing in advance that I could not be one hundred percent successful, I decided to proofread the final draft of the collection myself. (Full disclosure: one other person gave the stories a proofreading pass early in the process.)
 
Having written professionally in a number of mediums I know I have a decent eye. Not great, but good enough to catch a lot of common errors. Still, like every writer, I have my nemeses. For example, I am constantly transposing ‘from’ and ‘form’, and no spell checker can save me from that fate. Even when I consciously watch for that mistake, slowing my eye to a letter-by-letter crawl, I invariably miss an instance. (Case in point, when I originally wrote ‘from’ and ‘form’ above, I wrote it as ‘from’ and ‘from’ — and didn’t catch the mistake until re-reading the sentence for the umpteenth time.)
 
Too, it’s worth noting that much of my professional writing has been script work, both in the motion picture and interactive industries. While I certainly don’t want typos in my milestone drafts, a typo in a script feels like less of a crime simply because a script is a blueprint, not a finished work. When I really came to terms with the fact that I would be producing a finished product with my name on it, my level of concern (and vanity) about typos markedly increased. Where I previously felt that typos in a script were unprofessional, I suddenly felt as if typos in my short story collection would be a personal criticism of me.  
 
Given this heightened sense of responsibility, it probably seems incongruous that I decided to trust myself to find all the mistakes I’d made. I grant the point. The missing factor — beyond my desire to learn as much as I could about proofreading my own work — was my competitive desire to defy conventional wisdom. If I failed miserably, and I almost hoped I would, I would forever relieve myself of any obligation to track down mistakes on my own. On the other hand, if I succeeded, I might improve my craft as well as demonstrate the kind of attention to detail that authors and publishers look for in a freelance editor.
 
Step 1: Read and Repeat
The process I followed was pretty primitive: start at the beginning and read through the whole draft, fixing mistakes as I found them. When I was done I started in again, lather-rinse-repeat style. My goal was a full pass which revealed no new errors, although I knew that would hardly be a guarantee of success. Rather, it would simply signal the point at which I had become blind to my own work despite all efforts to the contrary.
 
How many times did I go through the whole book? I can’t tell you. It was easily four times (and here I mean four times during the final proofreading process), and probably six or seven. While that may seem like a lot (or not), what amazed me most is that I kept learning new things about the collection. Sometimes I found a subtle error between different stories (something an editor of almost any pay grade might miss), while other times I suddenly discovered obvious, in-your-face mistakes that made me wonder if I could proofread my own name.
 
What did I learn along the way? One thing I continually demonstrated to myself was that rewriting even a single sentence during the proofing process almost necessarily introduced new mistakes — either in the newly-written text, or when taken in context with the rest of the work. Because I kept finding sentences I wanted to tweak I made sure I revisited the changed text multiple times, over and above each full proofreading pass. (All word processors include highlighting, underlining or other marking functions that allow an author to easily identify changed sections of text, to say nothing of more complex revision/editing features which track changes in real time. If you make any revisions during the proofreading process, mark that text for review the next day. You’ll be amazed at how many mistakes you find.)
 
Step 2: Learn As You Go
The most useful thing I learned while proofreading TYOTE was to keep track of discovered mistakes, consistency concerns and usage issues in a separate list. As the final step in the proofreading process I worked through the list, item by item, using the ‘find’ function in my word processor to locate as many instances of the (potential) problem as possible. For example, once I realized that I had written ‘Mom’ as ‘mom’ in several places, I wrote ‘Mom/mom’ down to remind me to check all uses of the word for appropriate capitalization.
 
For TYOTE, here’s the list I ended up with:
  • Mom/mom
  • any more = 2 words
  • ‘em only in dialogue
  • start/ed/ing
  • very
  • really
  • just
  • too – no rule/see blog post
  • even
  • it’s/its
  • possessives
Many of these are obvious and would apply to any work. Because TYOTE was written from the point of view of a child, however, usage that might be improper for an older or more educated character was proper, but still required judgment on a case-by-case basis. The words ‘very’, ‘just’ and ‘really’ were checked not only for usage in each sentence, but relative to the overall work. The goal was to allow the main character to talk the way kids talk without turning the work into a colloquial swamp. Checking the use of such words in a dedicated pass allowed me to make those judgments in a way that would have otherwise been impossible.
 
The Stopping Point(s)
The best part about this two-step process is that it simply runs its course. You read and re-read the text until you can’t find any more mistakes. Along the way, you compile a list of words/issues to check across the breadth of the entire text. When you can’t find any more mistakes in your read-throughs you turn to the list, and when you’re done with the list you’re done.
 
Again, the fact that I ran out of things to find doesn’t mean there aren’t fifty (or five hundred) obvious mistakes in The Year of the Elm. It simply means I will never be the one who spots them. Having said that, the fact that I kept drilling down and finding more issues actually made me fell like I did a decent job. Had I made one pass, fixed some obvious errors, then found nothing to fix on my second pass, I would have had little confidence in the outcome.
 
In that sense I think any author can use this two-step process both to improve their proofreading skills and to gauge their own ability to proofread content. If you find almost nothing that needs fixing, chances are that your eye may simply not be up to the task. On the other hand, if you keep finding mistakes, and your knowledge of the work grows as you comb through the copy, the odds are that you’ll do a fairly good job of cleaning up the text. (Or at least a better job than you might have otherwise.)
 
For me, the best and most surprising thing about this process was that my authorial knowledge of TYOTE continued to grow even after I thought the creative process had effectively concluded. Not only didn’t I expect that, but having seen the benefits firsthand I can’t imagine not following the same process with subsequent works — even as I will certainly involve others in the proofreading process. (Again, my goal with TYOTE was to learn as much as I could about proofreading, and about myself in that role. In that respect the process I followed paid incredible dividends, and improved the collection in ways I could not have replicated using other approaches.)
 
Results So Far
The punchline is that no one has pointed out a typo or other mistake in TYOTE. While it’s tempting to believe that I really did perform some sort of miracle edit, the truth is more banal.
 
First, the number of readers is but a handful, so I can’t lay claim to any sort of crowd-sourcing or broad-based sample. Second — and I know this from having written online for years — readers almost never report mistakes. And why should they? Not only isn’t it their job to spend time fixing things I should have gotten right in the first place, but it’s a risky thing to do emotionally. Will the author be thankful, indignant, or simply ignore the message? I tend to think most writers are appreciative when notified of a mistake, but I’m sure there are irascible exceptions.
 
The final takeaway from this process, for me, is that editing your own work may or may not be viable, but in order to know – to have some measure of certainty that you’re not simply deluding yourself — you’re inevitably going to have to run your work by others. They may not find anything either, but that’s the only way to know for sure whether your text is clean.
 
I’m now convinced that my job is to give my text to others only when I’m sure it’s as clean as it can possibly be. It’s not my job to let others find and fix my mistakes because some of the changes I made to TYOTE during the proofing process could not have been conceived of by anyone else. My job is to work on the text exhaustively, until I literally have nothing left to give.
 
And then get help.

 

This is a reprint from Mark Barrett‘s Ditchwalk.