Flare CSS Management (and a neat little trick)

We have two main products, each with a main help system and one or more smaller surrogate help systems. One main help system is a master with around 30 merged .chms. The other is one big chmglob with just as much info, but linked to a legacy product that would not know how to point to merged chms, so say the Engineers.

If you know help, you can infer from this why I have a concern about managing CSS formats.

The legacy help system was converted from RH, and brought along untold amounts of format baggage in the guise of inline formatting and residual crap. We cleaned all that up, gave it a clean and fresh look (clean white vs unbrushed teeth yellow background).

We then started fresh in Flare on the new help system for the newer system. The newer product is .net, C#, VS2005 look-and-feel, which is ultra modern compared to the older. But the customer base is very much the same, so we adapted a very similar look and feel for both help systems.

So we used the same CSS formats for both help systems. Only difference was the banner on every topic.

Topic Banner for the new product



Topic Banner for the older product



Over the course of like 4 releases of each product, with around 40 .chms, and with us adjusting to the Flare way rather than the RH way, variances have crept into the many copies of the CSS in use.
Typically, when a new format was needed to handle a quirk or something we had overlooked (for example, text in tables that looked OK in RH seemed to be rubbing shoulders with table borders in Flare), the change got made by a writer and did not get propagated to every project. I am sure you can see where this got us.

So now that the hubbub from the latest releases has subsided, and we are about to load up Flare 4, I am spending some time looking at these CSS issues to both repair the CSS and plan ahead.

What Flare 4 appears to give us is a way to globally manage our CSS - Global Project Linking. If I read correctly what has been announced, we can put our 'master' CSS file out on our shared network drive and have all the Flare projects link to it. My guess is that we can lock it and thereby centralize changes, so that we don't end up with 40 different variants.

Of course, to do that, we need to have one CSS file to rule them all.

That brings me to The Neat Little Trick Part in the title.

By using the Stylesheet Medium setting in Flare's CSS Editor, I can set up, in one CSS file, two versions of the topic background, each of which uses a product-specific banner. Medium is most commonly used to distinguish between print and non-print formatting in a Flare target, but in this case I am using it to distinguish between two variants of online help.

Stylesheets Mediums are described well in the Flare Help (topics = Creating Medium Types and Associating a Medium Type with a Target), but the focus is on print vs non-print. This is another way to take advantage of this feature.

One other note - projects for help system A will have only the target for A, and projects for Help system B will have only the target for B, to avoid unfortunate results (product A has help banner for product B).