I started in the field of technical writing when I began writing the procedural documents for the hardware and software the company I was working for at the time was selling. The task came to me because I showed an interest, knew the products, and the technical writers hired under contract kept leaving with short notice. At the time, my company was using FrameMaker® and RoboHelp® for producing documentation, so that’s where I started. Unfortunately, a short time later, low sales resulted in a downsizing and my permanent position was eliminated. But because of my involvement with writing the various manuals, I was offered the chance to come back on a contract basis to continue that work.
By the time I began working again (there was a gap for various bureaucratic reasons), the company had decided to switch from FrameMaker® to MadCap Flare for undisclosed reasons. Without the budget to cover importing all the previous manuals and documents from FrameMaker® to Flare, all new projects would be created exclusively in Flare. So, just when I was getting comfortable with FrameMaker® and its idiosyncrasies, I had to start learning a completely new package. I had heard a little bit about Flare previously, but had not looked into it in any great depth, and was very interested in learning more about the product.
Comparing Flare to FrameMaker®
When it came to learning Framemaker® and RoboHelp®, I had the advantage of not starting from a completely blank slate; there were existing documents that I could examine to get an idea of how things were put together in each package. This was not the case with Flare and I was completely on my own when it came to learning about the software. Even so, I found Flare to be easier to get comfortable with than FrameMaker®. The following are a few features that stood out in my transition from FrameMaker® to Flare:
1. Resources and Support for New Users
One of the noticeable differences was the product websites themselves. I found the FrameMaker® site to be somewhat confusing and the help files I found there were the same that were supplied with the product. There were some tutorials and videos, but I found them to be of limited value. When I got stuck, mostly I would work by the trial and error method (fortunately I am quite stubborn when it comes to things like this), dig deeply into the supplied documentation, or conduct an internet search, as invariably someone else had already run into the same problem.
The MadCap website, by contrast, was very open and inviting, with direct links to many helpful PDF and video tutorials. I took full advantage of the webinar series as well, quickly coming up to speed on the basics of topic-based authoring, indexing, and CSS and styles in general. I particularly liked the ten video series explaining what styles are and how to use them. When it came to support, I found MadCap had the advantage as well. I really couldn’t find a way to send a support question to Adobe®, but MadCap made it quite easy and the support team responded quickly to any emails I submitted. The MadCap sales rep also contacted me on a regular basis to make sure I was getting along with Flare.
2. User Interface
There were a few other characteristics that set Flare apart from FrameMaker® (and here I am referring to Flare 11 and FrameMaker® 12). The biggest difference I see is in the overall interface. I find Flare to be just a bit more, well, friendly. FrameMaker® is basically monochromatic while Flare is colorful, for example. Flare has a row of large, colorful, intuitive icons across the top of the screen; FrameMaker® has small gray ones. With Flare, you can see what a style will look like before you apply it to a text selection while in FrameMaker®, all styles are shown in default style.
CSS Capabilities of MadCap Flare.
3. Formatting Features in Flare vs. FrameMaker®
Variables
Variables are another area where the two packages differ. In Flare, all your defined variables are contained in a single file, accessible to all topics in the project. In FrameMaker®, each document has its own set of variables. This is fine if your project consists of just one file but most FrameMaker® projects are made up of several files, grouped together as chapters in a book. If a variable is defined in one chapter, it does not automatically appear in the other chapters; the user must import the variables from the document where it was originally created. Even then, if the variable is redefined in one document, that change does not appear in the other documents until it is once again imported. With Flare, whenever a variable definition is updated, that change automatically appears wherever that variable is used, giving the author one less thing to worry about.
Paragraph Styles
The same is actually true about paragraph styles. Making a change to a paragraph style in one chapter of a FrameMaker® book does not affect any other chapters until the style is imported. With Flare, as long as each topic is associated with the same stylesheet (which they are by default within a project), any change in a style is instantly applied to every paragraph with that style in all topics. Again, one less thing to worry about.
Lists
In FrameMaker®, in numbered ordered lists, the first list item needs its own style to ensure that the numbering starts at one. Same with figure captions in a multi-chapter book (assuming that the first figure of each chapter needs to be labeled “Figure 1”). Keeping track of this adds to the complexity of the document. In Flare, each list item has the same style assigned (unless the author wants different styles, of course) and the numbering type (numeric, alphabetic, etc.) and sequence number is easily handled through separate menus.
Glossary Terms and Index Items
I also much prefer the way Flare handles things like glossary terms and index items. Here is how a glossary item and an index item are displayed in a Flare document, along with the information box that pops up when the cursor is hovered over one of the items:
Compared to the FrameMaker® glossary and index item markers (the large, bold T-shaped elements):
Which is the glossary and which is the index? The only way to tell for sure is to open the Marker pod, which is not nearly as user-friendly as the Flare method.
And don’t get me started on the different way TOCs are handled, especially the formatting. True, I was a bit daunted by the idea of creating my own style classes in Flare at the start, but now I create them whenever possible, as they make life much easier. Mediums still trip me up once in a while when I don’t check to make sure that the same Medium is selected for the stylesheet, topic and target but their value far outweighs this small issue. I could go on with more examples, but they would all show the same thing, I think. While both programs are powerful and capable, when I open FrameMaker® the feeling is: “I’m doing work.” When I open Flare, it’s more: “I’m doing work, but I’m also having some fun.”
Conclusion
All in all, it’s been an exciting and rewarding journey learning about technical writing and how to use the tools associated with the trade. While I am still fairly near the beginning of that journey, I plan to continue to expand my knowledge base and increase my opportunities by contributing to the Flare forums, both here and on LinkedIn. I’m hosting a Flare webinar for MadCap Software that is scheduled for September (click here to register) and submitted papers to the 2017 MadWorld Conference. In terms of my consulting business, I’m planning on using the experience and confidence I am gaining by working for my previous employer to expand out to other customers. Having a known environment to start out in does make the first steps easier and provides a solid start to my professional portfolio.
I hope this post has provided you with a small amount of insight as to how a non-technical writer with no Flare experience started using the software and is now a confident user and writer. If you find yourself in a similar situation, I think you will find the transition to Flare as relatively painless as I did.
