Page 1 of 1

Multiple Projects sharing content

PostPosted: Fri Aug 25, 2017 12:23 pm
by Pamb10
Hi everyone,

I am trying to decide the best way to organize my Flare projects (nothing created yet) so I can share images (and maybe some content) between projects....

Here is an example of what I am thinking:

Flare layout.png

Projects XX, YY and ZZ contain multiple output targets using conditional text and snippets throughout

The Composite project will contain a new target for each Project XX, YY, ZZ

I am thinking about this type of layout so when I need to generate documentation for the composite project, I can go into a single project and generate each target instead of going into each project XX, YY, and ZZ to generate three separate targets.

Does this make sense and is this possible to do?

Also, does it make sense to have a separate project holding all images that may or may not be common between all projects? I am looking to reuse images when applicable and have only 1 source image.


Re: Multiple Projects sharing content

PostPosted: Mon Aug 28, 2017 7:44 am
by Pamb10
Hope this post makes sense. Would love to hear some feedback.

Re: Multiple Projects sharing content

PostPosted: Mon Aug 28, 2017 9:51 am
by Nita Beck
Honestly, Pam, I was a bit perplexed by your post. I can't quite make out, from the diagram, just what you're trying to achieve. You have three projects (XX, YY, and ZZ) each of which seems to support Product A, Product B, and Product C, but then you want to pull into a composite project just Product A from XX, Product B from YY, and Product C from ZZ. I find myself wondering why you don't just have one big project.

In short, I don't get it. And that's why I didn't post. I'm willing to try to understand if you'd give the explanation another go.

Re: Multiple Projects sharing content

PostPosted: Mon Aug 28, 2017 10:17 am
by Pamb10
Thanks for your feedback Nita.

Ok let me try again.

My company has 3 products. I am thinking I will create a Flare project for each. Each of these 3 products has several versions which I will take care of in each project using different TOC and Targets. This is straightforward.

The part I am confused about is there is another product which is made up of the above 3 products, just a different version of them.

I can....
* create these versions as part of the original 3 projects (just add another TOC and Target to each).
* create a new project and use global project linking so the source and images are still in one place.

I feel like the only difference in setting it up the second way is that I can open one project for the third product and create and publish from within the one project as compared to going into 3 separate projects to generate and publish. It may just be easier to eliminate any complexity and just set it up as three projects with their own versions within.

I hope this explains it a little better.


Re: Multiple Projects sharing content

PostPosted: Mon Aug 28, 2017 10:45 am
by Nita Beck
I'm still not quite following, sorry. But I will say that your instinct to reduce complexity, to keep things simple, is a good one. One of my design philosophies is that when faced with complex requirements, strive for the simplest solution. The simplest solution is generally easiest to maintain.

But let me ask a question. So there is a 4th product that is made up of (versions of) the other 3 products, have I got that right? I would again come back to wondering if one grand project is in order.

Re: Multiple Projects sharing content

PostPosted: Mon Aug 28, 2017 11:03 am
by Pamb10
Yes u r correct.

Thank you for your feedback Nita.


Re: Multiple Projects sharing content

PostPosted: Tue Aug 29, 2017 2:58 am
by ChoccieMuffin
How about this - this is how we do it here but it might not be appropriate for you.

Globals project
    * Contains all the things that are TRULY global, like stylesheets, copyright text, page layouts, master pages, global conditions (like screen only and print only), global variables, and global TOCs (for example I have a "Front Matter" TOC that links to a cover page, TOC page and copyright page, all of which are in the topics in the Globals project that gets imported into other projects).
    * This project is imported into EVERY other project, so I only have to manage the stylesheet etc in one place.

Product A project
    * Imports Globals project.
    * Contains all screenshots, topics etc that are relevant to Product A.
    * Contains a condition tag set for conditions that are only relevant to Product A - call it ProdA.flcts. (Screen only, help only are in Globals.flcts). The conditions in this condition tag set can be applied at a topic or content level, and can be used either in the Product A targets or for importing into other projects.
      * May contain conditions like ProdA.AdminOnly, ProdA.GeneralUser, for output in the Product A project, or conditions like ProdA.BiggieOnly to be used when importing stuff into the biggie, like a biggie-specific TOC).
      * If this project is imported into other projects and, say, the TOC needed is different depending on the project, I also create separate TOCS (e.g. ProdA_for_bigger_ProdB.fltoc, ProdA_for_bigger_ProdC.fltoc) and apply the appropriate condition ProdA.ProdB_Only to the TOC for ProdB, etc.
    * All content that will be needed in other projects is tagged with condition ProdA.ProdA. This condition is applied to the topics and images, any sub-TOCs that might also be used in the biggie, and the condition tag set. Any stuff that is ONLY needed for Prod A and never imported into other projects doesn't get tagged (e.g. targets).
    * Topics are in a "Product A" folder inside the Content Explorer, and images are inside a "Product A images" folder at the same level (not buried in the Resources folder). This makes it easier to identify imported stuff in the biggie, and also in case imported projects contain topics with the same name.
    * Several different outputs (help, PDF). TOCs also may include sub-TOCs that may be needed in other projects.
    * Topics and images (and the folder they're in, for visual assistance), as well as the condition tag set and any sub-TOCs that might be needed in the big project, are conditioned ProdA.ProdA.
Product D (the biggie)
    * Imports from Globals and from any other projects, appropriately tagged. When importing from ProdA, for example, apply import conditions "include ProdA.ProdA and not (ProdA.ProdC_Only)" (Check the correct way to do this, it's an advanced condition and I always get confused!)
    * May contain nested TOCs, e.g. Front_Matter (from globals project), ProdA_for_bigger_ProdD (from ProdA), ProdB_for_bigger_ProdD (from ProdB) etc.
    * Conditions on output may also need to exclude conditions from sub-projects, e.g. ProdA.ProdB_Only.

It works really well for us, and means we don't have duplicate versions of files, or files that are almost, but not quite, the same.