Flare v. Robo Features

[dwag]

Would anyone be willing to provide a short list of stuff Flare does better than Robohelp, preferably stuff that can be demonstrated quickly? Thanks.

[nickatwork]

Bit tricky as RH just upgraded to v9 and all my gripes are regarding RH8. So many things just seemed un-finished and like they could have gone a few extra steps to make things better.

But from v8 that I was using before moving to Flare...

RH could only add a snippet as a block of text. It could not be inserted between words/sentences like Flare.

Better stylesheet editor in Flare. Just look at RH8 style sheet compared to Flare.

Loads more customisation with WebHelp skin outputs. Colors, blends, icons, etc etc. RH makes this difficult to say the least and is very restricted.

I spent so much more time hacking away in the HTML in RH than I ever need to in Flare. This was due to bugs and short-comings that were in RH8.

Oh, and RH support is awful.

[dwag]

Not in the least surprised by your last point. Thanks so much for the list. At our company, one division of writers is using Robohelp, the other Flare (long story), and pressure is being applied to adopt one tool companywide. One issue has been ease of integration with TFS, and that, according to the developers who are closest to it, is where Flare falls short; otherwise, gut feeling, at least among those in my division, is that Flare has more to offer, particularly in the support area. Besides that, both sides have been making the case that we should be able to continue using both tools. We'll see. Thanks, again.

[NorthEast]

One issue has been ease of integration with TFS, and that, according to the developers who are closest to it, is where Flare falls short

We keep our Flare projects in TFS and haven't had a problem with it. What aspects does it fall short with?

[dwag]

You'll have to forgive me, but at the moment, I've got only an indistinct smell for the reasons. If I recall, one developer explained it as Robo having knitted a cap specifically to fit the TFS integration (somewhere along in the process, the UI mimics/behaves the same as the TFS UI?), while Flare has tried to knit one cap that fits all, and it doesn't fit TFS as seamlessly as they'd prefer. I'll catch up with him and try to get a more accurate, concrete description.

[LTinker68]

Although TFS integration might be better in RH, I wouldn't base the whole decision on that one feature. After all, you don't have to integrate to any source control within RH or Flare -- you can use the source control's interface to do the checking in and out. Doing it within RH and Flare is certainly more convenient, but not having it doesn't prevent you from producing outputs in multiple formats, all of which provide the information the user needs and in a way that they can use it. After all, if the output sucks and the users don't use it, then TFS integration is a bit of a moot point.

So if you have the time, have 2 or 3 of your writers download and install trial versions of RH and Flare, compare them feature by feature, then build outputs out of both. Have non-tech people within your company (like your human resources, purchasing, etc. departments) review the two outputs and see if they can tell a difference and which one they like better. True, it might be a lot of work, but if you have the time, might as well do an in-depth review.

[dwag]

Here's an excerpt from a recent dialog the developer had with a Flare rep:

"I walked through the setup process for RoboHelp 9 in order to see the TFS integration first hand. It is definitely leveraging the TFS MSSCCI Provider for TFS. This is nice since all dialogs are the same that one would see in Visual Studio, but also it gives us the ability to select a WIQL query to list work items for association during check-in. In addition, the merging will invoke the merge tool defined under source control options in Visual Studio. In our case, we have it configured to use BeyondCompare for our merging."

[forfear]

Although TFS integration might be better in RH, I wouldn't base the whole decision on that one feature. After all, you don't have to integrate to any source control within RH or Flare -- you can use the source control's interface to do the checking in and out. Doing it within RH and Flare is certainly more convenient, but not having it doesn't prevent you from producing outputs in multiple formats, all of which provide the information the user needs and in a way that they can use it. After all, if the output sucks and the users don't use it, then TFS integration is a bit of a moot point.

So if you have the time, have 2 or 3 of your writers download and install trial versions of RH and Flare, compare them feature by feature, then build outputs out of both. Have non-tech people within your company (like your human resources, purchasing, etc. departments) review the two outputs and see if they can tell a difference and which one they like better. True, it might be a lot of work, but if you have the time, might as well do an in-depth review.

Yes. I have to agree with this.

[NorthEast]

This is nice since all dialogs are the same that one would see in Visual Studio, but also it gives us the ability to select a WIQL query to list work items for association during check-in. In addition, the merging will invoke the merge tool defined under source control options in Visual Studio. In our case, we have it configured to use BeyondCompare for our merging."

Ok, so it's the level of integration with TFS.

Both points are correct:

(1) When you check-in files to Flare, you can just add a comment to the changeset - you can't associate a work item.

(2) Flare uses Visual Studio's merge tool (or at least it looks identical).
Mind, although it's probably quite important for developers working with code, is that something you will use often? I very rarely need to merge Flare files; only if two authors have simultaneously edited the same file.

So, on the source control front, I guess it's how important these issues are.

[dwag]

Thanks for the response. I'm a bit out of my element here, but the issues evidently are important. We've got multiple code streams going simultaneously, merging here, merging there, with variations of the help included with each. Best I can say is, I'm happy with the way things are set up on my end: From Flare, I check out and work on whatever topics I need to each day, associate the completed topics with the appropriate screen IDs in the Alias file, and at the end of the day, I check in whatever topics I'm ready to check in, and in the morning, like magic, the help icons appear on the appropriate screens in the software, and the help is ready for testing. At various points along the way and when products are ready to ship, the help is merged with the code into the main streams.