Kindle vs Nook

Two months after buying a Nook from my roommate, my mom bought me a Kindle for Christmas. In the brief time that I spent with the Kindle, it won me over with its responsiveness and flexibility.

Kindle Wins: Page Turning Speed

The Nook’s page turning speed felt slow before I got the Kindle; I can’t go back to that ol’ dinosaur.

Kindle Wins: PDF Rotate, Pan, and Zoom

It’s nearly impossible to read PDFs on the Nook, since they have to be shrunk to fit the screen. Kindle can rotate, pan, and zoom those suckers. Of course, the iPad is the true winner for this category, since its screen is by default large enough for PDFs, and the iPad has built-in rotate/pan/zoom, and iPad apps are available for Nook/Kindle books and there are even iPad apps to annotate PDFs.

Kindle Wins: PRE Tag Wrapping

I read a lot of programming books, so PRE-formatted code must display properly on my reading device. The Nook requires explicit wrapping, otherwise it runscodetogetherlikethis. I have to use CSS magic to fix this. The Kindle automatically wraps code; it only looks worse when I use the same CSS snippet. Trust me on this; I’ve written both a Nook book and a Kindle book.

Kindle Wins: Physical Keyboard

Nook’s touch screen is slow, requires pressing buttons twice, and wastes battery life. Also, the physical up-down-left-right-click box on the Kindle means looking up words is really fast. On the Nook, I’m tempted to ignore words I don’t know. P.S., Kindle comes with TWO built-in dictionaries. Overkill, but the vast storage space means you might as well have both.

Kindle Wins: Searching and Sorting Books

When you have 500+ ebooks, pressing Next Next Next to get to one just won’t cut it. I had to root my Nook just to install a decent library browser.

Kindle Wins: Faster Web Browsing

Both Kindle and Nook’s browsers are “experimental,” but only Nook’s is super slow. I’m comforted by the fact that my website looks great on either.

Nook Wins On Principle

The Nook has a lot going for it. It’s based on Android, there’s a nifty touch screen to expand interface capability, the preferred format is ePUB–basically zipped HTML/CSS files, super easy to edit–, and who doesn’t love Barnes & Noble? I’m surprised to see so many points for Kindle when Nook has the better foundation.

Kindle Wins In Practice

Kindle is more responsive. Even Nook’s boot starts with a giant black rectangle which disappears, only to be replaced by the Nook logo after ten seconds.

While ePUB is preferable to MOBI, there are some great converters available. I can edit the ePUB, convert to MOBI, and push that to the Kindle. No problem. For a 10KB ePUB, the MOBI is 73KB–but what’s 60KB when the Kindle holds 3GB?

Android is awesome, but Barnes & Noble have been extremely slow to permit apps. At the very least, they could offer an option that says “Load custom app. WARNING: APPLICATIONS MAY BE UNSAFE BLAH BLAH BLAH.” In contrast, Amazon offers a Kindle development kit to encourage apps, which are the driving force for mobile device purchases anyway.

Yes, I left out the Kindle DX and Nook Color

If you have that kind of money, hand in the chips to buy an iPad, or pay a butler to drive to the Library of Congress and fetch original manuscripts, or whatever. Get off my case.

Reading programming books on the Nook

Programming books are hard enough to read: cryptic jargon, poor phrasing, blatant omission of critical details… the list goes on. But it’s even harder to read technical books on the Nook (or any ereader for that matter), because of some limitations of HTML (ePubs are zipped XHTML files).

HTML was not designed for consideration of really small screens. Coders typically use an 80-character margin for easy viewing on medium and large screens. So when a code snippet is shown on the Web, it also assumes a medium or large screen. Textbooks are also pretty big surfaces for code. That’s why Real World Haskell and Practical Common Lisp don’t chop up their code blocks very much. Both the print versions and the electronic versions rely on a big surface for viewing–about 80 characters or more.

Not surprisingly, when this code is viewed on a Nook, the code is cut off. Here’s an example:

PRE-Normal.epub

#!/usr/bin/env runhaskell

module Magic where

import Text.Printf

magic :: String
magic = unlines $ map magic
        where
                magicN :: Int -> S
                magicN n
                        | n > 0 && n

main :: IO ()
main = putStr magic

This is not valid Haskell code. It’s not even readable Haskell code. What’s the rest of the n > 0 && n condition? What happens after that condition is met?

The solution is to instruct Nook (and any other HTML viewer) to wrap the code and set it to a reasonable size (10pt or less). Add the following to the ePub’s CSS:

pre {
	font-family: Andale Mono, "Courier New", Courier, monospace;
	font-size: 80%;

	overflow-x: auto;
	white-space: -moz-pre-wrap !important;
	white-space: -pre-wrap;
	white-space: -o-pre-wrap;
	white-space: pre-wrap;
	word-wrap: break-word;
}

Now the code is readable. Choppy, at least you can see all of it.

#!/usr/bin/env runhaskell

module Magic where

import Text.Printf

magic :: String
magic = unlines $ map magicN [1..7]
        where
                magicN :: Int -> String
                magicN n
                        | n > 0 && n <
8 && n /= 4 = "09 f9 11 02 9d
74 e3 5b d8 41 56 c5 63 56 88 " ++ printf
"%02x" (0xbc + n)
                        | otherwise                = "
                 [ redacted ]                  "

main :: IO ()
main = putStr magic

Update: I received a Kindle for Christmas (will blog Kindle vs Nook soon). It turns out the Kindle automatically wraps PRE tags, and the above CSS ruins that wrap. To reiterate, Nook books require explicit PRE wrapping, but that same explicit wrapping destroys Kindle’s excellent autowrap.