TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Web Server & Documents From:"Susan W. Gallagher" <sgallagher -at- EXPERSOFT -dot- COM> Date:Tue, 8 Apr 1997 13:01:58 -0700
>> First, if you're delivering the files to the customer for use
>> on a local hard disk or company intranet, you don't know their
>> how there hard drives are formatted. If they've optimized their
>> drives for large files, a couple of hundred HTML pages could
>> gobble disk space like the monster that ate Chicago. You can
>> make a lot of enemies this way.
To which David Blyth replied:
>And the same number of regular help files won't gobble disk space? I'm
>not sure I understand here. You never download an entire HTML document,
>so your second objection seems more valid.
And David Demyan replied:
>...There is no need to actually download the
>files since the idea of the internet is to take advantage of
>client-server delivery of information. ... I do not understand how hard
>drive formatting can be "optimized ... for large files." But,
>whatever this impact is, since the files are not actually down-
>loaded to the hard drive, I don't believe it is significant.
So, I'll explain.
First, about disk space. Just for argument's sake, you have a
doc set that consists of 300 topics, each about 10 sentences
long. When you compile these topics into a single help file,
it's about 32K. When you create HTML docs, you have 300
individual files, but the same amount of information -- less,
really, because you don't have to store the window definitions
and additional help file informaiton.
When you store a file on a hard disk, the File Allocation Table
or other disk indexing scheme tracks the contents of individual
sectors. Even if store a single byte of information, that byte
will consume an entire hard disk sector. Disk indexing schemes
do not get any more granular than that -- it would take them
too long to retrieve information if they did.
The typical PC hard disk is formatted into sectors of 1K each.
(You can tell because that's the smallest file you'll find.)
You store the help file, it flows into contiguous sectors and
consumes about 32K of disk space. Even if you put it on a network
drive that's been "optimized for large files" -- that is, formatted
with sectors of 2K or even 5K each -- say 5K -- then the help
file takes up 35K of disk space. The difference is insignificant.
But, since *each file* consumes a single sector of the hard disk,
no matter what its size, those 300 individual HTML documents
consume 300K of disk space -- one document in each sector. If
your hard disk is formatted with 5K sectors, all of a sudden
that HTML doc set consumes 1500K disk space -- and it's the
exact same content as the 32K help file.
Again, if the docs are on your web site, it's your problem,
not your customers'. However, I've recently released HTML
documents on CD which may be left on the CD, copied onto
a customer's intranet, or copied onto an individual's
hard disk. I don't know the final resting place of these
docs. They may or may not make it to the Expersoft Web page.
But the docs are in HTML because they support a Java-based
product and need to be cross-platform. (Acrobat doesn't
support enough platforms.)
Then I said:
>> Second, if you're delivering the files to your web site for
>> online access, you have that horrendous lag time between
>> the request for a new page and its actual appearance. This
>> time delay can be a significant disruption in the users
>> thought process.
>> Making HTML pages a little longer than help pages seems like
>> the appropriate compromise. The users have faster access to
>> information because download happens less frequently and
>> they can start reading the top of a page while the rest of
>> it is being transmitted.
And David Demyan replied:
>I don't agree. The access is not actually faster
>and the resulting files are not chunked like Help files.