Who is using Xedit? and other questions...

[hjohnson]

Hi Folks,

We are experimenting with using Xedit in our review process and are encouraged, though not sold on it yet. I would like to pose a few questions and see if the forum has some experiences/insight/wisdom to share.

• Who in your company is using Xedit? Are they reviewers, content SMEs or other tech writers?
  Do all of your Xedit users also have Flare?
  Are all of your Xedit users in the same building/department, or in other locations?
  Do you have any Xedit users who had never used any Madcap products before, and what was the learning curve like?
  If you get the same topic back from two people with two different sets of changes, how do you reconcile those differences? Is there a way to do a "document compare" like in Word?

Other questions:

• Does anyone have reviewers who review content ONLY in Word?
  If so, what is your process flow like from sending the doc out from Flare, converting to Word, receiving edited content, and adapting the changes back into Flare?
  (Last one) If a reviewer sends a document back to you with changes AND change tracking turned on, can Flare convert those changes to annotations? I have not seen evidence of this yet.

Thanks in advance,

Helen@Block

[wclass]

We experimented a while ago and decided not to use X-Edit and continue out Word output/manual update process for reviews.

The main reason for not using X-Edit is that it works with a single topic at a time. When we write about a function it is usually made up of three or four separate topics, structured like this for easier single sourcing. I’d want the group of topics reviewed at the same time.

Our process ...
We generate to a Word document and send that to many non-Flare people for reviews. It comes back with some track changes, some comments, and some with the changes made directly and no highlights. I then review the reviews, using Word’s compare and merge features, and either accept or reject all the changes. Then I’d do a compare with the original document to find and highlight all the spots that need an update.

Making the updates to the original topics is manual. For small changes, like single words or punctuation, I’d make the changes in the topic directly. For large chunks of information, I’d import the Word document and then copy/move the information as needed.

While this does have a large manual component, I think I would review changes this closely anyway. The other problems I had with X-Edit when I tried it was that the changes were not easily seen (no tracking/highlighting) and you couldn’t accept or reject sections separately. For “in-team” reviews (5 in our tech writer team), we can all check out the project into Flare and make updates directly. Most of our SMEs/reviewers are in the same office, but there are a handful in our international offices (we are Melbourne Australia, and we work with US, Canada, UK, and several other places).

If you import a Word document that still has tracked changes, they will be mostly ignored by the Flare importer. Comments are ignored, and any new text added is ignored, but if you delete a word or two, they don't come through in an import. You have to accept or reject changes before importing.

[Cecily]

I've given up on it too, because

• You can't set Revision Marks (or similar), so reviewers either have to use Comments for everything (ludicrous) or correct it in situ (so you can't see what's changed)
• There is no Compare function to see differences between the reviewed and the source
• If you accept the reviewed version and then edit it, you can't easily go back to see what the original reviewed version looked like
• Each topic has to be sent as a separate file
• You can't send the TOC to show how the topics relate to each other

A good concept, but it has a long way to go.

[forfear]

Maybe if it was integrated with something like Google Wave....

[Carsten Pedersen]

Yes we tried it too, in our company, and is not using it for all the same reasons.

You should offcause be able to:

• Review the whole project not just on topics basis.
• Integration with topic status.
• Compare versions from different reviewers.

-cpede

[CJWyckoff]

Ditto on all reasons for not using XEdit. We are using primarily editable PDFs and Word docs for technical reviews.
The other issue our technical review personnel has is that they have to load and learn another piece of software. They won't do that unless we can sell them on the benefits of it, which, as of now, we can't.