Flare review - Interface (part 1)

Image copyright MadCap FlareMy project team has just completed our first “major” user assistance (UA) deliverable created with MadCap Flare. Actually, it was a set of deliverables, which we’ve been plugging through for the past several months. I’ve talked about Flare before, but now I think I have enough experience with it to offer a thorough assessment of the application.

Rather than dump everything into a single post, I’ll divvy up the review into several posts, according to a semi-standard workflow that most UA developers go through. The interface is the first thing users encounter, and I’ll cover that in this first post. Later, I’ll offer some comments on the experience of using Flare to:

  • Create/prep the UA system
  • Create content
  • Add extra features
  • Build and publish the system

Interface
Make no mistake - Flare is designed for a dual-monitor system. This is good and bad. It’s good because most users nowadays are (wisely) adding a second monitor to their systems. Most video cards today support dual monitors, and the added cost to a desktop system is negligible. Furthermore, study - after - study shows that adding a second monitor increases productivity by huge amounts, 20 to 30 percent in some cases. Once you go dual-monitor, you never go back.

Compared to RoboHelp, my other authoring tool, developing UA with Flare’s dual-monitor capability was quite refreshing. Any palettes I needed could remain on-screen, within easy reach of my cursor. And, of course, the layout can be completely customized, so you can arrange the palettes and windows any way which suits you best. (For a complete discussion of Flare layouts, see Andy’s posts on the subject over at Tech Write Tips.) You can also save a customized layout, so if things get moved around, you can re-load your layout to its preferred state. In fact, Flare allows you to save multiple layouts. This can be useful if you wish to have different palettes and windows at the ready during different parts of the development process - e.g., perhaps you have a preferred layout for writing, another for applying styles, and even a third for creating indices. You have complete control.

Why is this also “bad?” Well, it’s great to provide this capability, as long as you make sure it works consistently. Unfortunately, this part of the software has a few remaining bugs. Layouts don’t always appear properly, even if you’ve saved them. It gets a tad frustrating to hunt down & open the one or two palettes that you always use, each time you open the software. Another issue is that, while Flare works beautifully in dual-monitor systems, you actually have to open the software (or project file) from a shortcut or window on your primary monitor. If you launch the software from your secondary monitor, the layout tends to barf on you. Having said this, I should mention that these issues are present in the 1.1.2 version of Flare, and MadCap has repeatedly said that the “real” version of Flare will be its 2.0 release. Version 1.0 is primarily aimed at helping folks to migrate from RoboHelp. So, hopefully these layout issues will be resolved in the next version.

Another unique aspect to the interface is the ability to have multiple documents open at the same time. Flare arranges everything you open in a separate tab, much like Firefox’s tabbed browsing feature.

tabs
Anything you open loads in its own tab

This is great for tasks like cutting-and-pasting between topics, seeing instant results after changing a CSS style, or for viewing a page’s code alongside its counterpart in the visual editor. It’s a nice touch. Flare never closes the tabs, though, so if you don’t close them manually, you could eventually get “lost” in the sea of tabs stretching across the top of your screen.

Regarding the visual editor: This is where MadCap is blazing new territory. To the left of your visible content are “tag bars,” visual indicators of your document’s structure. (Remember, Flare develops in XML, so structure is paramount.) In the example to the right, you can see that my cursor was located in the second line item of the second ordered list, which was itself contained within a drop-down control. Slick, huh?

Content can be moved around simply by dragging its corresponding tag bar to another location. The benefits of this type of approach should be obvious to those of you who work regularly with XML. It’s fantastic when working with tables.

As for the remaining interface elements, Flare uses a very common approach to menus and icons. Common tasks are easy to find in the menu system, residing generally where you “think” something should be. Labels are not ambiguous or confusing. Any icons that are unfamiliar are rather easy to decipher, and tooltips abound. Toolbars have a definite Microsoft “feel” to them. It looks to me like the application was developed using C#, and it takes advantage of the nice features of the new .NET and WPF frameworks. Overall, the UI is essentially transparent, as it should be.

— end of part 1 —

1 Response to “Flare review - Interface (part 1)”


  • Flare 3.1 still has problems with FrameMaker - see my review at:
    http://stctoronto.netfirms.com/newsletters/2008/03/single-sourcing-madcap-flare-with.html

  • Madcap Flare: In-depth Review Beginning at MonkeyPI @ Structured Framemaker, FDK and XML Blog

Leave a Reply