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:"Mendem Concord, Inc." <dbdemyan -at- WORLDNET -dot- ATT -dot- NET> Date:Sun, 6 Apr 1997 17:38:40 -0400
Susan W. Gallagher wrote:
--snip--
> I agree with David. We've had excellent results with HTML Transit.
> Although we also have the capability of converting from RoboHelp
> to HTML, we haven't used this approach as yet.
Thanks for the concurrence. I don't know many who have tried HTML-T
and disliked it.
Susan, you disagreed with my sometimes-used approach of doing an
HTML conversion through RoboHelp --> WinHelp --> HTML when I want
a "Help-like" (my coinage) feel to the web files (deployed either
inter- or intranet). If I understand correctly, you prefer longer,
fewer files so that downloading is enhanced and rightly point out
that going through WinHelp first would make each HTML document
smaller, forcing multiple downloads. While this is true, I don't
agree with the technical basis behind some of your objections.
--snip--
> 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.
DBD Response: I do not see the necessity nor would I advise
users to make a separate downloads of inter- or intranet delivered
HTMLs. [I'm purposely ignoring the cached files since this is a
dedicated wraparound set of files to improve performance and has
no additional hard-drive impact beyond the amount of cache set
aside by the user.] 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. Leave the headaches to
the more powerful server. Therefore, I do not expect to make a
"lot of (new) enemies this way." 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.
> 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.
DBD Response: I'll ignore the significant differences between
browsing HTML via a dial-up internet connection and a dedicated
LAN-based intranet since these factors apply to both short and
long web pages. My stopwatch indicates short HTMLs download
quicker than longer ones, thereby avoiding the "time delay
(that) can be a significant disruption in the users (sic) thought
process." While I agree that delay is a disruption, I argue that
my approach actually works to avoid delay better in most
environments. I haven't tested extensively, but based on daily
observation, I strongly feel that shorter information chunks
appear quicker and are more Help-like than longer ones. Please
keep in mind that my recommendations were based on two information
requirements. For longer chunks of information that are based
on user guides or operators' guides, I would convert using HTML
transit and perserve some of the look-and-feel of the original
book. To achieve a Help-like environment, I would maintain
shorter files and convert through WinHelp.
> 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.
DBD Responds: I don't agree. The access is not actually faster
and the resulting files are not chunked like Help files.
> So, for our online solutions, we start with Word, go thru
> HTML Transit for browser-based docs (putting each major
> section or chapter into a separate HTML page), and go
> thru RoboHelp for WinHelp (putting each section heading
> thru level 3 into a separate WinHelp topic).
DBD Responds: I like the new trend blurring the distinction
between the online browsers. I like the idea of being able to
deliver Help-like files via web technology taking advantage of
a high degree of platform independence. This makes information
easier to get and browse and that's a good thing in this
business. I still like to use compiled WinHelp files on
Windows platform applications, but when I want to emulate the
excellent WinHelp look-and-feel _and_ maintain a degree of
platform independence, I'll convert using RH --> HTML.
Thanks for provoking a lot of thought on my part to defend
my position.
Regards,
Dave.
......................................................................
David B. Demyan Mendem Concord, Inc.
Toll Free: (888) 753-8500 Technical Writers
FAX: (908) 756-0129 Document Conversions
dbd -at- mendem -dot- com http://www.mendem.com
......................................................................
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html