Friday Comments Review: RoboHelp vs. Flare

When you find new authors it’s exciting to read their viewpoints. I initially started this blog with a thread of analysis of Adobe’s RoboHelp 6 release with which I was thoroughly underwhelmed. I had been watching the discussion on MonkeyPi previously, and part of the enjoyment of blogging is responding to what I call distributed discussions.

Back to RoboHelp vs. Flare: The Blog Review

It’s interesting that today’s examples are all from Utah. Being a former Coloradan for several years I have to say it’s nice to see some of the Rocky Mountain crowd. Now let’s enjoy some distributed discussion of RoboHelp 7 and MadCap’s marketing.

First, a view from Paul Pehrson on RoboHelp 7’s competitive abilities with his analysis of Adobe playing the innovation catch-up game:

RoboHelp is now in catch-up mode trying to figure out how to emulate the innovative features in MadCap’s product suite. Now it is MadCap pushing the innovation envelope here.

Will RH be able to maintain pace with MadCap’s one (or more) releases per year? Will RH be able to come out with new features that aren’t already in Flare?

Maybe so, but RH 7 wasn’t proof of that yet. Again, it will be interesting to have this discussion in two years and see where the major players are at.

I found Ben Minson’s blog when he guest posted to Tom Johnson’s blog. Ben posted a critical thesis about MadCap’s marketing which, by the way, is a great opinion piece.

The thing that has bothered me the most about what has happened with RoboHelp and Flare is MadCap’s marketing approach, which caused “Flare” and “MadCap” to leave a bad taste in my mouth.

Granted, Macromedia’s treatment of the original RoboHelp team was probably less than professional. However, Hamilton seemed to make it his quest to blow RoboHelp to smithereens. It wasn’t business—it was personal. If he could carry that little ring to Mount Doom and throw it in the fire, it would be worth everything that happened in between.

In my research into my Web 2.0 Technical Support series about MadCap Software I hadn’t seen anything untoward expressed online or in print. They did, however, carry a gag gift of the die kadov tag die T-shirt, an inside joke about RoboHelp’s shortcomings.

In fact, in my podcast with Mike Hamilton in December 2007 he was neutral about Adobe. I asked Mike H. several tough and somewhat leading questions about RoboHelp and Adobe. Before, during, and after the podcast he never said anything truly outside the norm, and in fact was more generous than I was in his analysis regarding the level of dedication that Adobe may have with RoboHelp.

In my podcast program we find the relevant segment within the Hamilton podcast:

10:10
Clarifies MadCap’s focus on Adobe: “…we don’t care what Adobe does, we’re focused on solving the problems of the technical writing community… I want to dispel any myth that we’re chasing Adobe.”

11:40
Why I started analyzing the space closer: MadCap’s openness in summer 2007.

12:10
Thoughts on other blogger’s views about Adobe’s Technical Communications Suite (TCS) launch. Mike responds by comparing integration of tools within Flare and within Adobe TCS – Example of Capture’s integration with Flare to support the concept of single sourcing workflow.

We went into other discussion of workflow…

34:30
Remembering RoboHelp: we each discuss where RoboHelp came from and why it’s so different from this model MadCap’s following. Mike elaborates on the competitive edge MadCap has right now in integrating all of their products.

36:40
Mike believes that both RoboHelp and Flare will be around for a long long time, of course he and I differ on this viewpoint. He does mention the caveat of how much innovation Adobe puts into RoboHelp being questionable which we both agree upon completely.

Here’s Ben’s post of A Little More about RoboHelp and Flare. 

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.

Ben posted a well-thought out analysis in the second post of his series. [What follows is a repost of my comments to Ben’s blogpost.

Regarding preference, I couldn’t agree more that ‘everyone has a nose’ fits the bill. Here’s my schnozz, poked into everyone’s business. Here’s my take on tech support between the two companies in the past year.

Regarding the capability to perform the best service for the customer (meaning the purchaser of the software) currently I think there’s no competition for MadCap. Then again, I know them. I don’t know who supports RoboHelp, but I used to. When they worked stateside and still understood the product, that is.

Rock

Regarding the capability to develop features through dollars spent in innovation - the jury is out with that. Adobe’s strategy is to offshore $200 million in development dollars to India. That gives you 5 to 7 times more bang for the buck - something like a billion dollars worth of development.

Paper

Sort of like that Aliens movie where the Hicks character said to nuke the site from orbit in order to be sure.

MadCap’s strategy has a bit more finesse. According to my interviews with their staff, they have been focusing on making the features that improve the workflow for technical communication.

Scissors - Here are the endgame strategies:

Adobe’s endgame - Adobe’s Ro-sham-bo move to the MadCap innovation is that they can throw more dollars and developers at the situation, therefore they can attempt to duplicate whatever features prove marketable.

MadCap’s Ro-sham-bo endgame move?

MadCap’s got all new code, and Adobe’s middle management probably doesn’t have the balls to make the judgement call to pony up the money it takes to completely revamp RoboHelp.

Adobe simply - after three years without a release that features requested innovation that isn’t simply a competitive match - that Adobe’s customer base will get sick and tired of renewing their contracts just to get the 14.0 or 15.0 release of a code base that originated in 1997.

Moral of the story

If you’ve got old code, you better have damn good support. If you’ve got new code and killer award winning support and innovation, it’s like a trifecta.

Related Posts: