HOT STATUS REPORT

Earlier this week I gave away my techno thriller (HOT STATUS) for two days. I can now report the results:

Seventy-one downloads, mostly from Amazon.com (61), but also from UK, DE, and Japan (7, 2, 1).

Last time, in three days, I had 70 downloads. Last time, the vast majority came on the first day, with just a handful on the other two. I wondered if it was some sort of weekend pattern.

This time, giving the book away in the middle of the week, over 89% of the hits came on the first day.

Conclusion: Do your giveaways one day at a time to maximize the number of responses. I know, it's a lot more work to schedule the giveaway and submit time after time to the book promotion sites, but you'll get more hits this way.

Last time I wondered if giving away HOT STATUS would result in sales of the sequel (MAD MINUTE). It did not.

But back then, the sequel was on sale at $2.99.

This time I lowered the price on the sequel to 99 cents.

I had four downloads.

My next experiment is to give MAD MINUTE away and see if I can generate sales for the prequel—at 99 cents.

Should work.

In the meantime, I got my first review for HOT STATUS. (First review for any of my books, really.) It came in just a few days before the freebie period. It wasn't mentioned on the promo sites, but maybe some folks went to Amazon and saw it—and it had some beneficial effect.

Maybe if I give away enough copies of MAD MINUTE I can get a review for that guy, too. I hope so.

Not only is it hard to sell books that have no reviews, most of the promo sites won't even list your book when it goes free if it doesn't have a load of reviews. And mostly five-star reviews, at that.

Last time I submitted my book to fifteen sites, and five published the promotion.

This time, I only submitted to the five that published the first time—three of them went for it the second time.

Generally, they want you to rest your book for a month before going again. I was right on the bubble, timing wise. I don't know if that was a factor or not.

More stuff coming up: Stay tuned.

HOT STATUS FREE - AGAIN

The experiment continues...

Last month I mentioned in my report on the three-day period HOT STATUS went free that I needed to try again, this time during the week.

The first time—Friday, Saturday, Sunday—about two-thirds of the downloads occurred on Friday. I wondered if the tapering off was the result of a week-end pattern.

This Tuesday and Wednesday (23rd and 24th) the book will again be available for free download on Amazon. You can click the image of the book cover on the left-hand sidebar of the blog page. Make sure it says it's free before downloading it.

I submitted the book to the same five places that responded last time, plus I looked again into the one place that said the book needed to be free on Tuesday. But that site doesn't seem to be accepting new books at this time.

I'll let you know how it all turns out.

FINAL SLASH

When I first started messing with Kindle books I inserted images with this format:

    <img src="name.jpg" width=500 height=750>
 
Later, as I tried to get closer to the ePub syntax, I added:

    alt="subject of photo"

after the sizing specs.

Finally, I added the final slash before the end angle bracket.

In XHTML, which is used by ePub, so-called empty or void tags have to be closed. So I started using slashes like this:

    <a name="chap_1"/> for anchors

    <br/> for break tags

    <hr/> for horizontal rules
 
Now my image insertions looked like this:

    <img src="name.jpg" width=500 height=750 alt="subject of photo"/>

And I fell right into a problem I hadn't seen before.

In my novel MAD MINUTE I had ganged up three images for my chapter starts: a small image of a Nike Hercules missile and images of digits to form the chapter number.

Put one image right after the other inside one paragraph, they run side by side horizontally. You just have to make sure the combined width specs come in well under the width of a Kindle Classic (around 600 pixels).

And it worked, not just in Classic and DX and iOS apps, but in Fire and Paperwhite, too.

Until I added the final slash.

Before I go on with this saga, I need to back up a moment.

Not long ago I read a blog by an ebook formatter who was using a width spec of 98%. This way, images that go almost full screen in Kindle Classic (around 600 px) will not be shrunk to a tiny little thing covering less than half the width of a Kindle Fire HD 8.9". That boy's got a lot more pixels to fill up.

It made sense. I could size all my "full-page" at 98%, insuring that every app got the full-size image, across the board.

But when I tested it, I found Kindle Classic (and others) didn't know how to handle percentage specs for width. When in doubt, mobi-code apps force the image to go full size—the actual, GIMP-created size of the file.

Okay, I could live with that. It just meant that every title page or chapter-start image I generated in GIMP would need to have an actual size equal to the full width of a Kindle Classic page.

Set the width at 98%, and the other guys (Fire and Paperwhite) would benefit from going from one margin to the other (well, almost).

I had tried to revise my multiple image chapter start by using percentages: 10% for each image.

But as I said before, Kindle Classic balked at the percentage spec—the images all went full size.

So I went back to sizing the images in pixels.

But now even THAT wouldn't work: The images still went full size.

But wait, it USED to work, right? In my earlier version of MAD MINUTE it worked! Didn't it?

