Posts Tagged ‘E-Books’

The Forgotten E-Book Reader: OLPC

Monday, December 26th, 2011

With the plethora of e-book reader devices available these days, it’s easy to overlook perhaps one of the better choices for mobile e-reading: the OLPC.

While it’s a bit heavier than most tablets (but still relatively light at just over 3 pounds), and lacks the “instant-on” feature of other devices (the OLPC is technically a netbook computer, so it needs time to boot), the built-in Read Activity (app) supports several types of file formats, including text, tiff, djvu, pdf, and epub.

At 6 inches x 4.5 inches, the OLPC’s color screen is bigger than most dedicated e-book readers, and almost as large as the iPad. The screen folds flat, which hides the keyboard and makes reading easier, and the screen also remains easy to read, even in sunlight.

So why isn’t it more popular as an e-book reader?

One problem is that it’s not clear how to add new content for the Read app to find.

By default, the Read app can open e-book files in the Journal, but the documentation doesn’t fully explain how to copy new files into the Journal.

In theory, you can drag-and-drop files from a mounted usb stick or external drive, but I found the graphical environment choppy and unreliable.

Fortunately, there’s a built-in Terminal script called copy-to-journal created just for this purpose.

Here’s an example of how to copy a pdf file from a memory stick to the Journal:

copy-to-journal "/media/my-usb-stick/My Book.pdf" -m application/pdf -t "My Book"

The first parameter is the full path to the file (wrapping in quotes is good practice, since it will work for files with spaces in their names and without), the second parameter (-m) specifies the mimetype, and the third parameter (-t) defines the title of the book as it appears in the Journal (it can be completely different from the filename).

Epub files work the same way, except the mimetype is different:

copy-to-journal "/media/my-usb-stick/My Book.epub" -m application/epub+zip -t "My Book"

The script can also attempt to guess the mimetype, using the -g switch instead of -m:

copy-to-journal "/media/my-usb-stick/My Book.epub" -g -t "My Book"

 

How Startup Products Evolve

