A typographic critique of the Kindle

Friday, January 2nd, 2009

I bought the Amazon Kindle right when it came out in late 2007. It’s gotten an increasing amount of press since then, culminating in Oprah’s gushing endorsement of it on October 24, 2008. (The NYTimes recently wrote a piece about e-books which attributed their rise in interest, in part, to the sales of the Kindle.) Since Amazon does not release sales numbers for whatever reason (perhaps because they are such a miniscule part of their business) analysts are estimating that there are somewhere between 250,000 and 500,000 in circulation at the end of 2008. Anecdotally, I’ve been noticing it more and more in airplanes and airports, and I’ve been hearing reports from random friends that their parents swear by them now.

To be honest, I marveled at the thing when I first got it, mostly because of the Whispernet feature which allows you to download a book on the fly, say, on your way to the subway, rather than stopping by a bookstore or library, (just what I need — more encouragement not to engage in planning ahead) but the visual design of the thing was wholly disappointing, and thus, it began to grow dust, languishing unused next to my bedside reading table. The Kindle had somehow failed to capture the simple aesthetic pleasure of reading.

“Flow State”

Jeff Bezos, in his interview with Charlie Rose about the Kindle, remarked that his team’s number one design objective in the Kindle was to achieve the “flow state” of reading — that is, the ability of the physical object of the book, the paper, the ink, the binding, to disappear when the reader enters the world created by the author’s words.

I am certain it’s easier to get into this “flow state” when you’ve got something in front of you that you really, truly want to read. And on this score, Kindle (and Amazon) should have things pretty much locked up (literally) in their almost infinite catalog of selections from the major publishers. Granted, this probably took a ton of negotiating on the part of Amazon with all of the major publishers for distribution rights, but when you’re Amazon, I’m sure you can pretty much walk into the room with a baseball bat and say, “We’re doing this. You all on board? Great. Sign here.”

Note: There are some technical limitations that are endemic to all ebook readers that use E Ink technology (or at least that I am attributing to limitations in E Ink) that I won’t discuss here, like the supremely annoying black screen when you change pages and the menu and windowing UI (though the new the new Sony PRS-700 has a touch screen interface which is much more elegant).

First, the good parts

Over the holidays, I was in the Charlotte airport, staring down an hour delay in my flight, and I walked by a bookseller where I noticed Niall Ferguson’s new book, The Ascent of Money, which I had forgotten was at the top of my list of books to read over the holidays. I opened the cover and balked when I saw that it was selling for $29.95. Somewhat in price shock, I marched back to my luggage, took out my Kindle, and I downloaded a sample chapter. After reading a few clicks, I was hooked and determined to have it, especially after seeing the Kindle price: $9.99.

$29.95 – $9.99 = $19.96.

Which begs the question: What’s that extra $19.96 paying for? In addition to the paper, the ink and printing, the cover material, the binding, and bailing out a floundering publishing industry, I realized that much of it goes into something that may or may not break your flow state: good typography.

Whither Good Typography?

If the web is 95% typography, then e-books are somewhere in the range of 98%. And in my wide and varied research, I think I can safely say that the reason reading long texts on screens hurts so much is that there are very few people who can set type properly anymore (that, and annoying banner ads and vertical scrolling, but we will address these problems in another post). Unfortunately, this is the case with the Kindle as well. The font they’ve chosen for all body text is Caecelia, drawn by Peter Matthias Noordzij. It’s a smart choice, since it’s an Egyptian (slab serif), so you get the advantage of serifs without having to worry about the slope of the foot getting killed at smaller sizes, but the way it’s treated in the Kindle is, well, unfortunate.

Lists

Basic component of HTML rendered rather thoughtlessly by the Kindle:

Images

The resolution of E Ink technology is purportedly around 300 dpi. In practice, or at least the way the Kindle renders images, it reminds one of the early days of the Palm, or of mezzotint. For instance, this graph below probably has some important labels, but no matter how hard I squint I can’t make out the text. I wonder if this were printed at 300 dpi on a laserprinter if it would be legible. I am sure the crappiness of the image quality is due to the fact that with E Ink you have only black or white “pixel” molecules with which to render text or image, and so it doesn’t matter if you have 300 dpi, you still need some levels of grey in order to do proper anti-aliasing and image reproduction. (I bet the image format on the Kindle is BMP.)

