On Sun, 23 Jan 2000 20:09:16 -0800 Sam Gendler <sgendler@impossible.com> wrote:
It is an unfortunate aspect of human psychology that it feels much slower to wait for a long time and then receive quickly, than it does to just receive the document a little slower, but with less initial latency.
Actually, as IBM extensively researched and documented with their old frame based terminals the reverse is generally true. Given a screen full of data which arrives, painting across the screen for a total of 10 seconds or Given a screen which paints instantly after a 10 second wait during which nothing visually happens other than a possible busy bar the majority of people will consider the second as far "faster" and "more responsive". There is however a riding caveat: Web users are trained to be able to do something with partial data, to be able to act _before_ the entire page has been rendered. In the IBM world above, the base assumption was that nothing could be done until the entire data set (the "frame") had been received. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=--
There is however a riding caveat: Web users are trained to be able to do something with partial data, to be able to act _before_ the entire page has been rendered. In the IBM world above, the base assumption was that nothing could be done until the entire data set (the "frame") had been received.
Exactly. I was speaking specifically of the web world, where all kinds of research has shown that simply including image size attributes in your <img> tags causes speed perception to be dramatically improved, since the browser can render the document before the images even begin to download. I myself frequently click through to another page long before a page has completed loading, partcularly if it is going slow. --sam
J C Lawrence wrote:
On Sun, 23 Jan 2000 20:09:16 -0800 Sam Gendler <sgendler@impossible.com> wrote:
It is an unfortunate aspect of human psychology that it feels much slower to wait for a long time and then receive quickly, than it does to just receive the document a little slower, but with less initial latency.
Actually, as IBM extensively researched and documented with their old frame based terminals the reverse is generally true.
Given a screen full of data which arrives, painting across the screen for a total of 10 seconds
or
Given a screen which paints instantly after a 10 second wait during which nothing visually happens other than a possible busy bar
the majority of people will consider the second as far "faster" and "more responsive".
There is however a riding caveat: Web users are trained to be able to do something with partial data, to be able to act _before_ the entire page has been rendered. In the IBM world above, the base assumption was that nothing could be done until the entire data set (the "frame") had been received.
This might be a `<table>' issue. If you generate one or more tables they won't be rendered until all their content is downloaded. In the HTML4.0 reference you will find hints to make it start rendering earlier.(it's just the matter of computing the number of columns and rows) -- CIMPOESU Teodor, Web Programmer @ DIGICOM S.A. Bucharest, Romania @ Internet, site development @ teo@digiro.net , +(401)-330.47.28 official home page ~ http://www.digiro.net/ Internet web page ~ http://internet.digiro.net/
On Sun, 23 Jan 2000 20:09:16 -0800 Sam Gendler <sgendler@impossible.com> wrote:
It is an unfortunate aspect of human psychology that it feels much slower to wait for a long time and then receive quickly, than it does to just receive the document a little slower, but with less initial latency.
Actually, as IBM extensively researched and documented with their old frame based terminals the reverse is generally true.
Given a screen full of data which arrives, painting across the screen for a total of 10 seconds
or
Given a screen which paints instantly after a 10 second wait during which nothing visually happens other than a possible busy bar
the majority of people will consider the second as far "faster" and "more responsive".
There is however a riding caveat: Web users are trained to be able to do something with partial data, to be able to act _before_ the entire page has been rendered. In the IBM world above, the base assumption was that nothing could be done until the entire data set (the "frame") had been received.
This might be a `<table>' issue. If you generate one or more tables they won't be rendered until all their content is downloaded. In the HTML4.0 reference you will find hints to make it start rendering earlier.(it's just the matter of computing the number of columns and rows)
Yes, but I do believe that most seasoned web developers know to avoid a table that encompasses the whole page. Most split the page into horizontal bands. Eg. the top table (which may encompass other tables) is the banner. Then one or more for content. Then one for footer. Or some other permutation. But returning to the desire to send HTTP headers and HTML back to the user before all the computation is done, I could relate to that. In fact, one of the things that put me off Zope for a long long time was the inability to send back HTML before all computation for the entire page had been done. By comparison, with CGI scripting, I was accustomed to sending back the HTTP headers almost immediately, and even the HTML for the table encompassing the banner bar. Then and only then would things like sending mail, updating databases, etc be done. This had the advantage that the end user saw the top of the page almost immediately. It appeared faster. Really. However, when I started using these CGI scripts on large projects, it soon became clear that there is a LOT more flexibility in doing all the computation first... so that you can use a redirect, or set cookies, or do other things with the HTTP headers that would otherwise be too late if you'd already sent the first half of the web page. Bottomline : it appears a little slower the Zope way, but it's more flexible and has eased my development a great deal. chas ps. Nice IBM anecdote, Sam.
participants (4)
-
chas -
J C Lawrence -
Sam Gendler -
Teodor Cimpoesu