Despite my absolute love for the iPad, I’m certain that Amazon’s new Kindle Fire
will be a successful product for consuming content. Let’s not debate that; the market will tell us within a few months.

How do we design and develop for Kindle Fire? There are seven questions I’m wondering about.

1. What type of tools will Amazon provide to developers?

Sure, Kindle Fire is based on Android but uses an earlier, forked version customized by Amazon. If Amazon wants to offer a large variety of apps on Fire then it needs to offer guidance on how to best develop for the device. For instance, Apple provides a clearly written Mobile Human Interface Guidelines document. Whereas, on the announcement day of the Kindle Fire, Amazon’s developer site says to come back next week to learn how to develop for Fire.

(Hmmm, perhaps secrets are hard to keep within Amazon and they didn’t want the technical writers to know too much before the product announcement.)

As with Apple, developers will have to pay Amazon a $99 annual fee to sell on the Amazon Appstore. It’s waived for the moment, so now is a good time to sign up. Presumably, the developer’s fee goes to cover the cost of creating the SDK and documentation. That’s fine, but Amazon can never beat Apple in the quality of tools and documentation. (Actually, Amazon doesn’t have to beat Apple at anything. Plenty of room in the market for both Kindle Fire and iPad to co-exist.)

2. Will the positioning of Kindle Fire as a consumer-grade device for content determine the type of apps created?

If so, then the range of apps will be fairly limited, which is not necessarily a bad thing. The two-point touch screen of Kindle Fire will restrict it as a gaming platform. Fire does not need to be a productivity platform since many who have Fire also will have a smartphone on which they can use productivity apps. Obviously Amazon will provide its own apps for watching movies and reading e-books. So that really leaves content apps in the form of books, children’s books, cooking, entertainment, lifestyle, reference, and travel. Most apps in those categories are relatiely similar beneath-the-hood and don’t necessarily make use of the most advanced parts of an SDK. So, watch to see what types of documentation and sample code Amazon provides.

3. For designing e-books will Kindle Fire ever support EPUB?

In one sense Amazon never needs to support EPUB since a third-party app for Fire could support EPUB instead, though it’s hard to imagine Amazon encouraging an iBooks or Nook app for Fire. But maybe so. In the end, consumers don’t really care about EPUB or format standards at all. Consumers care about the price of ebooks and the reading experience, so it’s likely that the overwhelming majority of book lovers who buy a Fire simply will stick with the Kindle app. This leads to the next question…

4. If not EPUB, then how close will Amazon go in supporting layout capabilities similar to those in EPUB3?

Seems like e-book designers are following the same trail as Web designers in having to tweak layouts depending upon the consumer’s choice of application. (With Kindle playing the role of IE in this saga. Let’s all sigh a bit.) But if Amazon keeps the capabilities of rendering e-books fairly close to EPUB then it’s not that big of a hurdle to support multiple e-book formats. Or, perhaps, Amazon could even take the lead and implement advanced capabilities before EPUB3 is completed. That won’t be good for e-book standards but could further strengthen Kindle’s position among consumers as the best e-book reading device.

5. How will the limit of 8 GB of storage force changes in the way apps and e-books are developed for Kindle Fire?

On the iPad many content-based apps are very hefty, often weighing more than 500 MB and occasionally more than 1 GB. On my 16 GB iPad I have to be very careful about managing those last two gigabytes. I had to delete both Al Gore’s Our Choice app and Tim Flannery’s Here on Earth app to ensure my iPad maintained space for new materials. (BTW, those are both good apps. The Our Choice has a small initial size but downloads a lot once you start reading each chapter.)

The 8 GB Kindle Fire may require re-thinking how many apps and e-books are structured…leading us to the next question.

6. Will the cloud-based caching technology in the new Silk browser also be utilized to support apps and enhanced e-books?

I’m hoping Amazon has some intelligent way to cache the enhanced content of an e-book and deliver it from the cloud as needed, and then remove it from the device cache when no longer needed. If so, the same could be adapted for apps that embed massive amounts of video and images. I’m very curious about how Amazon will handle this characteristic of many apps and e-books. I’m suspecting that the intelligent caching will be built into the entire system and not just the Silk browsing.

7. Will Kindle Fire quicken the adoption of Web apps?

Amazon could sidestep the entire dilemma over supporting developers in creating native apps by instead encouraging the development of Web apps. Indications are that the Silk browser is based on Webkit. As the Web app stack of HTML5, CSS3, and Javascript matures then it becomes a better option for cross-platform development. Even though HTML5 isn’t quite baked, the modest functional requirements of content-based apps might make it a viable option sooner than later.

Apple probably is not nervous about Kindle Fire, though every other tablet maker should be quite worried. Amazon is the only one with a retail ecosystem to match iTunes. And that’s what it’s all about.

Kindle Fire cannot be ignored by designers and developers of content-based apps and e-books. Time to figure out the strategy for supporting both iPad and Kindle Fire.

As a book design studio we have focused on designing covers and complex layouts for print. We’re continuing to do print design. Actually, that is Ceci’s specialty. But we’re adding a new specialization: the design of mobile apps. One might even say “books as apps”, but that’s not quite right.

I’m not exactly talking e-books or even enhanced e-books (as those are variously defined). Certainly, there is a demand and need for e-books based on a reflow format (e.g., EPUB) and also for digital facsimiles of print books (e.g., PDFs). No need to debate that issue any further, though I’m not quite sure about enhanced e-books where audio or video is simply stuck inside a long-form narrative or tacked onto the end.

The work that consumes most of my time these days involves stepping back and thinking about the structure and presentation of content on smart phones and tablets without staying within the traditional concept of a book. Indeed, the book as app is not a book at all, but a variation on materials and capabilities where the end result is a compelling product that people want to buy.

