Using a custom variable in footer?

[milmacrose]

I’m trying to create a template that can be used across the board for our unstructured operation and parts manuals (FrameMaker 11, Windows 7). Currently, the look of all the manuals is nearly the same, but the setups have been done by various authors, such that some page layouts use variables while other use hard text, and not all the same variables/paragraph tags/etc. are used, or in the same manner. Additionally, the use of conditional text is deeply ingrained in all the manuals. It's a mess that I'm trying to correct.

I’ve been working on (slowly but surely) trying to get uniformity in the all the manuals, not just for good publishing practices, but also so that I can apply scripts that will react the same across the board.

My latest challenge is trying to create a footer that reflects the model of equipment. Currently, this is done by having a string of all the current models in a product line in the master page footer, each tagged as conditional text. The book’s TOC controls the show/hide of the text throughout the book, including these footers. The books are also grouped according to the product lines, such that the string of conditional text in the footer is different per product line. (Thou shalt not copy a book component from one product line to another.) Trying to create a universal template that would include all the products as conditional text in the footer is not feasible.

I’m hoping to find a variable I can put in the footer that will reflect which model the book is covering, which is dictated by conditional text. I’m not a programmer, and I only have rudimentary knowledge of how to use them. But something tells me this can be done somehow—perhaps using a complete product list in the reference page (or even an external document?) and linking a variable there that will react to conditional text??? Something that tells the layout “if conditional text is set to XXX, use XXX in the footer” ?? I don’t know enough about variables and/or reference pages to know if this can be done, or if so, how…

I have no budget to work with, so it is just me working on this. Any suggestions would be welcome.

Rosemarie

[Matt S - Tech Comm Tools]

As a first step, consider using one set of naming conventions for all your files.

You can use Rick Quatro's FindChangeFormatsBatch plugin ($80?) to wrangle all your para, char, and other labels into one set of manageable styles.

Once you've normalized the styles applied, consider using your RunningH/F variables to display the model name, which ideally displays on a cover page, or in a heading somewhere in your document.

Offhand it sounds like you're in need of a book, class, or consulting session to reduce the time you're currently forced to spend on your editing process. Otherwise, undoing the work of multiple previous authors may prove to be an uphill task.

[milmacrose]

Actually, the template is more-or-less serving to bring the paragraph tags and such into alignment. I was lucky in that the para tags names were at least standardize, even though they weren't always set up with the same values, at least those naming conventions were in line with each other.

What I'm doing right now is to import all the files of one sections of the book (Ex. "Maintenance" may have 12 files -- by importing those files into one template, the template will control the values of the paragraph tags. So now, all 12 "Bodytext" tags are subordinate to the template's Bodytext values.) I have another script to go through and identify any paragraph tags that the template doesn't cover, which luckily, is a rare occurance. The biggest hassle is losing the far-too-many para tag overrides, especially Bold, but that's a small price to pay.

Personally, I would love to set this all up into a structured format, and go to XML, put all the files in a database with loads of metadata for searching, and have people just edit plain text. Doing that by myself, while keeping up with my regular duties would take way beyond my lifetime, and beyond my skill sets, too...<sigh>.

I have 3 collegues who have used Framemaker for nearly 20 years, but I don't think any of them truly understand even the basics. I see hanging headers, widows/orphans, and such (that my importing to a template corrects) that should be very rudimentary knowledge. I can't rely on them for help, and sometimes they fight me on even small changes. I get the usual "But that's not the way we've always done it"... <sigh> <sigh>

[Matt S - Tech Comm Tools]

Good to hear that your tags are standardized...that's perhaps the biggest piece of the puzzle.

I gave a webinar on FrameMaker template-driven design a few weeks ago (Sept 12)...you should be able to access the recording at https://attendee.gotowebinar.com/register/4187234233490363395

Also, if you're a member of Society for Technical Communication, Adobe is sponsoring a similar webinar series, and I'm presenting on templates on Oct. 5.  https://www.stc.org/event/free-stc-member-sponsored-webinar-managing-templates-maximum-content-effic...

[Matt S - Tech Comm Tools]

FYI, registrants are entered into a raffle, and winners get their choice of any of my Fm reference and workbooks.

[milmacrose]

HA! I'm already signed up for that STC webinar!

[FieryPantone]

I'll merely mention, in case it doesn't apply to your case, that I manage a stack of documentation for different devices where (of course!) the device name is a user variable. In some of the component files, I use text insets for content that is common across the device catalogue – and these, conveniently, pick up the value of the variable from the .fm file. In other words: a text inset includes a variable $deviceName. When I reference the text inset in a file where $deviceName is defined as countertop, the string countertop shows up in the inset; referencing the same inset in a file where $deviceName is defined as portable, shows portable.

At book level, I'll set $deviceName in one file and copy the definition to all the files in the book. In the one case where I had two very similar devices to document, I think I defined two variables $deviceA1 and $deviceA2 and used conditions only to determine which variable was displayed in the header/footer.

I'd agree with Matt's suggestion, though; having someone to help you sort out the, erm, complexities you've inherited may well make your life easier :-}

[milmacrose]

Heaven knows, I would love to take some more indepth classes on this!! Except... refer to my last line of the post... That's why I am reaching out to online forums... 😞

[milmacrose]

The device names (model numbers) are embedded in conditional text. We use single sourcing quite a bit, and conditional text to differentiate small changes between models -- but it got out of hand as the company grew, and no one has ever tried to correct the situation. Plus, we use "current" and "master" manuals for the same model - the current goes to the customer and is just for the unit he purchased; the master has all revisions of the model, and is used by our customer service --they both use the same files, and the older revisions in the master are hidden from the current version via conditional text.

So a single file -- let's say "Alternator" -- is common to nearly all models of our product line. The file may have started with alternator A which had three revisions. Alternator A may have been used in 5 models. Now a new model uses alternator B, which someone placed into the one Alternator file. More conditional text tags added for the new model... more instructions tagged differently... and pretty soon alternator A is no longer available and alternator C is added to the file -- plus six new models are developed that use B, C and the new D. and those are getting revised along the way. I am not exaggerating -- this is how the files evolved. 30 years of this system. Many are not this bad -- some are worse. What started as a good idea has grown into a real monster.

The footer currently has every model (encoded, since names would be too long) listed in a big long string that looks something like 152835305060HDS-R10doc092717, where numbers/letters prior to "doc" are part of a complex code--some models have a combination of these letters/numbers, as we have a standard 60, a 60HD, and a 60HD-R, and other such combinations-- plus multiplied by 2 for current/master.  What shows in the footer is controlled by very complex application of conditional text to those number/letters. Additionally, there are different sets of conditional text codes for various accessories and engine packages (each with its own manual) .

The only place these codes show up are in the conditional text.

I tried deleting the codes all together and just go with the company name, but my collegues balked -- they said they needed that code on each page, as people often give them just a page for making a correction, and the needed to know what model they were dealing with.