Flare as Frame Conversion Tool vs. Flare as Authoring Tool

[flarebrained]

Flare seems to be a robust authoring solution -- a good tool if you want to move your Frame docs into Flare and stay there (continue to author in Flare); however, it doesn't seem as ideal for authoring in Frame and importing into Flare on a regular basis. Some things don't seem as automatic as they should be, and there seems to be quite a bit of post-processing required once you get your Frame files into Flare. Thoughts?

I'm new to Flare, so it may be that I have a long way to go before I've mastered the conversion process. Does anyone here author in Frame and regularly convert to Flare nearly automatically (with minimal post-processing)? This is what we'd like to be able to do. Thanks.

[LTinker68]

The general thought is that you import your content into Flare and then work from there, without ever going back to Framemaker (or Word). The advantage is that you're now really single-sourcing your content -- you only edit in one place but you can output to multiple types of documents (print, web, etc.). You will still need FM installed on your machine so that you can generate PDFs from Flare, but other than that, the theory is that you wouldn't use FM again. Likewise, if you work in Word generally, then you import into Flare, continue working there, then only output to Word to distribute to the end user or to generate a PDF via Word (either using the built-in option in Word 2007 or using the Acrobat plug-in if you have it).

[NorthEast]

Just to start with, is there a reason you need to author in FM? If your authors only have FM and not Flare then so be it; but if you just need your content in FM for printing/PDFing, then you could always produce FM output from Flare. It's certainly worth investigating if that's an option for you. And if you just need it for making PDFs, then Blaze (and presumably the next Flare) will handle that.

I've spent a bit of time converting projects that were produced using FM/WebWorks. It was a one-way conversion, and I had to map the FM styles to a stylesheet I'd produced in Flare. We're currently only producing WebHelp output, but PDF is on the horizon.

I think my views are similar to yours. Flare is a great authoring tool, but I wouldn't necessarily use it to produce help directly from FM files.

You can use Flare to produce help direct from FM content (without post-processing), but I think your results will vary a lot depending on the templates/stylesheets that you're using. In my case, the style mapping options weren't comprehensive enough (e.g. no conversion of lists) to allow a full conversion without post-processing. However, if I was using a different stylesheet (and could use Flare's autonumbering), the process may have been a lot easier.

[sharon burton]

Flare can be used as a single sourcing tool, in that you import existing content from Word of Frame and then start working in Flare all the time. (of course, you can also just open Flare and start creating new content.) This is a good workflow for people who don't wish to use more than one tool to develop their content. It also works well for those who want to leverage the power of topic-based authoring in their workflow.

However, you can easily use Flare like WWP is used, in that you can develop content in Frame (or Word) and use Flare to create online help outputs, such as webhelp. This works well in other workflows; perhaps you have 1 person in your group who is the help guru and others have no time/interest in doing that. Of course, you can't really leverage the power of topic-based authoring in your workflow, but this may not be an issue for you.

I personally don't like the lists feature in Flare or Blaze. I'm a book designer and prefer to have more control over how my numbers and bullets look. I create autonumbered formats in my css for steps and bullets and use those instead of the lists feature. I'm not saying that one way is wrong, I'm saying I want more control than lists gives me. In my case, going from Flare to Frame is easier, because the lists are already autonumbered.

All this said, I also work with Flare 4/Blaze more than Flare 3. I don't have to output to Frame or Word to get PDF. And neither will you shortly.

Remember - you can participate in the Blaze beta and get essentially a sneak into Flare 4 by going to our website and signing up for the public Blaze beta.

And you can join us in the Importing FrameMaker files into Flare webinar by also going to our website and signing up. I added 2 more yesterday and will add another in August today. But sign up soon - they fill up very fast.

[SPearsall]

Once you are used to using FrameMaker, you don't really feel a compelling need to switch to a new authoring tool. You DO need a conversion tool that does a better job of creating online Help from FrameMaker files than RoboHelp does.
Familiarity with the tool is a good reason to keep using FM, which, you surely would admit, is powerful and feature-rich. But the best reason for using FrameMaker as the primary authoring tool in a single-sourcing solution is that FrameMaker produces a beautiful PDF from your text, based on your template, with minimal manual formatting tweaks. FrameMaker is the tool that God intended people to use to produce PDFs.
I probably feel the same way as the original poster here (flarebrained).
To sum up my current feelings about Flare: I was given a strong impression from a consultant at an Adobe conference and from MCF marketing that Flare integration with FrameMaker was well-nigh seamless. The term "linked" was used to describe the relationship between Flare and your source files. Since purchasing the software, I have been very disappointed with all the seams I've hit, particularly the following:
- several bugs, some horrible (thanks, Support, for providing a fix for the worst!)
- very little documentation about FM imports; no documentation about best practices
- difficult import process. Why is a whole new set of project subdirectories created during the initial import? Why do I have to spend 10 minutes clicking check boxes to accept the import? Why is a new stylesheet created for every reimport?

I do "get it," though. I'm SUPPOSED to use Flare as my primary authoring tool. I get that now. I did NOT get that before I purchased it. (Not saying I'm happy about it, but I do get it...)

