Yesterday I made a comment on Tom Johnson’s blog, I’d Rather Be Writing. A couple of months ago, Tom posted a list of ten reasons not to upgrade to Adobe’s Robohelp 6. (RH 6 is a help authoring tool (HAT); for those of you who aren’t technical writers, a HAT is a program that technical writers use to produce help documentation, either printed or online.)
Well, yesterday a reader named Richard posted a comment, asking Tom how long he had been working for MadCap Software, the authors of Flare (another HAT, which is a direct competitor to, and in some ways a descendant from, Robohelp). My response was to the effect that not all Robohelp critics work for MadCap, and not all Flare critics work for Adobe. I’m a Flare user, and I’ve found several bugs and problems with Flare that I think new users should be aware of before they pick Flare as their HAT of choice.
Tom responded asking for a list of problems I’ve found with Flare. This inspired me to write a full post on the problems I have encountered with Flare in the 6 months I’ve been using it.
Now I want to be really clear here on a couple of points: I don’t work for any HAT vendor. I’m not affiliated with any HAT vendor. That said, I use Flare as my primary HAT, and I really like it. I think Flare is a powerful tool that, for the most part, does exactly what I want a HAT to do. My list of problems with Flare is NOT a list of reasons that you should not consider Flare when evaluating a HAT. It is, in fact, a list of problems I’ve encountered as I’ve tried to use Flare in a real-world scenario. Some of these problems have easy solutions. Some of them don’t. Some of these problems are universal to all users, while some of them are specific to my help projects. Your mileage will vary.
Additionally, if you know nothing about Flare, then you should know that Flare is a fairly new HAT. It is XML-based, so all the source topics are stored as XML-compliant files which makes documentation management wonderful. Flare allows you to publish to multiple “targets.” One target might be a Word document with a table of contents, a foreward, headers and footers on every page with a printed glossary and index at the end of the book. Another target might be a different Word document with only some of the topics from the source project. This works if you produce two versions of your product, say a professional version and a “lite” version. A third target might be computer-based help (like you get when you press F1 in Microsoft Word) for your professional version. In the computer-based help version, you want different headers and footers (maybe breadcrumbs to show where you are in the overall help project), and you don’t want the same TOC, Index, Glossary, or even fonts as the printed version. A fourth target might be your computer-based help for the lite version.
When you get the projects set up with the styles for printed and computer-based targets, publishing to them is very easy. At the click of a button, you can create all four versions of your help from the source XML files. It is a powerful idea that works quite well, for the most part.
If you are considering Flare as a HAT, you really owe it to yourself to make good use of the 30-day free trial available from MadCap Software. The trail version is fully functional, but it will munge your outputs so you can’t use it professionally until you have purchased a license key.