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: Documenting for LCD or most common? From:Dick Margulis <ampersandvirgule -at- WORLDNET -dot- ATT -dot- NET> Date:Fri, 13 Feb 1998 15:50:00 -0500
Colleen,
You should definitely document for all the platforms you sell for, with
platform-specific illustrations for each.
A small getting started or installation guide might contain all the
information in a single edition (but in separate sections); otherwise
you may wish to publish separate editions.
This is an ideal application for something that handles conditional
printing, such as Interleaf (long boring technical aside coming. Skip to
the end of the paragraph if you already understand Interleaf's
effectivity feature): In Interleaf, you may assign attribute values to
objects. In your case, you could create an attribute called "platform"
and assign values such as "31," "95," "SunOS," etc. Components
(headings, for example) that are the same for all platforms would have
no value assigned to the "platform" attribute. Windows 3.x screen shots
would have "31" assigned to the "platform" attribute. Windown 95 screen
shots would have "95 assigned. Paragraphs of instruction would be tagged
similarly. You would then enter something called a Control Expression
that would turn components off if they did not match the desired
attribute value. For example, a simple control expression might be
"platform = 95." This would cause all of the untagged elements and all
of the Windows 95 elements to remain visible and everything else to be
hidden. Changing the Control Expression to "platform = 31" would hide
the Windows 95 elements and unhide the Windows 3.x elements. Pages would
reflow automatically, which sometimes leads to the need to tweak.
I'm sure there are other approaches, too; but I would definitely
recommend providing the user with documentation that actually looks like
the product on the screen.
Colleen Adams wrote:
>
> We are in the process of revising a user's guide for a new version of
> software (Windows-based ) which is about to be released. We've
> already re-pulled the screen captures which were done in Windows 95
> but had previously been done in 3.1. (BTW, the software is still
> compatible with 3.1.)
>
> Q: When documenting installation instructions, should we document for
> both 3.1 and 95? As a rule, should we document for lowest common
> demoninator or most commonly used? (I've already checked with
> Customer Support to verify that we still have some 3.1 users--and we
> do.) If yes, then do we split out the 3.1 instructions from 95 or keep them
> together?
>
> Q: We also have various tutorial lessons which step you through some
> applications of the software. Again, Windows 3.1 or 95?
>
> Any advice would be appreciated!! Thanks!!
>
> Colleen Adams
> External Documentation Supervisor
> Medi-Span, Inc.
> Indianapolis, IN
> colleen_adams -at- medispan -dot- com
>