Legit Reasons to divide content into several projects?

[mimisc]

Does separating content into separate Flare projects ever make sense? (A webinar I watched recommended putting all files in the same project; I'm wondering if there are times when this would/would not apply).

Our company has three separate brands (each brand has a completely separate dealer audience) and very little shared content, and I'm wondering whether we need to separate content into separate projects or not.

To make a better decision about how to chunk my content, how are the following things affected when content "lives" in several projects as opposed to a single project?
• Search results. If search results for different brands shouldn’t mix, would it make sense to separate that content into separate projects? How does MCFlare’s built in search work across projects?
• Separate landing pages. We need the ability to separate content for each of our Brand's dealer portals (so that each portal displays relevant content). Can we do that without creating a new project?
• Build times. My understanding is that the smallest unit you can build in Flare is a project. Is that correct? Do large projects (with 100s and 1000s of files) take a long time to build (over an hour)?
• Cross reference links. Cross reference links don’t automatically update if you try to link across projects, right?
• Keeping track of files. We have several writers, and we'll need a convention for organizing our file structure. I've seen several posts about using naming conventions to make files easier to find; is this a reason for separating content into separate projects?

Are there any other pros and cons to consider when making decisions about lumping content into a single project or not?

Thanks so much for your help!

[NorthEast]

Does separating content into separate Flare projects ever make sense? (A webinar I watched recommended putting all files in the same project; I'm wondering if there are times when this would/would not apply).

Our company has three separate brands (each brand has a completely separate dealer audience) and very little shared content, and I'm wondering whether we need to separate content into separate projects or not.

To make a better decision about how to chunk my content, how are the following things affected when content "lives" in several projects as opposed to a single project?
• Search results. If search results for different brands shouldn’t mix, would it make sense to separate that content into separate projects? How does MCFlare’s built in search work across projects?
• Separate landing pages. We need the ability to separate content for each of our Brand's dealer portals (so that each portal displays relevant content). Can we do that without creating a new project?
• Build times. My understanding is that the smallest unit you can build in Flare is a project. Is that correct? Do large projects (with 100s and 1000s of files) take a long time to build (over an hour)?
• Cross reference links. Cross reference links don’t automatically update if you try to link across projects, right?
• Keeping track of files. We have several writers, and we'll need a convention for organizing our file structure. I've seen several posts about using naming conventions to make files easier to find; is this a reason for separating content into separate projects?

Are there any other pros and cons to consider when making decisions about lumping content into a single project or not?

Thanks so much for your help!

I think you're confusing a "project" and a "target".
A project can have several separate targets (outputs), so your project could have targets for the different brands.
You'd use condition tags to mark which topics/files belong to each brand, and you'd set the conditions in each target to exclude conditions (content) that aren't for that output.

* Search results are only for the topics in that target, not the whole project.

* You can have a separate home/landing page per target (defaults to first topic in TOC, or can be set in the target).

* The smallest thing you build is a target, not a project. The build time is just for content in that target.

* You can't have any cross references between separate projects - you can only have cross references to topics in the same project.

* Having multiple targets in a project can potentially make it more complicated, which is why you should use a sensible structure and condition tags.


Using a single vs separate projects is down to what's in your projects. There's not a clear answer to what's best, just what's best for you.
Separate projects work fine provided the content is actually separate.
If you have any shared content or links/cross-references between content, then a single project probably makes more sense.

Generally, I'd always advise to start with a single project, as it's much easier to break up a large project than combine separate projects.

[mimisc]

This is extremely helpful. Thank you so much!

[devjoe]

You might make one project with a separate folder for the content unique to each brand, and one for common content. Each brand gets a target to build its output. You can apply conditions to the folders to exclude brands A and B from brand C's target, etc., while the common folder has no conditions and is included in all the outputs. This minimizes the amount of conditional tagging you need to do, but you can still tag individual files or sections within topics in the common files if necessary. And this will allow you to make cross-references from the brand content to the common material (or in reverse, but you should apply the appropriate conditions).

For this case where little content is shared, you might make a separate TOC for each target. If the common material is in one place, you can make a TOC for that which is referenced within the TOCs for each target. If the common material is scattered, it's probably best to just include it directly in each TOC; when you add new shared content, you'll have to add it to all three TOCs, but it could be simpler depending on your structure.

If you need to, you can make subfolders within those folders to organize different types of content. (Topics vs. images, or subject matter based divisions, or whatever way of organizing things makes sense for your work.)

Build times are usually pretty fast for help-type outputs. I have a massive HTML5 project with around 10,000 topics and thousands of equations and images, and that builds in two hours. However, this one is broken up into a bunch of separate projects, and each individual project builds quickly; it's only when I build the master (and only when a lot of the individual projects have been updated) that it takes a long time. We have an automated build set up to rebuild everything daily, so I don't have to be doing that all the time myself.

PDF outputs are a bit slower. One of the projects in that large system has a PDF of 1200 pages with about 1000 topics and 400 images and quite a few equations, and that takes an hour to build.