Six Reasons to love Flare

Last week I posted on stomach from Technically Speaking”>six persistent problems I’ve found in Flare, price a help-authoring tool (HAT) created by MadCap Software.

You may not be able to tell from that post, medications but I absolutely love Flare. I think it is a fantastic product. Truth be told, I’ve only used two HATs, Flare and RoboHelp X3, so my experience is understandably limited. However, I’m so pleased with Flare, in general, that I’m not even interested in considering other tools.

Also, since my experience with other HATs is limited, I’m not comparing Flare to any other HAT out there. If you are interested in comparing HATs, I recommend the HAT Comparison Matrix provided by the folks at

Ok. On to the meat of the post. Today I want to talk about six things I love about Flare (in no particular order).

1. Single-sourcing

At my last job (without Flare), we used a home-grown web-based help system for our product. If you wanted the same paragraph of text in two different topics, you had to insert it separately in both topics and hope that whoever came along to edit the paragraph later made the same change in both paragraphs.

Flare provides a feature called ‘snippets’, which are chunks of text that can be imported into any topic. To change the text you open the source file and make the change, which automatically populates that new text into all files the use that snippet. This has been a lifesaver in ensuring that similar features that share steps are consistent as they are described across topics.

I also really like the way Flare implements variables. (“Wait!” you say? “Didn’t you list Variables as one of the persistent problems?” Well, yes. But hear me out.) What is really powerful about variables with Flare is that you can set your variable definitions as part of your target definition. That means that you can set your variables when you create your target definition file and not worry about them again. If, for example, you are providing your help system to two different clients who each use specific terminology they want in the help system, you can just define that terminology in the target definition. You can continue developing content, inserting variables into the text, knowing that when the final output is built the correct variable will be used for the correct client. Variable implementation isn’t yet perfect, but I really like the model being used and I hope this will become a more robust feature in future versions of Flare.

Conditional text is another way Flare makes single-sourcing a great experience. I’m currently using Flare to create computer-based help as well as printed guides. I am using the same source files for both output types. However, there are some times when I want to say things one way for my on-line help and another way for my printed guides. (For example, suppose you have a sentence that reads “The purpose of this guide is to help you become familiar with Widget.” That works for the printed guide, but for on-line help, I want to say “help application” in place of “guide.”)

Using conditional text, I can include both “guide” and “help-system” and I conditionally mark the text so that the word “guide” only appears in printed output types and “help-system” only appears in computer-based output. I can create custom conditions, so this becomes a pretty powerful feature when combined with the condition settings available in the target definitions.

In short, Flare provides a lot of great support that makes single-sourcing from Flare a breeze.

2. CSS Support for different Targets from single style sheet

Flare is the first product I’ve used that supports different media targets from the same style sheet. This means that I can set the styles for my printed documentation and my on-line documentation in the same CSS style sheet. There is one location that contains all my style information.

I love having my styles based on CSS. One of my major complaints about the 7.x product line of Adobe FrameMaker is the difficulty of managing styles across large books or libraries. With Flare, I set all my styles in the style sheet and the changes are reflected automatically in every topic across the project.

My style information is text-based, so I can edit it in any editor of choice, including Flare’s built-in CSS editor, a powerful tool for editing CSS style sheets (more on this later).

Once I acclimated to using CSS for printed documents, I’ve come to really love it. It is a great standards-based way to ensure consistency across outputs.

One side benefit is that if customers decide to press the print button on the computer-based help application, the resulting printed page uses the “Print medium” settings in the CSS style sheet, so the printed page has the same look and feel as the printed guides. For me, this is very, very cool, and it is one of the things I love best about Flare.

3. Integration with Capture

Flare has tight integration with Capture, a MadCap product used for images and screen shots. While Capture is only a version 1 product, it is still a powerful tool that I’ve learned that I can’t live without. I am really looking forward to future versions of Capture to see how it improves.

The integration with Flare makes working with images really easy. With Capture, I can set different properties for images based on whether they will be used in printed output or on the web. For example, this allows me to have my images in the printed guides be .png images and the images in the online version be .jpg images.

Changes to images in Capture are stored in layers above the image, so you can change the underlying image while keeping the text or other alterations (including cropping) that you made to the original image. Since Capture also integrates with Flare variables, when I include a variable as part of the text on my image, that variable changes when the help system is built to the variable setting determined in the output target definition.

Capture also allows me to re-capture images, and depending on your settings, remembers the original image size and location (which you can re-size and move, as needed), so you can re-capture images late in the development cycle. This saved my bacon on a recent project when UI changes were happening the day before the scheduled release. I could re-capture the images while retaining all the modifications I’d made on the original image. I just replaced the bottom layer original image with the new one. This literally saved me hours of work at the end of the project when every minute matters.

4. Design of Tool

I love the way Flare is designed. While it may not be totally intuitive for new users, the more I learn about Flare, the more impressed I become with the smart design decisions made by the developers. Here are some UI features I absolutely love.

XML Editor

Flare’s XML Editor is top-notch. The editor gives you the ability to view “blocks”, which are really representations of the XML parent-child element hierarchy. The blocks appear on the left side of the editor. You can interact at the block level, collapsing blocks so you only see the parts of the document you are most interested in, or dragging them to a different position in the document.

The blocks are a powerful way to see nested tags and work with blocks of code, including paragraphs, tables, lists, etc.

