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.

› Continue reading…

Bookmark It

Hide Sites

This post continues my comments on the results of my experiments using RoboHelp Packager for AIR on a WebHelp project.

General Bugs

Having Back and Forward buttons is great. However, in Classic Help, they didn’t always seem to follow my navigation path. I don’t use browse sequences (and I turned that feature off anyway in the AIR generation dialog), so I don’t think I’m misunderstanding the purpose of the buttons.

The Classic Help TOC seems a little buggy when the Favorites pane is open. Everything worked except when I had a bunch of books open and had to scroll to get to the last book. When I scrolled, I got behavior like the selected book or another book automatically closing, or the TOC would jump so I couldn’t see where the selected topic was. (If I scrolled back up, the auto-closing book would open up again.)

Where I had Captivate demos in a topic, a huge space was inserted before each Captivate demo about the size of the demo itself. The demos work fine, but that big space is an irritant.

› Continue reading…

Bookmark It

Hide Sites

I had some time today for testing the RoboHelp Packager for Adobe AIR (isn’t saying “Adobe AIR” like saying “ATM machine” or “PIN number”?), so I went to town. I kept notes as I went. I would be flooding the Packager forum with threads after exercising the Packager, so I thought it would be better to not be the kind of guest who makes himself at home to the point of leaving his clothes and dirty dishes strewn all over the house. Instead, I’ll provide my critique here in my own space.

Please be aware that these are coming generally in the order that I made the notes, though there is some semblance of organization of related topics. And unless otherwise noted, I’m talking about the “Classic Help” layout, since that’s the one I tried first.

› Continue reading…

Bookmark It

Hide Sites

I was thinking about this yesterday and ended up talking to Tom about it today. We work on projects that have asked similar things of us, but in other cases, our constraints are quite different. One example is security.

Let me illustrate. One Web application may allow users to complete a process that is not in any way sensitive in and of itself. So the help content for that application also is not sensitive, so it’s not problematic for it to be on a publicly accessible server. Even if the data that the users enter in the application can be sensitive or private, you don’t know what they’re entering by reading the help, so there’s no problem.

On the other hand, another application may help users in completing a sensitive process. By association, then, because the help describes that process, it is sensitive. I have found that generally, the projects I work on require more security than Tom’s.

This creates a challenge for our team as we work on standard and best practices.

› Continue reading…

Bookmark It

Hide Sites

At the STC conference, I remember someone—possibly Scott Abel in a presentation—saying that technical communicators really ought to be out in the online support forums for the products that they document. I agree; in the forums you can see the problems that real users are having and what the answers are if anyone has provided them. Being the technical writer, you may know some of those answers yourself. But at the very least, you can find out how people are using the product and what frustrates them.

It seems that Adobe heard the call. Within the last couple of days, a self-identified “technical writer for RH working at Adobe” has begun participating in the RoboHelp forums on Adobe’s site.

› Continue reading…

Bookmark It

Hide Sites

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.

Bookmark It

Hide Sites

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.

› Continue reading…

Bookmark It

Hide Sites