Software, StoryBox

Making Epub and Mobi files with StoryBox

1 Comment

What? What? Really?

Yes. Here’s the rough and tumble guide to turning your StoryBox project into epub and mobi files. First, you have to have StoryBox installed, and you have to have your novel or short story written or imported into it. If you’ve never used StoryBox before, read the help sections on importing, and you should be able to get your project into StoryBox pretty quickly.

Once your story or novel is ready to go, you need to add the cover.

First, you’ll want to make sure you have your cover image in a proper format. Using MS paint, or other image editing tool, create a cover, then save it as a “jpg” image. You should size the image so that it’s not terribly large. I like 500×750 pixels, but if you find someone recommending a different size, use that if you wish. You just need to make sure it’s sized appropriately before you import it into StoryBox.

Next, Right click on the story node in the File Drawer and select “New Picture”. You can actually put the picture anywhere in the tree you want, I just like them as children of the story. Find the cover image you saved, and click Open. Once it’s done importing, you want to click on the image document in the File Drawer to open it, and then click the “Cover” checkbox in the Properties panel.

If you wish to use a picture as a scene separator, you can import another picture (I recommend using a png since they can have transparent parts) just like you did the cover, then click the “Scene Separator” box in the Properties panel.

Now, select Export from the Project menu. A small Export dialog will appear. Select “EPUB” from the File Format dropdown. If you want to use the picture for the scene separator, you will need to select “[picture]” from the Scene Separator dropdown. Click Export, choose where you want to save the file, give it a name and click save, and you’re done with the epub export.

To make a mobi file, download Calibre, a free e-book converter. Start it up, drag the epub file into it, right click on the file and select Convert Books->Convert Individually. A dialog opens up with a bunch of options. In the upper right corner, there’s a dropdown labeled Output format. Select MOBI from it. Click OK, and it starts converting. When it’s done, right click the book in the list again, and select “Open Containing Folder”, and it will take you right to where the .mobi file is. You’re done. In my tests, the conversion is pretty dang good and worked on my wife’s Kindle flawlessly.

Here are a couple tricks. If you want bold chapter titles, go into each chapter document, select the text (which defaults to “Chapter [chnum]”) and make it bold by hitting Ctrl-B.

The Table of Contents names are derived from the names of the documents in the File Drawer. Make sure these are how you want them. You can make the chapter titles in the actual document match the Table of Contents by using “[doctitle]” in the text in place of “Chapter [chnum]”.

If the paragraph indent is too large, this can be adjusted by changing the over-all paragraph indent in Preferences-Format tab. Paragraph and line spacing is ignored because on some readers, they don’t handle paragraph spacing well.

If you need to add some extra line breaks, you can put [br] where you need them. Places where you might want to do this are on the copyright page or an acknowledgements page. (Edit: I’ve changed the tag. Using html tags no longer works at all for a couple important reasons, one of which is to allow you to use > and < in your text).

If you need different license pages for different distributors, remember that you can use the “Include In Manuscript” checkbox on the Properties for each document to specify which documents to include in the export.

My goal for epub generation is NOT flexibility in format. My goal is having it be quick and simple to generate a professional looking epub file. Let me know if you think of an easier way to do something.

Software, StoryBox

StoryBox 1.3.101 Released

This release fixes a crashing bug with the outline view when scrolling.

When I released the last version, the component vendor that provides many of the controls I use (including the grid used in the outline view) had released an update that fixed some minor issues and promised performance improvements. So, I updated StoryBox with that updated version.

Unfortunately, they introduced a bug in the new version that created the unhandled exception message that people were seeing when I tried to restore the expansion state of the outline.

So, in this version, I’ve rolled back to the previous version of the components. They say there will be a fix for it in mid March, at which point, I’ll update StoryBox to use the new version. That new version should have a fix for another major issue, as well.

What’s really annoying is that figuring out what was causing this problem basically caused me to lose two days of writing time.

Download the latest build

Success, Writing

New Plan Day 1

3 Comments

Today was the first day of a new plan for my day. I’ve been fighting for a while with my daily schedule. I like to read blogs and other interesting things about the publishing industry. I have a day job to do, and kids to watch, well, by the end of the day when I was trying to write, I’d be tired and worn out. It had to struggle each day to get to the writing desk. I’ve managed it, but sometimes with only an hour or so to write. It also made my wife a bit unhappy because she often wouldn’t see me in the evening. She went along with it because the plan is for the writing to replace the day job at some point, but it’s not something she really embraced.

So, the new plan is that I go to bed at 10pm (instead of midnight) and I wake up at 5am to write before switching over to the day job stuff. This gives me at least two solid hours of writing time without the distractions of the day getting in the way. It also leaves the evenings free for whatever we want to do.

And it worked wonderfully today. I wrote 2000 words in about two and a half hours. Now the rest of the day is free to use as I need to without the worry of whether I’m going to get to the tasks of highest importance, at least as far as my career is concerned. My wife and kids would argue that they’re more important, and I’d have a hard time disputing that. But now, I get to spend time with them, too, without the writing hanging over my head.

Writing

Getting Writing Done

6 Comments

I’ve been a software developer for years. I know the process, I know the beginnings, middles, and ends of software projects, and I know this: “when it’s done” is not a good recipe for making money in the software industry.

I believe the same adage applies to writing. The “when it’s done” philosophy just doesn’t work. There are countless stories of young writers working on their book for years, tinkering with it until it’s “perfect”. I always wonder what they could have accomplished if, instead, they’d stopped tinkering and started another book.

The software companies I’ve worked for that prosper all do one thing. They have schedules, and they stick to them. They estimate how long a project will take them, and they decide on milestone dates that allow them to build the project they want to build. They have a process that they follow.

