MadCap Software Forums

My company's software interface is about to be rebranded for one of our customers and for others in the future, I hear. To keep up with engineering, I will need to rebrand the documentation - pdf and help files - for each customer that requests their own logos and corporate branding on our product.

Have any other Flare users been tasked with managing a series of rebranded documents? How are you handling it?

The latest suggestion to me is to have a master customer document file and use includes to draw the company-specific text and images as needed from a second file. They were hoping to do this at the "local" site, i.e., at the customer site on demand. So I supply an additional includes file. When the document or help page is opened, the includes are automatically drawn from the extra local file and the user/reader is unaware. Sounds nice, but I have never seen anything like this before...

Any suggestions?

As always, thank you in advance...

Kim

One way is to use conditions (for images) and variables for text. Depending on which output is needed you'd change the variable and select the condition(s) to have the correct portions get compiled into output. There is currently no way in Flare to have conditions and variables applied at run time. I did propose that as a feature request, but I know it isn't trivial. I propose you add your request here: http://www.madcapsoftware.com/bugs/submit.aspx

Another option would be to create a different skin and output target for each customer--you could also create a separate master page for each as well. In the target for each customer, you specify the appropriate skin and / or master page. As long as you restrict the branding content to the skin and / master page, you shouldn't have much trouble.

David (aka RamonS) just mentioned that you can't have conditions and variables applied at runtime. That is true, but you can specify conditions and variable sets to use in your target. So even if you have to have some brand-specific content inside the topics, you should be able to manage it with conditions and variables as long as you call the appropriate ones in each target.

HTH.

Thanks for the quick replies. I do use the variables and conditions features for the current documentation, soI am familiar with the features. That's the way I was planning to go when the rebranding issue came up.

I will add a feature request.

Do either of you (or anyone else) know of any available tool that does rebranding in a really efficient manner? Or maybe you have an example that has all the kinks worked out?

Thank you again!
Kim

KevinDAmery wrote:In the target for each customer, you specify the appropriate skin and / or master page. As long as you restrict the branding content to the skin and / master page, you shouldn't have much trouble.

One note about that... If you're building WebHelp output, then Flare automatically includes all the skins in the output folder and if each skin specifies a different logo then it'll include all of those graphics in the output folder, as well. Unfortunately, there's no way to apply a condition to a skin to exclude it from being included and even if your logo image is stored in the Resources folder, applying a condition to that file won't make a difference because Flare copies the image file to another location at the time you specify it in the skin.

So, after you build a WebHelp project, you're going to want to open the output folder and remove the skins for the other customers and find the associated image files. And you'll have to do that every time you build the WebHelp output.

I think the ability to apply a conditional tag to a skin (and all images specified in that skin) would be a good feature, too.

Did you already put an enhancement request for that?

Not yet, but you should put in the request, too. The more people who request a feature, the more likely that it'll be added sooner rather than later.

Done. I think I added a bug request on a similar item before this...concerning unused topics showing up in the output, as well as losing comment lines in my topics during compiles. All-in-all, a good product...just a few cleanups would be nice!

Kim

Tydalian wrote:Done. I think I added a bug request on a similar item before this...concerning unused topics showing up in the output, as well as losing comment lines in my topics during compiles. All-in-all, a good product...just a few cleanups would be nice!

But what about topics that I want to link to that I don't want to show up in my TOC? How do you determine what are unused topics? I may use context-sensitive help to pull topics directly that don't appear in any TOC or have any incoming links.

Also, I can see how comments might be useful in-house to help you determine what topics need more work or whatever, but a company might not want these comments going into the output when the project is compiled.

These seem to be two design decisions that achieve a desired goal, even if the desired goal isn't _your_ desired goal. What I'd recommend is a feature request to make these types of "features" optional. Those of use who like them as designed can continue to use them, while those who want different functionality can also be appeased. (I see an easy solution here being an option in WebHelp target editor for "maintain comments in output" and "include non-linked topics" as two easy options for setting these options on a target-by-target basis.)

Many Customers do have topics in their Projects that they only what CSH links to, or Only want to appear when searched for. Other people want topics to be in the project when they are linked.

Another case for this is with Topic Popups, you may have a Topic Popup, in your project, but not needed in your Table of contents.

Yep, it's really up to the author (not Flare) to tidy up unused topics.

If you have a load of junk topics in your project, then it's up to you to decide what to do with them. If you definitely don't need them, then delete them. If you don't know if they're used or you think you might need them later, mark the topics with a conditional tag and exclude that tag from the target. Then if you later want the topic back in, just remove its conditional tag.

Hi all. I see that I did not word my comment very well. You are very right about topic files.

What I "meant to say" were two different situations...and I am learning.

1. The comment lines I want to keep in my compiled topics, but which are removed all the time, are copyright statements and date/release info. This is helpful in a finished product, but is consistently removed... Perhaps you could just keep comments entered outside the body tags.

2. The more controversial suggestion came from my leaving the "sample" resource files in my project. I removed the sample topic, so there were no links to these files. I just "assumed" the sample .css, sample variables file, sample glossary file, etc. would not appear in output, but they do. So I now remove them, as I have customized files that I move from project to project. I simply thought any control file not linked shouldn't be carried into output. You all make good points on the use of conditionals in topics and I actually do code my projects that way.

I did not keep copies of my enhancement requests, so I'm not sure how I worded them. As I mention...I am learning!

Thanks for the clarifications!