Question about the wonderful world of reusable content

[sdcinvan]

Another newbie question...

I am building documentation (mostly PDF output - for now), consisting of:
quick start guide
user manual
performance guide
white papers

What are best practices on how to store these projects?

In the old days (before Flare), I would create a separate folder for each of these documents. Since there is some sharing within each project, is it good practice to store all of these documents under a single folder?

Thank you,
Shawn

[Nita Beck]

Shawn, your question isn't completely clear. Are you asking whether you should have one Flare project to cover them all? If yes, are you asking how you should structure the Content Explorer in that Flare projects? Or, but still if yes, are you asking where you should store the output that you generate with that Flare project?

I'm going to assume that you have them all in one Flare project, so you have four targets (one for each document), and that you'd like to know how to structure the project's Content Explorer.

I would encourage you NOT to structure your Content Explorer according to document or by a document's TOC. Rather, think about the TYPES of content you have. For example, many authors (myself included) categorize content by type (by purpose) such as tasks, concepts, and reference, to name the three most common types. You might also have other topic types such as FAQs, navigation (by which I mean topics that mainly serve to lead a user elsewhere, such as the topic associated with a book in a TOC and which has a miniTOC proxy, so Flare will build links to all the topics that appear under that book), and glossary terms.

In one of my projects, I've got my Content Explorer/Topics folder organized into the following subfolders:
-- Concept -- and within which all topic filenames begin with "con_"
-- FAQs -- filenames begin with "faq_"
-- Glossary -- filenames begin with "gls_"
-- Navigation -- filenames being with "nav_"
-- Reference -- filenames begin with "ref_"
-- Task -- filenames begin with "tsk_"

The beauty of this is that a topic can go in whatever TOC it's needed, into whatever target it's needed for. You might add a task topic today that is needed for just one target, but someday might be needed in a target that you haven't even anticipated.

In my experience, the keys to good single-sourcing are good structure (a place for everything and everything in its place) and good naming conventions (instantly recognize, just by its name, what something is and where it can be found in the project).

Think about this too. Although you today are the inventor of your Flare project, you need to plan for the day when either (1) another author joins your team and helps to maintain the project or (2) you've moved on and someone else entirely is maintaining the project. If you structure a project well and name folders and files well (and have documented the project well, but that's a whole other discussion), then any Flare author should be able to take it over.

EDIT: I forget to say this important thing. I tend to have one Flare project per product. Any kind of documentation for that product -- a Help system, a white paper, a quick start guide, and installation manual, etc. -- are all in the same project as it's highly likely that there will be a lot of shared content.

[sdcinvan]

Awesome response Nita. That is more than I expected.

Thank you.

[Nita Beck]

You're welcome. As a new Flare user and new single-sourcing author, you are asking the right questions. It's *really* important to correctly set up a Flare project right from the start so that it can be easily maintained as well as extended (as in, able to produce targets that today one doesn't even anticipate). That's why I took the time to write my lengthy reply.