Project design

This forum is for Single-Sourcing your Flare content to multiple outputs.
Post Reply
MichaelS
Jr. Propeller Head
Posts: 4
Joined: Wed Aug 05, 2015 3:34 am

Project design

Post by MichaelS »

What do you suggest for the design of a Flare project given the following makeup? The source files are Software and Hardware guides and Application and Release Notes. There are 80 projects in total.
There are two targets:
1. Online HTML help containing all projects
2. PDF for each project
At the present, each project is linked to a global project for the CSS, fonts, master page, skin, page layout etc.
For the online content:
• Four projects exist independently in the online content as well as being used in their entirety within another project
• One project is used twice
• Two projects are used three times
This a graphic representation for the online content.
proejct structure25.png
The questions are:
1. To create a single project or multiple projects
2. To use “Global Project Linking” or “Import Flare Project”
The current online HTML project design is just a TOC outline where each project is linked for runtime merging. This works well, but the CSS, master pages, fonts, etc. appears with each projects; i.e. 81 times! (including the parent). As there is more content to be added, a more efficient design is desirable.
Thank you in advance to all for your suggestions.
You do not have the required permissions to view the files attached to this post.
NorthEast
Master Propellus Maximus
Posts: 6359
Joined: Mon Mar 05, 2007 8:33 am

Re: Project design

Post by NorthEast »

MichaelS wrote:1. To create a single project or multiple projects
2. To use “Global Project Linking” or “Import Flare Project”
I wouldn't say those are the right questions/options.
Global project linking is the same as Import Flare Project.

You could:
(a) keep content in separate projects and import them into a single main project using project imports (global project linking)
(b) keep all content a single project (with no imports)
(c) stick with what you're using now (merging)

Whether you use a single project (b), or import content into a single project (a), you'll still have to set up that main project so that everything can co-exist together, and that you can build your separate targets. For example, you might need to rename files or alter folder structures (to avoid file conflicts), or use conditions to exclude content.
So the overheads in setting up (a) and (b) are pretty similar.

I'd generally always go for (b) a single project (with no imports).
I'd only go for (a) if there are some good reasons why I'd want to keep content in separate projects (which outweigh the drawbacks).

Using project imports (a) means the content can be built from a single main project, but the content itself can only be edited in the separate projects. So editing content in the separate projects and re-importing will be a hassle. It also means you can't link to anything that's not in the current project, even though it might exist in the main project (when imported); e.g. a topic in project 5 can't have a cross-reference to a topic in project 7, and a topic in project 7 can't use a snippet from project 5.
Post Reply