Monthly Archives: April 2009

Kindle: Becoming An Expensive Way To Read…

OK, I know this is my own fault…

I love the Kindle eBook device, and the ability it gives me to carry many books around with me, and buy them wirelessly, anywhere.

But it’s starting to look like a very expensive option. My first Kindle died, as readers of this blog will know, after I accidentally knocked it into the bath at home.

Although expensive, it wasn’t deeply mourned – since it gave me an excuse to go out and buy the much-improved Kindle 2, (which I’d have been tempted to do, anyway).

K2 happens to fit very neatly into a 6″ Ziplok sandwich bag, almost certainly averting the possibility of a watery grave similar to the one which claimed my first Kindle.

However, I was at an all-day meeting last week, and I was showing it off to a few people at my table. Then I received a phone call which meant I had to cut hurriedly out of that meeting and go to another one.

I had a lot of meetings last week. So it was two days later before I noticed my Kindle wasn’t in my backpack with the laptop I’d disconnected and stuffed into it when the call came.

I’ve been checking with receptionists, security, etc. – but it hasn’t turned up so far.

So now I face a hard choice. In order to read the 70-or-so books I’ve already purchased, do I shell out the price of a third Kindle? (Which would bring my Kindle outlay so far up to over $1000!).

Kindle, or a device like it, would be great for students. But I’d suspect there would be a fairly high device casualty rate.

I recently saw data from a “Kindle teardown” which put the actual hardware cost of the device at $185. When you add to that the cost of the free wireless networking support, etc, it’s clear Amazon probably isn’t making much profit on each device. Which means there’s not a lot of opportunity for future price drops, unless perhaps sales really take off and there’s a chance to cut unit cost by increasing manufacturing volume.

Will I buy another Kindle? Oh, probably. I’ll put it down to the cost of being an “early adopter” – and be a lot more careful about where I set it down in future…

Three out of four major Web browsers now support FullScreen mode

I’m grateful to Richard Fink for tipping me off to the fact that Beta 2 of Google’s Chrome browser now supports a FullScreen mode (keyboard shortcut F11) in which you can make all browser chrome disappear, leaving only the content you want to read.

It may seem trivial to you, but it’s clear to me from all the experiments I’ve done over many years that when you really want to read something, anything which appears on the screen other than the actual content is a distraction.

You can’t help it – none of us can. We’re all Homo sapiens Version 1.0, with a hunter-gatherer perception system which uses foveal vision to read, but whose peripheral vision remains highly sensitive to data – especially from the extreme left and right edges of our visual field.

Think about it. Anything appearing in those areas has the potential to be a serious threat to our safety in the natural environment in which our perception developed. Our brains have developed a hair-trigger for data appearing here, so that our “fight or flight” response can be tripped in order for us to act quickly enough to avoid danger.

The problem with FullScreen today, though, is that almost no content exists which has been optimized for it. Full Screen on the laptop on which I’m writing this means 1440 x 900 pixels. On your screen, it could be 1024 x 768, 1920 x 1200, or some other configuration.

Even worse, the pixels themselves are not absolute measurements. They could be 1/96th of an inch square, 1/147th of an inch square, even 1/208th of an inch square. What that means is that any area described in pixel dimensions by a designer assuming 96ppi could actually end up being only one-quarter of the size on someone else’s machine!

This is why I’m so insistent on the need for adaptive layout on the Web. We need a layout system which:
  1. Uses absolute, not relative, measurements.
  2. Interrogates the operating system and determines actual screen size and pixel pitch.
  3. Translates the absolute measurements of the original design into pixel dimensions for the actual display being used.
  4. Determines the optimum number of columns for best readability on that particular display given the text-size the user prefers for reading.
  5. Has much more granularity than today’s browser “Text size” options (you should be able to pick 10 point or 11 point for body text, for example).
  6. Lays out the content accordingly – in pages, not in a bottomless scrolling window.

It all sounds like a tall order, and a lot of work. But it isn’t rocket-science, and much of it has already been done in proprietary formats like Windows Presentation Foundation and Adobe AIR. It’s time we had the same thing on the Web.

FullScreen support is only a small part of what’s needed. But it’s another brick in the wall. I hope Safari will get on board soon. It should be easy, since it’s using the same Webkit as Chrome…