Captions

You would think someone on the Kindle team would have been able to spend a little time to create a style for caption text to differentiate them from the body copy. (The same is true of block quotes — no differentiating style.)  I don’t know if this particular book was rushed through without any styling or what, but in the immortal words of Duke Leto (in the David Lynch version of Dune), “Really damn sloppy!”

Rivers

It looks like by default, the Kindle likes to justify its pages of text. This gives you an even rag on the right side instead of a ragged, irregular one. The pros and cons of this can be debated. There are two variables that need to be adjusted for justifying wholesale large swaths of text:

1. Font size
2. Hyphenation

Without control of these two factors you will certainly have rivers, ie, channels of whitespace running down the paragraphs since whitespace, or more accurately, word spacing, is what is used to justify the lines. Unfortunately, font size can be controlled by the user on the Kindle, so whenever you decide to change the font size, the word spacing changes, and if you don’t have a hyphenation library (which it appears Kindle doesn’t have on board yet) and you get a diluvian horrorshow:

So, what happened to the text on the way to the Kindle?

One way to look at these typographic failures is to see them as byproducts of digitization, or to use my favorite analogy, this is what happens when you force atoms into the digital blender. Unfortunately, this is fraught with messiness (as clearly evidenced above) and it’s not clear who is responsible for the cleaning up of the digitizing mess. According to the Newsweek article:

Though Bezos won’t get terribly specific, Amazon itself is also involved in scanning books, many of which it captured as part of its groundbreaking Search Inside the Book program. But most are done by the publishers themselves, at a cost of about $200 for each book converted to digital.

Really? I highly doubt that scanning is part of the process of getting a book on the Kindle. I am pretty sure that most books nowadays begin on the computer (typed by the author on a word processor), then they are laid out by a designer on a computer, so that there is no need for them to make the round trip to print and then back again through a scanner.

Here’s what I think happens: they take the InDesign (or Quark ) file used for the book, export it as XML, and add Kindle-specific markup (this is an image, this is a caption, this is a list, and so on) to turn it into the proprietary AZW format. The semantic structure of books isn’t that complicated. It’s getting them to render nicely at all page-widths, font-sizes, etc. that’s hard.

Final Grade

From a purely visual, typography standpoint, I’d give the Kindle a C+. Good effort, but poor attention to detail. Fortunately many of these details just need some care and adjustment and are not necessarily the result of technical failures, just laziness and poor design judgement.

Next, I’m going to check out the new Sony PRS-700, which has a touch screen and highlighting ability. Stay tuned!

Also, don’t forget to nominate your favorite online read of 2008 here.

Tweet This Post

The Page is Dead, Part 2

Sunday, November 9th, 2008

(This is a continuation of Part 1 of “The Page is Dead”.)

What is a “page”?

We haven’t had to think about this question for the past three hundred years or so because it’s so obvious to everyone what a page is. We’ve just been staring at them so long we take them for granted.

It’s a sheet of paper.
OK, it’s a sheet of paper that has words and pictures on it.
A book or a magazine has a bunch of them bound together.

Simple, right?

Wrong. Take a look at Jack Kerouac’s manuscript for On The Road (at left). Is this just one long page?

Well, if you want to get technical, you might say, then, that a page is an arbitrary unit of displayed information. The “page” is, in actuality, a convenience that has been established for you, the reader. Really, it’s a design artifact of the codex, which made its debut in the first century at a time when the scroll was the dominant format for knowledge. Actually, long scrolls were made up of “pages”, ie, individual sheets of paper or whatever material that was used, stitched together, but to my knowledge, there was no definite way of referring to specific pages by number until the bound book came along and replaced the scroll.

Guess what, dear readers? The scroll is back.

That’s right. You’ve probably scrolled (unconsciously) a few times already just to read this. First you fired up your browser and requested a document from the World Wide Web. The problem is your viewport (that is, the viewable area for content in your browser’s window) is somewhere between 800 by 600 pixels and, if you’re lucky, anywhere in the range of 2000 by 1000 pixels. Even so, your monitor is most likely 72 pixels per inch and this means your resolution is low, seeing as a standard printed page is somewhere between 150 and 600 dots per inch (assuming 1 pixel ~= 1 dot). Fewer dots/pixels per inch means fewer words at a legible size per screen. This is why we scroll. We scroll because most documents are longer than can fit in one viewport unit.

