Today’s post is borrowing space on Communications from DMN. It’s called “What to Know When Switching from RoboHelp to Flare.” Hope you enjoy.
Tag: Flare
Sarah O’Keefe (@sarahokeefe) of Palimpsest tweeted today that according to a webinar she was attending by Ellis Pratt (of Cherryleaf, @ellispratt), nine times more people visit help websites than traditional help systems. This really got me thinking throughout the rest of the day.
If It Looks Like a Help System…
Why would people be nine times more willing to go to a website than an online help system? Since this may have been explained in the webinar but all I have regarding it is Sarah’s tweet, my initial guess is that people tend to think a help system is static and easily outdated (they don’t know about the Agile technical writer?), while a website is fresh and frequently updated. Whether those things are actually true isn’t as important as the fact that the audience perceives them as being true.
This led me to thinking that all is not lost for help authoring tools, though. I’m sure with some effort, I could make an online help system look like a website. Of course, it would take WebHelp to do that convincingly, so this approach may not be possible for all software products.
The first step would be to use some term other than Help. Next, get rid of that traditional side pane, one of the dead giveaways that you’re looking at a help system. RoboHelp and Flare, and maybe others, enable this.
Part of the problem here, though, is that the side pane contains much of the navigation. So it would take putting on the Web designer hat to work out the best way to offer navigation through the help.
I’ve got some bad news if you’re a die-hard RoboHelper. No, Adobe isn’t shelving RoboHelp, nor are they reintroducing kadov tags.
I’m being switched to Flare.
Once you’ve come out of cardiac arrest, let me explain.
I’ve said before that I’m not married to any particular tool; I don’t carry around a sign or a mentality that says, “If you don’t use RoboHelp, go jump off a bridge!” The whole HAT wars thing is a bit tiresome. I don’t have any particular feeling toward Adobe, though I’ve heard their customer support leaves something to be desired. And MadCap’s idea of what qualifies as a separate software application bothers me. But they haven’t committed some personal offense against me. (Though back when I evaluated Flare v1 and received a call from MadCap, the person sounded a little offended that I declined to purchase it.)

So since I don’t have some conflict of interest, it comes down to the tools themselves—and what our team is doing. We just hired two new User Education team members, and one is Flare MVP Paul Pehrson, AKA DocGuy. He sits next to me, and in a discussion about Flare that he and another colleague had the other day, let me tell you that the dude knows what he’s talking about. He told me he hasn’t used RoboHelp. The other new guy has used both and prefers Flare. And Tom Johnson is already using it.
I have enough to say to follow up on my previous post regarding RoboHelp vs. Flare that I thought a new post was in order. (If you read the other post, read the ensuing discussion.) One of the things that made me think about that topic in the first place was seeing Flare’s ad that suggested trading in your “legacy” software for the “new model,” Flare. RoboHelp was the only product mentioned by name in the promotion that offers a discount for switching. However, I’ll not assume that Mike Hamilton has anything to do with MadCap’s marketing, since he’s involved in the product management.
The podcast that Tom mentioned has Hamilton saying he wanted to disband some myths floating out on the Web about what happened between him and Macromedia. A brief summary: When Macromedia acquired eHelp, he expected RoboHelp to go to the next level, but they primarily wanted RoboDemo (now Captivate), another eHelp product. Macromedia seemed to make some counter-productive decisions: The RoboHelp team was working on RoboHelp X6 and only three months from release when Macromedia laid off half the team and planned to send RoboHelp to India. Then Macromedia decided to drop it completely, even though it was a very profitable product. When MadCap was founded, Hamilton and that team thought RoboHelp was dead. They wanted to provide something to help authors that was alive and running.
What I remember reading at the time this was going on, though, indicated that Hamilton was pretty skeptical of Adobe’s ability and commitment to carry RoboHelp forward. In the podcast, Hamilton mentions advantages of Flare that RoboHelp 7 also has. Macromedia clearly set RoboHelp back by shelving it, but Adobe has pushed it forward. He’s doing what he should when he promotes Flare, and perhaps it’s the fact that Flare’s history is so tied up with RoboHelp that it’s hard at this point to talk about the strengths of Flare without talking about RoboHelp.
At least in the podcast, Hamilton still seems to view RoboHelp as a limping technology, and MadCap’s ad appears to reflect that. Again, I’ve simply given my own observations of what happened. As my father says: Opinions are like noses—everybody’s got one. And if you’re like me, your opinions may be as strong as your nose, too.
A couple of years ago, I was using RoboHelp X5, a help authoring tool (HAT) that was several years old. In the software industry, letting your product go that long out of date is bad for business. RoboHelp still had a lot of users for a couple of reasons: Many had used RoboHelp and its predecessors for years, and there weren’t very many alternatives.
Macromedia had shelved RoboHelp and disbanded the product management team and RoboHelp developers in 2005. Mike Hamilton, the product manager, left about that same time. On the Internet, Hamilton criticized Macromedia, and by extension Adobe Systems, who had purchased Macromedia. He announced his joining a new company, MadCap Software, and that they would be releasing Flare, their flagship product and new HAT.
Journals by Email











