As you all know by now, I'm a big fan of the Kindle 2. My experience with reading standard, text-only fiction has convinced me that it's a winner.
However, it's clear that Amazon still has a lot of work to do if they want the Kindle to be used also to read non-fiction. A rumor this week suggested they might be planning to tackle that market next.
When I got my second Kindle 2 (you'll remember I lost the first one), I decided to re-read one of my all-time favorite non-fiction books on it - Jared Diamond's amazing "Guns, Germs and Steel", which chronicles the history of the human race and explains how it was the development of food production and domestication of animals in Eurasia which were the main factors in the European colonization of large parts of the world.
This was the major factor in the virtual extermination of native peoples by epidemic diseases like smallpox and measles - all of which had jumped the species boundary to humans from domesticated animals, and to which Europeans had developed some immunity due to thousands of years of exposure, while peoples like Native Americans and Hawaiians had their populations reduced to less than five percent by successive waves of disease.
Anyway, it's a great and fascinating book. Diamond's chronicling of the birth and spread of writing and printing - which were also stimulated by the same societal changes, and fostered by the ability of food production techniques which replaced hunter-gatherer lifestyles - has been of great value to me in my own studies of reading.
One of the most valuable features of the book is its series of tables and maps - and it was here that Kindle definitely let me down.
Kindle doesn't scale the text in tables so it all fits on a page, thus destroying the ability to compare at a glance lots of related facts.
I found that sometimes switching the text size down, below the size at which I can read comfortably, allowed me to fit the whole table on a "page". But usually it didn't, with the result that the tables were not quite useless, but very greatly reduced in value.
Same problem with maps and graphics. I don't know what Amazon did to get the graphics into their .azw format, but I'm guessing they were scanned as pictures. This of course means the text gets blurred. But also, the graphics end up gray and hard to read.
One thing I did notice - they seemed, just for a fleeting instant, to display much better when XOR'd as the Kindle first refreshed the page. Maybe Amazon should try this. But they certainly need to improve the handling of both tables and graphics to turn Kindle into a device on which you'd happily read non-fiction.
It's a pity. The Kindle weighs much less and is easier to handle than Diamond's printed book.
I'm also starting to hit a problem in which many of the books I want to re-read - and be able to carry around with me - just aren't available.
I'd like to re-read William Shirer's "Rise and Fall of the Third Reich" - a fascinating account of how a madman can make a whole nation insane, and a book everyone needs to read in case we forget how it can happen.
Another favorite author of mine is William Manchester. I'd like to re-read the two-part biography of Winston Churchill, "The Last Lion".
"Reich" and the two volumes of "Lion" together weigh several pounds, with thousands of pages. They're heavy and bulky to carry (especially when traveling), and together must make a stack about six inches thick. They're very awkward to read in bed.
In short, books like this are PERFECT candidates for purchasing and reading on a device like the Kindle. But despite being best-sellers, they are not available...
This week there was a rumor (or leak) on the Web that Amazon would announce a larger-format Kindle for reading textbooks etc. This would be a very smart move. Imagine the cost savings if textbooks (which must be regularly updated) went digital. And the relief of the ten-year-olds who would no longer have to struggle to school with a huge backpack, or a travel suitcase with wheels..
Thursday, April 30, 2009
Tuesday, April 21, 2009
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:
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...
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:
- Uses absolute, not relative, measurements.
- Interrogates the operating system and determines actual screen size and pixel pitch.
- Translates the absolute measurements of the original design into pixel dimensions for the actual display being used.
- Determines the optimum number of columns for best readability on that particular display given the text-size the user prefers for reading.
- 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).
- 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...
Tuesday, April 7, 2009
Distributed Proofreaders: What your work could look like if it was paginated...
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...
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.
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.
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...
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.
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.
Subscribe to:
Posts (Atom)