I’m going to try something different here in the old blog. I’m going to do a short series on some of the questions that seem to come up over and over to help out those people who are new to our industry. The first question I will tackle is:
What is the optimum size for my Flare project?
This seems like a simple question, but it is actually very difficult to answer because, as with so many other things in life, “it depends”. I have seen small Flare projects that were perfect for company A and I have seen HUGE Flare projects that were perfect for company B. The important thing is that your projects meet your specific needs. To achieve that there are some guidelines that can be followed.
Guideline 1: Smaller is better
All things being equal it is easier to author and work in smaller projects. When you need to find that one specific graphic you need it is much easier to find it from a library of 50 images than from a library of 5,000 images. As projects scale you simply have more data, images, files, and other assets to sift through to find the specific item you are looking for. This isn’t necessarily bad and we do provide tools to make this as easy as possible, but in broad terms smaller projects tend to be more efficient for authors to work in. But…
Guideline 2: Too small is bad
What! You just said that small is good! Yes, that is true, small is good but too small is bad. Fortunately there is a very easy test to let you know when your project is too small. If you ever, Ever, EVER find yourself having to make the very same edit in multiple projects that is an immediate sign that those two projects would likely benefit from being merged into a single project. The very concepts of content management, single-sourcing, and multi-channel publishing are based on the ability to edit content only once and then re-use as necessary. If you have to make the very same edits in multiple projects then the projects are definitely too small and are hurting your ability to single-source publish rather than enhancing it.
Following these two guidelines can help you to determine what the optimum size of your projects should be. In the real world I have seen 300 topic projects and 20,000 topic projects and both were “just right” for their particular environments. The bottom line is to not get hung up on numbers but pay attention to the authoring performance and efficiency of your project.
NOTE: Changes coming in Flare 4
The guidelines above will still be good to follow going forward, but the release of Flare version 4 will add some new flexibility to how people size their projects. One of the new capabilities in Flare 4 is the ability to use “Master Project Linking”. The concept is that you could create a master Flare project on a network share location and in this master project you can store any elements (CSS style sheets, snippet files, topics, templates, Master Pages, etc.) that you would like to be common across multiple smaller Flare projects. This will allow some of those huge 10 or 20 thousand topic projects out there to be broken into smaller projects and still never have to do the multiple edit thing. This Master Project Linking model creates a new library of shared components that can be used and re-used across as many Flare projects as you need.
For example, if you place your master CSS file in the Master Project on the network and then you link to it from 15 smaller Flare projects then you will have the same look and feel in all 15 projects. Then, if there is a need to update the styles you only update the style sheet once and your style changes automatically filter down to all 15 projects.
This will be adding an entirely new level of flexibility allowing teams to be able to plan their Flare project sizes around what is optimal for their particular team.
P.S. Before anybody asks, no we have not publicly announced an official Flare 4/Blaze ship date yet, but it is close enough that I felt it was important to include the above information for those who are doing project planning.