Recently, I’ve been managing draft and published content using two MadCap Flare projects. I came up with this solution after noticing draft HTML pages appearing in the search of my generated help files. This was something I really didn’t want to see.
In MadCap Flare, a project contains everything you need for publishing help files including, but not restricted to, stylesheets, HTM files, and skin settings. The Contents folder is a key part of the project as this is where all the HTM files are contained. The trouble is, when managed incorrectly, some of these files can appear in searches.
As MadCap Flare authors, we often need to experiment with new techniques as offered by Flare’s rich functionality. This may involve creating dummy HTM files within a project. An alternative project can serve this purpose of separating these HTM files from the main files for publication.
Putting files in to the second project is simply a matter of cutting and pasting the files from the original project. The key here is to perform a cut as you want to remove the files the source location. You then need to delete the files in question from the original project.
You can also cut and paste the stylesheet and skin file from the original project so that the content in the second project shows the same look-and-feel as the original project.
You can make as many changes to these HTM files in the second project for the purpose of testing your content. And none of the changes affect the original project.
Once you have created a build, you can return the HTM files that you added to the other project back to the original, in case you need to use these files next.
Adding files to another project is also useful in these ways:
- If you want to manage content without conditional text. Though MadCap Flare lets you create many conditions, you may not want to create too many for the risk of forgetting to apply the conditions when generating your help build.
- If your online help includes generic product page descriptions, another project can be used for different, though related help pages. For example, the second project could be used for a step-by-step tutorial or as documentation for another product in your company. However, as far as I know, it is not easy to reuse content across multiple projects through snippets. By dropping in stylesheets and skin files from the main projects, you can create a consistent look-and-feel, which is useful for branding.
- A second project can also be used for troubleshooting and testing. When dealing with MadCap Flare to solve a problem, they often ask for another project that can be zipped and sent to them.
Using two projects is a simple and clean way of separating content. It is also very quick, as the MadCap Flare interface lets you easily switch from one project to the other.
It is also possible to transfer the files out of the Contents folder to a Windows folder location. This has almost the same effect, but the styles are lost when the files are saved in the Windows folder.
There are many clever ways in which online content can be manipulated in MadCap Flare. And I feel that there are many more things to learn!
I enable the “Exclude content not linked directly or indirectly from the target” option in the target file under Advanced. I also have one condition (tag) called “DNP” (do not publish) and exclude. Using those two tricks, I’ve never found “unpublished” pages via search in my final published content. I’ve tried (tested several times).
I can confirm the method outlined by Baritonejp works. So no need for 2 projects really…
Thanks for your comment. I will try the method from baritonejp. The idea of my blog post is to find out what other users do in the community. So your opinion is valid.