Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Flare 4 was just released today by Madcap Software. In this podcast, I talk with Sharon Burton — product manager at Madcap Software — about all the main features of the Flare 4 release.

Flare 4 topics we discuss include the following:

• Page layouts
• New outputs (PDF, XPS, XHTML, and Adobe Air)
• Enhanced reporting capability
• Built-in topic reviews
• Additional help guides
• Global project linking
• Image resizing
• Smart cross-references
• Mini-TOCs for print

Although Flare 4 is the core focus of this podcast, Sharon also explains a little about Madcap’s other new releases, including Blaze, X-Edit, and Analyzer.

As if releasing 4 new products (Flare 4, Blaze, Analyzer, and X-Edit) on one day wasn’t enough, Madcap also totally redesigned its website.

If you have questions about Flare 4 or any other Madcap product, direct them to Sharon at sburton@madcapsoftware.com. You can also visit Sharon Burton’s blog at http://madcapsoftware.wordpress.com. You can visit Mike Hamilton’s blog at http://madcapsoftware2.wordpress.com.

If you have feedback on the podcast, add your comment below the post or send me an email at tomjohnson1492@gmail.com.

Contest Note: By the way, today is the last day to enter the Flare 4 giveaway. (If you missed the post about the Flare 4 contest, see “Flare 4 Giveaway — Enter to Win a Free Copy by Commenting on this Post“). In the contest deadlines, I said I would announce the winner on the day of the Flare 4 release. So Monday night (Sep at 9 p.m. MST, I will announce the winner. You can enter the contest up until that time.

When I first heard of Blaze, my immediate question was — Doesn’t Flare already publish to Word and FrameMaker? If so, why would I need Blaze?

The short answer is, you don’t need Blaze if you already have Flare. But if for some reason you only write printed documentation, and never online help, then Blaze might be for you.

Despite the irrelevance of Blaze for my project needs, Blaze does have a new review feature that is unique and worth exploring. As you know, you often you need SMEs and other team members to review your content. When your content is trapped inside a help authoring tool, you can’t quickly send SMEs a file to review — how could they open it? As a result, we traditionally publish our help to Word or PDF, print it out, and then stick it on the SME’s desk.

However, in many cases getting a SME to review 100+ pages of documentation is a battle. Like most people, they’re busy. Reviewing something takes times. Writing is often not their expertise or interest. So, you know the story. Either it never gets reviewed, or it gets reviewed tenuously.

With Blaze, Madcap offers you a totally new review workflow. You send a topic to a SME for review from directly within the Blaze interface by going to File > Review > Send for Review. When you do that, the following dialog box appears.

Selecting the “Allow Reviewers to edit content” check box gives the reviewer control to make changes to your text. If you clear this check box, the reviewer can only insert annotations.

After selecting your options, Blaze packages up the topic with a stylesheet and any relevant images and puts it in a .bltrev file. In the same step, it initiates an email handler that interfaces with Microsoft Outlook to create a new message with the file attached. It then sends the file to the email recipient you selected.

But how does the SME open a .bltrev file? Here’s where X-Edit Express comes in. The SME downloads this free application (requires .NET 3.0 as well, if not already installed). When the SME then double-clicks the .bltrev attachment, it opens in X-Edit Express. The SME can then insert annotations or make direct edits to the content.

Note that X-Edit Express only allows you to edit and annotate existing content. If you want the SME to actually contribute new files for your project based on a template, you’ll need X-Edit (which isn’t free), and the review process is slightly different. But the workflow of sending an attached file back and forth through email is still the same.

After the SME finishes reviewing your topic, he or she clicks Return to Sender (an option within X-Edit Express) and the email handler pulls up Outlook and sends the file back to the author, i.e., you. When you double-click the attachment, you’re prompted to add it back to your Blaze project with the following dialog box.

The email handler then saves it in a special inbox folder that Blaze recognizes.

As an author, you open Blaze and go to File > Review > Topic Reviews. A Topic Reviews pane appears on the left with a filter at the top (the pane is similar to other panes, such as the Content Explorer or Project Explorer). In the filter, select Inbox, and you’ll see the SME’s review, with the edits or annotations. As desired, you can choose to accept the reviewer’s edits and overwrite the original.

Accepting annotations is different from accepting edits. If you accept the annotations, they’re added to the topic, but rather than appearing within the topic’s text, they appear in an Annotations pane to the right. When you select one of the annotations in the Annotations pane, it highlights the word related to the annotation. Kind of neat there.

Overall, I like the topic review, but I’m not thrilled about the idea of sending attached files back and forth over email. It feels too 1995-ish.

In contrast, a centralized review from a wiki-type editor makes much more sense to me. But I can see how implementing this would be difficult. Blaze would need to have wiki-like features, and require a database. Topics would need to be editable through a browser. And you would need a mechanism that prevented simultaneous overlapping edits. Maybe that’s what Team Server is about — I don’t know.

Still, the idea of sending one topic at a time to a SME for review may prove interesting. And the movement of files through email is relatively slick (if you have Outlook, that is. I have a clunky old email program called GroupWise that has some hiccups with Blaze email handler). Sending a topic for review is not as strenuous as manually attaching files to messages.

But here’s my question: If your project has 200 topics, does that mean the SME gets 200 emails from you to review? Yes, that’s how it currently functions. You can only send one topic to review at a time. In many ways, this makes the topic review feature less useful. The idea, however, is to send topics to the SME to review as you finish them, rather than in one big whallop near the release deadline. That workflow may actually prove to be more efficient.

Although I’ve limited tmy discussion to reviews by SMEs, I can see how a topic review would be helpful for team authoring. If you have a contractor, intern, or other assistant, the topic review provides them with a way to author content that you can add to your help project with relative ease.

The following are some of my takeaways from the podcast:

• In an interesting real estate twist, Madcap moved back into 7777 Fay Avenue, which is where the former Blue Sky Software headquarters were. (Blue Sky produced eHelp, which later became RoboHelp.) This move back into the Blue Sky’s offices wasn’t intentional, but it seems fitting for Madcap, whose staff consists of many former RoboHelp employees. Apparently when the real estate agent unexpectedly announced the address of the new-found property, everyone listening on the phone fell silent.
• You can sense Mike’s enthusiasm in the podcast. As a former technical writer, he and others at Madcap say they understand the technical writing community and its pain points. They’re trying to solve all problems technical writers face, and they’re approaching solutions for the entire workflow.
• One can hardly ignore the impressive innovation Madcap has put forth over the past two years. They’ve produced a vast product line in a short amount of time. Some have even accused Madcap of having a “secret sweatshop of developers.”
• In talking about innovation, Mike says they aren’t “just taking a handful of existing tools, throwing them in a box, and doing some marketing” (which he refers to as shovelware — obviously referring to Adobe’s Technical Communication Suite). All of Madcap’s apps were built from the ground up to support the concept of single sourcing. The products share integration of variables, visual elements, and even code.
• Madcap Analyzer, one of their recent innovations, is a new product that Jeter says is “so good it’s scary.” Madcap Analyzer allows you to see problems in the help, such as inline formatting applied instead of styles. Hamilton says they “will continue to innovate tools into this space.”
• Madcap has an open roadmap of development. They talk about what they’re working on, what’s coming in future releases of their products. Nothing is secret at Madcap, and they even solicit their roadmap ideas from customers.
• Madcap actually uses their own tools to produce their documentation (what Jeter refers to as “eating their own dogfood”). This is also a point Rob Houser raised in his review of RoboHelp 7.
• A recent San Francisco chronicle article reported that Adobe is laying off employees, while Madcap is rapidly expanding its staff and offices.
• If you’ve downloaded Flare and Blaze, you know that the two look very similar. Mike says that when developers update the Blaze code base, it also updates Flare too, so that any hooks and other development foundations are available in the other products. This blending of code is how they share variables and other interactive features (and how they’re able to quickly produce so many products).
• Madcap’s centralization of employees gives it an advantage when it comes to communication. If you need to talk to a developer, you can walk over to his or her desk with questions (as opposed to Adobe’s distributed model, which has developers in India and offices in the U.S. and other countries.)
• Blaze promises to be a heavy-hitter — more impressive than first imagined, apparently. The formidable Sharon Burton has joined the Madcap team as product manager and is heading up Blaze.
• Madcap now has 25% of the market growth. This is a trend that has a sharp curve upward.

Personal Reactions

The rivalry between Madcap and Adobe isn’t World War III, Mike says. But there is a strong tension between the two companies. The rivalry between Adobe and Madcap is good in an economic sense, in that it keeps consumer costs down, encourages innovation, and removes the ability for either company to sit back on their laurels.

During the podcast, Hamilton talks a lot about Madcap Capture (the integrated screen capture tool). He highlights this as an example of the integration of the Madpak authoring suite. Hamilton clarifies the purpose of the suite: Madcap is trying to provide single sourcing solutions that fit the software development workflow which technical writers live in. All the products function together to enable total single sourcing of your content.

Despite the logic behind the complete product line, the emphasis on integrated screen capture tools seems hard to buy. I almost invariably tweak my screen shots using SnagIt and Photoshop before inserting them into online help. I love both of these image capturing and editing tools. Why ask me to abandon them for something else? Every product has strengths and weaknesses and customers may want to pick and choose selectively. For example, I’d choose Captivate over Mimic, and Flare over RoboHelp, and Snagit/Photoshop over other screen capture tools, and Audacity over Echo (if they’re even competitors), and Visio over some other tool they might create. In my opinion, the concept of the suite is similar to a Swiss Army knife: lots of tools in there, but all kind of mediocre.

Mike points out that content created by a variety of tools may look inconsistent. If I were to use the Madcap suite of tools, the screenshots and screen demos and online help would all have the same look and feel. And you can share variables and content more easily between a suite of tools rather than a miscellany of products.

Maybe he’s right. I haven’t tried the Madpak suite of tools — only Flare and Mimic separately. Maybe the concept of the suite will grow on me with use.

Where Are the Blogs?

Finally, where are the blogs? With all the war going on between Adobe and Madcap, you’d think that each product champion would be hitting it hard on the blog scene. Nope, they’re both blog shy. If either were to start blogging in a whole-hearted, authentic way, they’d surely win over some of the audience.

Adobe has basically outsourced its blog to the development team in India, and Madcap sticks to its forums. Neither of these puts a personable face on for customers.

Based on some insightful comments, I decided to strike out the above. Adobe does have a good blog, and it looks like Madcap is getting ready to enter the blog scene.