When we talk about a “web page” are we simply referring to all of the rendered content in one HTML document? I assume that’s what advertisers refer to when they talk about “pageviews” — how many people have requested the HTML document that has my ad embedded somewhere in it? Again, I question the use of the term “page” here, as others have questioned the relevance of such a measure as the pageview itself. Businesses that lash themselves to arbitrary metrics without doing some honest thinking about what they’re really trying to do and practice “maximizing pageviews” to increase ad inventory deserve to fail in the coming years. Some have even called this practice of pagination evil. In any case, the page is dead, and so is the pageview.

Who killed the static page?

The other truth about “pages” is that new browser technologies are changing the very nature and the characteristics of HTML documents. Actually, the new browser technologies (I’m thinking of Javascript and AJAX in particular) are not new at all; they’re just beginning to be used well on major sites now, which means that the paradigm is shifting from static pages to dynamically drawn, internally refreshing pages. When you request a web “page” from a site like, say, Facebook, you are not just receiving an HTML document, you are downloading a complex set of Javascript code that allow individual components on the page to get and send data back to databases without reloading the entire “page”. (When you change your status message on FB, it updates without refreshing the entire page, which means you just robbed somebody of a “pageview”.) This destroys the old idea of the page as a static document, the basic assumption of on which the Google economy is based.

We now have to move towards thinking of “pages” as “screens” or even something like “views” — not “view” as in “page view” but “view” as in “a view” of something, as in a representation of data. (See Model-View-Controller.) The more sites move towards behaving like actual applications and are focused more on interaction versus mere presentation of content, the more urgent it is that we develop a better vocabulary for talking about what it is we are building.

Tweet This Post

The Page is Dead, Part 1

Friday, November 7th, 2008

We are no longer bound by the page refresh model. With this change, new user interaction idioms have surfaced on the web.

– Bill Scott, Director of UI Engineering, Netflix

“The page is dead. Long live the page!”

Over 4 years ago, Karl and I were brainstorming a piece of software what would eventually come to be called “Morpheus” (more on this later). We had locked ourselves away for a week inside a small windowless room at Community Connect Inc. where we were both employed at the time, with only a whiteboard and some paper and our ideas. CCI was embarking on a gigantic structural overhaul of their back-end and front-end architecture at the time, which would affect millions of users across three different community sites. As the information architect and lead front-end developer, we were faced with the task of re-imagining every single interaction and functionality and somehow representing these changes visually. That is, we had to make a crapload of wireframes.

“What? You want wireframes for every single page?!? Are you kidding me?”

Any IA who has faced this knows it is a sisyphean task. “Oh, you forgot the state when a user is logged in but has no friends so they don’t have access to this widget on that section.”

This problem runs many layers deep. The Business Customer knows (very generally) what he wants the application to do; he just can’t paint the picture accurately enough but, like pornography, he knows it when he sees it. That’s where the Information Architect comes in (I use the term more as a role than a job description since in reality most IAs wear many hats). The IA is responsible for translating these nebulous “business requirements” into visual blueprints which are then consumed by a whole host of people:

• Visual Designers, whose job is to put the flesh and makeup on the bones
• Front-End Developers (FEDs), who translate the wireframes into structural, semantic HTML first, then, after the Visual Designers are done skinning, slice and dice the PSDs or Illustrator files, translating the design into working web pages with CSS
• Back-End Developers (or Developers or Engineers or Programmers), who use the wireframes to determine how the databases that serve the content get structured, and what functionality needs to be coded to extract every element of data in order to populate every page
• The Business folks (including Sales) who use the wireframes to present their product idea to their board or to investors to get funding, and to sell the idea to potential customers
• Usability (User Experience Experts, Interaction Designers) who use the wireframes to actually test the screens and interactions with actual users to see if they make sense

Faced with the prospect of modeling every single state of every single “page” in a community website that had a panoply of features ranging from chat, personal pages, notes, news articles, not to mention all of the administrative pages that needed wireframing, Karl and I were convinced we needed to approach this problem in a different way. We had to come to terms with the fact that the “page” was no longer what it used to be.

To be continued…

Tweet This Post