TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Over the past decade I've used both RoboHelp (7-8 years) and Flare (3+
years). I'm currently using both RoboHelp 10 and Flare 8 at the office.
RoboHelp 10 because it's what they had the license for when I got here and
I use that for legacy projects. But I've got a new product where I'm
choosing to use Flare 8 (bought with my own money, which should tell you
something) because while RH can do all the things I've done with Flare in
the past, it's just such a pain in the rump to get RH to do them. I think
you'll find that most of the people who love RH have been using it forever
and know how to make it behave because they've grown with the product. But
if you're new to the product (or like me, coming back after years away)
it's NOT intuitive, And learning the odd ways that RH implements things is
difficult at best. I'm not a stupid person. I can write code. I know
HTML and CSS. And I tend to apply the KISS principle to my projects. And
I'm still baffled by RH on a regular basis. So while on a feature to
feature comparison the two products may be similar, the usability of RH
leaves much to be desired. I'm constantly searching for settings, heck,
constantly searching for FILES that aren't where I expect them to be in my
RH project. For my new product I'm on a tight (agile) schedule, so after a
quick pilot project in each RoboHelp and Flare (I'll admit, some of my RH
frustrations are extremely "dirty" legacy projects, but I struggle with
even "clean" projects in RH), I chose Flare for my new project because it
took me so much less time to get from zero to useable, skinned and
corporate branded output.
I used to rave about Flare's helpful documentation, but I think that praise
may have gone to their technical writer's head. The current doc set for
Flare 9 has a rather overwhelming 39 PDF guides. (Seriously MadCap?
SERIOUSLY???) And each one I download seems to be hundreds of pages long
(much of that content is single sourced, which makes it even harder to wade
through). But even so, I still think it's easier to search the Flare
documentation than the RH documentation. And the Flare user forums are by
far superior: easier to search, more active users, more actual answers to
questions. So if the worst thing I can think of to say about Flare is that
there's too much doc? *shrugs*
Are you using source control? If so, ask a LOT of questions during your
demos about their integration with source control. I've used Flare with
Team Foundation Server and RoboHelp with Git, and there is quite a
difference. I did a lot of reading before I set up the integration with
Flare and TFS, and tested the heck out of it before rolling it out to the
team at my previous job. Things went really smoothly. By default, Flare
does NOT check in your output directory with your source files. Which is
awesome, since you may generate output several times in one day. But I
don't really think that RoboHelp is designed for integration with source
control. (RH does not integrate with GIt directly, but then again neither
does Flare). I can open a project just to check on something, not make a
single modification, and Git still tells me that RH made changes to several
support files which Git them wants me to check in if I change branches. By
default RH generates output inside the project folder, which means that
depending on how your dev team has set up your build structure, you could
be checking in your output files twice (I recently cut the size of one of
my projects in half by deleting duplicate and unused output files from the
project).
But the best advice I can give on choosing a tool is, know what your
requirements are. Have a sample/pilot project (even if its just a Word doc
with a dozen Lorem Ipsem topics at various heading levels). Download the
trial versions of each, and take at least three or four days with each HATT
to generate a pilot project. See what their default templates look like.
Create a TOC, add an index. Then generate the outputs you plan to use
(online or printable). See how easy or hard that is to do. Play around
with the CSS and skins. Play around with their other nifty features you
want to use (expanding text, thumbnail graphics, whatever). You really do
have to USE a tool before you know if it fits your need.
Personally, I need to get working on my ROI statement to get the office to
buy me Flare 9. I really, really want their new side-by-side WYSIWYG and
code views.
--
Julie Stickler http://heratech.wordpress.com/
Blogging about Agile and technical writing
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
New! Doc-to-Help 2013 features the industry's first HTML5 editor for authoring.