I think those same ideas can be applied to writing books. There will be differences if you self-publish vs going the traditional route, but those differences are only in the implementation. The key is still to come up with a process and to stick to it.

When developing a process, think about the all the steps that need to get done before the project is complete. Yours may end up being different than mine, but here’s the essential process I’ve worked out for me.

  1. Write the first draft.
  2. Sit on it for a month
  3. Read it carefully and make sure everything I wanted to say is there
  4. Fix any issues I discovered while reading
  5. Send it to a couple readers
  6. Fix any errors they find
  7. Send it (or publish it)

You may notice that I don’t count outlining and other project development in the process. That stuff is generally done before I count the project as “started”. It’s difficult to set up a deadline if you don’t know all the work involved, and those things are key elements of determining the amount of work involved. (Note: You should try setting a deadline for your development work, too, especially the outlining part if you outline. Otherwise, the development work can turn into a never ending project on it’s own.)

Another person’s process might look like this:

  1. Write the first draft
  2. Have a reader read it
  3. Fix the errors
  4. Send it (or publish it)

Another writer might specify several rounds of revisions and drafts. It really doesn’t matter.

Now that you have your process spelled out, assign workable deadlines to each part. Only you know what your schedule is like, so I can’t do it for you, but here is a general approach.

For the first part, you need to determine how fast you write, if you don’t already know. Spend a couple days writing a short story. See how many words per hour you write. Some people write 750 words an hour, others write 1500, others write 250. It doesn’t matter, you just need to know.

You probably have a rough idea how long your project will be, or should be, or what you want it to be. The more you write, the better you’ll become at knowing the length before you start, within a certain percentage. Take that number and divide it by your word per hour rate. For illustration, we’ll use 90,000 words (a typical novel length) and 750 words per hour. It comes out to 120 hours of writing. Add fifty percent to the number, which brings us to 180 hours. That’s the number of hours to use for determining how long you should schedule for your first draft.

Why did I add fifty percent? Basically, crap happens. You get sick, your dog dies, your computer takes a dump. You have to give yourself room to maneuver. In the software industry, the general rule of thumb is to double your initial estimate. There are always unknowns. Give yourself the time to deal with them.

Alternatively, if you write on a regular basis, and you know your typical output per day, say, 1000 words each day you spend writing, you can divide the project word count by that number, and that’s how many actual days you’d have to spend writing. If you don’t write on weekends, of course, you adjust for those. And don’t forget to add fifty percent. Using the example from above, you would schedule 135 writing days.

Now that you know how many hours you need to spend on the draft, figure out how many hours a day you can work on it, and which days you can work on it, and do the math. Figure out where that end date is. Mark it on your calendar. Commit to finishing the draft by that date.

For reader steps, allow them time to read it, especially if they’re doing it for free, but specify a time frame. A month should generally be long enough, though sometimes it isn’t. It’s better to estimate long here, and tell your reader a shorter time that you’d like to have it finished. If they haven’t finished by the end of the time you gave, you have to figure out what you want to do. Either push your other deadlines out, or find a new reader, or both.

For doing revisions, my current policy, because I haven’t done many of them, is to give myself a quarter of the hours that I allocated to my original draft. I’m only fixing things. Again, figure out how many hours you have in your day to do the work, and mark the end date on the calendar. Do not allow yourself to tinker endlessly beyond the end date. Once you hit the deadline, call it done.

All this will add up to a “ship date”. A date on your calendar that you will call it done and just ship it out, either to publishers, agents, or all the ebook distributors.

The key is to be ruthless with those dates. Hitting dates is the difference between a book that gets done, and one that never sees the light of day. Reward yourself for hitting the dates. Give yourself bonuses for completing them early.

When you miss a date, you should immediately write up a small document that examines what went wrong. Did you underestimate the time required for that step? Did you underestimate the size of the project? Were your estimates of time available incorrect? Why did the estimation errors occur?

I’d like to tell you that it’s fine to miss a date here and there, but it’s not. Not if you want to be productive. Not if you want to publish, and publish a lot. Missing dates can become a habit, and it’s a habit that can set you back months or years from achieving your goals.

I know, many of you may be reading this and thinking, “What the hell? I’m an artist! I can’t be constrained by deadlines!” If you’re one of these people, and you’re still reading, I thank you for not giving up on me yet. The process I’m suggesting is completely customizable by you, the artist. You set your own boundaries, whatever they may be. Setting boundaries is how a piece of work gets finished. If you want to give yourself three years to finish a book, by all means, give yourself three years. If working on your book is just a hobby that gives you pleasure, then don’t listen to me.

A schedule is a tool for getting stuff done, nothing more. I have a lot of books I want to write, and I’m sure, by the time I’m done writing them, I’ll have a lot more. I don’t want one of those books to eat up the rest of them, and this is how I’m keeping that from happening.

Shattered, StoryBox, Writing

Status and Stuff

2 Comments

So, here’s the Friday status update. What? You’ve never seen this before? Go back and look! OH, wait, stop… It’s new. I guess I’ve never done one of these before.

Shattered is in sort of a limbo while I wait on a couple more readers. Once the feedback from them is in, I’ll be taking most of my weekends getting the second revision and edits done, which I expect will take a month. Then it’ll be publish time, and you can finally read it.

SotR has a deadline for the first draft of March 25th. I’m making good progress on it (if you followed my tweets @mark_fassett, you’d get daily updates), and I don’t foresee any huge problems making the date.

I hope to have an update to StoryBox this weekend, too. It won’t have any big major feature changes, but it should have some minor usability improvements. I’m still thinking about how I want to work covers and other e-book property info into the UI. I’ve got three places in mind as to where it could go, and I’m not completely happy with any of them. But, I have to get it figured out before Shattered get’s published.