Re: GDP: length/page-splitting of subsections

[Rune Zedeler]

Citat Graham Percival <address@hidden>:

> The all-in-one HTML page is **5 megs**.  I'm astounded that so many
> people (ie more than 0) are choosing to download that monster _every
> time_ they want to look something up in the docs.

We don't.
Browsers have caches, you know :-)

> Let me phrase this question differently:
> - if you currently use the all-in-one HTML page, how could we organize
> the non-all-in-one docs such that you use them?

I actually think that if we have each section on one full page (suggestion 1,
that is) I would start using the several pages manual.
Navigating so much as what is nessesary in the current manual I loose the
overview and spend too much time waiting for the page to load.
I agree that loading times are important. But for me, typically it is the
request time (i.e. the delay), not the transfer time (i.e. the speed) that is
the limit. I often have to wait several seconds from I press a link till it
starts to load. But as soon as it loads it goes very fast.
I did a very quick count, it seems like we have something like 60 sections.
If the whole manual is 5Mb, that means that each section is about 120kb.
On a 256kbps line (that is, on a rather slow line) loading the whole thing will
take four seconds. Add to that that you can start reading as soon as just the
text has been loaded - before the images are compoletet - I will say that the
"loading times" argument for possibility 2 is nonsense.
What takes time is requesting the page - not loading it after it has been
requested. Hence, the fewer pages to reqeust, the less loading time.