Well, it’s official now. I’m leaving Microsoft.
It's time to begin the next stage of a mission that began for me in the early 1980s - when I realized that computers were about to change the publishing industry radically and forever. I helped to drive the desktop publishing revolution that changed high-quality printing and made it accessible to anyone with a personal computer.
I guess the second stage began when I first saw hypertext in 1985, while writing the user manual for Guide, the first Macintosh hypertext authoring program (those were the days when software needed a thick printed manual).
Hypertext was supposed to replace paper. But everyone promoting it had forgotten the one basic flaw in the reasoning – reading from the screen was so bad that everyone would still print information in order to read it.
The journey brought me from Scotland to the Pacific Northwest, to work at Microsoft, which I believed was the one company in the world best-placed to lead the transition from reading on paper to reading on a screen.
It may sound trite, but so many millions of people worldwide use Microsoft Windows and Microsoft Office that it's a truism: Change Windows and Office, and you change the world.
There are probably a billion people worldwide with ClearType on their PCs and other improvements like the onscreen reading view in Word.
I've had the opportunity to work with many clever folks at Microsoft. Together, we have driven a lot of change. I want to publicly thank the ClearType team at Microsoft, most of whom I’ve worked with since I joined the company over 14 years ago. They drank the Kool-Aid before anyone, when they worked for me in Microsoft's Typography group. Back in 1995, we produced a plan together which focused us on reading from the screen. The Verdana and Georgia fonts were the first fruit of that work. And they're still believers.
I’d like to thank Charles Torre of Microsoft's Channel9. It has been a huge success, and it has always been a delight to work with him. If you want to see Bill Hill videos, Channel9 is the place to go. Together, they've had hundreds of thousands of views.
It has been a privilege to know and work with all at Channel9, and I hope we’ll stay in contact.
The job of making the screen as comfortable to read as paper is not yet completed. I've come to believe that it is the development of Web standards, and standards-based rendering, which will take us the rest of the way.
There’s huge potential. Two trillion pages are still printed in the US alone, every year, and that’s an enormous waste of energy and resources.
For some time, I have been preparing for leaving Microsoft by setting up my network and communications. You’ll find me on FaceBook and LinkedIn, as well as on my website and this blog.
As you all know, I’m a Man With A Mission. I have no intention of becoming a beach bum. I always said that I would probably go back to writing, which I did professionally for almost as long as I worked in the software industry. I’ll continue with my blog and website.
I’ve become convinced over the past couple of years that no one company or browser will make the transition to reading on screen happen. I still believe in eBooks. Amazon has definitely seized the lead there, by providing the two things which were both essential to success – a device and a bookstore.
I have some other ideas I’m not yet ready to talk about. And of course I'm available as a consultant.
I’m facing the future with what is probably the right mix of fear and excitement. It has always felt like this is destined to happen, it’s a lot bigger than me, and I’m not in control.
In the past, what seemed like the worst thing that could happen has often turned out to be the best thing that could have happened.
Reading on Screen IS The Future of Reading. People thought I was mad when I tried to tell them that back in the 1980s and 1990s. Now we all spend hours every day, reading from a screen. We've come a long way.
But we still have promises to keep, and miles to go before we sleep
Tuesday, May 5, 2009
Thursday, April 30, 2009
Kindle: Disappointing for reading non-fiction - textbook version soon?
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..
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..
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.
Thursday, February 19, 2009
Experiments in Web Readability: A Book
Last year I began a project to try to push readability on the Web as far as I could using today's technology, which would also help me be clearer about what I felt was missing.
I started in August, because I've been working in the Internet Explorer team at Microsoft, and that was when the team shipped Internet Explorer 8, Beta 2. Microsoft had previously announced that Internet Explorer 8 would use Web-standards rendering by default, and Beta 2 was the point at which I felt standards support became robust enough to try doing some real work using only standards markup.
We have now shipped the final version of Internet Explorer 8, and its standards support received plaudits from some unexpected sources last as the Web woke up to the reality that IE8 is not merely standards-compliant - its has the best support for CSS 2.1 of any of the current Web browsers.
Now, we're not as far forward on CSS3 as some of the others, but in my opinion the approach the team took (I can claim no personal credit for it) was exactly right. Rather than support a "mixed bag" of some CSS 2.1 and some CSS3, it's better to fill out one level first before moving on to the next. That seems to me like a disciplined, methodical and dependable approach.
I'd done some work earlier to demonstrate the use of embedded fonts in Web pages to improve readability. However, not being an HTML or CSS guru - but more of a type and design guy, and primarily a writer - I'd used print publishing software to create multiple-column layouts and automatically generate the Web pages from there.
The reaction I got from Web purists - well, it was more like jihad than criticism or useful suggestion...
But they did have a point. The code output from the publishing application was obscure, obtuse, not understandable by any human, and impossible to edit. HTML and CSS validation tools from the W3C, available online (http://validator.w3.org/ and http://jigsaw.w3.org/css-validator/ ), basically told me I was an idiot, and that my markup wouldn't pass their scrutiny - ever.
So I decided to teach myself some HTML and CSS and do things the hard way, coding by hand. I tried a few editors, but found the one I liked best was Notepad++, available free at http://notepad-plus.sourceforge.net/uk/site.htm If I'd been more of a programmer, I'd probably have used Microsoft Visual Studio or Expression Web, both of which will also output Web-standards markup. (They also have a lot more programming power, so you can do many other things than just hand-edit code - but that was overkill for someone like me).
Now, I was learning as I went. Mea culpa. You can drive a bus through the holes in my coding. It wasn't intended as a coding sample. It wasn't designed for accessibility. I just needed it to work. I did, however, run the W3C's HTML and CSS validation tools on every page.
Next thing was to decide on a first project. A book seemed like the right way to go, since the layout would be pretty straightforward. I could have merely toyed with a few pages of a book. But I wanted to do a real project - an entire book, from "cover" to "cover". Apart from anything else, that would reveal any problems of scaling.
I chose The Mabinogion, a book of mediaeval Welsh tales and Arthurian stories, which was translated from the Welsh in 1849 - no copyright problems there!
I downloaded the text from Project Gutenberg. PG has done us all a great service in converting all this public-domain content - but it's impossible to read as it is, and would really benefit from better layout and attention to readability.
The first thing I wanted to do was create a design which would work with the Web browser in Full Screen mode. All those buttons, address bars, menu bars etc. are great when I'm trying to find content. But once I've found it, they're a distraction; I just want them to go away while I read. Internet Explorer lets you hide everything using the F11 shortcut. Firefox does the same. Sadly, Safari has no FullScreen capability, and neither does Chrome.
I created a title bar at the top, which also had Page Forward-Back and Chapter Forward-Back buttons. The only other features I included on the title bar (I admit, partly out of anti-jihadist mischievousness) were the W3C's "Validated HTML" and "Validated CSS" logos.
I did not want scrolling. I wanted completely paginated content. There's no question it's more readable that way. Of course, that creates a dilemma. Despite the fact that Web content is supposed to be adaptive, it's not really. Almost 20 years ago, when the first Web browser was built, the engineers involved took the "easy option" of creating the bottomless scrolling window for content.
It was an understandable, expedient engineering decision at the time. It's much, much harder to set content in pages. But it makes all the difference in the world when you do. Browsers can't do this yet. And that means you have to do it manually (which sucks, and turns what should be a simple task into a Labor of Hercules).
Isn't it terrible that the Web today is still paying for an expediency decision taken 16 years ago at NCSA when they developed the first Mosaic browser?
Today, you can do pagination if you're working with, say, database-type data, or search results - where you're dealing with lots of individual paragraphs.
But if you want to do the same thing with flowing text that's meant for reading, you have to decide on a page size, then create lots of pages manually. This approach is totally impractical in any production scenario; however, if I wanted to show the benefit of paginated content, that's what I'd have to do.
I've taken a lot of flak for this approach from people like Joe Clark, who's accused me of trying to drag the Web backwards by "apeing 19th- and 20th-Century print layouts" (and a lot more). But I've been studying text and layout for about 40 years, and I contend that print layouts didn't happen by accident. They developed as a result of more than five centuries of evolution, to optimize for the way human visual perception works.
The Web, and the computer screen, haven't changed human perception. And they haven't yet evolved to optimize for it. So, I'm trying to adapt what we've learned over 550 years or so to the Web. I can't yet get where I'd like to end up - but I know where I'm going.
Anyway, I decided upfront that the page size would be 1440x900 pixels, which happens to be the size of my laptop display - a MacBook Pro (running Windows Vista, which I vastly prefer to OSX).
With the aspect ratio of a typical laptop, single-column layout doesn't really work; two-column is much better for a book (even that's a little bit too wide).
Multi-column layout is out there in CSS3; but the best way to do it right now is using Javascript. I found one out on the Web which did the trick. There were issues, which I'll come to later.
That decision made, it was time to get to what's probably the most important decision when laying out a book - the body text. I chose Cambria, which is one of the ClearType-optimized faces we created and shipped in Office 2007, MacOffice2008 and in Vista.
I used the WEFT tool to create Embedded OpenType font objects of all the fonts I planned to use in my projects: Cambria, Calibri, and Candara, all from the same ClearType-optimized collection. It has to be said that we have neglected that tool, and it wasn't as simple or straightforward as I'd hoped. But once I got it working, I could copy and paste the same CSS "@ font-face" declarations into the style sheets for the other projects and use the same .EOT font objects over and over.
I created subsets of the fonts, with only the Basic Latin character set, because I never write in Cyrillic or many of the other languages the complete font supports. That kept the size of the downloadable font objects down. I could have used per-page subsetting or per-site, but that might mean creating new objects every time I added more content - and I only wanted to do this once.
I chose 12point as the body text size (not pixels, a relative dimension, but points - an absolute size). I realized hard-coding the text size would create problems in future, because it didn't support making the text bigger for people who wanted/needed "large print". But the point of doing this book was to show that a readable book could be done on the Web.
One other decision I made up front was to make a very clear division between content and formatting. HTML is the child of SGML and XML, in which content and formatting were supposed to be strictly separated.
So I decided to put ALL formatting in the CSS and only structural markup in the HTML. A few times during this series of projects I broke my own rules in minor ways, (like using markup for italics in the HTML because I was in a hurry), but I managed to remain really strict almost all the time.
I found that on a laptop a two-column layout gave line-lengths which were slightly longer than ideal. I'd probably go in and increase margin and gutter sizes to take care of this in a production scenario. I also found that even with these long lines, word-spacing still got too wide sometimes, so I added another Javascript I found on the Web to hyphenate the problem lines.
I defined styles for headings, pull-quotes, etc. I know I allowed the CSS to get a bit out of hand and it could be cleaned up a lot if I went back to it now. But I was learning as I went...
Manual pagination was a real slog. I ended up with 112 separate Web pages...
The process of creating them became reasonably automatic after a while. But cleaning up the Project Gutenberg text in order to remove some line breaks, replacing their "inches and feet" marks with the right HTML entity coding for single- and double-quotes, apostrophes, etc. was tedious.
Since quotes are used in the HTML markup, you can't do a global Search and Replace. And because some of the quotes are opening ones, and others closing ones, you have to make sure you get the right ones in the right places. (Some closing quotes were missing in the PG markup, too). All this means any attempt at automation is limited; a lot of manual supervision is still needed.
Getting columns and pages to break in the right places was less than trivial, too. The multi-column Javascript uses the Document Object Model (DOM), so it isn't aware of anything smaller than a paragraph.
In practice, that means if you have long paragraphs you'll end up with weird column and page breaks. The Mabinogion was translated in 1849 - when long paragraphs were much more fashionable than they are now. So it meant going in and doing a lot of manual editing, breaking long paragraphs into shorter ones to make column-breaks work. However, eventually I got it all working pretty much the way I wanted.
I hit a problem later. I was updating my version of Internet Explorer with daily builds, from the Beta 2 with which I'd started. And some time along the way an Embedded OpenType bug crept into the Release Candidate builds. It was fixed long before the final release, but if you're running RC1 you'll find the EOT fonts don't always appear, and the text looks awful. Hitting Refresh is a temporary workaround. Go and download the final shipping version if you haven't already done so.
Internet Explorer is currently the only browser which supports EOT font embedding, of course.
I posted the finished book on my website:
http://www.billhillsite.com/mabinogion.htm
Then I went back and read it. For the first time ever, I comfortably read a whole book on the Web!
I'll talk about some of the subsequent experiments in later posts.
I started in August, because I've been working in the Internet Explorer team at Microsoft, and that was when the team shipped Internet Explorer 8, Beta 2. Microsoft had previously announced that Internet Explorer 8 would use Web-standards rendering by default, and Beta 2 was the point at which I felt standards support became robust enough to try doing some real work using only standards markup.
We have now shipped the final version of Internet Explorer 8, and its standards support received plaudits from some unexpected sources last as the Web woke up to the reality that IE8 is not merely standards-compliant - its has the best support for CSS 2.1 of any of the current Web browsers.
Now, we're not as far forward on CSS3 as some of the others, but in my opinion the approach the team took (I can claim no personal credit for it) was exactly right. Rather than support a "mixed bag" of some CSS 2.1 and some CSS3, it's better to fill out one level first before moving on to the next. That seems to me like a disciplined, methodical and dependable approach.
I'd done some work earlier to demonstrate the use of embedded fonts in Web pages to improve readability. However, not being an HTML or CSS guru - but more of a type and design guy, and primarily a writer - I'd used print publishing software to create multiple-column layouts and automatically generate the Web pages from there.
The reaction I got from Web purists - well, it was more like jihad than criticism or useful suggestion...
But they did have a point. The code output from the publishing application was obscure, obtuse, not understandable by any human, and impossible to edit. HTML and CSS validation tools from the W3C, available online (http://validator.w3.org/ and http://jigsaw.w3.org/css-validator/ ), basically told me I was an idiot, and that my markup wouldn't pass their scrutiny - ever.
So I decided to teach myself some HTML and CSS and do things the hard way, coding by hand. I tried a few editors, but found the one I liked best was Notepad++, available free at http://notepad-plus.sourceforge.net/uk/site.htm If I'd been more of a programmer, I'd probably have used Microsoft Visual Studio or Expression Web, both of which will also output Web-standards markup. (They also have a lot more programming power, so you can do many other things than just hand-edit code - but that was overkill for someone like me).
Now, I was learning as I went. Mea culpa. You can drive a bus through the holes in my coding. It wasn't intended as a coding sample. It wasn't designed for accessibility. I just needed it to work. I did, however, run the W3C's HTML and CSS validation tools on every page.
Next thing was to decide on a first project. A book seemed like the right way to go, since the layout would be pretty straightforward. I could have merely toyed with a few pages of a book. But I wanted to do a real project - an entire book, from "cover" to "cover". Apart from anything else, that would reveal any problems of scaling.
I chose The Mabinogion, a book of mediaeval Welsh tales and Arthurian stories, which was translated from the Welsh in 1849 - no copyright problems there!
I downloaded the text from Project Gutenberg. PG has done us all a great service in converting all this public-domain content - but it's impossible to read as it is, and would really benefit from better layout and attention to readability.
The first thing I wanted to do was create a design which would work with the Web browser in Full Screen mode. All those buttons, address bars, menu bars etc. are great when I'm trying to find content. But once I've found it, they're a distraction; I just want them to go away while I read. Internet Explorer lets you hide everything using the F11 shortcut. Firefox does the same. Sadly, Safari has no FullScreen capability, and neither does Chrome.
I created a title bar at the top, which also had Page Forward-Back and Chapter Forward-Back buttons. The only other features I included on the title bar (I admit, partly out of anti-jihadist mischievousness) were the W3C's "Validated HTML" and "Validated CSS" logos.
I did not want scrolling. I wanted completely paginated content. There's no question it's more readable that way. Of course, that creates a dilemma. Despite the fact that Web content is supposed to be adaptive, it's not really. Almost 20 years ago, when the first Web browser was built, the engineers involved took the "easy option" of creating the bottomless scrolling window for content.
It was an understandable, expedient engineering decision at the time. It's much, much harder to set content in pages. But it makes all the difference in the world when you do. Browsers can't do this yet. And that means you have to do it manually (which sucks, and turns what should be a simple task into a Labor of Hercules).
Isn't it terrible that the Web today is still paying for an expediency decision taken 16 years ago at NCSA when they developed the first Mosaic browser?
Today, you can do pagination if you're working with, say, database-type data, or search results - where you're dealing with lots of individual paragraphs.
But if you want to do the same thing with flowing text that's meant for reading, you have to decide on a page size, then create lots of pages manually. This approach is totally impractical in any production scenario; however, if I wanted to show the benefit of paginated content, that's what I'd have to do.
I've taken a lot of flak for this approach from people like Joe Clark, who's accused me of trying to drag the Web backwards by "apeing 19th- and 20th-Century print layouts" (and a lot more). But I've been studying text and layout for about 40 years, and I contend that print layouts didn't happen by accident. They developed as a result of more than five centuries of evolution, to optimize for the way human visual perception works.
The Web, and the computer screen, haven't changed human perception. And they haven't yet evolved to optimize for it. So, I'm trying to adapt what we've learned over 550 years or so to the Web. I can't yet get where I'd like to end up - but I know where I'm going.
Anyway, I decided upfront that the page size would be 1440x900 pixels, which happens to be the size of my laptop display - a MacBook Pro (running Windows Vista, which I vastly prefer to OSX).
With the aspect ratio of a typical laptop, single-column layout doesn't really work; two-column is much better for a book (even that's a little bit too wide).
Multi-column layout is out there in CSS3; but the best way to do it right now is using Javascript. I found one out on the Web which did the trick. There were issues, which I'll come to later.
That decision made, it was time to get to what's probably the most important decision when laying out a book - the body text. I chose Cambria, which is one of the ClearType-optimized faces we created and shipped in Office 2007, MacOffice2008 and in Vista.
I used the WEFT tool to create Embedded OpenType font objects of all the fonts I planned to use in my projects: Cambria, Calibri, and Candara, all from the same ClearType-optimized collection. It has to be said that we have neglected that tool, and it wasn't as simple or straightforward as I'd hoped. But once I got it working, I could copy and paste the same CSS "@ font-face" declarations into the style sheets for the other projects and use the same .EOT font objects over and over.
I created subsets of the fonts, with only the Basic Latin character set, because I never write in Cyrillic or many of the other languages the complete font supports. That kept the size of the downloadable font objects down. I could have used per-page subsetting or per-site, but that might mean creating new objects every time I added more content - and I only wanted to do this once.
I chose 12point as the body text size (not pixels, a relative dimension, but points - an absolute size). I realized hard-coding the text size would create problems in future, because it didn't support making the text bigger for people who wanted/needed "large print". But the point of doing this book was to show that a readable book could be done on the Web.
One other decision I made up front was to make a very clear division between content and formatting. HTML is the child of SGML and XML, in which content and formatting were supposed to be strictly separated.
So I decided to put ALL formatting in the CSS and only structural markup in the HTML. A few times during this series of projects I broke my own rules in minor ways, (like using markup for italics in the HTML because I was in a hurry), but I managed to remain really strict almost all the time.
I found that on a laptop a two-column layout gave line-lengths which were slightly longer than ideal. I'd probably go in and increase margin and gutter sizes to take care of this in a production scenario. I also found that even with these long lines, word-spacing still got too wide sometimes, so I added another Javascript I found on the Web to hyphenate the problem lines.
I defined styles for headings, pull-quotes, etc. I know I allowed the CSS to get a bit out of hand and it could be cleaned up a lot if I went back to it now. But I was learning as I went...
Manual pagination was a real slog. I ended up with 112 separate Web pages...
The process of creating them became reasonably automatic after a while. But cleaning up the Project Gutenberg text in order to remove some line breaks, replacing their "inches and feet" marks with the right HTML entity coding for single- and double-quotes, apostrophes, etc. was tedious.
Since quotes are used in the HTML markup, you can't do a global Search and Replace. And because some of the quotes are opening ones, and others closing ones, you have to make sure you get the right ones in the right places. (Some closing quotes were missing in the PG markup, too). All this means any attempt at automation is limited; a lot of manual supervision is still needed.
Getting columns and pages to break in the right places was less than trivial, too. The multi-column Javascript uses the Document Object Model (DOM), so it isn't aware of anything smaller than a paragraph.
In practice, that means if you have long paragraphs you'll end up with weird column and page breaks. The Mabinogion was translated in 1849 - when long paragraphs were much more fashionable than they are now. So it meant going in and doing a lot of manual editing, breaking long paragraphs into shorter ones to make column-breaks work. However, eventually I got it all working pretty much the way I wanted.
I hit a problem later. I was updating my version of Internet Explorer with daily builds, from the Beta 2 with which I'd started. And some time along the way an Embedded OpenType bug crept into the Release Candidate builds. It was fixed long before the final release, but if you're running RC1 you'll find the EOT fonts don't always appear, and the text looks awful. Hitting Refresh is a temporary workaround. Go and download the final shipping version if you haven't already done so.
Internet Explorer is currently the only browser which supports EOT font embedding, of course.
I posted the finished book on my website:
http://www.billhillsite.com/mabinogion.htm
Then I went back and read it. For the first time ever, I comfortably read a whole book on the Web!
I'll talk about some of the subsequent experiments in later posts.
Wanted: A Waterproof Kindle...
Over the past few months I got used to reading on my Kindle. No, it still isn't the best reading experience. When reading at night - which is when I read most - I'd prefer a backlit screen. The flashing page turns really irritate me, and the page-turn "paddles" are so easy to hit by mistake that I've lost count of the number of times I've involuntarily flipped backwards or forwards (sometimes multiple pages).
But I've been a voracious reader since the age of three. From the age of ten, and during my early teens in the East End of Glasgow, I would check out eight books at a time from the local public library - and I still had to visit it twice a week (My own two tickets would allow me to check out only two books. But I could get six more tickets by enrolling my father, mother and sister...)
I found I was prepared to put up with the Kindle's shortcomings in exchange for the real convenience of being able to carry my library around with me - and especially for the ability to buy books online from Amazon.
The biggest problem I have is that one of my favorite places to read is in the bath. Run a nice hot bath, lie back and relax with a book... Aaaaah!
And that's how my first Kindle died.
Oh, I thought I had the technique down. I never actually held the Kindle over the bathwater. I'd found a way of balancing it against the faucets; only had to reach up and turn the pages.
But, as my countryman the poet Robert Burns tells us, "The best-laid plans of mice and men gang aft agley" (Translation: No matter how good your plan, Mr Murphy will often get you).
I'd just had a lovely bath and a good read, and slipped as I was getting out. The towel caught the Kindle, and - splash!
I quickly whipped it out, dried it off, hoping that water hadn't had time to reach the innards. But it was gone. Half the screen was solid black, the other half solid white. Taking out the battery, drying the Kindle out, recharging the battery - nothing worked. Dead. Gone. R.I.P.
And of course, my portable library and the book I was reading went with it.
I haven't lost my library. At my home I can't get Kindle to connect wirelessly. So I've been buying my books on my laptop and downloading them to there, then synching the Kindle. So the .azw books are still there on my hard drive. I just need another Kindle, activated to the same Amazon account.
I decided not to buy another Kindle 1. They were not available on Amazon, and anyway the Kindle 2 was on the way. Perhaps that would fix some of my issues.
Once Amazon unveiled Kindle 2 it was obvious they're been listening to Kindle 1 customers. Gone are the horrible page-turn paddles, replaced by page-turn buttons which are still large enough to be easy to hit, but don't automatically turn pages when you pick up the device.
The Amazon blurb for the Kindle 2 says that it now has 16 levels of gray instead of the previous 4, so that should help a lot with photos in books, which were previously awful. I do recollect reading somewhere that page-turns were also less intrusively "flashy", but we'll have to wait and see.
Anyway, I went ahead and ordered my Kindle 2 a few weeks ago. They're supposed to be available for customers on February 24, with preference being given to existing Kindle owners. We'll see. But I'm certainly looking forward to a device that's thinner, with longer battery life (although I never found that to be a problem with Kindle 1).
And I'm really looking forward to continuing the Terry Pratchett novel I was reading in the bath that day...
But I've been a voracious reader since the age of three. From the age of ten, and during my early teens in the East End of Glasgow, I would check out eight books at a time from the local public library - and I still had to visit it twice a week (My own two tickets would allow me to check out only two books. But I could get six more tickets by enrolling my father, mother and sister...)
I found I was prepared to put up with the Kindle's shortcomings in exchange for the real convenience of being able to carry my library around with me - and especially for the ability to buy books online from Amazon.
The biggest problem I have is that one of my favorite places to read is in the bath. Run a nice hot bath, lie back and relax with a book... Aaaaah!
And that's how my first Kindle died.
Oh, I thought I had the technique down. I never actually held the Kindle over the bathwater. I'd found a way of balancing it against the faucets; only had to reach up and turn the pages.
But, as my countryman the poet Robert Burns tells us, "The best-laid plans of mice and men gang aft agley" (Translation: No matter how good your plan, Mr Murphy will often get you).
I'd just had a lovely bath and a good read, and slipped as I was getting out. The towel caught the Kindle, and - splash!
I quickly whipped it out, dried it off, hoping that water hadn't had time to reach the innards. But it was gone. Half the screen was solid black, the other half solid white. Taking out the battery, drying the Kindle out, recharging the battery - nothing worked. Dead. Gone. R.I.P.
And of course, my portable library and the book I was reading went with it.
I haven't lost my library. At my home I can't get Kindle to connect wirelessly. So I've been buying my books on my laptop and downloading them to there, then synching the Kindle. So the .azw books are still there on my hard drive. I just need another Kindle, activated to the same Amazon account.
I decided not to buy another Kindle 1. They were not available on Amazon, and anyway the Kindle 2 was on the way. Perhaps that would fix some of my issues.
Once Amazon unveiled Kindle 2 it was obvious they're been listening to Kindle 1 customers. Gone are the horrible page-turn paddles, replaced by page-turn buttons which are still large enough to be easy to hit, but don't automatically turn pages when you pick up the device.
The Amazon blurb for the Kindle 2 says that it now has 16 levels of gray instead of the previous 4, so that should help a lot with photos in books, which were previously awful. I do recollect reading somewhere that page-turns were also less intrusively "flashy", but we'll have to wait and see.
Anyway, I went ahead and ordered my Kindle 2 a few weeks ago. They're supposed to be available for customers on February 24, with preference being given to existing Kindle owners. We'll see. But I'm certainly looking forward to a device that's thinner, with longer battery life (although I never found that to be a problem with Kindle 1).
And I'm really looking forward to continuing the Terry Pratchett novel I was reading in the bath that day...
Friday, August 8, 2008
Authoring Web-Standards Pages: Like Setting Type in the Days of Gutenberg...
I've just spent the last few days working to build a set of Web pages which are authored to W3C standards (HTML 4.01 and CSS 2.1) They're now up on my website:
http://www.billhillsite.com/
I've done some HTML authoring before, of course. But I always stayed away from anything but the simplest hand-coding. When I wanted to do something more complex (typographically speaking), I'd fire up a publishing tool, which would let me do things in a visual way and then translate what I'd done into code.
This time - at least at first - I didn't really care about the code itself. I was creating the pages in order to show off how Embedded OpenType (EOT) font embedding could be used to really enhance readability on the Web, by allowing Web designers to use high-quality commercial fonts on their pages, even though readers would not have those fonts installed.
It worked like a charm - at least as far as my goals of showing off the technology were concerned. I even apologized for the code when I posted the pages, and explained that they were merely a vehicle to show EOT actually working.
I wanted to post the pages quickly, to coincide with an announcement by font vendor Ascender Corporation that it was supporting Embedded OpenType (EOT) and launching a new website:
http://fontembedding.com/
I'd have liked to have posted a Web-standards set of pages, too, but there just wasn't time. My colleague Chris Wilson tried to warn me. He even coded up the first page. But we couldn't get them done in time for the announcement, so I decided to go with what I had.
Reactions were wildly different. One or two people were really helpful - one offered to give up some of his time to convert the pages to cleaner Standards-compatible code. But some were downright rude. Don't they get it? If you disagree with someone, but you're civil about it, there's a good chance they'll listen to your argument.
Anyway, I'd already decided that I needed a set of identical Web-standards pages up there. While the offer to make them for me was very generous, it wouldn't do much to improve my personal level of understanding. So I thought it was time to get my hands dirty. I bought a pile of HTML and CSS books, then set about deconstructing Chris's page until I'd figured out how it worked. (If you want to learn how to paint, the best way is to study the work of a master...)
You can't use any really visual tool to do this work - they all end up inserting chunks of their own code, which is inefficient and impossible to understand.
Chris recommended I use Notepad, the basic text editor that comes with Windows. I also tried FrontPage, which worked fine as long as you stuck to the HTML view. I found life a lot easier with line numbers, so Chris told me to try Notepad++, and that's what I ended up using.
It's a good tool, and it's available free on:
http://notepad-plus.sourceforge.net/uk/site.htm
Chris's other suggestion was to use Visual Studio, but that's way too heavy-duty for me - I am only an egg (from Robert Heinlein: Stranger in a Strange Land - See BOOKS I RECOMMEND).
My first page was a struggle, as you'd expect. But it was a great feeling when I finally got it to do what I wanted. It was even better when the W3Cs HTML validator service passed it (after I'd tidied up - it caught a couple of orphaned opening and closing tags first time around).
After that, my coding for each of the subsequent pages got steadily quicker.
I think Web standards are great. I've been a big supporter inside Microsoft. They still need to be evolved to support really great typography, because the Web is without doubt the publishing medium that will replace paper, and should be capable of doing anything you can do with paper (especially as screens get better).
My experience with authoring standards-compatible pages by hand - and the fact that there isn't any other acceptable way - really got me thinking.
We're back in the days of Gutenberg. In those days, all text had to be set by hand. It was a job for the real expert - not something any regular person could ever do. One of the world's great type designers, Herman Zapf, told a conference a few years ago that no-one has ever yet succeeded, despite all the technology developed since, in setting type as well as Gutenberg.
The key to Gutenberg's setting was that he used many more ligatures than are in common use today. A ligature (from the Latin root meaning to bind) is a special character which creates a new composite binding together two or more letters in order to make them fit better together. The most common examples are ff, fi, ffl, ffi, etc.
Most typefaces today have only a handful of ligatures. But Gutenberg cast many additional ones which ensured a tight and aesthetically pleasing fit of groups of two, three, four or more letters.
We see character sets in typefaces being extended all the time to support more languages. OpenType has given us the ability to create many more ligatures. But we're not yet using that capability to its full potential.
Hand-coding standards-compatible Web pages is just like setting type by hand. If I want a true apostrophe, for instance, I have to type " ’ ", or paste it in. True double or single quotes, em-dashes - they all have to be hand-coded.
How sick is that?
Hand-setting of type was a huge bottleneck in the printing process. It took about 400 years (until Victorian times) before machines like the Linotype and Monotype typecasters were able to take over most of the load.
Of course, access to machines like that was pretty much limited to professional publishing concerns.
The typewriter made it possible for almost anyone to put print on paper - pretty ugly, limited, monospaced print, it's true, but it was great leap forward.
Since the advent of the personal computer in the 1970s we've seen steady progress in the quality of printed material ordinary non-experts can produce. Dot-matrix and daisy-wheel printers have been replaced by laser and inkjet printers. Regular word-processing software like Microsoft Word can turn out very professional documents. The desktop publishing revolution of the 1980s brought software which can do just about anything you want. And you don't have to be an expert to use any of these - templates and default settings will give you professional results.
And here we are with the Web. It's the most important publishing medium in human history. Because for the first time it democratizes both the production AND distribution of high-quality content. And you can read it on a screen, keep it up to date, re-purpose it, etc.
But it's clear to me that we're still missing a huge piece of technology: an authoring tool which can be used by anyone without expert knowledge( i.e. the ability to hand-code) which produces standards-compatible, professional-quality Web pages.
That's the Desktop Publishing revolution of the 21st Century, and it's still waiting to happen..
http://www.billhillsite.com/
I've done some HTML authoring before, of course. But I always stayed away from anything but the simplest hand-coding. When I wanted to do something more complex (typographically speaking), I'd fire up a publishing tool, which would let me do things in a visual way and then translate what I'd done into code.
This time - at least at first - I didn't really care about the code itself. I was creating the pages in order to show off how Embedded OpenType (EOT) font embedding could be used to really enhance readability on the Web, by allowing Web designers to use high-quality commercial fonts on their pages, even though readers would not have those fonts installed.
It worked like a charm - at least as far as my goals of showing off the technology were concerned. I even apologized for the code when I posted the pages, and explained that they were merely a vehicle to show EOT actually working.
I wanted to post the pages quickly, to coincide with an announcement by font vendor Ascender Corporation that it was supporting Embedded OpenType (EOT) and launching a new website:
http://fontembedding.com/
I'd have liked to have posted a Web-standards set of pages, too, but there just wasn't time. My colleague Chris Wilson tried to warn me. He even coded up the first page. But we couldn't get them done in time for the announcement, so I decided to go with what I had.
Reactions were wildly different. One or two people were really helpful - one offered to give up some of his time to convert the pages to cleaner Standards-compatible code. But some were downright rude. Don't they get it? If you disagree with someone, but you're civil about it, there's a good chance they'll listen to your argument.
Anyway, I'd already decided that I needed a set of identical Web-standards pages up there. While the offer to make them for me was very generous, it wouldn't do much to improve my personal level of understanding. So I thought it was time to get my hands dirty. I bought a pile of HTML and CSS books, then set about deconstructing Chris's page until I'd figured out how it worked. (If you want to learn how to paint, the best way is to study the work of a master...)
You can't use any really visual tool to do this work - they all end up inserting chunks of their own code, which is inefficient and impossible to understand.
Chris recommended I use Notepad, the basic text editor that comes with Windows. I also tried FrontPage, which worked fine as long as you stuck to the HTML view. I found life a lot easier with line numbers, so Chris told me to try Notepad++, and that's what I ended up using.
It's a good tool, and it's available free on:
http://notepad-plus.sourceforge.net/uk/site.htm
Chris's other suggestion was to use Visual Studio, but that's way too heavy-duty for me - I am only an egg (from Robert Heinlein: Stranger in a Strange Land - See BOOKS I RECOMMEND).
My first page was a struggle, as you'd expect. But it was a great feeling when I finally got it to do what I wanted. It was even better when the W3Cs HTML validator service passed it (after I'd tidied up - it caught a couple of orphaned opening and closing tags first time around).
After that, my coding for each of the subsequent pages got steadily quicker.
I think Web standards are great. I've been a big supporter inside Microsoft. They still need to be evolved to support really great typography, because the Web is without doubt the publishing medium that will replace paper, and should be capable of doing anything you can do with paper (especially as screens get better).
My experience with authoring standards-compatible pages by hand - and the fact that there isn't any other acceptable way - really got me thinking.
We're back in the days of Gutenberg. In those days, all text had to be set by hand. It was a job for the real expert - not something any regular person could ever do. One of the world's great type designers, Herman Zapf, told a conference a few years ago that no-one has ever yet succeeded, despite all the technology developed since, in setting type as well as Gutenberg.
The key to Gutenberg's setting was that he used many more ligatures than are in common use today. A ligature (from the Latin root meaning to bind) is a special character which creates a new composite binding together two or more letters in order to make them fit better together. The most common examples are ff, fi, ffl, ffi, etc.
Most typefaces today have only a handful of ligatures. But Gutenberg cast many additional ones which ensured a tight and aesthetically pleasing fit of groups of two, three, four or more letters.
We see character sets in typefaces being extended all the time to support more languages. OpenType has given us the ability to create many more ligatures. But we're not yet using that capability to its full potential.
Hand-coding standards-compatible Web pages is just like setting type by hand. If I want a true apostrophe, for instance, I have to type " ’ ", or paste it in. True double or single quotes, em-dashes - they all have to be hand-coded.
How sick is that?
Hand-setting of type was a huge bottleneck in the printing process. It took about 400 years (until Victorian times) before machines like the Linotype and Monotype typecasters were able to take over most of the load.
Of course, access to machines like that was pretty much limited to professional publishing concerns.
The typewriter made it possible for almost anyone to put print on paper - pretty ugly, limited, monospaced print, it's true, but it was great leap forward.
Since the advent of the personal computer in the 1970s we've seen steady progress in the quality of printed material ordinary non-experts can produce. Dot-matrix and daisy-wheel printers have been replaced by laser and inkjet printers. Regular word-processing software like Microsoft Word can turn out very professional documents. The desktop publishing revolution of the 1980s brought software which can do just about anything you want. And you don't have to be an expert to use any of these - templates and default settings will give you professional results.
And here we are with the Web. It's the most important publishing medium in human history. Because for the first time it democratizes both the production AND distribution of high-quality content. And you can read it on a screen, keep it up to date, re-purpose it, etc.
But it's clear to me that we're still missing a huge piece of technology: an authoring tool which can be used by anyone without expert knowledge( i.e. the ability to hand-code) which produces standards-compatible, professional-quality Web pages.
That's the Desktop Publishing revolution of the 21st Century, and it's still waiting to happen..
Subscribe to:
Posts (Atom)