[Bob Williams]

Originally Posted by Forrest

That's not the case, I have not been saying that a progress bar is strictly a measure of time.

I apologize, then, for misinterpreting you.

All that I have been saying is that it is a measure of something that, in this case, cannot be done accurately.

Load a complex page and watch the status bar. You will see the number of total resources increase.

That's why I said the resource count was generally fixed, because it's not in every case. As it happens, most of the sites I visit tend to have a fixed resource count, but I guess more often it's not fixed.

If a progress bar was used on every tab, you would see them constantly getting longer and shorter, then longer again, then shorter... as the pages load. This is unless the total measure of the progress bar was a constant value. For example, if a full bar was equal to 1000 resources. Otherwise OW would have to continually recalculate the overall measure of the bar.

But that's exactly what the text counter does. A growing progress bar (or conversely, a shrinking % done) would be exactly the same but graphical instead of textual. Having it be graphical simply lets you get the gist of what's happening without the burden of details--and often, especially when you're moving along quickly, that's exactly what you want. It's very similar to an analog tach or speedo in a car versus digital ones. (If you're not a driving enthusiast, just ask someone who is whether they prefer digital or analog gauges and why.)

That said, they wouldn't necessarily need to get shorter. If resources are added to the count, the bars could just hold their current positions until they once again accurately represented the overall measure. I suspect this is what other browsers do, which explains why their progress bars tend to pause periodically. I would actually prefer they change fill length (perhaps with the addition of a high-water marker), though, as then you can see--and know--exactly what's happening instead of guessing.

The difference with the text version, IMHO, is it leaves the guesswork to the user. In other words - it's just reporting the facts and not trying to interpret them into some measure of completeness.

But a progress bar would be reporting the exact same information, just visually. Basically, you're being told what proportion of the presently known resources have already been loaded. If more resources are added, you adjust it.

First of all, if what you're looking for is an at-a-glance graphical representation of page loading status of multiple tabs, without having to click on them - that already exists. At least when "start drawing before entirely loaded" is checked, the tab thumbnails provide an indication of how much has loaded in a page. Furthermore, this is far more accurate than a resource count progress bar would be.

It's far more accurate if the tabs are big enough to see that level of detail, but mine aren't. I can see that the navigation graphics and such are starting to appear, but I can't see whether the body text is there yet. Also, remember that there's a list view of the tabs where you have no preview at all; a progress indicator would support both tab styles. (WRT the situation I specifically mentioned, most of the time, after a restart, OW opens up my tabs in list view and then switches on its own back to icon view sometime after it finishes loading everything. Thus, even if my tabs were normally big enough to see that much detail, it wouldn't help me in this case.)

I'll use the example you cite - the ad. A progress bar isn't going to let you know if that's what's holding up the page. You will still have to click on the tab to see if you can read the content. Even if the page has loaded 99% of the resources, one can't tell from a progress bar that the last 1% is the text on the page. So if you're trying to avoid waiting for all your tabs to load before you can find one to read, a progress bar isn't the answer.

Except in very rare cases (mostly AJAX-extreme cases like gMail), the text on the page is part of the base HTML, which is the primary resource, and the ads are usually secondary resources (i.e., those that are only known about after the primary resource--the basic HTML--is loaded). As a result, when you're stuck loading the very last resource, it's almost always an ad or at worst, some other image on the page. Very, very rarely is it the text.

I completely agree that this is all far from optimal. Unfortunately, I can't think of a workable solution that *is* optimal.