Lately, I’ve been chatting a bit with a some people who use MadCap Flare, or more specifically the MadPak Suite. Something that came up more than once in those chats was MadCap Analyzer, a tool for finding problems in a Flare project and for making various suggestions.
Surprisingly, not everyone I talked to has used Analyzer. It’s a useful app, and whenever I work on a project in Flare I run Analyzer over it at least once.
I also found that most of the people I talked to only focus on Analyzer’s variable and snippet suggestions. Only a couple have taken a close look at Analyzer’s index keyword suggestions. Those suggestions are a potentially useful way of beefing up your index.
by: Ben Minson
MadCap Flare was developed (at least initially) by the group that built RoboHelp, now an Adobe product. When MadCap released the first version of Flare, they wanted the interface to be easy to grasp for RoboHelp users to reduce the pain of switching. I played with the trial version of Flare 1 and found it fairly easy to find my way around—and this was back in the days of RH X5.
I recently switched from RoboHelp 7 to Flare 5. I’m not the person to ask about the merits of one over the other because I don’t have enough experience with Flare yet. Because I’m coming to version 5 with my knowledge being only that which my colleagues have told or shown me, I hope to make life easier for anyone moving from RH to Flare or at least trying Flare out. Given your background with RH, I want to help you avoid using up time trying to become oriented with the concepts that Flare is based on.
Following the tradition of previous DocTrain conferences, this one started off with a set of day-long pre-conference workshops. For a variety of reasons, I decided to take in the two sessions on topic-based authoring using MadCap Flare. Led my Mike Hamilton (MadCap’s VP of Product Management), the sessions opened my eyes to Flare’s capabilities and did a bit to change my opinion of the tool.
Not that I was anti-Flare or anything like that, but my brief flirtations with Flare left me thinking that it was a complex tool that would take a while to master. I still think that, but now I have an idea of what Flare can do and (to a degree) how to make it do the things that I want it to do.
The first session was notable because Hamilton gave some of the best explanations of XML, single sourcing, and multi-channel publishing that I’ve heard in a long time. You can see those explanations in the session slides that Mike Hamilton will be posting to his blog.
The morning session was an introduction to topic-based authoring with Flare, while the afternoon session focused on content control and publishing techniques. Hamilton took the participants fairly deeply into the application, and demonstrated how to use Flare to create content, and to import from Word and FrameMaker.
Hamilton also gave the group a quick run through of Flare’s upcoming DITA project import feature. At a high level, this feature can pull in a DITA topic map and enables you to map styles to the DITA files on import.
So, what did I get out of the session? A few things:
- Mike Hamilton stressed that when using Flare, you need to forget about how you worked with other tools. You don’t use Flare in the same way that you’d use, say, FrameMaker or Word.
- Planning a project is one of the keys to success when using Flare. Understand that needs, the scope, and the deliverables before even starting Flare. This seems like tech writing 101 but that’s something that some users of Flare seem to forget.
- Think in terms of topics. Hamilton suggested that you create what he calls a cloud of topics, and from there pull those topics together into your deliverables. Keep things based on tasks — identify the tasks, and then fold in the concepts (which explain why) and the reference material (which contain any additional information) into the tasks.
Overall, my impression was that the key to success in using Flare is preparation. Once you’re prepared, and once you know the application, creating content becomes smoother.
MadCap Software just release not one but four products. As Sharon Burton notes in her blog, “no one releases four products at once”. Admittedly, the four products are related (and, it appears, capable of being tightly integrated). This wasn’t a major surprise, but it’s still pleasant.
Blaze 4 is arguably the most anticipated of the products that MadCap released. It packs a lot of new features (check out Sharon Burton’s blog post for details), and MadCap has put out a short white paper on the benefits of topic-based content development. Definitely worth a look.
Tom Johnson has been working with Madcap Flare for a while now, and has published a blog entry detailing the things he loves and hates about it.
What Tom describes can be categorized as more of a like/dislike relationship than something as intense as love and hate. But he gets to the core of some of the great features of Flare, and some of the wonkiness of the product. And Tom did it the right way: he took the time to get to know Flare. As I wrote elsewhere, that’s the only honest way to review a product.
That said, we have to keep in mind that Flare is a relatively young product. It’s going through some teething pains. And, as I understand it, the folks at Madcap Software listen very carefully to their users, and (I hope) will eliminate or at least smooth out the 31 issues that Tom pinpointed. At the same time, I hope that they’ll improve upon the 45 things that Tom likes about Flare.
To be honest, though, I’m sure that Flare will always contain some features or functions that don’t appeal to everyone. No matter how much you love a piece of software, there will always be something about it that annoys you. I get frustrated sometimes with FrameMaker and OpenOffice.org Writer — and I’m a big fan of both.