Yesterday, the New York Times announced that it would be selling 13% of its front page real estate for advertising.

The New York Times front page, Jan. 5, 2009

Back in August of 2007, they sliced off 1.5″ to save on printing and paper costs.

The New York Times loses 1.5 inches on August 6, 2007

The page is dead, or dying, indeed.

Clay Shirky provides some excellent perspective:

…People will always be interested in information relevant to their current situation. The part of that that’s really hard journalism, like covering the city council or whatever, where it’s long and it’s boring but you got to do it, is going to increasingly have to find new business models, because we can’t just rely on Bloomingdale’s to subsidize that anymore with display ads. And so we’re going to have this move to what I think are going to be a lot more nonprofit models for news, a la NPR. But, much more importantly, the idea that there are news organizations and other kinds of organizations, I think, is just going to break down under the weight of the evidence.

Read the entire interview. Part I and Part II. It’s worth it.

* For more on the future of journalism itself, Cliff Huang and Atley Kasky over on the GOOD.is blog have an excellent take: “A Glimpse at the Future of Journalism.”

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.

Note the price differential (list price of $29.95 and Kindle price of $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:

Kindle tripping over an ordered list

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.)

Not just a crappy photo; the type is illegible in real life.

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!”

Awkward line breaking on centered captions

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:

Justification without hyphenation

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.

Depends on who you ask. I like to define a wireframe as equivalent to a keyframe in a storyboard. (The problem is that most websites are not linear, but that’s a topic for another post.) I’ve done thousands of wireframes in my career as an Information Architect/Interaction Designer (have we settled on an appropriate title yet? I guess not). I don’t live for wireframing, even though making them is one of my most marketable skills. I have developed a very pragmatic view of it, having seen how my wireframe “bibles” are clung to by business customers, salespeople and QA, and then unceremoniously forgotten after the first beta launch. The tricky thing about wireframes is that they can mean different things to different people, depending on what stage of the project you’re in.

So now I have developed a Zen-like detachment with wireframes: they are ephemeral. In fact, I make it a habit of suggesting to clients that we schedule into the project plan a wireframe bonfire, usually sometime after launch. Every time, I get a double take and a laugh of disbelief. Why a bonfire? To emphasize the reality of the end goal, the working application itself. Users don’t use wireframes. Also, I want to make the point that wireframes are dead and the application is alive, that decisions that may have looked great on paper may, in reality, not work when put in front of real users.

The Evolution of Wireframes

Wireframes need to evolve over the course of a project. For larger projects (3 to 9 months) I’ve found it useful to clarify both for myself and the business customer what to expect from wireframes at different stages.

Lo-Res

In the nascent stages of a project, when ideas are being thrown about by all stakeholders and everything is in flux, lo-res wireframes may appear on anything from whiteboards, scrawled on the backs of napkins or scrap paper. Think of them as thumbnail sketches.

Lo-Res wireframes should be

• Sketchy
• Loose
• Quick
• General
• Monochromatic

An example of a Lo-Res wireframe

Usually, I will gather these scraps of paper and translate them into digital roughs.

A digital Lo-Res wireframe

Note the “default” style for everything:

• Labels should be descriptive of the content. Avoid using real copy (except for logo)
• Content areas are grey blocks with the label in the top left corner
• Multimedia or graphics are indicated by a different grey box, with label centered in middle
• Buttons are indicated by rounded corner and centered label text

Not using copy is important at this stage because you don’t necessarily want the client focusing on details yet. It can be distracting from the larger goal, which is that you want to get agreement and sign-off on basic proportional representation of types of content and their general hierarchy. At this stage, you should be able to use this to answer the question: What are the primary, secondary, and tertiary content blocks on the page?

Medium Res

Once you have established what content needs to appear on the page and have a good sense of their general hierarchy, you can start to add more detail, in the form of more realistic headings, navigational copy, and basic indications of functionality.

A Medium-Res Wireframe

As you can see, there’s a little more resolution here, like you’re adjusting the focal length so that you can make out more clearly the major elements of the screen. But you’ll notice that not everything is in focus yet, namely the body copy, which I like to represent as grey bars to give an idea of type density without getting bogged down into specifics yet.

I’ve found that once you start introducing dummy copy and dummy data, the viewer’s expectations and reactions start to change, regardless of your frantic entreaties to disregard such characteristics. There is a point at which our attention begins to hone in and we start to notice certain elements, unconsciously or not, and it takes all of your discipline and awareness as creator of these documents to modulate the viewer’s expectations through the blurring and smudging of various elements (at one point I considered applying a “Pencil Sketch” filter in Photoshop to my wireframes). But at some point, you will have to address these things, such as color, highlighting, typography, dimensionality, and data, which will bring your wireframes to to a higher level of resolution and expectation.

Tomorrow: I’ll dig up some Hi-Res wireframes and talk about clickable prototypes, the ultimate in high-resolution wireframes. Stay tuned!

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.

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…