Adventures in Global Linking

I am putting together a Flare 4 project for use as a department standard template and repository. It will be stored on a network drive in a folder that we use as our main sandbox (or litter box as the case may be) for active projects and other worthwhile junk (those pictures of the Norwegian Majesty gliding through the Bermuda cut). The foremost reason is that the drive is reliably backed up, and it is easier to work from than our source control drives. I would have to say we are pretty good at non-worst practices.

The global linking feature in Flare 4 is going to help us standardize our css, which has tended over the course of several Flare versions and a bunch of product releases to drift significantly toward eccentricity. When you have like 50 projects being worked on by multiple writers, with projects changing hands with some frequency, and our Flare usage evolving (yeah, evolving, that's the ticket), it is pretty hard to synchronize that many stylesheets when a change is needed. So the opportunity to use a global stylesheet beckons.

Beyond that, a number of other elements lend themselves to standardizing. The new page layouts are a prime example, as are variables and table formats. I also think the group will profit by having all the elements that need to be set up for single sourcing pre-defined in a global project.

Something else that we have had a problem with is writers copying elements (such as tables) from one project to another, and even though the tables use the same stylesheet, the table itself still points back to the old project (until you use table properties to convince it that the local stylesheet is friendly), resulting in annoying but ultimately ignorable build errors. My hope is that pointing all the tables back to a central stylesheet will prevent this.

All this sounds good in theory. It is difficult to predict how this will work between six writers and a course developer. So the plan is to develop the global project, apply it to a couple of working projects, and see how it works out.

More later...

Later...
So far so good. I created a project that incorporates almost all of the stuff I have worked on for Frame importing and single sourcing and PDFing. I am not done by any means, but making a global project and having to update it to get results will force me to test out the theory of re-importing and updating with rebuilds and all that stuff.

So I saved the global project, and created a new project from scratch (empty template) and created an import of a Flare project. I added stuff, as Madcap recommends, and when I built a PDF target I started to find things that I had overlooked or just done wrong in the global stylesheet. So I opened up the global project, updated that, and did a re-import. Actually several, iteratively. While there were occasional weirdnesses, such as messages about missing files that were not really missing, and files in use that weren't or should not have been, the updates worked quite well, and I was able to accomplish quite a bit.

One of the best things is that by centralizing the template and layout and style development, I only have to do it once (in the rare cases I get it right the first time, anyway). When I go into work tomorrow, I won't have to look through 50 projects to find my latest fix, or forget where I was and have to start again (less madness, more method). I am exaggerating, of course, but there were times when an interruption or a meeting made me forget something, until I got that vague deja vu that I had redefined that page layout before, and not in a previous lifetime.

This is rambling and generalized and borderline frantic because that is my life as I know it (which reminds me for no good reason of Dennis Hopper in Flashback - "The 90's are going to make the 60's look like the 50's.")

My intention is to blog some of this in more detail so that the mythical reader might get something like a concrete suggestion or tip, rather than "global good; topic good, single-source good, Silverlight ugh."