Thursday, August 11th, 2011
[ Edit: Reading this back, it occurred to me that what I described could also be considered a pivot, which is very much en vogue among the lean startup crowd. Since, however, there is some confusion as to what pivoting really means, I'll stick with my evolution analogy. ]

Just over a year ago, I was working on a new marketplace for ebooks, mostly because independent authors were being under-served by Amazon and Apple’s iBookstore.

They still are, actually, but every author I came into contact with really, really wanted to see their work sold there.

As one author put it to me, “If it’s not in iTunes, it’s not real.”

So the site struggled to get content, and without that, it didn’t attract any readers, either.

Would you shop here?

Listening to Clients

The problem (in my mind, anyway) was that the site’s clients (i.e., the authors) were asking for something that didn’t fit into my preconceived notions of what the marketplace should be:

Can you get my book in Amazon?
Why did Apple reject my book?
Do you have connections to Amazon and iTunes?
Can you help me format my book?

Eventually, though, those messages did manage to reach into my brain, and I realized something important.

Brain shown actual size

People want to sell on Amazon and iTunes, but they don’t have the technical know-how to do it.

Both Amazon and iTunes require authors to submit epub files that pass validation.

Since, however, the people who wrote the epub spec insisted on going with a uncompromisingly strict approach, it created a situation where producing an epub file is easy, but getting it to validate was hard.

Mutation #1: eBookBurn.com

So while the original marketplace didn’t survive, it demonstrated a problem that needed a solution.

That led me to build a different type of site, one where authors could create valid ebooks without knowing how to program.

As I’ve written before, it’s not only popular with users, but also generates revenue.

Those Pesky Off-Topic Requests

But once again, I started getting a stream of suggestions that went against my neat worldview of what eBookBurn.com was supposed to be.

This time, it was a variation of “Can you help me sell my book?

Unlike before, though, I didn’t have a clear vision of how I could help, or even if I could (and it’s not a problem for just independent writers: mainstream authors and established publishing companies struggle with this as well).

One author who has solved this problem is Amanda Hocking.

She admits to being baffled about why she succeeds while other, similar authors fail, and suggests a combination of “good covers” with “similar [cheap] prices”.

But Amanda’s books stand out to me for a different reason: her books have hundreds of reviews on Amazon, in stark contrast to other ebook-only titles.

And she has a strong presence on both Twitter and Facebook.

So would it be possible to mobilize people to read, review, and tweet about a given book?

Does Harry Potter do this to you, too?

Mutation #2: BookHunch.com

Enter BookHunch.com, which I recently opened to a small set of beta users.

The basic premise is that authors and publishers submit new or pre-release books to a community of book lovers, who in turn read, review, and share their opinions.

Readers get points for participation, which determine their level of access.

Points mean privileges, including special access to content, and, eventually real-world rewards in the form of gift cards or donations to favorite charities.

And all reading is social: readers can invite their friends, with whom they can make and share notes about the book, right alongside the text.

It’s also possible just to read the book and ignore all the community aspects of the site, so even digital hermits are welcome.

On the other side, authors and publishers not only get social media exposure and explicit feedback, but also analytical reports of readers’ implicit behavior: how many pages people read, where they stopped reading, how long they took on a particular chapter, etc.

And implicit behavior is interesting, in that it probably has more to tell an author than all the written reviews and notes do.

As this notable study of netflix habits shows, people tend to claim that they want to watch highbrow films, but when it comes to choosing what to watch right now, they usually wind up with something less refined.

More likely to survive and reproduce?

The initial response for invite requests has been encouraging, and I’ve already gotten some useful suggestions.

Here’s a preview article on the Digital Reader blog.

 

Illustrated ebooks with epub: using the svg image element

Wednesday, June 15th, 2011

All things being equal, the epub format is preferable to pdf for reading on devices like the iPad, Nook, Sony, Kobo, and other dedicated e-readers.

But for some types of books (such as manga, comics, or graphic novels), epub doesn’t seem to be able to handle large images that should fill the screen.

Apple has gone so far as to create its own fixed layout format for such ebooks.

It is possible, though, to stick with epub and get perfect results for illustrated ebooks, using the forgotten (or perhaps simply overlooked) svg image element.

Here’s a peek under the hood of how we do it at eBookBurn.com, as part of our new illustrated ebook publishing feature.

This is an example of the markup to use in your epub’s xhtml files for each image:

<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="100%" height="100%" viewBox="0 0 592 900" preserveAspectRatio="xMidYMid meet">
<image width="592" height="900" xlink:href="images/page01.jpeg" />
</svg>

What this markup does is take a JPEG image sized 592 pixels wide by 900 pixels tall, and frame it in the center of a 592×900 svg element.

It turns out that 592×900 is the right size and aspect ratio for “standard-sized” six inch e-ink screens found on the regular Nook, and Sony Reader.

So why use svg at all?

Wouldn’t it be simpler to define it with the plain img tag (as this epub template does), like this?

<img src="images/page01.jpeg" width="592" height="900" alt="Page 1"/>

Unfortunately, many devices, such as the iPad and the Nook Color, have screens larger than six inches.

So on those devices, using the plain img tag in your epub’s xhtml files leaves an embarrassing whitespace gap, from where the image stops to where the actual screen ends.

The svg element shown earlier, though, is different: it stretches the image to fill the entire screen, while preserving the aspect ratio.

It’s also important to note that 592 width and 900 height specified within the svg and image elements should not be thought of as pixel sizes, since no units are defined, but as a width-to-height ratio.

So any image with the same aspect ratio as 592×900 will work well, regardless of its actual size. Scaling up to larger screens, though, also means the dpi count should be reasonably high, at least 72 dpi (and more for images whose base size is smaller than 592×900 pixels).

For most devices, that’s enough, but some e-readers insist on adding margins and other padding to each page, so it’s helpful to define this in the xhtml file’s head block:

<style type="text/css">
@page { margin: 0.000000pt; padding: 0.000000pt; }
</style>

And these css classes in the stylesheet:

.svg_outer {
display: block;
margin-bottom: 0;
margin-left: 0;
margin-right: 0;
margin-top: 0;
padding-bottom: 0;
padding-left: 0;
padding-right: 0;
padding-top: 0;
text-align: left;
}

.svg_inner {
display: block;
text-align: center;
}

So the final xhtml for each page image looks like this:

<div class="svg_outer">
<div class="svg_inner">
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="100%" height="100%" viewBox="0 0 592 900" preserveAspectRatio="xMidYMid meet">
<image width="592" height="900" xlink:href="images/page01.jpeg" />
</svg>
</div>
</div>

Just repeat that pattern for every image in book, for every chapter that contains full-page illustrations.


Update, May 1, 2012: Moriah Jovan has been kind enough to provide sample epub files created using this technique:


A Freemium Model That Works

Tuesday, May 10th, 2011
If you are creating ebooks for sale, check out BookHunch.com, a new approach to promoting books, regardless of whether you are selling your books on Amazon, iTunes, or elsewhere.

When I started eBookBurn.com, I was unsure of the pricing model, but I was definitely determined to charge money for it.

Ebook conversion “consultants”, part of a cottage industry that has developed recently, take an author’s source material, spend several days or weeks hacking it into an acceptable (or in some cases unacceptable) digital file, and charge several hundred dollars.

So in that context, I started with a time-based scheme: one day of using the editor cost $25, one week cost $150, and so on.

My reasoning was: if an author already had their source file ready, copying chapters into the editor and making minor edits would take no more than a few days, the resulting files would read well, and it would cost just a fraction of hiring a consultant.

Unfortunately, people have come to expect that web apps should be free or at least “freemium”, and so my pricing generated some complaints.

Since I got no traction, I tried keeping the basic concept, but lowering prices.

That improved things a little, as I started to see some paying users, but the ratio of people who started to sign up versus those who actually paid and continued was disappointing.

So I tried offering three days free to every new account, and that worked, at least in converting visitors to registered users.

I saw a big jump in my log activity, and several new ebooks were being generated by different authors every day.

However, as before, very few of those users actually paid to continue once the free period was over, and many simply re-registered with a different email address.

It was frustrating, since traffic was high, and based on the number of new registrants I was getting, I knew this service filled a need.

Start Over

I got some unexpected help from a sales rep from a “deal of the day” site (i.e., an AppSumo clone).

She was interested in it, but wanted to come up with something that she could package and sell on their site.

I got her to sign up, and walked her through the basics of creating an ebook, which she got right away.

After a while, she said, “Why don’t you let people sign up for free, let them use the editor as long as they want, but when it comes time to actually burn* the book, charge them a flat fee?”

Eureka!

*Unlike most people who asked about the name, she immediately understood that the “burn” in “eBookBurn” was analogous to “burning” a CD or DVD, without my having to explain it first

The Benefits of Paying Users

A few days after I announced the change in policy, the site had already generated more revenue than in the prior month.

Even better than the boost in revenue was the increased feedback.

When people pay for something and do not like the result, they complain (i.e., unlike people who try something for free and simply shrug when something goes wrong).

Those complaints led me to fix several issues that I hadn’t seen or anticipated before, and it made the service even better.

Perhaps best of all were some of the emails I got back from users when I solved them:

You guys are awesome.

Let me just say that you rock!

So, yeah, thanks. :)

