The Kindle

With great fanfare Amazon just announced its dedicated ebook reader -- the Kindle. The web is "ablaze" with coverage: starting with the Newsweek cover story, "The Future of Reading", and continuing with the Kindle Product Page.

Overview

Ars Technica, CrunchGear, Gizmodo, PaidContent, and BoingBoing, have reviews. And there is no shortage of commentary:

• John Gruber (DUM),
  
• Seth Godin (you won't find me on Amazon's new book reader) 
  
• Nick Carr (the Luddite Dream of Jeff Bezos)
  
• Mark Pilgrim: (The Future of Reading (A Play in Six Acts) 
  

Wired has a brief comparison of the Kindle vs. the Sony Reader, and Rothman's Teleread Blog , where I first heard about the device months ago, comments on the design and format issues.

The feature set is unremarkable (essentially the same hardware specs as the Sony reader; they both sport the 166.67 dpi E-Link screen), with the standard ebook functions: zoomable text, search, annotation, -- but what distinguishes the Kindle is the connection to Amazon -- easy ordering and downloading content from the Amazon via always-on EVDO wireless networking. The connectivity comes for free with the device, but subscriptions fees apply to magazines, newspapers, and surprisingly, blogs.

The Amazon connection also brings 90,000 titles at introduction--nice---but this leads to two questions: what about the other millions of titles, and at what rate will the Kindle-compatible titles grow. It seems to me that cutting deals with individual publishers is not going to cut it -- this is not Steve Jobs dealing with a few record labels -- what is needed is a simple method for generating content for a device, so that both mainstream and long-tail content are available. Today this is answered by PDF, and the .epub format also promises to fulfill this need -- neither of these formats is currently supported natively on the Kindle. The supported file formats are: Kindle (.azw), text (.txt), unprotected Mobipocket (.mobi, .prc), Audible (.aa) and MP3 (.mp3). Amazon supplies (for fee) conversion of content via an email address assigned to each Kindle, and other conversions can be managed via its Digital Text Platform.

The Design, Marketing and Positioning

The design of the Kindle is fugly but seemingly functional. It includes a scroll-select wheel, and a physical keyboard---this feature alone breaks the "bookiness" that the device is striving for. But a physical keyboard is probably required given that the slow responding E-ink screen probably won't adequately support an on-screen keyboard. It will be interesting to analyze the UI and general user experience of the interface, but the reviews and videos to date don't provide enough detail yet. I'm hoping any UI or functionality bugs can be fixed via software updates.

In the promotional videos, Bezo's introduction, and the Newsweek piece, there is an emphasis on the act of reading -- note that the spokespeople recruited to push the device, Toni Morrison, Michael Lewis, Daniel Handler are authors, not geeks. I also note that the demo video has a "Kindle Dude", similar to the "iPhone guy" to introduce its features -- but unlike the Apple personality, K.D. gets out of the studio, putting the device through its paces in the park, coffee shop, the airport, and at home.

The Rocket ebook , REB 1200 , Sony Librie , Sony Readers, Irex Iliad, Kindle. It feels like the period between 1977-1981 when the personal computer marketplace was shaping up. Lots of machines that taken individually had interesting features, but none that reached the sweet spot that defined a product category.

Kindle, sadly, you are no IBM PC.

Although it feels like a device Steve Jobs would have rejected, the basic concepts are sound (take-your-content with you, nice screen, easy connectivity, document conversion and self-publishing), there is so much that can be improved: the design, DRM/lock-in, a more open platform.

Where is my device that can order content from not just from Amazon, but from other outlets as well, one that can easily and beautifully display any blog, not just selected ones (yes, I know the limited web browser fixes this somewhat, but what about a Google Reader-like application built into the device? Whoever develops a beautiful, universal container for my purchased, commercial, web, and personal content will win, Kindle points the way, but does not quite reach it.

Programming Infographics with Processing

In learning Processing, it occurred to me that it could be used to produce visuals previously done via traditional tools like spreadsheets and presentation software. Using Processing means that layout decisions are programmed in -- for example the placement of pictures to annotate a barchart; instead of tediously placing each graphic, the placement is automatic. To test this, I used this graphic, produced in Keynote as a basis:

Here is the same data, but produced by code in Processing:

In comparison to the original Keynote graphics, I toned down the bar chart color significantly, and also plotted the products pictures as data, instead of axis labels.

The Data

Of course, visuals must be data driven, and Processing can take input from files; in this case, tracking stock price with other events: Apple Stock price to personal purchases,(incidentally this kind of visualization can based from other things as well, Google products. vs. stock price, Fat content of foods, IMDb ratings, or a drug companies product launches vs. stock price, etc.

The relevant stock data can be obtained from Yahoo Finance -- select the relevant time interval, and then download the data as a CSV file. Note that these visualizations work best if there is not too many data points.

The data file that my Processing code uses consists of these fields:
date, stock price, picture file, product name (with the exception of the first line, used to specify the title

for example:

Apple Purchases vs. Stock Price
2002-04,12.4,tipb.jpg,Ti PowerBook
2002-08,7.38,jaguar.png,Jaguar
2003-04,7.11,itunes.jpg,iTunes
...
2007-10,172.75,leopard.jpg,Leopard

The code

The code (166 lines) is broken down into these sections:

1. Read in the data, with sanity checks
2. Define major object locations based on percentages relative to the graphic's width and height (for example, the title is defined to be located at 7% of the overall height)
3. Define scaling factors
4. Show Title
5. Show the Y axis label, and the Grid
6. Plot the data

The display of titles, bars, data values, labels, grid, images, names, and dates, can be independently toggled on or off, controlled via boolean variables.

Observations

The model visual has the traditional barchart, but invoking the option to remove the grid and bars allows the the product pictures and the stock values to serve as data points:

Here is a slightly different twist: Relating the introduction of "iconic" Apple products with the stock price:

Having complete control over every aspect of the graphic is freeing --- with Processing, you are not constrained by what a standalone software package can do --- if you can conceive it, you can easily program it in without waiting for Apple, Adobe, or Microsoft to add the feature or behavior. (Another useful side effect is that your graphics won't look like everyone else's).

Processing encourages this interactive "sketching" style. (in fact instead of "code" and "graphics", the Processing environment refers to these collectively as sketches.

I note that using percentages and not hard-wired "magic" numbers means that the graphic will scale when the height and width are adjusted. This means that you can pick the correct aspect ratio for a given data set and the various graphic elements remain in their proper places. Also, because each section of the graph is drawn and placed independently, re-arrangement and experimentation is easy: Need to move the product labels -- adjust one number -- hit the execution command, -- boom. Instant gratification.

I plan to continue this with other types of data -- See the flickr set for more.