User Comments on Documents

[Andy001]

We use Flare to produce web help documents. These are used in remote locations with no internet access. Our users would like to make an annotation or comment on their Flare document - with feedback when they return 1 month later. I understand they could use any htm editor to make the change but, that would cause loss of configuration control of the document. How can they make and save comments?

[RamonS]

One way is to create a Word document and pass one copy out to each of the remote users and have them make the changes in there with track changes enabled. The problem is that without any connectivity whatsoever using a common tool of any kind is not an option. So after the month you'd get a bunch of Word documents back and would need to make the changes manually. Of course, you will get cases where you need to consolidate 5 change requests for the same thing, but that would happen anyway.

[KevinDAmery]

Depending on the budget you have available, you could also look into Madcap's Feedback Server / Service.

[LTinker68]

Depending on the budget you have available, you could also look into Madcap's Feedback Server / Service.

I'm not sure how well that would work without an active Internet connection.

[KevinDAmery]

True. I'm not clear exactly how the updates are intended to get sent back in that case--regardless of what method is used for the users to add their comments, at some point the have to be transmitted in some way or other.

[Richard Ferrell]

With Feedback Server and Service they would need to have access to the internet, or at least access via thier local network to a feedback server.

[LTinker68]

Might be a feature request to allow for comments and ratings to be saved in a local queue and then submitted all at once the next time the user connects to the Internet. Kind of like you can compose email in Outlook and wait to send it.

You might be able to use the X-Edit software that's in pre-release (http://www.madcapsoftware.com/products/xedit/), although I'm not sure how well that works with compiled output. It sounds like it's more for as the project is being written, although an .htm file is still a .htm file, so it might work. You can always sign up for the beta and see if it'll work for your situation.

[Andy001]

Thanks all, I'd like to change the description of what the user is looking for:

They would like to make a "redline" correction that would stay persistant in their copy of the document until they got back to us and we could incoroprate the mark-up in to the next revision.

[RamonS]

....which is about what I proposed, just by using Word.

[peregrine]

Another option you might look at is to use Adobe Acrobat's review tools. If you have the full version of Acrobat, your users can use the Reader to add comments to a PDF file. The advantage for you is that the process of merging comments back into a master PDF from several readers' PDFs is easy (and easier to read IMO than Word markup). The advantage for your users is that it's far easier to tell apart the original text from their comments and changes. If any of your users has the full version of Acrobat, they can merge comments on their side and share a "master" PDF that has all their individual changes in it.

[RamonS]

There are also viable alternatives to a full Adobe application. FoxIt makes tools that can edit PDFs and those cost a fraction of what Adobe wants.

[Andrew]

I understand they could use any htm editor to make the change but, that would cause loss of configuration control of the document.

Can you explain what you mean by "loss of configuration control"? It seems to me that Dreamweaver (or one of countless other products) would serve the need perfectly -- you could even create a CSS style (which you do not use) for them to use for all user comments, and that would enable you to fairly easily find their comments when the occasion arises.

Others have suggested using Word or PDF...but if the "hypertextuality" of a WebHelp/HTML Help document is valuable, then I see Word or PDF as a compromise I would be hesitant to make.

[RamonS]

I guess what was meant is the fact that an XHTML editor does not typically have track changes or version control as a feature. I do not know how savvy the users are that will make the comments in regards to retaining strict XHTML or style compliance. My experience (and the same was reported by many others) is that subject matter experts are just that experts on the subject matter, but not technical writers who are skilled in designing printable or webable documentation. That is why most recommendations are proposing to use some sort of other format that is not likely to cause chaos and destruction to your source documents.
Furthermore, the proposals assume that one wants to make use of common and/or inexpensive tools. Sure, you could give each user Dreamweaver and instruct them to add comments using a special style, but that means buying a full Dreamweaver license for each of them and giving them some sort of training unless they are already accustomed to using Dreamweaver (and my guess here is that giving each of them Flare will be cheaper and do the same trick). Even if you use Dreamweaver and a special style, you will still need to incorporate these changes in Flare manually since you will get several edited files back.
I'd use a Word document and use track changes, use PDF with annotation enabled, or give them a PDF that has page and line numbers and tell them to use a spreadsheet to mark page and line and the proposed change.

[Andrew]

I wasn't criticizing your solution, RamonS; a Word document would work just fine if the "hypertextuality" isn't a significant issue. Given that Andy001 was starting with WebHelp, I assumed a narrative document was not how the document was organized, and that perhaps a Word or PDF document would not be the best solution.

As for using an HTML editor:

1) I threw out Dreamweaver as the most commonly-known program, and one that I know is fairly easy-to-use for simple edits. There are so many editors out there (several free) I couldn't possibly list them.

2) There is no problem with chaos or destruction in source documents; the users are editing the output files, rather than the source files.

3) Depending on your users' HTML savvy, this may or may not work. If they don't have someone in IT or some kind of person with a passing familiarity with HTML, this solution is untenable.

(On a side note -- unless the annotation capability of PDF has *dramatically* improved over the past few years -- or it has capabilities I am unaware of -- it's nearly worthless for revision comments or changes unless you buy one of the expensive versions, and then it is only marginally better.)