I checked the old file, just to be sure, using Kindle Previewer: And yes, it worked!

Why wasn't it working in my newest book?

You probably already guessed the answer, but it took me a while to compare the files and realize that the ending slash before the last bracket was ruining everything.

So I went on with my life. I worked AROUND the problem, resizing all my images in GIMP so they would work full size.

There was no problem with images designed to go full page—I'd already fixed that deal. It was when I created images of individual letters (as super-big capitals for the first words of chapters) that I got into more trouble. Some of these smaller images were right at the edge of pixelation.

I found I needed to select extra wide fonts, like Rockwell Ultra-bold and Broadway and Goudy Bold, or the images of individual letters looked too ragged.

I thought I was going to have to live with this annoyance.

Then I remembered something from my research into the origin of the final slash in XHTML. Older browsers went nuts when they ran into that thing. The solution, add a space before the slash.

I'd seen that space before, when I went hunting for working versions of the OPF file. End tags had slashes, and some of those slashes had spaces in front of them. But not all of them. It looked chaotic. I wondered how you decided when to use the space and when not to. Did it really make any difference.

One thing I noticed, Kindle didn't seem to care if there was a space there or not. I removed them all. And had no problems.

Now I wonder.

When I checked some test code at an HTML validator site, I got no argument when I put one or more spaces in front of the final slash. (But leave out the SLASH, you'll get a good talking to.)

I went back to my Kindle image tags and inserted a space before the final slash.

Bingo! It was like the end slash wasn't even there!

(Actually, there were some minor items: In Paperwhite, using the slash without the space made the images slightly smaller; in iPad, the images were taller [but not wider] with just the slash in place; only Fire seemed the same for all—slash, no slash, slash with space in front.)

Now I could go back to sizing in pixels in Kindle Classic. That was nice, but it didn't solve the other problem. With or without a space before the slash—or without the slash itself—Kindle Classic reverted to full-size images when the width was given in percentage.

And without using width=98%, how could I get my images to spread out full width on the HD models?

I thought the solution might come from my dalliance with drop caps.

Drop caps only work in Fire and Paperwhite (kf8), so if you want to use them there, you have to make arrangements for the older versions (mobi code guys like Classic, DX, and iOS). I thought the answer for the full-page image problem would be to split the code, giving different instructions to the kf8 apps and the mobi apps.

Turns out splitting the code wasn't necessary. You do need new code, though, a new image class, in fact, but it doesn't have to hide behind a kf8-only screen. Add this code to your style section:

   img.wide
    {width:98%;}

Now some of my image insertion codes look like this:

    <img class="wide" src="name.jpg" width=500 height=750 alt="subject of photo" />
 
Be aware there is some rather mysterious interaction between the kf8 percentage spec and the pixel specs in the tag. If the spec in pixels creates a bigger image than the percentage, kf8 apps go with the pixel specs, even if the image gets all disproportionate. You'll have to test these guys in actual use, in Previewer at least.

Recently, I actually had a chance to use this information.

I just put up a revised mobi of HOT STATUS. I set my full-width spec to 98%, but there were problems. In my Photo Gallery of full page images I had five or six that refused to show up in iPad. I needed to be able to lower the size specs of those images to get them to work.

After I put the new code in place (and added the space in front of the final slash), I could do just that without having to go back into GIMP and actually change the size of those images—which, if I had done so, would have affected all the other apps.

This new code also led to a fix for the use of large letter images at the start of new chapter paragraphs. What I wanted was a bigger actual image resized by code to a smaller one. To work the compromise between Kindle Classic font size one to font size six, you need a letter (boxed or not) around 30 or 32 pixels square.

Here's the new code:

    img.letter
   {width:12%;
   font-weight:bold;}

Now the code for a chapter start paragraph might look like this:

   <p class="start"><img class="letter" src="rockwell ultrabold T.gif" width=32 height=32 alt="rockwell T" /><b>his particular morning</b>, ten-year-old...
 
You can also add a float:left spec and use this technique for "drop" image letters:

   img.drop
   {float:left;
   width:12%;
   margin:10px 8px 0px 0px;}
   
Crank up your Kindle Previewer and get to work messing with this stuff.

Or don't: You COULD just stick with "font-size:large" or "font-size:x-large" for your big capitals and be done with it. Or set everybody to 2 em. At least the capital letter will size up and down with the font.

Remember: Images of letters never change size, though a shifting font size makes it look like the image is jumping up and down. If we could just figure out how to keep readers from messing with the font size...

One brave strategy (or do I mean reckless?) might be to pick a font size and stick with that. When you check out a book that just went up on Kindle, the online Previewer is set to Fire at font size 3. You could put your entire attention on that font, make it look perfect, then take a quick peek at the rest to be sure it doesn't look TOO outlandish at smaller and larger fonts.

Boy, would THAT be a relief!

Update: Part of what I said above was right, and part was wrong. I still think you should put the final slash in, and putting a space in front of it won't hurt anything. But my reasoning was wrong; it had nothing to do with older browsers learning to live with the final slash.

In fact, the first image insertion tag I displayed above, the one ending with the sizing in pixels, WOULD fail if I put a slash at the end (without a space to protect it). But the revised tag, using the alt image title at the end, would also work just fine with a slash at the end (with no space in front of it).

Turns out the problem was putting a slash right behind the pixel spec. It apparently contaminated the spec and made it invalid. Kindle Classic and DX need both specs to size properly, so they went full size. Kindle Fire (and also the iOS apps) only need one spec to size an image, so they were unaffected when the slash turned the final spec to junk.

Also a fix: put the pixel specs in quotes. Anything to keep that evil slash from rubbing up against the raw numbers. (It's also needed for ePub.)

And I now make some other changes:

     <a name="chap_1"/> for anchors -- becomes: <div id="chap_1"></div>

    <br/> for break tags -- becomes: <br />

    <hr/> for horizontal rules -- becomes: <hr />

All to make the book ready for ePub. More about that later.

AN EXPERIMENT WITH "DROP" IMAGES

We've seen the work of drop caps. It's also possible to treat IMAGES of letters like font-based letters. Sort of.

But only in Kindle Fire or Paperwhite.

One easy way is to create some image style code and put it in the style section at the top of your book's HTML. Like this:

   img.drop
   {float:left;
   margin:10px 8px 0px 0px;}

Then, when you want to apply it, call the "class" just inside the <img> tag. Like this:

   <img class="drop" src="rockwell ultrabold T.gif" width=12%/><b>his particular morning</b>, ten-year-old [etc.]

I've also added the so-called "illuminated" letter to the mix. In the following screen shots of Kindle Previewer, the width spec for the first illuminated T is 80 pixels. The second one is set for 20%.

Here's Kindle Fire at font size 1:



The images are floating, all right, but at this font size there's been no convincing tuck-in of the text—not enough words.

Okay, so let's go to font size 3:



Now we've got some tucking in. In all examples, the image is surrounded by text. It's starting to look real. And if the paragraph had been longer, the first view would have worked, also.

Now, font size 7:

Looking even better. That letter is buried at the beginning of the paragraph.

But look at what happens in 8:

The Rockwell Ultra-bold T has been dropped all right, dropped in status to a somewhat regular letter. Is a one-line drop even a drop anymore?

Well, we've seen this before. When you’re dealing with the images of letters, there's no difference in size from one font choice to another. The relative size of the letter shrinks or balloons as the selected font rises or falls.

Now here's iPad at font size 5:

You can pretty much always count on iOS to level out the drama. As a mobi-code app, the letters will never "drop"—iOS, as well as Kindle Classic and DX, can't understand the "float" command.

Here's Kindle Classic 1:

Since each image was sized in percent (which mobi can't handle), they all defaulted to the actual size of the image.

Now, Classic at size 6:

Again, full size images. No real difference from raised caps created by images.

Finally, Paperwhite at font size 6:

Very similar to Fire at 7. I think the 80 by 80 pixel version (first illuminated T) looks the most natural.

But look what happens at font size 1:

 
 
In the third line (image width=20%), the boxed-up letter T is so large it encroaches on the remaining letters of the word "the." No doubt some experimentation with sizing would deal with this sort of thing.

But the fact is, images of letters are fixed in size. Using true drop caps—which manipulates actual font—allows the initial cap to size up and down with the font selected.

On the other hand, image-based drop caps look a lot more dramatic in mobi-code versions of Kindle than plain old 2 em caps in the standard, default font. And no need to split the code between kf8 and mobi.

More compromise and decisions . . .

And speaking of more decisions, one can also put a border around the drop image.

Here's Fire size 3 with a double red border at a width of 8 pixels:

Now Fire at font size 7; ridge type border, 12 pixels wide, in yellow:

And finally, Fire at 5; inset border, 12 pixels wide, in orange:

There are other border styles: dotted, dashed, solid, groove, outset. Check out the w3schools tutorial on css to find out more.

The complete code for the yellow ridge drop image:

   img.drop
   {float:left;
   border:12px ridge yellow;
   margin:10px 8px 0px 0px;}

Margin specs go: top right bottom left.

As for when it makes sense to use drop images, see my discussion of the use of drop caps in a previous post. Drop caps of either variety are pretty fancy fare for most books.

Still, I like the "illuminated" letter, especially with the ridge border. It looks great in the dropped position, and pretty special in mobi, too (though, sadly, sans border).

I'm sure I could whip up a more interesting version than the one I've been testing here—and put my own dang border around it, too. I just need to write something that cries out for the use of the little darlings.