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.
Again, very easy to assign this header to the text in the xml editor.
>When doing major updates or revisions I find it much more efficient to
have all the content in one big file instead of one file per topic or few
topics.
Ah, but that is one of Flare's greatest strengths. One of the reasons why I
choose Flare was for its powerful single sourcing capability. Yes, it is a
very different documentation concept but if single source (re-usable
content) is important to you, this segmenting of content is actually quite
nice.
> MadCap ended with bug reports or feature requests or them telling me it
was a known bug
I concur. The first two weeks of being knee deep in MadCap Flare, I was
'discovering' about a bug every three days! And placing a feature request
about the same number.
Fortunately, I have successfully worked around all the issues I
encountered. But for a little while, I was wondering if I made a huge
mistake. Trust me, you need to buy a support contract for your first year!
On Thu, Sep 26, 2013 at 12:31 PM, Robert Lauriston <robert -at- lauriston -dot- com>wrote:
> FrameMaker's WYSIWYG display very closely matches PDF output. Dealing
> with PDF page breaks is a pain with Flare (as it is with Confluence,
> and probably with every other authoring tool that doesn't have a
> page-oriented WYSIWYG editor).
>
> FrameMaker can export change markup to comment-enabled PDF for review
> by people who don't have FrameMaker.
>
> WebWorks' web help looks better out of the box and is the easiest to
> customize of any authoring tool I've used.
>
> WebWorks support was very responsive and solved all my problems. (Most
> of my support calls to both Adobe and MadCap ended with bug reports or
> feature requests or them telling me it was a known bug. MadCap fixed
> some of my problems in the course of the year I was using Flare but
> the worst weren't fixed until I'd gone on to the next job.)
>
> When doing major updates or revisions I find it much more efficient to
> have all the content in one big file instead of one file per topic or
> few topics. Flare's granularity in that regard is my least favorite
> thing about it. If you're going to make me go to all that trouble, why
> not use a non-proprietary source format so I can mix and match tools?
>
> The search in Flare's web help is weak.
>
> The one big plus for me with Flare was having the source in XHTML. On
> the other hand, way too often I had to edit the XHTML to fix
> formatting problems that didn't respond to GUI commands. (I have the
> same kinds of problems with Confluence, by the way.)
>
> On Thu, Sep 26, 2013 at 11:41 AM, Shawn C <shawn -at- convergent -dot- io> wrote:
> >>Flare's usable but given free choice I'd use FrameMaker plus WebWorks.
> >
> > I'm curious Robert about your response. Why do you feel that FrameMaker
> and
> > WebWorks are a better choice for you.
>
--
Shawn Connelly
technical writer
<shawn -at- convergent -dot- io>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
New! Doc-to-Help 2013 features the industry's first HTML5 editor for authoring.