4

My team uses MadCap Flare for documentation and we have an editor on the team. When a writer is ready, we assemble a review package in Flare and send it to the editor, and she makes changes and sends it back to the writer for resolution. (The writer has the final say, and responsibility for making sure edits don't change the technical accuracy of the documentation.) The review bundle sent back to the writer contains marked-up changes similar to those in Word's "track changes" mode -- cross-outs for deletions, a different color for insertions, and annotations (call-outs) for other editor-to-writer communication.

That's all fine, but Flare requires that each change be individually accepted or rejected, and the problem we're having is that an edit for a single paragraph might produce a dozen individual changes, each of which needs to be handled. If you were to accidentally accept 11 of them and decline one, you'd have messed-up text because the changes are all related. We want atomic change groups -- accept all or none of these -- in this situation. (Flare does support "accept all" or "reject all" at the file level, but that's too coarse-grained.)

We've tried Google and we've got some pretty experienced Flare users on the team, and the best we've come up with, when a block of text requires many small edits, is to have the editor cut/paste the text into a new block, edit that, and then delete the original. But that's tedious if done all the time and hard to anticipate if making changes while editing. The editor shouldn't have to make two passes, one to read and then a second to go back and make changes either "inline" (if just a few) or by this more-elaborate cut/paste routine (if more extensive).

Is there a way to cause Flare to group a selected set of changes together to support atomicity? I envision the editor being able to mark all changes in a paragraph as being part of the same group, and the writer then being able to say "yes" or "no" to that group.

We are using a mix of version 9 and 10. If upgrading everybody to version 10 would help we can do that.

  • I know nothing about your specific issues, but maybe it's time to consider another tool. Just as one example, some people use git to manage documents (other than programs), and it allows all sorts of flexibility for handling revisions. I'm sure there are other tools as well. It also might be possible to combine more than one tool - do fine grain in git and then put the changes back into flare as one change, etc. – Joe Oct 1 '14 at 0:55
  • @Joe we can't change tools; this is what is used company-wide and there is an enormous installed base. We do use source-control too, but we use Flare's review system because the reviewer can work right there in the WYSIWYG editor, without committing any changes to the source tree until the writer then accepts or rejects the changes (at which point, source-control-wise, it's treated like any other edit). Most of this works pretty well, but we've found no good solution to this particular problem. Thanks for the input. – Monica Cellio Oct 1 '14 at 0:59
  • 1
    Version 11 is out, and includes Git support. I'd email them and ask what they recommend, perhaps even request atomicity as a feature if it isn't present. – rdtsc Jul 22 '15 at 12:24
1

This has nothing to do with the source control, so the GIT support in V11 and 12 is a red herring.

There is no better way of doing this, as of version 12 (April 2016). What you are doing and your work around are the only two ways I know of doing what you want.

In our group, we use Track Changes for the changes that we want the author to review. We don't use Track Changes for the changes that we have the authority to make without having the original writer re-review it. But this has the undesirable effect of requiring the editor to keep clicking the on/off button.

Your other option would be to only allow the reviewer to annotate the doc, rather than edit the doc, but that has other painful repercussions.

Finally, I will point out that in Flare 12, when you generate a PDF, Flare now has the option to print the track changes content and the comment bubbles in the PDF, so people can review the PDF file itself and see the tracked changes. I know this still doesn't directly answer the need in your question, but it is a cool new feature related to what we are talking about.

The best thing to do at this point is to submit a feature request on MadCap's website giving them an example and use case. They are pretty receptive to feedback.

  • 1
    Thanks. I think we did submit that feature request (sometime in 2014), but maybe it's time to poke it again. We're on Flare 11 now, with one person testing out 12 -- bummer to hear that 12 won't help us with this either. – Monica Cellio May 17 '16 at 3:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.