Stay tuned for a lot more on this topic.

Katie Peek over at A Canary in the Data Mine: Explorations of Data Analysis and Information Display blog posted an interview with me on the topic of book design and the changing world of electronic publishing.

The day after. This is a book design blog, so you’d expect me to write about iBooks, the dazzling ePub reader built into the iPad. But I’m not. (Well, I will a bit). And I’m not going to write about what features are lacking in iPad (first generation, after all) or if there’s even a market for this type of device: duh. And I’m not going to waste time debating the backlight. There are a lot more important things to do, such as figuring out how to design content for this new device. Notice: I said designing content, not designing e-books.

iBooks is a response to the market-driven phenomenon of people wanting to read hundreds of pages of text on a computer screen. Is that the best we can do, read text on a screen? Personally, I want to use an ultra-modern computing device for engaging with content in ways not possible merely with text. (Of course, I’m talking primarily about non-fiction here. I love literary fiction & the interplay of words, sentence after sentence, though I still prefer my novels in print. But that’s just a personal preference.)

And I’m not talking about enhanced e-books, which often mean no more than just some multimedia tacked onto the end. Adherents of e-books are constantly stressing the importance of breaking away from the concept of the printed page. Yet, the ePub reader on iPad uses a page concept & strongly reinforces the concept of the physical book (transplanted to the screen).

I’m interested in breaking away from the concept of the page & the physical book. But I’m not too interested in a lengthy stream of re-flowing text. The page, the physical book, & even the re-flowing text are all great in their own ways if you want is to read 80,000 words on a topic. But I seldom have that much time. But I am interested in learning. And don’t we read non-fiction because we want to learn?

Maybe I only need a stimulating 10,000 words arranged in even smaller, bite-sized chunks seasoned with imagery for obtaining an overview of a topic. A multi-touch screen allows me to interact with the content, furthering my retention of ideas. A playful, game-like component pulls me further into the narrative. (Remember, narratives don’t have to be linear or even textual.) I would buy such a product, a content app that started me along the journey of exploring an unfamiliar topic. I love to learn, I love to read. So what’s next: I would then purchase a more in-depth book on the topic (either in print or as an e-book).

Listen up publishers: you just sold me two separate products. Think about that.

How can digital media aid in learning about a topic in a visually engaging manner? That’s the challenge we should address in designing for the iPad. The iPad gets us a big step closer.

As I think about designing content for the iPad, I’m not thinking so much about ePub. I want to breakout of whatever constraints & restrictions imposed by the ePub rendering engine. The iPad provides a robust canvas. When I think of paid content on the iPad, I’m not just thinking e-books. I’m also thinking apps.

The app development environment for iPhone is superb and is the basis for the iPad SDK. There’s an NDA around the iPad SDK beta. So, no specifics here.

Here at sorodesign we are working to develop some apps for the iPhone & the iPad that revolve around content but are not at all what one would think of as e-books or even enhanced e-books. We’re experimenting. Designing for the iPhone & the iPad requires creativity. That’s exciting.

And what is required from all of us for devices like the iPhone, the iPad, & similar products from other vendors that will come along: new ways of writing, editing, designing, publishing, & reading.

When people say the word e-book they don’t always mean the same thing. The distinction among types of e-books is very important when it comes to e-book design.

In the world of big commercial publishing e-books are nearly synonymous with Kindle. (And I’m including related formats such as EPUB in this category.) These e-books are designed for use on dedicated reading devices or other portable devices (e.g., iPhones). The key concept here is re-flow: forget about pages, as in printed books. The e-book is a stream of text that automatically re-shapes itself depending upon the width and length of the screen. And forget about design, at least for now. Currently, designing this type of e-book is all about making the e-book look as decent as possible within the severe limitations of e-book reading devices.

E-books based on re-flow are here to stay. But I’m betting within a few years that the design capabilities for this type of e-book will improve. That will happen in the same way Web design has improved over the years. Or, possibly, perhaps re-flow e-books always will be the bare-bones version of books.

As long as people are happy to buy that format, why should publishers spend the money to make the content formatted any better when there’s always the alternative of PDF and even print for those who want a more typographic experience. The good aspect of all this is that consumers may be able to read books in whatever format they prefer.

Actually, with all the announcements coming out of the Consumer Electronics Show in Las Vegas, the capabilities for better looking e-books may be approaching even more rapidly than I expect. Then again, after working with technology for a couple of decades, I know that real change doesn’t happen as quickly as press releases are spit out by marketing departments.

The other common definition of an e-book is PDF, where what you see on the screen looks like the printed page. This works fine on a decent-sized screen (i.e., desktop, laptop, or even a netbook), but is painfully difficult on a small screen. From a design perspective, PDF offers the most flexibility and is the easiest to produce if you already have the book designed for print.

E-books based on PDF are here to stay.

A variation on the PDF e-book is the screen-oriented PDF: the content is designed to fit the screen and resembles a fantastic PowerPoint presentation more than a book. These screen-oriented PDFs are more like a brochure, usually less than 50 pages, and often given away for free. As with any type of PDF, the screen-oriented PDF offers a lot of options for the designer. Commercial publishing houses are not too interested in this format, but Internet marketers make a lot of requests for it.

Enhanced e-books are yet another category: text-based e-books supplemented with visuals and additional features such as audio or video interviews with the authors and other background information. Commercial publishers seem very interested in enhanced e-books for the value-added features, which in turn can result in a higher price for enhanced e-books. Of course, all that material also simply could exist on a Web site. But how do your charge for a Web site? Hence, back to e-books where there’s an easily recognizable price model for consumers.

And what about e-books and magazines that follow a cloud model? That’s worth exploring in a post all its own.