Devices

Open Question: Do You Read Books on a Cell Phone?

Mobile book reading is already popular in Japan and anecdotal evidence suggests it could be catching on elsewhere. I'm curious to see how prevalent phone-based book reading is within the TOC community.

  • Have you ever read an ebook on a cell phone? (This doesn't include Kindles, Sony Readers and other standalone e-reader devices).
  • Have you read more than one ebook on a cell phone? If yes, how many do you typically read in a year?
  • What inspired you to first read books on your phone?
  • In your opinion, what are the pros and cons of reading books on phones?

Please share your thoughts in the comments area.

How to Read any Type of Document on the Kindle (Almost)

There are a few options for readers who want to convert PDFs or other non-supported files to the Kindle's AZW format. Amazon's recommended method is to email the file to your personal Kindle email address. It's also possible for users to convert PDFs and other document types themselves using Mobipocket Creator or Stanza.

All of the above methods have the same flaw: AZW does not support the kind of advanced layout available in formats like PDF, and non-Latin fonts aren't easy to convert. What if you need to review a complex legal form, or read a graphic novel, or one in Chinese? A hidden feature can help.

screen_shot-50087.gif The Kindle has an undocumented picture-viewing mode that was first uncovered by Igor Skochinsky. Although the black and white E Ink screen is not especially good at displaying actual photographs, it is quite good at rendering line art and text.

Here's how to do it, using PDF as an example. Note that unofficial features may be buggy and could damage your Kindle; proceed at your own risk.

  1. Convert the PDF to a series of images. Commercial versions of Acrobat should be able to do this in batch, but users of free readers may have to convert a page at a time. The Kindle can read JPEG, PNG and GIF; the latter two will work best. Because the picture-viewing application doesn't support a table of contents, you'll need to name the image files in ascending alphabetical or numeric order (e.g. "0001.jpg," "0002.jpg," etc.) For best results, resize the image to 600 x 800, the resolution of the Kindle screen.
  2. Connect the Kindle to your computer using the USB cable. Once connected, browse to the Kindle's drive. If you have an SD card installed that will appear on your computer as well. The following procedure works on either the Kindle or the SD card. I prefer to do everything on the SD card -- it feels safer.
  3. Create a folder called "pictures," and a folder inside of that with the name of your "document." Put the images in the document folder. Disconnect the Kindle from the PC. When you go to the Kindle's home screen, nothing will have changed. This is where the secret feature comes in:
  4. Press Alt-Z from the home screen. Your book title should appear in the list.
  5. Click on the book title. It will open the first image. Use the normal Kindle next/previous buttons to page through the "book." The picture viewer has menu options of its own to control the size of the image and how it's rendered.

screen_shot-50096.gif

Credit: octopus pie

Of course because the "PDF" is really an image it's not possible to search the document or rescale the fonts. Text-heavy PDFs should be converted in one of the recommended ways.

This same technique can be used to load image-based documents directly, such as comics. (Peeking inside the "pictures" folder after it's been read by the Kindle reveals a file with the extension manga, suggesting that the picture viewer was intended to be used for this purpose).

It's also possible to convert documents in Russian, Chinese or other non-Latin scripts this way. The Kindle does have support for embedded non-Latin fonts as part of its "Topaz" file format, but there are no tools for end-users that output Topaz.

(Screenshots courtesy the undocumented Alt-Shift-G feature, which saves to the root of the SD card.)

Q&A with Developer Who Turns Ebooks into iPhone Applications

Ebook files and e-reader software usually exist as separate entities, but Tom Peck of AppEngines merged the two to create individual ebook applications for the iPhone App Store. In the following Q&A, Peck discusses his ebook software development process, consumer response to his apps, and future ebook projects.

Why did you opt to bundle individual ebooks as software applications rather than create a single e-reader program?

I have been reading ebooks (mostly from eReader.com) for many years. I wanted to make a book reader program for the iPhone that was as simple to use as possible. I feel that the way existing ebook solutions work is too complex for many users: they have to download the ebook software, then go to a separate Web site and create an account, enter credit card data, and then find and purchase content.

The iPhone App Store sales and distribution process makes it simpler and more convenient to have an ebook reader as part of an ebook itself. Developers can only distribute applications through the App Store; there is no way to distribute data files like ebooks. Therefore, it made sense to me that each book had to be a complete application.

Although this is more convenient for App Store customers to get a book, the process of making each book into an app takes more time for development. Each book becomes its own Xcode project, requires testing, and requires time to load all of the data (descriptions, screen shots, application file) to the App Store. I have developed tools and techniques that automate as much as possible, but each book takes several hours to complete, not counting the many hours spent writing the ebook reader itself.

Have you used any of the e-reader applications available through the App Store (e.g. Stanza, eReader, etc.)? If so, how do these compare to your own apps?

I have used the eReader software. I am a long-time eReader customer, having purchased dozens of their books and read them on my Treo. I have not used Stanza.

The biggest difference is that those products let the user download content from the Internet. Some let users create their own content and download it to the iPhone, which is nice. My reader is purely a book reader.

The eReader app supports a bookshelf list, showing all the ebooks. With my apps, each ebook appears as its own icon on the home screen.

My current reader program compares nicely to eReader. At the moment, I do not support landscape mode, which eReader does. Both offer text search and table of contents. I admit that the search function in my first batch of books was not very usable; newer books have a much better implementation, even better than eReader's. Both programs support different font sizes, images embedded within the text, layout options such as indenting and centering, and font styles.

One feature my reader has is instant repagination when the user changes font size. Using my reader, the user can increase or decrease font size using the "pinch" gesture, similar to zooming in and out of photos, and the results are immediate. I spent a lot of time to make this very, very fast. Changing the font size in eReader requires the program to repaginate in the background, a process that can take over 30 seconds for the entire book.

How many ebooks have you made available through the App Store?

Currently, about 140. More are in the pipeline; all newer, copyrighted works from other publishers and authors.

What has the response been like?

Response has been very good. My current download numbers for all books (not counting several free books) is almost 1,000 books a day. The numbers per book vary day by day, with some books having as many as 50 downloads a day. Most of the public domain titles have counts around five per day.

Most encouraging are that the newer works are selling just as well as the classic stuff. iPulp, a publisher of science-fiction and adventure short stories for young adults, has four works in the store right now with six more in review. These are priced at $0.99 and $1.99 and have sales of about 10 per day. The two Max Quick novels sell for $5.99 each. Currently they are selling about 13 copies per day and the numbers are increasing (they've been in the store for less than two weeks).

Are you selling ebooks or ebook applications through other platforms?

Right now, I am only working with the App Store. I am watching to see what other cell phone vendors and carriers do. As some of your blog postings have noted, the success of the App Store is making other carriers look at copying Apple.

I have spent time with Google's Android platform and have a version of the ebook software that runs on Android.

How much of your ebook content comes from Project Gutenberg?

My initial group of books, about 110, were all from Project Gutenberg. I constantly get requests from customers to add new books, so I have added more Project Gutenberg stuff. Now that I am working with publishers and authors to produce their works as ebooks, I will focus primarily on new works.

Can you list some of these publishers/authors? How did your relationships with these publishers and authors come together?

In the store now are a book on computer security by Neal Puff and a memoir by Teresa Wright. All relationships came about because of my presence in the App Store with the initial set of ebooks. I've been contacted by small publishers and individual authors to turn their works into ebooks for the iPhone. I work with them to get the content in an appropriate format, get the various graphic elements (cover art, icons, etc.), produce the ebook app, have them review the app, and put the app into the App Store.

Do publishers pay you a flat fee to prep App Store titles or is it a revenue share?

Revenue share.

Did you anticipate this type of publisher response?

I was a bit surprised at how quickly publishers contacted me. I thought I would have to market to them.

Are there other content sources or types you'd like to incorporate?

One publisher I am working with offers textbooks. That would be an interesting type of content. A textbook could take advantage of the ebook being a standalone app, offering more interactive content for quizzes that would appear within the book.

Some App Store reviewers complain that you're making money off of public domain content. How do you address these complaints?

The Project Gutenberg license clearly allows people to sell works based on the Gutenberg files. I am following the license, and I do send 20 percent of the revenue earned to the Project Gutenberg Foundation. Mobipocket, eReader and Amazon Kindle all sell public domain works for much more than $0.99.

Each book requires a lot of manual work. The Project Gutenberg text files are a good starting point, but I have to edit each one to add information about chapter starts, poems, songs, emphasized text, etc. Many files have extra data like page numbers that have to be cleaned up. I tried to automate this part, but there is so much variety in the files that only hand editing can get the correct results.

Since your ebooks are applications, and iPhone apps are stored on the device's docking screens, is there a concern about clutter? Do you have any organization tips for people who buy multiple ebook apps?

I would say that this is a general problem with the iPhone Home Screen user interface. iPhone blog sites describe users with 100 apps or more on their devices, and finding a specific app can become a problem.

iTunes does allow users to selectively install apps on individual devices. This is probably the best way to deal with lots of apps: for users to only install the apps they need, and keep the rest on their desktop machine. Personally, I tend to read about two books at a time, then I remove them from the device when finished.

What near-term features or products are you planning?

I am working on a new version of the reader software that adds many new features: bookmarks, notes, landscape mode, etc. Once completed, I will re-release all existing books with the new features. Customers will get the updates for free.

I also am working on several non-ebook iPhone apps.

Commentary: Apple Could Own the Ebook Category

A recent discussion on the Reading 2.0 list examined Amazon's place within the ebook universe and the threat Apple poses if it enters the same space. In the following excerpt, John Conley looks at the fundamental differences between Amazon and Apple:

The debate as to how successful Apple is in selling music through iTunes and its impact on the music industry provides insight into Steve Jobs' strategy. People speculate that iTunes is contributing significant incremental profits to Apple even though Jobs says that it is not. Since the total results as far as costs and sales are really buried in the detail none of us may ever really know.

What is going on is that Apple is determined not to make the mistakes they made when they first came out with the Apple I in the '70s. They are using Mac, iPod and now iPhone to incubate a user base that is growing at a remarkable rate. They own the mind share of the next generation of power users, which is this generation. I have five children, age 27 to 13. When the oldest went to college he went with a PC, as did the next child. That was before iPod. My third child will be a senior in college this year and has been a Mac user since 14. The 13 and 15 year old are Mac users. The two oldest, one who is a PhD candidate, have converted to Mac. As this generation ages to the point of conspicuous consumption they will be all Apple in their information needs. They look at my briefcase with its multiple chargers for numerous devices and laugh. They know that Apple will provide them with the ultimate device. They have a level of loyalty to Apple that speaks of the incredible consumer power that now exists with the brand.

Whatever the current functionality of any Apple device the user belief that the next generation of iPhone will continue to innovate and provide the functionality that this next generation of users will require is why the Kindle will never have the success required to make it the mainstream device for end users.

The law of numbers will apply here in that if you have the largest installed base and strong brand loyalty you will provide the most desirable sales channel for those companies that are looking to sell product. Consumer product companies may not like dealing with Wal-Mart because they set all of the rules, but they do it anyway because they are the most powerful channel. Amazon desires to be the Wal-Mart of Web distribution, but they have no value added other than price. Apple provides the connectivity, software, platforms, and most important, loyal customers. If and when they decide that ebooks are a viable driver or requirement to meet the needs to their tens of millions of incubated users they will dwarf the efforts of any other ebook service provider in the market and the publishers will readily come to them with content. (They will also not make the mistake of asking the publishers to provide the content in some proprietary format.)

Apple's profit model is dependent on selling hardware and software. They bring more value added to the equation then a company like Amazon who, is only a distributor and a technology wannabe. Hardware is not Amazon's core competency and they do not have the infrastructure or money to fight a technology war. In the end they will be happy to be a partner in distribution of ebooks to an Apple device that meets the needs of e-readers and without a doubt be more functional than any device that Amazon would attempt to market.

Distribution is what Amazon has as its core competency. The Kindle, like all of its predecessors, will not rise in success beyond the early adopters because Amazon does not own the brand loyalty within the consumer electronic market segment that is required to make the next big step in creating meaningful demand.

(Excerpt reprinted with John Conley's permission.)

Open Question: Have You Seen a Kindle in Public?

A flurry of new Kindle guesstimates and analyst predictions has reignited the Kindle number debate (something I'm not fond of). One of the oft-cited arguments is: "How can the Kindle be so popular if I've never seen one in public?"

There are big holes in this line of inquiry, but since it gets raised so often I figured a few device-spotting questions were worth posing to the TOC community:

  • Have you seen a Kindle in public? If so, where did you see it?
  • Have you seen a Sony Reader or other standalone e-reading device?
  • Have you seen more than one e-reader?
  • When did you first see an iPod in public? How about a cell phone?
  • When did iPods and cell phones transition from public novelties to commonplace items?

Please share your thoughts in the comments area.

Books Fail to Crack Top 100 in iTunes App Store

Over at Radar, Ben Lorica analyzes sales and category data for the iTunes App Store and makes an interesting discovery about the store's book section:

The Book category is comprised mostly of ebooks and while there are over 150 such "apps", it was the only category not represented in the Top 100 rankings ...

As Ben notes, most of the applications in the App Store's book category are individual ebooks -- most drawn from Project Gutenberg -- wrapped up as stand-alone software packages. The user reviews attached to these ebook apps fall into two camps: critics who cry foul over public domain titles repurposed with a price tag, and advocates who see value in the applications' low cost (most are $0.99) and easy access.

A Big Boost to Books as Apps?

Perhaps inspired by Apple's success with their iPhone App Store (which is already bringing in $1 million a day), T-Mobile has announced plans to add a similar storefront across all of their phones -- reaching more than 30 million subscribers. From Silicon Alley Insider:

This fall, T-Mobile is planning to gut its current, lousy method of distributing mobile apps -- favoring software companies that it has revenue-sharing deals with, according to MocoNews. In its place: An iPhone-like app store that's organized by popularity, not payola. The platform will be open to "almost any developer" that agrees to T-Mobile's revenue split, which one developer says is "very generous."

Books as standalone apps (and as collections, such as Shakespeare) have already proven popular enough for Apple to add "Books" as a category. There are several important implications of this for publishers:

  • Disintermediation. This is yet another channel for individual content creators to reach an audience, and some part-time app developers are already earning a nice payday. Surely some will be vanity press material; just as surely some will not.
  • Pricing and discount structure. Right now Apple takes a 30% cut, and paid app prices are settling around tiers like $0.99, $1.99, $4.99 and $9.99 (amusing $1,000 outliers aside). The thrashing continues on this front, and consumers will be the ultimate arbiter.
  • Distribution. Publishers are rightfully wary of Amazon's growing power, and the wireless delivery is arguably the driver behind the bullish outlook on the Kindle. The iPhone App Store and now T-Mobile are welcome competition, though carry a double-edged sword as gatekeepers controlling which content gets in front of their customers.
  • Form, not just format. Smart publishers (and as usual, I use the term loosely) will go beyond just displaying printed book content in these new devices. Digital, networked environments require rethinking how best to do the "job" of a book.

The distinctions between content and software are falling away, and smart publishers need to begin adjusting accordingly.

Optimizing Web Content for the Kindle Browser

Amazon Kindle Amazon's Kindle store is convenient, easy-to-use and stocked with thousands of titles. But what about publishers and content distributors who want to reach the estimated 240,000 Kindle users without going through Amazon's program? And what about content formats that the Kindle does not directly support?

One selling point of the device is its free, ubiquitous Internet service and Web browser. Amazon has filed the browser under "Experimental" but it's quite usable as-is. With a few simple changes to a Web site's HTML code, it's even possible to specially cater to Kindle users.

The screenshots used in this article are from the mobile version of Bookworm, my Web application for reading ebooks in the EPUB format. Although what's being displayed is ebook content, it's being delivered by the Kindle's browser, not the Kindle ebook technology, which does not yet support EPUB.

Because the mobile Web version is already heavily optimized for small devices, the layout is simpler than a traditional Web site. What works for an iPhone or other wireless device will also be a good starting point for the Kindle, although we'll see there are some special considerations that don't apply to any other device.

Default or Advanced Mode?

When the Kindle ships, its Web browser is in "default mode." It will not load images or CSS styles, but it does render basic HTML tags like the italic tag <i>. Personally, I prefer "advanced mode," which displays Web pages more like a traditional browser, but some sites can be unreadable in this mode.

When optimizing for the Kindle it's best to consider that most users will not change from "default mode," or even realize that the option exists.

How different are these modes? Here is a comparison shot of the same screen from Bookworm in both modes:

kindle-4.jpg kindle-6.jpg
My list of books in Advanced mode, showing tabular layout and more advanced font styles My list of books in Default mode

In Default mode, all the information about the books runs together. It would be better to present this as a simple vertical list, the way the Amazon Kindle store does, rather than as a table.

Font Size Considerations

You can choose from six font sizes in the Kindle browser. As a content creator, you can provide a wider range of font sizes in your Kindle-formatted Web page, but take care that they aren't too small. The device doesn't clearly display fonts that are smaller than its default six sizes.

In this screenshot, the table of contents for a Bookworm book is not readable, even though this page has already been tailored for the small display of mobile phones:

kindle-3.jpg

This problem is only likely to occur in Advanced mode where stylesheets are activated.

Usability

The Kindle's method of selecting and traversing hyperlinks is unique. The user activates links by selecting along the vertical, or Y-axis, using the scroll wheel. When multiple links fall on the same line, the Kindle will open a dialog box so the user can clarify which link is the target.

In Bookworm, users move to the next or previous chapter by selecting navigation links lined up horizontally (see the top row of the first image). In the Kindle, this presentation forces the user to click a second time to select the appropriate one:

kindle-2.jpg

For commonly-used navigational items like this, line up the links in a vertical row:

  1. Next
  2. Contents
  3. Previous

Now no second click (and accompanying page refresh) is necessary.

It's also important to remember that the Kindle is a black-and-white device. If your site uses text color to convey any useful information (such as what is or is not a hyperlink), re-work the design to accommodate a grayscale display.

Finally, keep pages short. The Kindle cannot scroll; long Web pages are paginated like books. Pagination with E Ink devices is slow relative to scrolling on a computer screen. If possible, keep all your content on the first Kindle "page" when viewed at the default font size.

Targeting the Kindle

Web browsers are identified using their "user-agent" string. The current version of the Kindle is broadcasting this user-agent: Mozilla/4.0 (compatible; Linux 2.6.10) NetFront/3.3 Kindle/1.0 (screen 600x800). It's beyond the scope of this article to describe how to set up your Web site to deliver different kinds of content to different browsers, a process that varies considerably with your site's technology.

How do you test your layout if you don't have a Kindle? There's no substitute for having the real device (tell your boss it's for "research"), and currently Amazon does not offer any kind of browser emulator. Some possibilities:

  1. Disable stylesheets on your browser and look at the output. Does it still make sense? (Instructions for disabling stylesheets; Firefox users should install the Web Developer add-on)
  2. Use a text-only browser like Lynx

Some Last Advice

Don't spend too much time on this process. The next version of the Kindle is expected soon, no doubt with an improved browser. Indeed, Amazon could offer a new version of the existing browser at any time. Most of the changes recommended above should take little time and money to implement, and can make a great difference in user experience.

In addition, optimizing your site for small-screen browsers can have other benefits: they allow an increasing number of mobile users to get quick access to your content, and aid accessibility for screen-readers and other non-standard browser types.

Reinventing the Book and Killing It are Separate Things

Richard Cohen has a bone to pick with Amazon, the Kindle, digital books, and anyone who threatens the welfare of bookstores, children and unknown literature. From Cohen's Washington Post column:

... over at Amazon they are inadvertently thinking of ways to make the world worse for children and for the grown-ups who love them to pieces. What Jeffrey P. Bezos, Amazon's founder, wants more than anything is to do away with the book as we know it. "Jeff once said that he couldn't imagine anything more important than reinventing the book," said Steven Kessel, one of Bezos's top guys. Kessel is in charge of digitizing everything in sight.

Nothing more important than reinventing the book? Not ending world hunger? Not taking Rush Limbaugh off the air? None of these? What's wrong with the book? I understand that it's bulky and expensive to ship and that it entails the consumption of paper, which is probably not green, but then what is? The book has been around for a very long time (Google the exact number of years, please), and I love it so.

Cohen's column adheres to the "book lover overreaction" we've discussed previously. Market forces and changing consumer tastes may indeed signal the end of traditional bookstores, and that's something to lament and fight against. But this idea that digital books have been set loose by entrepreneurial masterminds -- diabolical sorts intent on destroying the print universe -- is overwrought. "Reinventing" the book is not synonymous with "killing the print book." Digital books are nothing more than alternative delivery mechanisms for content. Their intent (if ebooks can have intent) is to expand choice, not eradicate the printed volume.

I can't tell if Cohen is saying goodbye to print books or bookstores or some combination of the two. His column is clearly a cathartic exercise, not a market analysis, but the association he seems to make between a downturn in bookstores and the rise of digital books is incorrect. Bookstores are in decline partly because consumers are purchasing their core product -- print books -- through online retailers like Amazon. Ebooks may eventually achieve widespread adoption and, by extension, lead to the shuttering of traditional bookstores, but that's not currently the case.

(Via Shelf Awareness)

Which Game is the Kindle Changing?

Labeling the Kindle a game changer is premature, says Liz Gunnison from Portfolio:

... the Kindle's target buyer would be a person who reads so much that they have ceased instilling books and periodicals with nostalgic value...yet not so much that they are rarely far enough from a computer to really need a separate device.

To top it off, one can imagine a single device (and Amazon account) being used by an entire household. And we're talking only about those that choose a Kindle, of course, rather than a competing device such as Sony's portable reader.

So, all things considered, how many Kindles does that work out to? Two million? One million? Five hundred thousand? [Emphasis included in original post.]

Gunnison's analysis looks at the Kindle as a book game changer, but Gary Frost from futureofthebook.com says the device is actually a shopping disruptor:

The book reading function is a decoy to disguise a portable shopping device. The one click is a well known Amazon purchase feature. The connected Kindle device makes this relation portable and the format is just as accessible for a baby register or power tools as it is for books. Its also worth a mention that Kindle sells print books.

Frost is on to something. Amazon built its early business on books, but it eventually diversified with thousands of additional product categories. The Kindle might follow a similar path: sink the first mobile-buying/digital-consuming hook into early adopters with the Kindle, then expand.

(Via Jose Afonso Furtado's Twitter stream.)

What if Ebooks Were the Dominant Platform?

I recently came across an old blog post from Harvard Business School professor Andrew McAfee that discusses the utility of the "technology flip test". McAfee writes:

At a conference years back I was sitting on a panel that was asked to talk about future of the book. As the discussion was heating up about the inevitability of the electric media, someone on the panel (I wish it had been me) proposed a flip test. He said "Let's say the world has only e-books, then someone introduces this technology called 'paper.' It's cheap, portable, lasts essentially forever, and requires no batteries. You can't write over it once it's been written on, but you buy more very cheaply. Wouldn't that technology come to dominate the market?" It's fair to say that comment changed the direction of the panel.

The ebook vs paper flip test is intriguing for a number of reasons:

  • It inverts the offense and defense: Ebook advocates become defenders and paper-book supporters become disruptors. Shaking off the vestiges of a default argument is always a good idea -- think of it as a "debate cleanser."
  • It amplifies the strengths of each format ... initially: When I ran through the flip test on my own, I at first honed in on the cost savings of ebooks (no paper, no printing, no shipping) and the sensory aspects of print books. But further review revealed deeper complexities to this debate. And that led me to ...
  • It upends assumptions: Print's dominant position in the real world causes me to challenge pro-print arguments, most notably the tactile experience overreaction that often derails discussions. But placing ebooks in the hot seat gave me a new perspective on ebook defenses. For example, if my default reading environment was electronic and networked, would I want (or need) a disconnected outlet? Would I crave solitude and a languid pace? Does the upside of ebook economics supersede the other reading/storytelling experiences I'm looking for, or would I welcome a print alternative the way I now welcome an electronic option?

What's your take on the flip test? Does inverting the argument open the discussion, or is this a diversionary trick that detracts from the issues at hand? Please share your thoughts in the comments area.

(Original idea and McAfee link via Reading 2.0 list.)

How Hackers Show it's Not All Bad News at the New York Times

News of a looming downgrade of NYT stock to "junk" status by Standard & Poor's sadly isn't all that shocking. I'm certainly glad I'm not an investor holding any NYT.

But there's something going on at the Times that probably won't make it to Silicon Alley Insider, much less the mainstream business press, and it's something that's starting to make me think the Times just might succeed in adapting to the changing rules of the media and publishing game (though there will almost certainly be many more casualties before it's over).

So what's the Times doing that's so important? They're hacking.

Not hacking in the nefarious sense, but in the original sense of experimentation, and curiosity, and solving interesting problems (as Paul Graham put it, "Great hackers think of it as something they do for fun, and which they're delighted to find people will pay them for.") How many other publishers are running blogs about their work with open source software? Even fewer are developing and releasing their own high-quality open source software:

Quite frankly, we wanted to scale the front-end webservers and backend database servers separately without having to coordinate them. We also needed a way to flexibly reconfigure where our backend databases were located and which applications used them without resorting to tricks of DNS or other such "load-balancing" hacks. Plus, it just seemed really cool to have a JSON-speaking DB layer that all our scriptable content could talk to. Thus, the DBSlayer was born.

That is not typical newsroom conversation.

But this isn't just about open source software, or even about some developers building cool software to run backend system. The Times has put developers right in the middle of the newsroom. At a MediaBistro event in May, Aron Pilhofer from the "Interactive News Technology" group at the Times (sharing the stage with their Editor of Digital News, Jim Roberts), talked about how the Minnesota bridge collapse was when they realized they needed to develop their own tools to cover the news with the web, and not just on the web. Less than a year later, when Hillary Clinton's infamous public schedule was released, they had the people and the skills in place to crunch 12,000 PDF documents (containing images of scanned documents) through a text-recognition program, on to Amazon's "Elastic Computing Cloud" and finally into a Ruby on Rails Web application providing full-text search across all eight years of calendars.

Just this week, the Times' Derek Gottfrid gave a talk at O'Reilly's Open Source Convention (OSCON) titled "Processing Large Data with Hadoop and EC2" based on work he'd done on the Times' archives. Again, this is the kind of talk you're not likely to hear at most newspapers (or magazines, or book publishers) these days:

I was able to create a Hadoop cluster on my local machine and wrap my code with the proper Hadoop semantics. After a bit more tweaking and bug fixing, I was ready to deploy Hadoop and my code on a cluster of EC2 machines. For deployment, I created a custom AMI (Amazon Machine Image) for EC2 that was based on a Xen image from my desktop machine. Using some simple Python scripts and the boto library, I booted four EC2 instances of my custom AMI. I logged in, started Hadoop and submitted a test job to generate a couple thousands articles — and to my surprise it just worked.

Earlier this month at FOO Camp I had the pleasure of meeting another hacker from the Times, Nick Bilton, part of the Times R&D lab -- the folks who built the impressive NYT iPhone App.

UPDATE: Nick Bilton points out via email that:

There were people from nytimes.com that were instrumental in building the NYT iPhone app also ... Is there anyway you can add a couple of words that the R&D Group 'worked with nytimes.com' to help build the iPhone app?

If you're worried about EBITDA and EPS, then you're rightly worried about the Times right now. But if you're worried about the future of journalism, and about the ability of established media companies to adapt to a digital world, there's also reason to be excited about the Times right now too.

Technology's "Killer" Distraction

A new search engine, Cuil, is attracting the requisite "Google killer" coverage. Thankfully, Seth Godin provides some much-needed perspective:

I have no doubt that someone will develop a useful tool one day that takes time and attention away from Google, but it won't be a search engine. Google, after all, isn't broken, not in terms of solving the iconic "how do I find something online using my web browser" question.

I have no beef with Cuil itself (the handful of queries I ran worked fine), but this "killer" business is another matter. In the history of tech prognostications, has an upstart killer ever successfully terminated its target? More importantly, what possible benefit do any of us get from this type of analysis?

I can only imagine the useful commentary we would see if the killer oeuvre could be stricken from the record. The bombastic flavor-of-the-day cycle might be replaced with actual thoughts about the future of particular applications and their accompanying industries. Perhaps we'd even stop shoehorning lightning-in-a-bottle success stories into unrelated products (e.g. the Kindle/iPod comparisons). And maybe we'd finally see that the exciting developments -- the products and experiments that really stir things up -- come from people who focus on creation rather than dominance.

As Seth eloquently notes:

... success keeps going to people who build new icons, not to those that seek to replace the most successful existing ones.

The Media Industry's Perspective Problem

A newsroom survey conducted by the Pew Research Center's Project for Excellence in Journalism touches on one of the major issues -- and failings -- affecting mainstream media: the power of flawed perspective. Here's an excerpt from "The Changing Newsroom" report:

Staffing for coverage of sports, local government and politics, police and investigative reporting, all grew in 30% of the newsrooms surveyed. Although not specifically measured in the survey, anecdotal evidence suggests that at least some of these gains have been driven by pressure to provide web content during the course of the day. Some of this content is often then "reversed published" back into the newspaper. [Emphasis added.]

There's a huge difference between "published" and "reversed published." A published piece of content -- be it an article, a podcast, a broadcast, or even a book -- is pushed into the world with a clear intent (inform, entertain, influence, etc.). But reversed published content has been stripped of intent. Its sole purpose is to fill space; whether it entertains, informs, or influences is secondary.

The whole concept of "reversed published," and the adjacent issues of print vs Web vs mobile vs broadcast, illustrates a fundamental flaw in the media perspective. Content should be defined by its audience, not by its container. If an article is initially published on the Web, that article must be geared toward the Web audience. If the same material later appears in the paper, that material needs to be geared toward the newspaper audience. Same goes for mobile consumers and broadcast consumers.

Repurposing material without regard for its audience is a luxury the media industry used to enjoy when it was a primary information conduit. The only difference is that years ago the Web was where rehashed shovelware was dumped ("Story continues on A12", anyone?). Early Web users quickly tired of media's detritus, so they looked elsewhere for useful information. Apparently, media organizations didn't learn from this past mistake because now they're pulling the "repurposed content" maneuver with traditional audiences. No one wants rehashed bits.

This is where perspective comes in. If a media organization continues to think in terms of content containers rather than content consumers, then it will inevitably default to "reverse publishing" and other bad habits. These days, as audiences scatter and company valuations plummet, every piece of content needs the justifications and intentions of fully published material.

Cloud Computing's Potential Impact on Publishing

If you use Google Docs or access email via a Web browser, you're already versed in cloud computing. Access to Web-based material is taking the place of downloads.

Cloud computing focused in the early going on software as a service (SaaS) applications, but Amazon, Netflix, Google, Apple, Microsoft and others are now tapping the cloud for content delivery (some of these companies focus on streaming entertainment, while others focus on content creation/management).

An interesting conversation about the cloud's impact on content publishers popped up recently on Peter Brantley's Read 20 list. Peter, by way of an an article link, noted that Amazon is moving some of its video distribution business into the cloud. From Last100:

Not only is Amazon utilizing streaming in order to deliver "instant" playback but it also means that content doesn't have to be permanently stored on a user's hard drive. As a result, Amazon is able to offer another potential benefit to customers: a virtual video library of previously purchased content, stored in the 'cloud' (on the company's own servers) ready to be streamed as many times and to as many compatible devices as the user has access to. While this will initially consist of PCs running Mac OSX or Windows, along with select TVs from Sony, in the future this could extend to many different devices, either through specific partnerships like the one currently forged with Sony, or by utilizing browser-based standards or any other technology or protocol Amazon chooses to support.

Expanding on Peter's post, Mike Shatzkin said the centralization of cloud-based content raises issues around digital rights management (DRM) and other access limits:

The cloud changes everything in terms of piracy and copyright. We are living in a transitional period where computer storage is decentralized. When that period is over, and the time is now not far off, everything is accessed from the cloud and it will be a relatively easy matter for rules about content access to be enforced by the content originator or distributor.

As others on the Read 20 list pointed out, cloud computing brings up additional questions around copyright and ownership. Toss in concerns about system reliability, open vs. closed clouds, and the potential for lock-in (or lock out) and you can see this rabbit hole growing deeper.

Cloud adoption may also represent an important moment in book publishing's digital transition. Publishers have enjoyed the past luxury of learning digital lessons from the media, music and film industries, but the wait and see approach may not work this time. If consumers come to expect access to their content -- all their content -- anywhere/anytime, publishers will need to meet that expectation ... or risk watching an unaffiliated company or industry step in.

Open Question: Should Publishers Develop Software Apps?

Book publishing's response (or lack thereof) to the iPhone 3G and the App Store has stirred up an interesting question around publishing and software development: namely, should publishers create their own software applications?

Sara Lloyd from thedigitalist says a focus on content, not software, is key:

Interestingly the price of apps [in Apple's store] is already plummeting as free apps get more highly and more frequently rated and the paid-for apps drop down the ratings. Perhaps this suggests even more strongly that the App is not The Thing; it is merely a container or a channel for the content, which will still be The Thing.

On the other side, James Bridle from booktwo.org says publishers are the natural source for e-reader apps:

Most ereader technologies are built by techies who put the technology before the reading experience: the combined skills of typesetters, print designers, editors and technologists that only publishers possess could, with the right direction, produce a far superior ereader app than any we've seen so far.

What's your take? Should book publishers move into the software domain? Please post your thoughts in the comments area.

Survey of Book Industry Reaction to New iPhone and App Store

Kassia Krozser struck a nerve earlier this week with criticism of the publishing industry's slow approach to the new iPhone and the just-opened App Store. From Booksquare:

Call me crazy, but I'd expect an industry that salivates over moving 150,000 units to be all over the potential for reaching seven million "mobile is the future" customers. Are you not out there, listening to readers, gauging their interest? They want, you have, and you're still hiding the goods. I get this isn't the largest market you have, but is that an excuse to sit on the sidelines?

Sara Lloyd doesn't see long-term value in this current burst of iPhone excitement. From thedigitalist:

... apart from a few digital PR points scored against competing publishers, there doesn't seem to me to be any huge value in first mover advantage here for publishers, unless we want to make the decision to become software developers. The perception is that the App Store has 'opened up' the iPhone to publishers and to e-reading. The reality is that the iPhone has always been enabled for e-reading ... So, whilst we have been awaiting the launch of the App Store with interest, we didn't see enormous advantage in, for example, creating a reading app ourselves or Being There on Day One, just for the sake of it.

Expanding on the software theme, James Bridle says book publishers are uniquely positioned to develop ebook applications that meet consumer needs. From booktwo.org:

... who better than publishers to craft such software? Most ereader technologies are built by techies who put the technology before the reading experience: the combined skills of typesetters, print designers, editors and technologists that only publishers possess could, with the right direction, produce a far superior ereader app than any we've seen so far.

Broadening the analysis, Michael Cairns says the "silo" mentality displayed in this iPhone debate is a competitive obstacle that needs to be put aside. From PersonaNonData:

To bring us back to the iPhone circumstance, as long as publishers continue to think in terms of traditional functional silos and roles and responsibilities they limit themselves in their ability to leverage their assets. In contrast witness Amazon which has never considered any aspect of the publishing value chain to be off limits and more publishers need to think in this manner if they want to redress some of the advantages Amazon and others retain (or new competitors develop) in the marketplace.

(Many of the links and call-outs in this post were provided by Peter Brantley via his Read 20 list.)

Ebooks Abound in New iPhone Apps Store

Today my email inbox (and the twittersphere) is brimming with comments about ebooks comprising 8% of the currently available apps in the new iPhone Apps store. These are not all ebook readers, mind you, some appear to be individual public domain titles available for $.99. This may well just be low-hanging fruit for developers (packaging up text and/or html into an app is probably a great way to get your feet wet with the iPhone SDK), but it's still worth noting. There's already been some interesting activity around ebooks on the iPhone (like Readdle and TextOnPhone), but iPhone 2.0 may prompt a real surge in ebook activity on the iPhone.

Open Question: How Can Ebooks Improve the Reading Experience?

In "Random thoughts about the Kindle," Seth Godin suggests three ways the Kindle could improve the "act of reading a book":

* Let me see the best parts of the book as highlighted by thousands of other readers.

* Let me see notes in the margin as voted up, Digg-style, by thousands of other readers.

* Let me interact with hyperlinks and smart connections not just within the book but across books.

What suggestions do you have? How can digital books -- or, more broadly, digital content -- improve the reading experience? Please share your thoughts in the comments area.

Exploring DIY E-Reader Platforms

I've been working with the EPUB open ebook format a lot lately, but when I want to read a book in it, I have to use my computer. There just aren't any devices which support it yet. Naturally this leads me to wonder whether I could build my own e-reader.

I'm not a hardware person, but the last few years have seen an emergence of open hardware platforms designed to allow even ordinary programmers like me to modify and customize small devices. As far as software goes, an e-reader is pretty straightforward: it's just some text on a screen. That shouldn't be too hard, right?

Surveying the landscape of hardware options, I've ranked below a variety of devices from "friendliest" to "most-intensive DIY." I'm not addressing PDA or phone devices here, largely because I consider their screen size and text rendering insufficient (but plenty of people disagree).

The Chumby -- With a 3.5" touch screen and reasonable $175 price tag, this little wireless computer in a bean bag is an obvious candidate. There's a full-fledged development environment and large community of users. Most Chumby applications are written in a lightweight version of Flash, which is easy enough to develop in.

It has a few downsides, though. The Chumby doesn't have much storage space at all, so any ebooks would have to be saved online and streamed to it, a page or a chapter at a time. Since it's meant to be an always-on wireless device, that seems doable. The screen might be too small to comfortably read lots of text, as it's meant for short bursts like RSS feeds or Twitter updates.

Unfortunately, it's powered by a wall outlet, with only a small 9-volt battery for emergency backup. People on the hardware forums have managed to hack in rechargeable batteries, and I wouldn't be surprised if a totally-wireless Chumby is forthcoming. [Disclosure: O'Reilly AlphaTech Ventures is an investor in Chumby Industries.]

BugLabs -- The most open of the commercial hardware platforms, BugLabs sells individual pluggable modules that support various features, from touchscreens to cameras to GPS. It looks like a great platform, but it's very expensive ($349 for the base module plus $119 for the 2.5" touch-sensitive screen). The screen is probably too small for comfortable reading, but the company Web site promises a larger display soon.

Both the Chumby and BugLabs have touchscreens, which is key for making small screens more usable.

The Kindle -- All the heavy lifting has been done already to get into the Kindle filesystem and peek inside. It's probably too difficult to extend the existing Kindle environment without true source code, but it might be possible to do some simple things, like add new fonts. Few people have really explored hacking on e-ink devices, largely due to high cost and low availability. I suspect when the first color e-ink devices come out, used black and white ones will become popular playthings for enthusiasts.

YBox2 -- For the ultimate DIY experience, the YBox2 platform is a pile of electronic parts you solder together and assemble in an Altoids tin. It doesn't come with a touch-screen, or any screen at all: you connect it to a television or monitor. It uses the tiny Propeller chip, which powers many hobbyist devices and small robots. Like the Chumby, YBox2 comes with networking capability but little storage, and would need to stream book content from the Internet. The networking isn't wireless and of course there's no handy rechargable battery, but if you are the kind of person who can build a YBox2 you probably know how to make those too. I am not that kind of person.

While I'd be happy to crawl around a hacked Kindle, I know I'm not ready to program my own microcontroller. BugLabs seems great from a developer standpoint, especially when they release a larger screen, but I'm unwilling to shell out almost $500 just to experiment. The Sony Reader doesn't have networking, so that's much less interesting. Perhaps a Chumby is in my future. Any other options?

Stay Connected
RSS TOC RSS Feeds
 Blog Feed
 News Feed
 Combined Feed
 New to RSS?
Newsletter Subscribe to the TOC newsletter.
Tarsier Icon Follow TOC on Twitter.
Newsletter Join the TOC Facebook group.
TOC Widget Get the TOC Headline Widget.
Search
Conference
Tools of Change for Publishing Conference

Save the Date! TOC 2009 will take place Feb. 9-11 2009 at the Marriott Marquis in New York City. Sign up for the conference newsletter to hear about important dates and developments as the show approaches.

TOC DVDs
TOC 2008 Tutorial DVDs

Now available. These tutorials dive into the necessary skills and tools critical to the future of publishing.

TOC Job Board
Tag Cloud