Should you create one project or many? What kind of relationships should your projects have with one another (if any)? Which methods, processes, and features best fit your needs? How should you structure the files within your Flare projects?
Flare is extremely flexible, which means your project universe (i.e., all of your projects, tools, features, elements, and content; and how it is all put together) might end up being somewhat unique. Therefore, you will want to take some time to plan your project architecture, both externally and internally.
- External The external project architecture has to do with your projects as entities, their structures, and what is outside of them. This includes the external processes, tools, and other factors surrounding your projects—such as source control, task management, templates, and more. See External Architecture.
- Internal The internal project architecture has to do with the structure of files and use of features inside a Flare project. It includes things such as naming conventions, folders, and structuring the project with snippets, conditions, variables and more. See Internal Architecture.
Along with the information about external and internal architecture, we have included explanations of how we (the MadCap Software Documentation Team) use the various features described and the methods we have adopted.
Keep in mind that there are best practices, or recommendations, here and there. However, there is no universal best practice for designing your architecture. What might be best for one author or writing team, but not be best for others. You need to be aware of the options available, explore the pros and cons of each, and make educated decisions.
