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: Convert Paper Documentation to Web Format From:Dan Emory <danemory -at- primenet -dot- com> To:"Christensen, Kent" <lkchris -at- sandia -dot- gov>, "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Fri, 5 May 2000 10:26:20 -0700 (MST)
At 09:20 AM 5/5/00 -0600, Christensen, Kent wrote:
>re: How do you expect readers will use the material? If you expect they
>will actually read and use the information on line, then it makes sense to
>deliver the material in an on-line format (HTML or XML etc.). (Penny
>Staples)
>------------------------Snip--------------------------
>I'd go on and add that the web is probably a more "visual" medium in other
>ways, and I think that "documentation" that has lots of graphics will be
>more successful. This may also be somthing required for successful
>conversion to web presentation.
>True, but likelihood of users wanting to read online material that is simply
>copied over from a paper version is low in the first place. If the paper
>stuff is "enhanced" for the web by insertion of hypertext links and revised
>formatting for screen viewing, the likelihood will increase. It takes some
>extra work to avoid the self-fulfilling prophecy thing.
======================================================================
I completely agree. As I stated in my earlier post on this subject, the
on-line document should use the typography and layout that has at least the
look and feel of a well-desinged printed doc, but it most certainly should
be robustly hypertexted, including (if PDF is the deliverey format) a TOC in
the bookmarks (FrameMaker autogenerates these bookmarks). Also the judicious
use of visual cues (e.g., bold, italics, and particularly color) for
keywords, headings, etc. have been experimentally proven to greatly enhance
the ability to quickly locate the needed information.
When it comes to graphics, particularly large, complex ones, there's a real
problem with most on-line delivery formats. PDF is the exception. Not only
can it handle large graphics (including making a larger page size for them
in the midst of lettr-size pages), but also because Acrobat offers a zoom
capability (up to 800%), which can make all the difference.
====================
| Nullius in Verba |
====================
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory -at- primenet -dot- com
10044 Adams Ave. #208, Huntington Beach, CA 92646
---Subscribe to the "Free Framers" list by sending a message to
majordomo -at- omsys -dot- com with "subscribe framers" (no quotes) in the body.
