As we are getting deeper into single-sourcing our content, it is clear that the design will be a key to efficiently maintaining and updating the content. As such, which design in Flare is proven to be more efficient:
- A single master project containing all of the single-source content.
- A single parent project with multiple child projects, where both the parent and child projects may contain single-source content.
- Other?
We are currently single-sourcing content that exists between a parent project and multiple child projects. We are considering single-sourcing all content from one master project, and are attempting to prove whether additional steps/overhead will be involved by remaining in the current parent/child model.
Key questions:
- If a single master project is recommended, at what point does the project become unwieldy in Flare?
- Could you please provide cautions, pros, and cons?
Single Master Project vs. Parent/Child Projects
-
- Propeller Head
- Posts: 29
- Joined: Mon Mar 16, 2009 3:54 pm
-
- Propellus Maximus
- Posts: 1985
- Joined: Tue Jan 23, 2007 8:18 am
- Location: Darn, I knew I was around here somewhere...
Re: Single Master Project vs. Parent/Child Projects
Keeping everything in one project is usually the simpler approach if most topics will be used in the majority of outputs and you only have a minority of topics that are specific to individual outputs. However, if most of your topics are not common to all outputs, I would expect that putting the common topics in one project then linking to it from the other projects would make more sense (my projects so far have been of the first type, so I haven't gotten into project linking at this time).
Until next time....
Kevin Amery
Certified MAD for Flare
Kevin Amery
Certified MAD for Flare
-
- Sr. Propeller Head
- Posts: 110
- Joined: Tue Feb 26, 2008 12:17 pm
- Location: Home: NH --- Compensated Servitude: MA
- Contact:
Re: Single Master Project vs. Parent/Child Projects
What Kevin said, but your description does not contain enough particulars about your contents, the product or products it documents, the output target types, the number of writers, the number of outputs, and other 'stuff' that it is hard to make a solid recommendation, in my opinion. These things matter a lot, in my opinion, and not knowing them makes any recommendation a shot in the dark.
Even the terms 'master project' and 'project linking' have multiple meanings and implications such that unless we are both using the same definition, I could give you way bad advice with the best of intentions.
For example, I would say that the simplest and safest approach is to use totally separate Flare projects, and use a global project import to maintain standards over time (the exact same stylesheet and page layouts and variables and such, locked from editing by individual writers). If your logo, main font, or product name changes, you change it in the global project, import to the individual projects, and all is well.
If an individual writer blows up a project, none of the others blow up with it. With a single master project and multiple writers, any cook can spoil the whole broth.
I cite that only to show that without more details, anybody could suggest almost anything.
My suggestion is that you offer to provide offline from the forum enough details for one or more of our experienced forum junkies to help you do a solid evaluation and recommendation for structuring your projects.
Given the details, minus proprietary info of course, I think you could get a range of good opinions and areas for your group to follow up on (because only you know your real working environment).
Even the terms 'master project' and 'project linking' have multiple meanings and implications such that unless we are both using the same definition, I could give you way bad advice with the best of intentions.
For example, I would say that the simplest and safest approach is to use totally separate Flare projects, and use a global project import to maintain standards over time (the exact same stylesheet and page layouts and variables and such, locked from editing by individual writers). If your logo, main font, or product name changes, you change it in the global project, import to the individual projects, and all is well.
If an individual writer blows up a project, none of the others blow up with it. With a single master project and multiple writers, any cook can spoil the whole broth.
I cite that only to show that without more details, anybody could suggest almost anything.
My suggestion is that you offer to provide offline from the forum enough details for one or more of our experienced forum junkies to help you do a solid evaluation and recommendation for structuring your projects.
Given the details, minus proprietary info of course, I think you could get a range of good opinions and areas for your group to follow up on (because only you know your real working environment).
-
- Propeller Head
- Posts: 12
- Joined: Thu Apr 24, 2008 7:02 am
Re: Single Master Project vs. Parent/Child Projects
Another option might be a single project that contains all topics. Create a separate TOC for each child and link the child TOCs into a parent TOC if necessary. This way you can build the child outputs individually or use the parent TOC to bulld all at once. You can also share topics, stylesheets, page layouts.