Bill Hill: The Future of Reading on the Web, Part 2
- Posted: Oct 20, 2008 at 8:35 AM
- 54,226 Views
- 32 Comments
Download
How do I download the videos?
- To download, right click the file type you would like and pick “Save target as…” or “Save link as…”
Why should I download videos from Channel9?
- It's an easy way to save the videos you like locally.
- You can save the videos in order to watch them offline.
- If all you want is to hear the audio, you can download the MP3!
Which version should I choose?
- If you want to view the video on your PC, Xbox or Media Center, download the High Quality WMV file (this is the highest quality version we have available).
- If you'd like a lower bitrate version, to reduce the download time or cost, then choose the Medium Quality WMV file.
- If you have a Zune, WP7, iPhone, iPad, or iPod device, choose the low or medium MP4 file.
- If you just want to hear the audio of the video, choose the MP3 file.
Right click “Save as…”
- High Quality WMV (PC, Xbox, MCE)
- MP3 (Audio only)
- MP4 (iPod, Zune HD)
- Mid Quality WMV (Lo-band, Mobile)
- WMV (WMV Video)
This is the second part of the interview that Dan and Christian did with Bill Hill. (See
Part 1 here).
While many people know Bill from his work on True Type and his passion for improving screen readability, Bill is now working on improving Web readability in Internet Explorer and how reading on the Web hasn't improved since the early days of browsing.
In this part of the interview we continue with the discussion on font embedding. But this time Bill Hill tells us also about readability in general, shows us his website and thoughts that he had during designing the reading and layout experience for it. In one of the various side stories he explains to us how and why the letters in our alphabet evolved as they did. By the end of the interview Bill Hill shares some personal stories that includes also how he started to learn reading animal tracks.
To see Bill's site using font embedding and clean HTML/CSS with multi-page flow, go to http://www.billhillsite.com.
While many people know Bill from his work on True Type and his passion for improving screen readability, Bill is now working on improving Web readability in Internet Explorer and how reading on the Web hasn't improved since the early days of browsing.
In this part of the interview we continue with the discussion on font embedding. But this time Bill Hill tells us also about readability in general, shows us his website and thoughts that he had during designing the reading and layout experience for it. In one of the various side stories he explains to us how and why the letters in our alphabet evolved as they did. By the end of the interview Bill Hill shares some personal stories that includes also how he started to learn reading animal tracks.
To see Bill's site using font embedding and clean HTML/CSS with multi-page flow, go to http://www.billhillsite.com.
Comments Closed
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums,
or
Contact Us and let us know.
Follow the Discussion
Awsome video
The heading in http://www.billhillsite.com/ doesn't wrap correctly in IE7 so I'm assuming the site is designed for IE8?
It gives me a horizontal scroll bar at the bottom and a whole lot of nothing to the right even at 1440X900.
I DO find that site very easy to read though, so I like it.
Great talk though. I really liked the point about adopting the computers to the human eyes instead of vice versa.
Mr. Hill is a pleasure to listen to. I think he should get his own show.
Lascaux cave drawings
Lascaux wiki
In my subscription to National Geographic there is an add that has a picture taken of cave writings. I was fascinated by the idea that these are early forms of writing. Place a camp fire in the cave and let it flicker on the walls and you have early form of moving pictures that must have been mesmerizing to the creator and his friends. I wonder what the price of admission was. Maybe they traded furs or stone cutting technologies maybe it was some kind of social bonding. The art work and rendering of such animals is remarkable. I think these cave paintings are a testament to the legitimacy of the human brain during prehistoric times. Ill bet these people had the intelligence to use a computer if they had them. It makes me think, that if we compare the computer technology to those cave drawings that there are still many more advancements to be made in technology. Particularly in writing and communications.
I assume you're talking about Embedded OpenType - which, by the way, is also the Web font embedding scheme which Adobe supports.
We never had any thought of extracting license fees from competitors for this technology, now or in the future. It's implicit in handing it over to the W3C as a Web standard that granting rights to any IP it uses is part of the package.
Correct, the site is designed to use the default Web-standards rendering in IE8. A horizontal scroll bar, ugh!
Try IE8 Beta 2 - it's terrific, very stable, and has a compatibility button so older websites don't break.
http://www.microsoft.com/windows/internet-explorer/beta/
And please let me know if you still have problems. 1440 x 900 should be ideal, that's what it was created on.
Some great books:
"Guns, Germs and Steel" and "The Third Chimpanzee" by Jared Diamond.
"The Journey of Man: A Genetic Odyssey" by Spencer Wells.
You might like to read my paper "The Magic of Reading", which is posted on my website.
http://www.billhillsite.com/osprey.doc
ehmmm... I don't like Betas anymore so I think I'll stick with IE7 until IE8 is final.
I saw the site working on your computer in the video so that's good enough for me.
If you're curious, this is what it looks like in IE7 scrolled all the way to the right with the text that doesn't wrap correctly highlighted so you can see it.
http://img530.imageshack.us/img530/8881/billie7jh8.jpg
Site was specifically designed to utilize IE8's Web standards rendering. Works in other Web standards browsers, but no embedded fonts.
Great talk as always, very informative and very interesting, always love your stories. You should strap a camera on Dan and head to the forest.
I was looking at your site earlier, and it doesn't quite render correctly in firefox 3.0:
This is in 1600x1200 on a CRT, so no cleartype unfortunately.
Then there's the scrolling. Reason number one why columns don't work on the web: I have to scroll down to read all of column one, then scroll back up to continue in column 2. This is fine if all the text fits on one page like on Bill's screen, but on my screen that's not the case.
On the web, you have to always design for the lowest common denominator. That means 1024x768. Quite a lot of people even still use 800x600 according to the statistics from some of my sites. And that's assuming they're running the browser full screen, which not everybody does. Add mobile devices with different form factors and it gets even more complicated.
A web site must work at every conceivable screen resolution. Bill has managed to create a nice site that unfortunately only works at one, which makes it useless in the real world. I understand this site is for research purposes, so it's not an issue there, but this is a real world problem that needs to be solved. I'd be very interested in hearing Bill's ideas on how to solve that but unfortunately he doesn't seem to be replying to the comments on these last two videos.
I thought Bill used to post here under a different alias, that's probably why it didn't register.
On the web, you have to always design for the lowest common denominator.
I don't think that's necessarily true. Of course, you know that separating the content from layout is the first step to making automatic reflow work. I do love the idea that the browser can gracefully switch from 3 columns layout on a landscape monitor to 2 columns on a portrait Tablet PC monitor, to a single column, scrollable iPod Touch.
They do wonderful stuff at CSS Zen Garden, but I hope that web devs don't have to know CSS ninjitsu to do that. Perhaps, now that Bill is on the case, the browser can determine column layout as well as page size just by our display size. Talking about adapting machines to us and not the other way around
I've briefly looked at Flash 10 and they are touting advanced text layout functionalities. Not sure what that means yet, but the trend seems to be moving away from W3C and browser support onto more self-contained content engines like Flash and Silverlight. Perhaps that's a more viable way than herding the browser cats towards correctly implementing correctly a W3C standard.
Great talk, as always, Bill Hill.
Bill, I just wanted to let you know that in IE8 Beta 2, the pictures are not scaling with the column width. This results in the pictures overlapping the text in column 2. Also, designing for 1440x900 is not a great idea. Personally, I never maximize my browser window. It's roughly 1024*768 most of the time, on a 1280x1024 display.
Also, and this is just my opinion, the web makes it possible to not have to bother with pagination. I'd like to see more of move towards content being on one page, rather than splitting it up to mimic a paper publication or to load a few more banner ads.
Spivonious: I *think* at least in part bill is looking at a few aspects of reading and the web and how to deal with them.
the size he is using I think is just one that he can test with his screen. I think he did say that he wants to mke the number of columns a dynamic factor at some point.
here is one example, if you make a page "FOR" 1024x768 then on other screens it's going to waste a lot of space.
or if you make a "flow layout" that sizes to the screen w/o some kind of column sizes then the lines get way to long.
and if you make the text just one column with a good width then the scrolling and wasted space suck.
Pageination: well I find it much better to be able to "go to" page ## of a document then to try and find where I was by scanning 80,000 lines of text. that alone is one reason to have "Pages" of text. I do not think that bill was advocating adverts, if anything he would (IMHO) say they are bad due to the way they try to pull your eye to look at them thus ruining the reading process.
echoing print layout should be a great way to put the most content on a screen at one time.... that's what they have been doing for a long time.
I'm not trying to put words in Bill's mouth, just that I think I agree with what he is upto.
I would love to see some of this work take bill next to working with the Visual Studio team on the web form/ win form/ wpf/ silverlight designer tools.
I hate how the built-in web form tools do nothing to help a developer make a good web form.... sure they dump textboxes and lables into a container but.... no help with how to layout that data entry form, just an ugly chunk you then have to fix.
The problem I always find with building for the web is that it usually forces you to make a choice between evils... hard-setting sizes for everything in pixels so that at least everthing remains in the intended persepective, or trying to scale stuff and then getting everything to scale as expected... text can use pixels, points, ems... but other elements are far more problematic... while scaling bitmap-type images (jpg, gif etc) is just plain nasty.
It a bit like rubbing jam in your hair... the more you try to fix it, the worse it seems to get.
That was fantastic. The last few minutes were incredibly thought provoking. The idea of going back to our distant past to expose the roots of our present problems is more generalizable than it first seems. Nurture over a million years became our Nature. Human civilization has only been around for a few tens of thousands of years and therefore could hardly have an impact on our nature. So many of our problems originate from the fundamental mismatch between the evolved human nature over eons and the demands of modern society which has been around for a much shorter time.
The masthead <div> Bill Hill's Blog, has another font subtituted, which makes it longer, which overflows into the next div, and so on and so on down the page.
The site was designed to show off font embedding, which IE has had since 1996. With IE8 Beta 2 it works great. However, because the code uses cross-browser standards, if you have the right fonts it also renders fine in Safari and FF. I've tested on both (although FF's multicolumn support can do funky things at times. It uses its own proprietary tags - which don't validate with the W3C's CSS3 validation tool. I put the Mozilla tags in at first. But I wanted to have the pages absolutely standards-compliant, so I took them out).
Part of the purpose of creating those pages was to show why it should be solved for the Web...
Go look at the New York Times reader or Seattle P-I Reader on your machine. The P-I one's free; it will install WPF in the process.
Sorry, but you're very, very wrong.
We've just never seen it done right yet. But we will.
Also, I like the idea with the DPI value thing, though, I always can see the pixels. Even on a 204DPI screen, easily. My eyes are very good (too good actually) and it would need a 800+ DPI screen to let me no longer notice. When I am looking for a notebook, I do not look for the display form factor or the display size, when I am considering the screen criteria. I am looking for the form factor of the notebook and the screen resolution. Because for me, higher resolution means I can put more stuf on my screen. A notebook for me has to me of small form factor, so that I can run around with it easily. If I were to look at the DPI value, I would have to get one with a considerably large screen, where the pixels would disturb me like nothing. I am very fine with the 96DPI model, and I am very well running a 147 DPI screen on that. I can put more stuff on my screen that way.
Large fonts are of no use to me, they just waste space. Space I don't realy have. I prefer a font size between 8 and 10 visible pixels. That's about the border of a readable font rendering in pixels. The higher the resolution the more text fots on screen, the more text fits on screen, the more I can read without changing the page or scrolling.
Bill, I can't remember if you requested something like this on part 1 or part2; but it's a script to replace " with correct typography quotes in HTML... It reads a file called testcontent.txt and does the replacement and puts the new content in testcontent.html. If you combine this with a directory reader you could make quick work of it. I might the 900th person to send you this but atleast I can sleep knowing I tried to help.
Enjoyed the post as always...
var fso = new ActiveXObject("Scripting.FileSystemObject");
// Read a file containing our quoted content
var file = fso.OpenTextFile("testcontent.txt", 1, true, 0);
var content = file.ReadAll();
file.close();
// This line says find everything between " and ", record that as $1, then. We return the output as “ + $1 + ”
var content = content.replace(/\"([^"]+)\"/g, "“" + "$1" + "”");
// Save the new content to an html file
var file = fso.OpenTextFile("testcontent.html", 2, true, 0);
file.writeLine(content);
file.close();
Run through once by hitting "Replace", then "Find Next", effectively skipping every second ".
Then run through again hitting "Replace" for every one.
At first I made the mistake of putting all the HTML header stuff in. Also, my normal paragraph opening tag is <p class="hyphenate">.
This meant there were lots of " marks which couldn't be replaced - therefore I couldn't use "Replace All".
All stuff you learn the hard way.
But even if you got the automated process right, you still have to check everything by eye because of the initial transcription errors. Well, if you've been a professional editor like me for more than two decades you do
Moral: Do all the S&R work on the plaintext file before you put any tags, DOCTYPE or other declarations in it.
The other issue I had with the Mabinogion text was that it was written in 1849, a very different era in which paragraphs nine or ten sentences long were acceptable. This caused two problems, one aesthetic and one technical.
Aesthetically, it's hard for us more modern folks (even folks as old as me) to read paragraphs that long; that's not the way people write today.
From a technical perspective, it caused problems because the multicolumn Javascript uses the DOM. That means its lowest level of granularity is the <p> element. So if you have long paragraphs you get very weird line-breaking at the bottoms and tops of columns. I found that you could get around this by breaking the long paragraphs into shorter ones, effectively creating more opportunities for "good" column breaks (ie at the ends of paragraphs). Sometimes I had to go in and create or remove paragraph breaks higher up in column 1 of the text, or lower down in column 2, to force "good" column breaks.
At the end of a chapter, I often had to put in multiple <br> tags at the end of the text to force a decent column break - which is why the columns at the ends of chapters aren't equally balanced.
In other words, there was still a lot of manual work to get column and page-breaks right...
I know how we can make a huge number of those issues go away. Which was one of the reasons for doing this project
Right on Bill. I thought about this specific issue when I wrote the sample script but I assumed the editors back in the day would check for the matching end quote. I didn't know the full history of the works.
I find it interesting your approach. I'm sure in the past the method of choice would be to save in a publisher-friendly format (word exported pdf). I suppose the point is the developer/designer/publisher should have options of how to format things easily.
There is no reason you can't give the script more advanced logic; maybe even put the display logic in JavaScript so it can best adapt to changing displays. For example if you had some function that would calculate the ideal character width of the page or column for a given client then you could change the works to auto justify, and get optimal page breaks.
I'm a very lazy person -- I would have wrapped this in an ASP master page and written a few scripts because chances are you're going to do all this work and 2 years from now someone will have the bright idea to change <br> to mean 1.5 line-spacing or something and you'll have to re-do all your efforts.
Anyway Bill, good luck on your project...
It was a lot of work, but I wanted do it to squeeze the maximum level of readability I could, with the functionality we have today, using Web-standards content. Then I can help specify exactly what has to happen to fix the many issues I've identified.
There are things I'd like to see happen in Internet Explorer, there are things that need to happen to evolve better Web standards, and there are things that could be done to improve authoring tools.
If the web really is the publishing platform of the future - and of course it is - then we need to give that platform all the capabilities authors and developers require to create professional-quality typography and layout - in an environment where the content creator does not know the characteristics of the display device. What he or she does know, however, are the characteristics of the human who'll be reading it - for those haven't changed in millions of years.
It's a fundamental change from the way we've designed the display of information for 35,000 years. So it's going to take a while. Times Roman was not built in a day
"([^"]*)"
(including the leading and trailing ") in the "Find What:" field and
“\1”
in the "Replace With..." field.
You can then use Find and Replace as you normally would, either using "Replace All" to quickly replace all instances, or "Find Next" to find what it thinks is a quoted string, tweaking the text if it's incorrect (i.e. adding the missing ending ") and then clicking "Replace".
[EDIT: Corrected regex]
Either should work. I prefer points.
Quick Thoughts:
1. I had to click on "Commont On Post" 3 times to comment on...the post. This is slightly annoying.
2. Where can I go to learn about how the open-sourcing effort is progressing?
Slow Thoughts:
I just downloaded IE 8 RC 1 and installed it on my ThinkPad with a 1440 x 900 screen set at 121 DPI and the default browser font set to Calibri and plain-text to Consolas.
I've noticed a lot of things breaking on Cover.htm even when IE8 is full-screened. Where should I post those bugs?
Remove this comment
Remove this thread
close