How to keep track of 80 conditional text tags... (was RE: FrameMaker.next)

Martinek, Carla CMartinek at zebra.com
Fri May 18 06:09:18 PDT 2007


-----Original Message-----
From: Diane Gaskill

My question is Why??  I suppose this is a little OT, but I cannot
imagine needing more than 10 conditions, even when you create PDF for
both computer screens and handhelds, and also help, as well as have 3 or
4 models of a product described in the same set of files.  How in heck
to you keep track of 80 tags, Carla?

Diane

==========

Good question!

First, to set it up, we have at least 7 different product lines, and
then many of those printers have special versions (Customs) for specific
customers. Some printers are OEM'ed and need to be rebranded, and may
have special programming on them or special hardware features that are
different from our standard line.  Depending on the printer, it could be
rebranded for 1-3 different OEM vendors, there are 5 or more programming
guides for different programming languages that work on our printers,
and there are 2-3 hardware pieces that attach to the printers, and they
have their own guides.

To manage all of this, we create a matrix table, showing all the
conditions and the various types of docs.  Down the left side is each
product/product line.  A product gets a specific color assigned to it.
Across the top are the types of guides -- Programming Guide (PG) User
Guides (UG), Quick Ref Guide (QRG), Maintenance Manual (MM) and
Maintenance Kits (Kit).  Variations on the conditional text style
indicate the guide type (plain, overline, underline, strikethrough,
etc.)

Naming for conditional text is logical:

UG Product1
UG Product2
UG Product3
QRG Product1
QRG Product2
QRG Product3
PG ProgLang1
PG ProgLang2
MM Product1
...and so on...

We discussed it as a group, and felt it was more logical to group by
guide type than by product name with our stuff.  YMMV, and in your
situation you may find it easier to group by product name.

This table is part of an "import from" document that writers are
supposed to use to define the user variables and set the conditional
tags to show for a particular document.  Because content is shared,
conditional tag and variables for a particular topic could be set to
anything when you go to generate your book file, so you would use the
"import from" file to set these items.  A writer would know just by
looking at the table which conditional tags are showing (if conditional
text is hidden, then no text appears in the corresponding table cell).

Oh, and when you're working in a situation like this, the most important
thing is that conditions need to be ADDITIVE.  NEVER create a
conditional tag that is "not this" or "not that," -- you're only setting
yourself up for trouble (been there, done that).  If a piece of text
needs to have 40 conditions applied to it, then that's what it needs.
This also puts the conditions in a format that can be managed when we go
to XML.

This conditional text structure required some forethought and planning
to accommodate all of our needs, but now its easily expandable as we add
more products and printer lines.

I'd be happy to send an example to anyone who'd like to see it.

-Carla
 
- CONFIDENTIAL-
This email and any files transmitted with it are confidential, and may also be legally privileged.  If you are not the intended recipient, you may not review, use, copy, or distribute this message. If you receive this email in error, please notify the sender immediately by reply email and then delete this email.



More information about the framers mailing list