Distributed Proofreaders: What your work could look like if it was paginated…


The Dance of Death created by Distributed Proofreaders for Project Gutenberg, with the browser in Full Screen mode.

I’m indebted to Juliet Sutherland for commenting on this blog, and especially for pointing me towards the work being done on books for Project Gutenberg by Distributed Proofreaders.
As Juliet points out, their aims are not exactly the same as mine. They are trying to “make the best of the Web as it is today”, while I and some others argue that the way to make a lot of things better on the Web is to expand what you can do on it.

Readers of this blog will know I’m a proponent of being able to do adaptive pagination on the Web – paginated content whose layout adapts to fit the screen on which it’s being viewed.
People like Joe Clark (actually, I don’t think there are any other people like Joe) would have you think that I’m a heretic, who wants to “turn the Web into outmoded print layouts.
That’s not what I’m advocating at all; what we have on the Web today should stay – but there are better alternatives for many types of “reading” content, and those should be added to what we already have, thus expanding the range of possibilities.
Then people can make up their minds what they prefer, instead of having to work within silly, outmoded constraints like “Web pages always have to scroll in a bottomless window.
As I’ve said elsewhere, that particular constraint exists only because the software engineers building the first publicly-available Web browser, NCSA Mosaic, took the easy shortcut of displaying Web content in a bottomless scrolling window in order to avoid the harder layout problem of pagination. It’s become part of the fabric of the Web, and it’s high time it was questioned.
Distributed Proofreaders has done a great job on books – working within the constraints of the Web today. Juliet pointed me to “The Dance of Death”, a 16th Century book by Holbein, with fanastic woodcuts, as an example of how their work can adapt to different screens.
Here are some thoughts on opening up the book and examining it and its markup, and some ideas on where I’d like to see this type of content be able to go in the future.
None of this should be construed as a criticism of what DP has done (although I do have minor niggles like the use of “inches” and ‘feet’ marks instead of proper typographer’s quotes). This DP book has been proofread and set with great care and thought, and if it’s a typical example, then DP is to be congratulated on a job well done.
Since DP doesn’t specify typefaces or fonts in the books it does, at first all the text appeared in Times New Roman – the default font in most browsers for pages that don’t specify fonts.
Now, TNR was a great print face in its day. It’s not very nice on screen, because it has a small x-height. And it really does look old and tired. Part of that is no doubt because it has been the default font for documents in word-processing software for decades. It has, not to put too fine a point on it, been beaten to death. But that aside, it does look “old-fashioned” – and not in a nice way…
The first thing I did was change my default font in Internet Explorer 8 to Cambria. Instant improvement! Cambria is the best serif face for reading on screen, no question, and this book looks great in it. (I’d choose Calibri as my favorite sans serif). Another way to do this would be to switch CSS stylesheets (which Internet Explorer now supports, since Beta 2 of IE8.
Incidentally, Juliet had the gripe that many of the problems DP faces were the result of trying to get pages to work with Internet Explorer. I hope that will become a “gripe of the past” now that IE8 has shipped using Web-standards rendering by default.
Next thing was to play around with browser width, by re-sizing my browser window. As Juliet points out, the layout adapts very well to changes in browser width, which would equate to different screen sizes.
However, on a larger, modern laptop display, there’s so much unused screen either side of the browser window that the “book” gets lost. There’s too much distraction either side – even if it’s only a large area of unused white screen.
And while the content adapts to width very well, it’s still a less-than-optimal scrolling read…

The Dance of Death in a narrower browser window – still a long way short of the immersive experience of reading a printed book.
Since Juliet sent me this link yesterday, I’ve been experimenting with different layouts to create an improved, paginated version of this book, just to show what it could look like. But this morning an email arrived from my colleague Mike Duggan in Ireland, with a really nice paginated layout.

Mike’s a visual guy, a great typographer, and tends to do his mockups in Windows Paint. So this is just a .jpg. But it’s easy to see how it could be created on the Web, using a CSS stylesheet plus multicolumn and hyphenation Javascripts.

Doesn’t it look much better than most content of this type we see on the Web? With a layout like this, in Full Screen mode, you could truly have an immersive book-reading experience.
Mike Duggan’s mockup of a paginated layout for The Dance of Death
What do we need to be able to do this on the Web? Well, the biggest obstacle is that today you’d have to paginate it manually, which is not only time-consuming, but means you have to decide upfront on a fixed size – and that’s terrible.

With AJAX, you could get the window size from the operating system, and use that not only to calculate the optimum number of columns, but the depth of the columns in which the content would flow.

You really don’t want to be dependent on Javascripts for multi-column and hyphenation. I’ve talked about the problems of a DOM-based multicolumn .js elsewhere in this blog. Those functions are much better done with the layout and composition engines of the browsers – which are much more sophisticated.
You’d like to be able to just create a Master page, then hand off the actual setting to the browser – whatever browser the reader is using – and have create as many “new pages” as it needs to place all the content.
You’d want graphics to be scaled to fit a grid determined by the AJAX calculation. That grid would be based on multiples of body-text line-height – and would change if the reader, for example, wanted or needed to read in larger type.
There would be common elements for every page. You’d need to increment page numbers. The “virtual pages” created would need to be temporarily stored in a cache somewhere so the reader could navigate the “book”.
There are all kinds of details like this which would need to be thought through. And there would certainly be HTML and CSS standards developments which could help.
There are issues like the one pointed out by Richard Fink, of how you index and reference in a book which has different page numbers for different readers. (My suggestion for this is to take a leaf out of the Bible, and refer to passages by Chapter and Verse. Amazon’s Kindle uses “Location numbers”, which works but is pretty ugly).
That’s why this kind of innovation shouldn’t be done in any one browser. It needs to be a collaboration involving them all. It has to become an extension to existing Web standards.
For example, the CSS3 standard for multiple columns allows you to specify columns either as an integer number – which means column width floats, or by specifying a column width – in which case the number of columns floats. It would be nice to be able to specify upper and lower limits for column width, so you’d get smooth reflow as window size changed.
I know my own personal ideal (and that of Mike Duggan and another expert colleague, Geraldine Wade) is to use my browser in Full Screen mode. But that may not be what everyone wants, and they should be free to choose what they prefer. If our way works better for them, that’s what they’ll end up using.
There’s a lot of work needed to make this happen. But as far back as 1984, I saw an unknown software application – running at that time only on the Apple Macintosh – which would let you create a Master Page grid for any size of page, then allow you to autoflow content into it. The application would automatically create as many new pages as it needed to place all your content.
That little application was called PageMaker, and it created an entirely new market for software, fonts, printers etc. called DeskTop Publishing (it was the era of the capital letter in the middle of words).
Is anyone really trying to tell me that the Web can’t be made capable of doing what was easily possible a quarter of a century ago? We need it to become a publishing platform capable of the highest-quality layout and typography people can imagine.
I have an OnScreen Reading discussion group over on FaceBook where anyone is welcome to get together and talk about all of this. Ultimately, though, I’d like to see this discussion take place under the auspices of the W3C or the CSS working group. Maybe it’s already happening, and I just don’t know about it…
Word of warning: I’m not interested in flame wars over on FaceBook. People do need to be able to argue their point of view, if it’s done in the spirit of moving forward – but not as adversaries, scoring points. I’m keeping myself as the only admin on that group, so I can throw off anyone I judge is getting out of hand.

Experiments in Web Readability 3: A News Magazine Feature

Before: The start of a feature article on the Newsweek Website

After: The same first page – but laid out for readability. Don’t forget to put your browser into FullScreen view (F11 – if you have one of the two browsers that support it…)

My next project was one that’s really close to my heart. A few weeks ago, I came across a GREAT article in the online edition of Newsweek about the 2008 Presidential Campaign. It was full of terrific background on the candidates, the way they and their teams thought and acted, and the various phases that each of their campaigns went through before Obama’s victory.

The writing was outstanding. But the readability was absolutely AWFUL!!!! It was a struggle to plough my way through what should have been an amazing reading experience, with well-written, engaging content.

So first I tried to analyze what was wrong, then began experimenting. I knew I couldn’t do it exactly as I wanted with today’s Web technology. But I knew instantly that I could make it a lot better.

The first thing that’s wrong is the same problem with every news site I’ve seen – it’s just far, far too busy. In the rush to become “Webby”, they’ve created pages with columns of hyperlinks off to each side, videos you can click on, etc – and in the process they’ve broken up the writing in horrible ways, making reading a disjointed experience, unlike the printed Newsweek, which you can sit down and read at your leisure, soaking in the words like floating in a nice hot bath….

It’s worth noting that Newsweek’s pages have TEN PAGES of script and coding before the first content even appears in the HTML!

If you add to that the distractions of Web browser chrome, you’re really stacking the odds against an acceptable reading experience.

Now I’ve seen and tried so-called “bookmarklets” which generally use a Javascript to strip out only the text (or text and “significant” graphics) from a Web page or article to give you a “readable” version. Every one I’ve seen so far “throws the baby out with the bathwater” and turns what should be a great visual experience into a boring one. Usually you end up with nothing but text, no graphics, a layout that uses only the center of your display, etc.

It’s like using a flamethrower to treat an outbreak of acne…

The other big problem I see in news websites is that in the rush to replace revenue from print ads with Web ads, they’ve stuck really intrusive ads in really instrusive places.

You get stuff that flashes at you. Our Homo sapiens version 1.0 perception system treats movement at a Priority0 interrupt. We have no choice but to pay attention, because movement to a hunter-gatherer equals either Threat, or Lunch…

Trying to read when that’s going on is like trying to read a book in a cageful of lions. For more on this, read my Paper, The Magic of Reading.

Advertisers need to realize that catching our attention in this way is totally counter-productive. Yes, we have to look. But we deeply resent being distracted in this way. Modern humans need their attention to be wooed – clubbing them over the head went out with the cavemen!

The last thing you ever want to do is buy anything advertised in this way.

Don’t get me wrong. As a newspaperman, I’m a realist. If people aren’t paying for Web content, then advertising revenue has to be able to support these news-gathering organizations.

Advertising doesn’t need to be distractive or intrusive, just because it’s on the Web. People buy issues of the printed Vogue magazine as much for the adverts as for the other content. The adverts look great! They don’t distract, because I have the option to page past them if I want. If they’re attractive enough, I won’t – and a whole multi-billion dollar print advertising industry was built on that premise.

I’ve worked on a couple of online projects at Microsoft in which we’ve created really great adverts. I’ve already spoken about adaptive adverts in the New York Times Reader. Those change to fill the available space as content itself reflows adaptively when either the window is resized, or the reader changes the type size (which they need to be able to do).

In another project, a colleague commissioned an agency to build onscreen ads which were so much BETTER than anything you’d ever seen in print. And they can have sound, be interactive, be animated, or contain video. Just as long as you can turn off the action when you want to focus on reading.

So it’s not that onscreen advertising is evil – it’s just that no-one’s doing it right yet. I included an advertisement for Rolex watches, taken from the Newsweek website, in the second page of my version of the article. The original was actually animated: the watch hand swept around the dial. That might not bother me when I was reading. If it did, I ought to be able to click to turn the animation off and on.


Second page of the Newsweek article, with advertisement. Ads ought to be able to span one, two or three columns – or even be full screen.

So I started playing around with various layouts. I liked the navigation strip Newsweek had used, with the “Secrets of the 2008 Campaign” across it, and links to the various sections. That worked very well with the kind of navigation I’ve shown you in my previous experiments. All it needed was to add page turn buttons (and link them to the Left and Right arrow buttons on my keyboard).

I haven’t made the strip interactive yet, because I’ve only done one section of the article. But you can see how it would be done: make each of the headings – Highlights, Chapter 1, Chapter 2 ,etc – a “hot spot” with a link to the relevant first page of each section…

Again, I decided on pages of 1440 x 900 pixels. I don’t like fixed pages, but there’s no easy way (no way at all, really) to get exactly what I want today without using them (sigh!).

I started doing some mockups, and sent them to colleagues. Mike Duggan came up with a great layout, although I modified it and he may not agree my modifications are better. He had the same four narrow columns, but I found his proposal to set the text ragged right gave an effect which was too distracting in that column measure, and so I made the body text justified instead.

If you use justified text on your website, then you really need to use hyphenator.js to hyphenate it – otherwise you end up with awful word spacing, especially in narrower columns.

I used another javascript to do multiple-column layout. I’ve mentioned before, it uses the DOM, doesn’t understand anything smaller than a paragraph, and therefore is challenged when it comes to breaking longer paragraphs at the bottom of columns.

For that reason, I apologize to the Newsweek journalists who wrote the content. I’ve had to chop up their longer paragraphs to try to overcome this technical problem. Doing this job properly would involve using the much more sophisticated layout and composition engine of the browser itself – which is how it should happen in the future.

Remember, I’m stuck with using tricks to overcome the limitations of the Web today. And trying to influence the Web of tomorrow in the process.

The body text is Cambria, my favorite for sustained reading. All the fonts I used are embedded using Embedded OpenType. The font objects were all created with subsets which contain only the Basic Latin character set to keep the size down. Means I never need to create new ones, and those font objects are available on my site for every one of the pages I create.

Only Internet Explorer supports EOT so far. If you’re running another browser, you’ll need the fonts on your system (if you’re running Windows Vista, Office2007, MacOffice2008, or have installed the Office 2007 compatibility pack, they’ll be there).

The main heading, “Obama” is 72 point Calibri in a weight of 700, with an upper-case transform. You can find all of these in the CSS stylesheet I created: http://www.billhillsite.com/newsweek2.css

A word of warning. My stylesheet “grew organically” and was not really methodically planned; I just re-used earlier ones and modified them. So there are almost certainly styles in there I’m not using in this publication. It needs a good cleanup…

The toughest part about doing this project has been the fact that I have to manually paginate, since there’s no browser which supports pagination of flowing text content today (I know, you can paginate paragraphs from a search engine or database – but you can’t paginate a book or a magazine).

I’ve properly paginated only pages 1 and 2 so far. I need to go into subsequent pages, add some more graphics, sub-headings, pull-quotes, and ads to break up the text in a nice way. I also need to go in and split up the longer paragraphs. And I think I need to create at least one more page to hold all the overflow text which will result from that. So it’s still a work in progress.

But I think what I’ve done so far is a big improvement on the same article on Newsweek’s website. I hope you agree.

I really want to work with Web designers, the browser teams and W3C standards folks (both HTML and CSS) and others, to make sure that what I’m forced to achieve by trickery today becomes really easy and absolutely routine on the Web of tomorrow.

Experiments in Web Readability 2: A Blog

The first page of my Readable Blog. Click on each of the graphics in this article to go to the original page on my website. You’ll want Internet Explorer 8 to view the embedded fonts properly.

My first full-scale Web Readability experiment – a book – showed me that you could produce text on Web pages which people could read for long, sustained periods.

It wasn’t a simple process, since it involved a lot of manual editing to get column- and page-breaks right. It meant you had to create a separate web page for each page of the book – which of course meant you had to duplicate all the header code, code to draw the title bar, navigation buttons etc. on each of the pages.

That’s wasteful! But until Web browsers’ layout engines support full pagination, there is no other way as far as I can see. Ideally, what you want is a kind of “Master Page”, which includes all repeating elements. I think this can be done using CSS; I plan to try some experiments in this area.

However, there’s still no way to have your browser flow the content until your “page” fills, then create a new one, and so on until all the content’s placed. This is what software like the Windows Presentation Foundation (WPF) – based New York Times Reader does – and we need this functionality on the Web. It will mean that not only will Web browsers have to evolve, but we’ll need new (or improved) Web standards, too.

Anyway, that’s in the future. I wanted to see what I could do today.

For my second project, I chose a Blog. Blogging has made publishing content easy. But the resulting output is ugly and hard to read.

Why can’t a blog be as readable as a well-laid-out magazine? There’s absolutely no reason, except the technology has not yet evolved to support it.

Today, blogging software (like Blogger, or LiveSpaces) pretends that it’s giving you a multi-column layout. But that’s only true for the first screenful or two. If a blog contains longer articles, then as you scroll down you end up reading the same old, boring, wasteful single-column – with large sections of the screen either side of it completely unused.

That’s the main reason I chose white text on a black background from among Blogger’s layout options. I’d prefer black text on white – but when there’s just one narrow column of text in a vast area of white, the screen’s punching far too much light at the reader. A page of printed text:

  1. Is reflecting light, not transmitting it, and
  2. Has an overall, even “grayness” because it’s generally filled with text (typographers call this “color”)

Ideally, the Web needs true multicolumn layout. And, of course, you can’t have that without pagination – it makes no sense at all to have to scroll down to the bottom of a column, then all the way back up to the top of the next one in order to continue reading.

Multicolumn layout and pagination makes a blog much more readable

When I began my first experiments, my friend and colleague Mike Duggan designed a “masthead” for my blog. It was originally laid out in a print publishing application; I wanted to see if it could be replicated using Web standards markup.

Another colleague, Chris Wilson, managed to recreate it.I tweaked his code a little until I was happy with the final look. Problem 1 solved – a consistent look to all the pages, using CSS for the text specs. I also used the same “Forward-Backward” buttons I’d used in the book – because again the pages were designed to be read in FullScreen mode, so the pages and not the browser would contain the navigation.

(Interesting digression here)

Although the buttons were better than browser chrome, it was still a bit of a pain to have to reach for the mouse, move the pointer up to the button and click. Somehow it seemed to detract from the smoothness of page-turns that you want, especially in a sustained read, like a book.

Just this morning, though, my friend and colleague Greg Hitchcock asked me if it was possible to have keystrokes (left and right arrows, for instance) do the job instead.

I emailed the Internet Explorer team and Alex Kuang sent me a script which allows you to assign keystrokes. I copied it, saved it as a Javascript with the name keynav.js, and copied it to my website, http://www.billhillsite.com/

Then I edited the pages of the book to add a reference to the script, and two fragments to the existing “next page” and “previous page” code. Now you can use left and right arrows to page through the book. Try it at http://www.billhillsite.com/mabinogion.htm

I haven’t put these page turns in my readable blog yet, but I’ll do that over the next day or two. Turning pages this way on a laptop just feels so much more natural!

(End of digression)

Back to my readable blog. I set about laying out the pages using the ClearType optimized fonts we shipped with Windows Vista, Office2007 and MacOffice2008. I used Internet Explorer’s Embedded OpenType capability to do that.

I picked up the same multicolumn Javascript I’d used for the book, and used CSS to set the number of columns to 3, to give a more magazine-like layout.

I used CSS to create a Drop Capital at the start of the main story on each page. CSS drop caps are a bit of a pain. There’s a lot of trial and error involved, and you still can’t do true “typographic” drop caps. The CSS working group needs to get some eminent typographers like Robert Bringhurst involved in defining how this kind of functionality should work.

That said, the drop cap I managed to create (with a lot of help from Chris) still looked better than the normal “vanilla” beginning of a paragraph of text.

Then it was down to writing the text and adding graphics to create each page of my blog as a separate web page. Getting the column breaks right still took a lot of work because of the lack of granularity in the multicolumn Javascript.

One thing you should note about these pages is that I also took a lot of care to make certain the baselines of text were aligned in adjacent columns. That definitely adds a huge feeling of stability to any layout. It’s one of those magical typographic attributes; without that, something will feel very wrong and unbalanced about any multicolumn page, and unless you’re experienced you won’t even know what’s missing. You can just feel a page “settle down” once you get this right.

To achieve this rhythm, you need to make sure that everything on the page – all your different styles, the depth of every graphic, etc, is based on multiples of the line-height of the body text.

I did this manually. But there’s JQuery code to do it on the site of my former colleague, Fil Fortes. Find it here.

There’s still a major problem with this kind of layout. Because multicolumn requires pagination, and there’s no such thing as a “fixed page size” on the Web – because readers will access sites on a wide range of different displays – this kind of layout will need to become adaptive in order to work everywhere.

The WPF-based NYT reader does this, changing the number of columns and the sizing of pictures, etc, to fit the window in which it’s being displayed. We really need this technology on the Web. Otherwise we’re still doing things the way information designers have worked for 35,000 years – since they first painted on cave walls.

A page from my readable blog with graphics showing how effective adaptive layout can be.

I hope you’ll agree, these layouts are much better than the poor options blogging tools allow us today.

Now, don’t get me wrong – the blogging tools of today have democratized publishing in a way we could never have dreamed of when I started work as a newsman back in the 1960s. They make it possible to write content really easily, add graphics and links, post it, deal with comments and all kinds of other stuff.

But they’re all still in their infancy, and need to learn the lessons it took the world of print 550 years to absorb…