That is a PERFECT way to deal with the problem.

Now I will add the remaining chapters and finish the book.

Great!

Thanks!

It’s amazing how a few emails like that can keep you going.

Simplifying eBook Creation

Thursday, January 6th, 2011
If you are creating ebooks for sale, check out BookHunch.com, a new approach to promoting books, regardless of whether you are selling your books on Amazon, iTunes, or elsewhere.

UPDATE, May 10, 2011:
The latest news about eBookBurn.com can be found here.


Last year, I presented a talk at BarCampNYC5 on "How to Create an eBook".

I spent most of the talk on ePub, and how to generate ePub files programmatically.

That audience was mostly developers or people otherwise technically-oriented, and while there were a decent amount of well-informed questions, it was clear that creating an ePub from scratch was a lot of work, with few good (read: simple) tools.

Even Adobe’s InDesign, which is used by most professionals, requires significant manual reworking.

Fast-forward to last month, when I released eBookBurn.com, an online eBook creator composed of Xinha on the frontend, fused with a more sophisticated version of the ePub generator described in the IBM tutorial.

I announced it on Hacker News, reddit, and MobileRead.

The initial response was terrific, and I even got an early review at the Digital Reader blog.

Over the past week, I got a chance to address common feedback with an update which I released today. Here were the major points:

  1. Pricing
  2. The first go-round on pricing was based on the idea that if you hire a consultant to prepare a specification-valid ePub (and validity is important, since you cannot sell in Apple’s iBookstore otherwise, for example), it will cost upwards of $500 per book. So, in that context, a create-all-the-books-you-want model for a given amount of time made sense.

    Many people felt that was too high for self-serve, though, and it was a good point: while I make an effort to answer support emails, there’s no guarantee that I’m able and willing to address every customization request.

    So the new pricing reflects that, and there’s also a three day initial period where use is free.

  3. Cover Image Sizing
  4. Until today, your book cover image had to be exactly 590 pixels wide by 750 pixels tall. Any variation got you rejected.

    Now, it’s more of a suggestion, since the new release simply scales your image to the right size automatically.

    This is important for a few reasons: it’s a better user experience, and the 590×750 size is based on current standards, which will change over time as device resolution improves, etc.

  5. Importing from existing docs
  6. In the first release, you had to type everything from scratch, or cut-and-paste from another document.

    While that option is still there, many people wanted to be able to upload a non-eBook format document, and have the conversion done automatically.

    PDF was by far the most requested, followed (weakly) by MS Word.

    Even though PDF is a notoriously difficult format to parse into text, I have been experimenting with using the PDFMiner API, so I thought to try it here, despite Yusuke Shinyama’s warning:

    PDF is evil. Although it is called a PDF “document”, it’s nothing like Word or HTML document. PDF is more like a graphic representation. PDF contents are just a bunch of instructions that tell how to place the stuff at each exact position on a display or paper. In most cases, it has no logical structure such as sentences or paragraphs and it cannot adapt itself when the paper size changes. PDFMiner attempts to reconstruct some of those structures by guessing from its positioning, but there’s nothing guaranteed to work. Ugly, I know.

    The results are decent (if I do say so myself), but a lot depends on what kinds of pdfs are uploaded: essays, whitepapers, and other mostly-text docs come out ok, with some editing needed. Brochures, slides, forms, and other works with more intricate visual formatting require much more editing.

    But in contrast to other conversion tools which simply take static jpeg or png snapshots of each page (I’m looking at you, calibre), the full text is parsed and returned as text, which means it can be edited.

    There’s still no support for uploading and converting MS Word documents, partially because of how few people asked for it (especially relative to PDF), but mostly because of the huge pain in the neck it is.

    In theory, importing from Word’s docx format should be trivial, since it’s xhtml under the hood, which is just what ePub requires, but Microsoft added a few surprises.

    One option is to ask people to save as filtered HTML first, before uploading, but it’s not the best solution, so I’ll be considering ways to address that.

    I’ve also noticed that cutting and pasting from Word docs, which is the only alternative in the meantime, introduces funky Microsoft-specific namespaces which break validation, so I need to come up with a solution for that as well.

Book Burning in the Age of E-Books

Tuesday, June 8th, 2010

Book Burning in the Age of E-Books

via xkcd.com

E-Book Readers: Opportunity Knocks

Friday, December 18th, 2009

Best observation I’ve read in a while:

So why do I feel uneasy? Because two companies who are in the business of pushing books have come up with nearly identical solutions [Amazon with the Kindle, Barnes and Noble with the Nook]… feels like the mp3 player market before Apple introduced the iPod… feels like the smart phone market before Apple introduced the iPhone. The companies who thought they were “in the business of _______” developed digital means to push their content or solve problems. Then Apple showed those companies that they had wasted a lot of money to come up with a solution to the wrong problem, that they had designed (or not designed) a solution to a problem that either didn’t exists or only existed because they created it. Apple rethought the “problem” to render a completely different solution.

— “jamesmcintyre” (read the whole thing here)

Of course, someone may beat Apple to the punch this time…