Adapting content for the Kindle e-book reader requires that you follow an unholy mix of usability guidelines for other environments:
Print guidelines for body text
Web guidelines for headlines and summaries
Mobile device guidelines for page design and interaction design
Body Text: Linear Flow
As I discussed in my review of Kindle 2's usability, the device is best for reading long linear material, such as novels and some non-fiction. Kindle's best user interface feature is turning the page; the reading experience you design should require no other interactions.
Writing linear books simply requires a skill that all good authors already possess: the ability to keep readers immersed in the plot.
Kindle also works well for the long, narrative articles common in certain literary magazines and Sunday newspaper supplements. No surprise that The New Yorker is currently the best-selling magazine for the device.
Kindle works poorly for non-fiction books that have many illustrations or that require users to frequently refer back and forth between sections. Even if Kindle had a color screen, heavily illustrated books would still be better in print because moving around in Kindle is awkward. My own books fall into this category, so even though I'd like to sell more books, I can't really recommend that you buy them for Kindle. My latest book is available in Kindle format, so you can download a free chapter and try for yourself (and then buy it in print :-)
Letting customers read a book's initial pages for free is a great Kindle innovation and makes good use of the digital medium's ability to dissolve the print requirement to bundle chapters. (Thus, this is a better-than-reality feature.) The innovation will no doubt sell more books — particularly for fiction, where people will want to see what happens next once they're gripped by a story. In fact, for mystery novels, Amazon could probably give away the first 90% for free and charge the entire fee just for the last chapter.
Free previews will also change book writing: you'll have to ensure that your best material is in the first chapter , because that's what will sell the book.
Sadly, this is not how I like to write books. My updated book on web usability starts with chapters on our research strategies, how we rate and prioritize usability problems, and how our new findings differ from my first book on Web usability, written 10 years ago. I want a book to be a total experience , where I set the stage for readers to experience a rich understanding of the later chapters (rather than launch straight into the payoff material, such as how to present product pages, which doesn't come until chapter 9). To me, the ability to inspire deep thinking is why non-fiction books still have value compared with websites, which are better for quick hits and controversial writing.
So, in my books, I might resist the tug to deliver quick-hit first chapters — but if you want to sell Kindle downloads, don't follow my example.
Headlines and Summaries: Support Hypertext Navigation and Information Scent
For newspapers, magazines, and some non-fiction books, people won't read the text from beginning to end. You must help them choose which articles (or chapters) to read.
You can do this using various types of tables of content, such as the following newspaper section's list of articles:
Such article listings must be written according to guidelines for writing for the Web.
Users typically see headlines out of context . Section listings within a larger publication are a partial exception. In the screenshot above, for example, all the articles pertain to arts or culture. A magazine's main ToC or the list of a newspaper's front-page stories offers less context.
In any case, your headline, supplemented by a deck (short summary), must be sufficient to give readers (a) a sense of what the article is about, and (b) the ability to judge whether they'd want to read the full story.
With only 25–30 words to achieve these goals, you can't waste word count on a byline. (The exception here is for regular columnists or pieces written by famous people; in such cases, readers might decide between articles based on the author. Interestingly, there are some similarities between this guideline and the guidelines for the "From" field in email newsletters.)
The 4th headline above, "On Loan, 16th- and 17th-century Spanish, Italian and..." would certainly have had much stronger information scent if they'd used the last part of the second line for more headline words, rather than the journalist's name. Specifically, the headline is missing 3 keywords:
"Paintings," to give readers a basic grounding in the article's topic; readers can't see the illustrations that accomplished this goal in the printed newspaper (see below). Yes, "paintings" appears in the summary, but users read headlines first and read summaries only when those headlines catch their interest.
"Exhibition," to state what's actually news. The word "loan" hints at this, but in an indirect manner that requires user interpretation. In headlines, it's better to be as literal as possible to facilitate scanning.
"Frick Collection" (or simply "Frick"), to cue users into the article's "news-you-can-use" aspect: the exhibition is on display at the Frick Collection, so interested readers can go there to see it.
Compare the screenshot above with the article's presentation in the New York Times print edition:
Note how the two pictures situate the story, both at the highest level (it's about paintings) and more specifically (a certain style of art, from a certain period). In the Kindle's section listing, you must provide the same context using only words. That is, exactly as you typically do on the Web when representing a story on a homepage, in search engines, and other out-of-context places.
In adapting this article for Kindle, the editors did at least one thing right: they changed the headline. "Sharing Reflections of Tycoon Taste and Wealth" has zero meaning out of context. On the printed page, the headline can play up the story's human-interest angle because other design elements tell readers the who, what, where, and when.
Interaction Design & Page Design: Mobile Usability Guidelines
As discussed in my Kindle usability review, it's awkward to interact with the device through its 5-way controller. Also, after every selection, you're doomed to wait for a sluggish response. And, once you finally get something, you get very little because of the small screen.
Setting aside the header and footer areas, Kindle 2's content area is 525x650 pixels, or 341 kilo-pixels. In contrast, a mid-sized PC screen is 1280x1024, offering 999 KP of content, or the equivalent of three Kindles.
Given these constraints, navigating non-linear content on Kindle feels much like navigating websites on a mobile phone. Kindle content designers should therefore follow mobile usability guidelines for many user interface issues, including the presentation of article pages.
Let's say, for example, that after looking at the New York Times business section listing, we select the headline "G.M. Lays Its Future on Washington's Doorstep." The summary is: "Rick Wagoner, the chief executive of General Motors, met with government officials to." (This summary is not brilliant given the available word count, but we'll let that be.) Clicking the headline gives us the following screen:
What's wrong? Two things:
This first screenfull provides virtually no new information, beyond what the previous screen told us. This violates a major mobile guideline, which is to reward users for the pain they suffer with every move. With a small screen, you must repeat less and allocate more space to new material.
The useless photos and captions waste most of the content space. While images can be valuable, you should typically defer them to subsequent screens, dedicating the crucial first screenfull to dense, utility-focused text. (The art story above might be an exception. In that case, a painting might be sufficiently valuable to present on the first screen.)
Compare the Kindle presentation of the business article above with the one that ran on the front page of the newspaper's business section:
In print, the pair of big portraits dramatizes the tension between business and government, particularly when combined with the scare-mongering headline, "The Last Option." This otherwise vague headline works because it's combined with an explanatory subhead and presented in a box with another article on the auto industry that adds further context with a photo of a manufacturing line.
This front page is a good piece of newspaper design. Porting it to Kindle — even after improving the headline — makes for a poor piece of information-appliance design.
Book Collection IA
Kindle opens up another problem: How to create information architecture for entire collections of books. After my last article, several people wrote to me about how they particularly liked the ability to keep huge numbers of books on their Kindle rather than filling up bookcase after bookcase. Having moved many heavy boxes of books too many times to remember, I empathize.
Kindle 2 can store 1,500 books on the device and even more in Amazon's in-the-cloud storage. Unfortunately, the UI is not up to managing the realistic-sized book collection that a heavy reader would accumulate in just a few short years. It's sadly common for designs to handle the initial small-scale usage scenarios well, without being able to scale to long-term use, with its associated growth in items to be managed.
Kindle's book collection IA is simple:
Books live in one of two locations: the active bookshelf or the archive. If you keep the bookshelf itself small, it's easy enough to manage, but that simply shifts the management problem to the archive.
Each location is a linear list of books, which you can sort alphabetically (by title or author) and chronologically (by the last time you viewed the book).
That's it. High learnability, with this few concepts. So, the first several months of Kindle use will be a joy. But learnability is only 1 of 5 usability criteria, and experienced users will find it increasingly difficult to find their way around a growing book collection.
Hopefully, Amazon is planning to introduce a more advanced IA in future releases — perhaps after better hardware allows more powerful UI controls. Amazon definitely has plenty of data about books, including categorization and similarity between related works. Ideally, publishers should also contribute to the findability of their books in large collections (something they didn't have to worry about in the past).
Optimize for the Medium
Since I started writing Alertbox in 1995, it's been a recurring theme to design for the medium. In the beginning, this meant "don't design your website like a glossy brochure." (I.e., print design is different than online design.)
For Kindle, it's certainly unacceptable to simply repurpose print content. But you can't repurpose website content, either. For good Kindle usability, you have to design for the Kindle. Write Kindle-specific headlines and create Kindle-specific article structures.
No surprise, really: It's simply the 1995 lesson updated to a 2009 device.
(Update December 2011: Kindle Fire user testing.)