Before we publish our final output files, we must go through a quality assurance cycle. This cycle includes the following activities:
- Find and fix broken links and missing images
- Find and fix layout problems
- Find single sourcing candidates (so that you limit the maintenance of your project)
We use a QA checklist to ensure that all points are covered.
Prepare for localization
If your Flare projects are to be localized, you need to make a final QA process. The checklist for preparing a Flare project for localization includes:
- Removing unused folders and files
- Making sure that no texts are embedded in images
- Exporting only the portions of the project which must be translated
For more information on the localization process, go to Phase 4: Localization.
YES – we’re finally there. We can now build our outputs and go through our publishing checklist to make sure they are ready for release.
When the output is tested, it’s ready for publishing. So in Flare, “build” means build a local copy of the output, whereas “publish” means build a final copy for release. This final copy can even be copied to different “destinations”. So if you need one copy for local testing, one copy for the development server, one copy for the website – you can copy to all these destinations in one operation! See more tricks under “Automation” below.
Documentation review process
Madcap has integrated the entire document review process into Flare and Contributor. W2U has extensive experience in guiding our clients through this important process. We start by analyzing how the current review process works and how we can improve it using the Madcap tools. Often, we significant enhancements once the review process is fully implemented. The Subject Matter Experts – who are using Contributor – to review the content have been very positive towards the new review process. One advantage is that the SMEs do not need to read long manuals anymore. The technical communicator can give the reviewers small packages along the way – and connect all the strings back in Flare.
It’s now time to train all the documentation team members in the use of Flare. Our experience is that this is the perfect time to take the training. Because we have all the main building blocks in place, the features have been tested and we can create a training workshop based on the client’s own material. We go through all the main features of Flare and create a fully functional Flare project together. In advance, the client and W2U builds the training agenda together.
The agenda is based on the standard training workshops offered by W2U:
The result of the training is a functional Flare project that the client can continue working with after the training.
Onsite startup coaching
Many questions have been answered by the onsite training, but when you are on your own in Flare, new questions may arise. It’s really like driving a car. You have the driver’s license now, but you are not experienced in driving a car.
W2U has been onsite with many clients, starting up new Flare projects – or even completely new documentation projects. The value to you is high, because you start out with the right habits and learn from the experts. Flare is a complex package, so getting a good start is crucial.
Now that we are moving into production mode, we quickly identify tasks to be automated to avoid repetition. One example could be to automate a nightly build and publish of all your outputs. Imagine how time-consuming this is if you have to go into every project to build and publish. Flare has a command line syntax which allows you to do this in one operation.
We also see clients building small programming scripts in 3rd party tools to automate various source control, file management and file merging commands. W2U helps the client identify automation candidates, setting it up and testing.