[LTinker68]

I do "get it," though. I'm SUPPOSED to use Flare as my primary authoring tool. I get that now. I did NOT get that before I purchased it. (Not saying I'm happy about it, but I do get it...)

Have you signed up for the Blaze beta? All the stuff in Blaze will be included in Flare v4, but you can get the Blaze beta now and see how well it'll work as a replacement for FM, which is what it's more geared to do.

[GregStenhouse]

however, it doesn't seem as ideal for authoring in Frame and importing into Flare on a regular basis. Some things don't seem as automatic as they should be, and there seems to be quite a bit of post-processing required once you get your Frame files into Flare. Thoughts?

Once set up correctly*, I reckon the process is at least equal with other products (maybe even more automatic). If you turn on the option to "Auto-reimport before 'Generate output'", all you need to to is hit the "Build" button, grab a cup of coffee, come back to your desk and your updated CHM or whatever is sitting there.

* note: this takes a bit of time, setting up the stylesheet, starting with clean Frame files, setting up the TOC and helpIDs etc, testing for problems, fixing at the source or using workarounds, retesting. But it's worth investing the time up front to get it right, as it saves you with each build down the track. See the following "best practices" for some good tips (intended for Blaze, but also relevant for Flare 3.1)
http://madcapsoftware.files.wordpress.c ... raft41.pdf

If you have any problems or specific examples, post them here. Hopefully we can assist with any conversion problems to avoid future post-processing.

For example, it appears that Flare creates a copy of the stylesheet (so you end up with 2 or more) if:
1. you are linking to the project's own default stylesheet (in the Stylesheet tab)
2. you hit the reimport button

To avoid this, you can link to a stylesheet in a central location (e.g. C:\common), and before you hit "Reimport", clear out all files manually from
Content\[frame book name]
Resources\Stylesheets
Project\TOCs

Or, use the "Auto reimport" option which appears to clean all this out beforehand automatically.

Cheers
Greg

[RickHenkel]

We have around 25 authors producing over 10,000 pages in FrameMaker. Converting all those pages to Flare isn't an option for us right now, so I had to figure out how to use Flare as a Frame conversion tool. It took me several months to work out a process that requires nearly no work in Flare itself. We import the Frame files into Flare, set a few things minor things like the caption that appears in the WebHelp title bar, and let Flare process the output.

That said, the reason that our conversion requires nearly no work in Flare is because I've created a FrameScript script that I run on copies of my Frame files before I import into Flare. Among the many things that this script does are the following items:

* If processing a single FrameMaker file, creates a book file, adds the FrameMaker file to the book, and creates a TOC file

* Moves the table of contents to the beginning of the book file to correctly process the contents in Flare

* Sets page numbering throughout the book to consecutive Arabic to correctly process the contents in Flare

* Retags certain paragraphs to make them appear correctly in the contents

* Removes all conditions (Flare does not seem to retain the show/hide settings of FrameMaker conditions, so this part of the script removes all conditions set in FrameMaker, while maintaining the shown/hidden text, to avoid having the wrong text appear in Flare.)

* Converts all variables to text (Flare does not seem to convert variables in headings and does not add them to the table of contents. This part of the script converts all inserted variables to text while retaining the actual variable values that Flare uses for headers and footers.)

* Inserts all user variables at the end of the appropriate file so Flare can read them and use them in headers and footers

* Removes change bars

* Changes the width of certain table columns to make them better fit the width of the HTML page

* Removes ~ from paragraph tag names (Flare doesn't seem to correctly interpret special characters in tag names.)

* Processes acronyms to make the acronym pop-ups work correctly in Flare output

* Moves sidehead paragraphs down to follow the paragraph that they preceded

* Converts all soft returns to HTML code for line breaks to overcome a Flare bug that ignores soft returns

* Adds code for HTML links to open them in a new window (Without this code, HTML links open in the Document pane of the documentation file. This part of the script adds code that enables the user to click a link while maintaining his location in the documentation.)


Like I said, this took a lot of time and a lot of trial and error to prepare, but it has made our Frame-to-Flare conversion process very smooth and has allowed our writers to continue authoring in Frame. Plus, I have designed our stylesheets so that the output from our Frame-to-Flare guides is nearly identical to the new guides that we are authoring in Flare.