Multiple webhelp sites - same content folder

[sarahwilliams]

Hi all -

I'm new to Flare - so if this is a dumb question - sorry in advance.

I'm documenting a software suite that has multiple versions. Imagine Microsoft Office - You have Word, Excel, PowerPoint 2003 and Word, Excel, PowerPoint 2007.

I want to create one webhelp site that has all the versions and components, and then component specific help that is context sensitive. I'd like to have one content folder that they all link to so that I am not replicating files and taking up unnecessary space.

I've already played with changing the output file name in multiple targets, the issue I am having is that the data folder containing the toc remains the same name and overwrites.

Is there a more elegant solution for this? Am I going about this the wrong way?

[RamonS]

Since you want to keep anything in regards to CSH separate why not making a project for the CSH content for each product. You won't use that content with any other application. Then use an additional project for all the common content. Within the application for example Help > General Help would open the common project. Pressing F1 or a Help button would make calls to the CSH content.
While this is the easiest approach that doesn't even make use of single-sourcing it has a few drawbacks. The one I'd dislike most is that you cannot use search in the common help to find something in the product specific CSH content, because those are in the end to independent help projects. My guess is that you do not want to do that.

I can think of another approach to do things a bit different, but also more complicated and not exactly what I think you want (I must say that I am not 100% sure I understand correctly). Option one is to put all and any content into one big project and use conditions to slice and dice the help for each product. The problem here is that anything in common will be duplicated in the output and you quickly get a project that is very difficult to manage. One benefit is that you can reuse content across all helps either by cleverly applying conditional tags or use snippets.
A different twist is to use a master project with sub-projects. The sub-projects would contain all the CSH content and the master project all the common content. In the end you'd still need some set of conditions to get the desired output, so there isn't much gained other than that you do not have to deal with a monster project, but then again, using snippets across all projects won't be an option.

My guess is that you want individual projects generate independent output, but then have the option to relate one output to another so that you have one help that really consists of two project outputs, one common section and one product-specific section. As far as I know Flare cannot do that and I couldn't even think of a straight forward way to do that.

So what to do now? I'd take a closer look at the common content. Is it really that huge that multiplying it by the number of products would become a huge burden? In today's settings I'd be inclined to say yes if the common portion is around 100 MB in file size or bigger (and that is a hefty project right there). If you have eight or more different products you eventually get to waste a GB in drive space, which again in the grand scheme of things isn't a big deal now that one can get a 1TB drive for 80 bucks. Things get a bit different if you have other constraints, such as highly limited drive space on a web server or customers who mainly use cell phone networks or dialup and where downloading even 10 MB more is a real pain.

Finally, my recommendation. I'd go ahead and craft three very simple, but basically complete projects (you can use the Flare sample project and copy it three times) and tie those together with conditions and project linking making one the master project and the other two subprojects. If you cannot get any grip on that I recommend to go the more intuitive way using conditions only in one big project. Make sure that you create a folder for each product and a common folder and then build the content up in there while still keeping everything in one Flare project. That should work out OK if you do not have to document extensive enterprise applications with 1,000 or more forms each and bazillion options that may cause things to work differently.
I think it is an honorable intention to not use more drive space then absolutely necessary, but I think the effort that would take to make it work and work well outweighs the little benefit you may get.

If none of that helps or even worse, I totally confused you, please complain.

[sarahwilliams]

Thank you, that helps a lot. I think I just have to give up my desire to go super lean on the content and not have repetitive content.

Thank you!

[RamonS]

You are welcome....super lean is unhealthy, with fat comes taste...or less stressful working in this case.

[forfear]

Make sure that you create a folder for each product and a common folder and then build the content up in there while still keeping everything in one Flare project. That should work out OK if you do not have to document extensive enterprise applications with 1,000 or more forms each and bazillion options that may cause things to work differently.

IMHO, i am personnaly upgrading our internal projects to this structure as i start start sharing content across projects, so that i dont have 3 or more 'Introduction.html' topics overwriting each other when i do a Flare Project import, with a merged project containing content from 2 or more projects.

Before
Content
Introduction
Reference Guide

AFTER
Content
- Project X
- Introduction
- Reference Guide


In a merged project
Content
-Project X
- Project Y