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.
:: Well, to get nit-picky (and really, who doesn't like to get
:: nit-picky?),
No argument from me... though what exactly are nits and how would you pick
them? ;)
:: there are plenty of scenarios in which this particular
:: characteristic of
:: HTML makes it better for file management.
File management or content maintenance? There's a big difference, and the
example below fits more into the latter than the former...
:: For example: I've got our 500-page manual posted in HTML
:: format on our Web
:: site. I determine that, doh, 5 screenshots are incorrect. I
:: retake the
:: screenshots, upload the new versions, and I'm done. If it
:: was posted in PDF
:: format, I'd have to insert the images in the source, then
:: re-distill the
:: source and post the PDF to the site. What's more, the PDF
:: will take longer
:: to post because it's probably considerly-bigger than my images.
I won't disagree that HTML is more manageable content-wise in this regard,
but there are other factors at work here that still make this a gray
(disabled? *vbg*) issue:
1) Very seldom do screen shots change in such a way that you only have to
update images and not accompanying text. So you're playing with graphics AND
content.
2) Posting time should not be an issue. If you're involved in content
management for the Web, you should have either direct network access to the
server or some sort of high-speed access for FTP. Otherwise you're wasting
time in general. ;)
3) Even in the extremely simple scenario you outlined above, you are
uploading 5 files as opposed to one, and who knows if all 5 files belong in
the same directory, should keep the same file names, need to now be included
in a new folder for some bizarre reason. With a PDF you are uploading one
file to one directory.
Of course if the document is large enough, you would want to maintain both a
PDF and an HTML copy for increased usability, if being served from the Web
or via another downloadable access point. No one likes to sit and wait for a
5+MB file to download. I think that's fairly safe to assume. *IF* HTML is
designed well and chunked well, users would have a better time navigating a
site for info, and THEN if the info is deemed Download-worthy (man, now I'm
having Seinfeld flashbacks) they would grab the PDF.
Of course PDFs can be chunked into smaller files too...
...what's the current price of tea in China? *vbg*
*****************
BILL SWALLOW
Technical Writer
C O U R I O N C O R P O R A T I O N
1881 Worcester Road
Framingham, Mass. 01701
T E L * 508-879-8400 x316
F A X * 508-879-8500
www.courion.com
*****************
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
Sponsored by Cub Lea, specialist in low-cost outsourced development
and documentation. Overload and time-sensitive jobs at exceptional
rates. Unique free gifts for all visitors to http://www.cublea.com
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