The editor is the first I’ve seen that lets you toggle parts of the view space from a WYSIWYG view to a code-view; in fact, Flare lets you switch to a type of code-view for individual XML elements while retaining the WYSIWYG view for the rest of the topic you are editing.

If the source file changes while you are working, it is automatically updated in the Flare editor. For example, if you are working with a topic and you decide you want to edit the actual XML code, you can open the text in an external editor (any editor of choice) and make your change. When you save it, it is automatically updated in the Flare editor, so you are always working with the current copy. This is true for all content in Flare, including images.

I could go on. The XML editor in Flare is powerful. I’ve never seen anything quite like it.

CSS Editor

If you have worked with CSS style sheets, you know how hard they can be to maintain. Very quickly they get long and complicated. When you want to edit a style, you have to search through the CSS to find the particular style, then you have to know the proper syntax for getting the style you want. Well, Flare has made that process much, much simpler with their powerful, flexible CSS editor. The editor shows you the elements in your project that you can set styles for, and gives you a list of relevant styles for that element. You can change the grouping to see the available style settings grouped by property groups, relevant styles, or even those styles that have a value set for them. This CSS editor is better than any stand-alone CSS editor I’ve used, and makes creating styles across multiple media types a breeze. Once I started using the CSS editor, I wondered how I ever did CSS without it.

Flexible layout

Flare’s designers seem to have gone out of their way to make the workspace as flexible as possible. It seems that every window can become a pane, and vice versa. Windows can be detached from the workspace (a great tool if you’re using multiple monitors for authoring), as can panes. You can dock items to any of the four sides of the workspace. You can then save multiple layouts that you can reopen later. This is particularly handy because often different types of work are easier with different layouts. So when you are writing new content you can have certain windows and panes in one arrangement, while easily using a totally different arrangement for indexing. Find the layouts that work for you and save them, so you can spend less time trying to get the windows just right and more time authoring your content.

I could go on. The tool is well-designed by people who obviously have thought a lot about how help authors work. Once you get accustomed to the workspace and the Flare way of doing things, you really begin to appreciate the beauty of how Flare is designed.

5. Support from MadCap

Madcap support is fantastic. These are people who are very interested in getting it right, and work to ensure that problems are understood and addressed.

After my last blog post, I actually received an e-mail from MadCap support wanting to know if they could call me to discuss some of the problems I reported. Imagine somebody from Adobe wanting to call you to talk about the problems you’re encountering with PhotoShop or FrameMaker. Keep imagining, because it ain’t gonna happen. MadCap provides forums where users and MadCap support employees troubleshoot problems poised by other MadCap customers. Customers who purchase maintenance agreements also have additional options for obtaining support. We have an e-mail based maintenance agreement, and I am amazed at how quickly support has responded to my problems. They haven’t been able to fix every problem I’ve sent yet. But I believe they are working on them. I believe that they care about the customer’s experiences and want the experience to be a good one. They go out of their way to ensure that customers are happy and things are going well.

The care they show their customers engenders loyalty in return. I can put up with some persistent trouble in the application when I believe that the provider is taking my concerns seriously and will work to improve them.

6. Implementation of standards-based, plain-text files

I also love that Flare uses standards-based project source files. All of the project files are standards-based, non-proprietary formats. Most are XML-based, with a few exceptions (.css style sheets, document header files for context-sensitive help, etc.). However, I know that my content isn’t being held hostage by MadCap. As the years go by, if I need to migrate to a different HAT, I know that my content will be accessible.

Since the files are plain-text, not binary, they also work nicely with source-control software. When I make changes to a file, the source control can track which changes were made, rather than storing a whole new copy of a binary file. My entire project is 16MB, of which 15 MB are images. This makes for much more efficient storage on the source-control system.

In short, Flare is a fantastic help authoring tool. It is my tool of choice. If you are developing help content, you owe it to yourself to check it out and see if it is the right tool for you too. I think you’ll be glad you did.

I am. Every time I come to work.

6 responses to “Six Reasons to love Flare”

  1. Question about Flare…
    Is there a way to add a generic “previous topic” and “next topic” hyperlink to a master page?

    (Previously, we ran our FM docs thru Webworks, which added a previous and next buton to the top and bottom of each page. These were, of course, connected to the previous and next topics.)

  2. Hi,
    Your post is wonderful, and it points to many things I am looking for in a program. Right now, I write all of my documentation in vi, complete with DocBook tags, and then compile it into PDF and HTML outputs. But I don’t have the kind of control I want over design and layout.

    We need to produce attractive PDF manuals, HTML versions of the same, help files, and training videos. So I’ve been investigating ATCS and MadCap’s offerings. I would appreciate any resources or suggestions you have that might help me make the best decision. I am nervous about the MadCap suite for its youth and lack of broad acceptance, and nervous about ATCS for its impression of bloatware and questionable standards support. I do like its DITA push, however.

    Anyway… keep writing awesome posts!

  3. We love Flare too. I’ve used RH before and was glad to upgrade.

    I’m looking for a repository of assistance, tidbits of wisdom and all that jazz for software developers trying to ‘hook’ the help system to their project.

    They use C# and want to use .chm because it is ‘easier’. (yuk) Where do I get help for these guys?

Leave a Reply to Douglas K. Beagley Cancel reply