This week, I’m going to post a series of tips about RoboHelp, mostly concerning FlashHelp. I realize that FlashHelp isn’t a commonly used output, at least not as common as Microsoft HTML Help or WebHelp, but in my opinion, that’s all the more reason to post about it. Often, those who do use it can’t find much on the Web to help solve their problems.

The Problem

When you generate a FlashHelp output from RoboHelp, you want to take a look on your computer before publishing the files to a server. But a warning comes up that says, “Flash Player has stopped a potentially unsafe operation.” It won’t let you view your output.

The Solution

Go to the Flash Player Settings Manager page on Adobe’s Web site. This link should take you directly to the security settings tab (see the image).

Then do the following:

1. Click the Always allow radio button.
2. Click the arrow in the dropdown box that says “Edit locations.”
3. Click Add location.
4. If you want an entire drive (which is what I did so I wouldn’t have to browse for a bunch of directories), just enter the letter of the drive, followed by a colon and backslash: “C:\”. If you want a specific directory, click Browse for folder, select the directory, and click Open.
5. Follow steps 2–4 for each directory where you want to allow Flash content to play unhindered.
6. To remove a directory, click on it, click the dropdown box, and click Delete location.

But wait—won’t you have to now document these steps for everyone who is going to be viewing your FlashHelp system so they don’t get this error? No, this is a problem when viewing the output locally, not when viewing it over the Internet. If you are sharing the help project with other writers, they’ll want to follow these steps as well.

I see questions from time to time in the RoboHelp forums about ways to deal with the same help system in multiple languages. So I thought I’d lay out the way I do it for reference.

First, let me say that I think the ultimate way to deal with localization would be for the help authoring tool to be able to run all of the translations out of one project. RoboHelp 7 lets you have multiple tables of contents, glossaries, and indexes, and of course, there are conditional build tags that let you create multiple versions of a single help topic. However, as far as I know (and I may be revealing gross ignorance here), it doesn’t let you do multiple versions of:

• Project title (for the browser title bar)
• RoboHHRE.lng, the file that drives text like input prompts and error messages
• Topic titles (the actual HTML file title, not necessarily what appears at the top of a topic—or if it does allow this, you’d have to manually apply the conditional tags in the HTML rather than in the WYSIWYG editor)

Because of said limitations, here’s what I’ve done.

(more…)

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.

(more…)