Apache OpenOffice (AOO) Bugzilla – Issue 86155
Record Changes: tabular change list makes editorial approvals impossible
Last modified: 2014-03-17 10:53:19 UTC
Thanks very much for your Write application (used in Ubuntu). It nearly satisfies our need for a professional word processor. Unfortunately, one aspect, Edit/Changes/Record is not functionally adequate to allow us to convert over from Microsoft Word (even Word '97) for use in copy-editing documents for consumer publications. In MSWord, changes can be accepted or rejected by clicking on the change in the text and making the choice in a "Track Changes Toolbar". The potential change is seen in the actual document text while the decision is being made to accept it. On the other hand, in OpenOffice Writer 2.3, changes can only be accepted or rejected from a simple consecutive list of all edits. This list does not show the actual edit copy itself. Only the date of the edit entry is shown. In a document with hundreds of changes (like a book or even a detailed magazine article) it is impossible to find a proposed change by looking at the list -- one would have to know the dates of each proposed change. While it is true that if you select (highlight) one anonymous list entry, the working document window scrolls to the location of the selected change, this still means that a user must click blindly in a long list to gradually narrow down the choices and locate a section of interest. In normal editing, the document is the focus, not a list of changes, and an editor wants to proceed by reading the document and making yes/no choices as the reading progresses. MSWord allows this simple functionality. As a change is read, clicking on it allows acceptance or rejection of that change. This is a normal intuitive functionality and focus does not have to be shifted to a list. There is no need to hunt through a numerical dated list to relate it to the document. Because not every change in a document is acted upon, and because some changes are physically located far from preceding ones, it is not possible to keep the list synchronized (mentally) with the editor's position in a reading. An editor may also jump around a document editing a few key sections out of order. A sequential list of changes naturally cannot be synchronized with this kind of necessary activity. In a recent (and to us disheartening) change in the commercial publishing world, more and more of the print publications we deal with are REQUIRING that freelancers use Microsoft Word for submitting and editing manuscripts. They no longer accept .doc documents prepared or edited in another program. Once that becomes policy at an organization it is extremely difficult to reverse it. We believe this may be partly due to unfamiliar and problematic "track changes" (Edit/Changes/Record) experiences at the publication with Open Office Write. All commercial editing is essentially collaborative, and these particular tools need to be intuitive and in fact equivalent to the MSWord methodology, or Open Office will be effectively banned in this industry. We hope that the otherwise excellent OpenOffice Writer's change tracking interface can be improved in this one area. It would make OpenOffice suitable for group editing in a professional publications setting, and allow us and many others to make the move away from Microsoft products. Thanks very much for your consideration. Steve freelance technical writer Cheryl freelance food writer and copy editor
We are aware of the problems. See also issue 9661, issue 6191, issue 24585 and issue 69906 e.g. *** This issue has been marked as a duplicate of 24585 ***
closing duplicate.
This is NOT a duplicate of Issue 24585. That issue merely requests a change in the toolbar menu. That would absolutely NOT satisfy the problems we have outlined in this issue. It is also NOT a duplicate of issues requesting a location of "comments" to the margin in a balloon. ----- It is not about editorial comments feature in MSWord, which are different than editorial changes. This issue requests a change to the Open Office > method for reviewing (and accepting or rejecting) prior recorded edits. < To reiterate, the MSWord method allows locating these recorded edits visually, inline, during a read, clicking on them inline, and accepting or rejecting them. This a natural and normal way to review an already edited document, and accept or reject proposed changes. The editor normally does a read-through of a paper document in this way. It allows either skipping around the document, or reading it sequentially with a What-You-See-Is-What-Is-Proposed-For-Change immediate recognition and approval functionality. Open Office uses a completely different non-intuitive and difficult methodology involving table of edits that is totally separate from the document itself (like an Undo list in a CAD program) arranged by date. This table does not indicate where in the document any particular edit is. Clicking on one edit in this table at random, autoscrolls the document to that edit. That is the only connection between the two, and the only way to find an edit for approval. This is completely backwards from normal editing procedure, and a useless method of reviewing and accepting or rejecting edits in a read-through. The document is subserviant to the table of edits. The table of edits moves the document around. A total inversion of a user's priority. An editor does not want to leave the document, take a stab at an irrelevant historical list of edits, and experiment to see where it scrolls the document to, so that he or she can narrow down the possibilities through subsequent entry trials, hit or miss, until the "right" entry is found. An editor wants to read the document, see the change in it, (usually made by someone else, since there are many people involved in any professional publictaion -- authors, copy editors, proofreaders, fact checkers, etc) click on that change to accept or reject it. Done. In this case, Microsoft has it right, and it is a standard expectation. Wish it was otherwise, but editors don't mess around with software functionality issues. If Open Office Write complicates their job (and in this case it makes it impossible), they will not only refuse to use it, they will ban documents created by it from their publication for internal use and freelancers alike.Even if the (.doc) document itself does not carry the functionality (the editing program does that). As copy editors and writers, we have already experienced this personally. In some cases we are not allowed now to use it even for initial copy, by decree, from the publisher. It is critical that this be addressed before wider use of these editorial bans makes it impossble to use Open Office professionally. I am very much a supporter of open software, and have contributed financially, assisted with documentation, and also assisted users with issues in forums. Open Office has made an invaluable contribution to the movment and advanced the wider acceptance of many open operating systems. I would hate to see this acceptance stifled by he publishing industry over an addressable issue like this. I hope you will re-consider lumping this issue with the others. It would certainly not be satisfied by merely changing a menu. Thanks.
Title change to make the specific issue clearer. Thanks.
Reassigned to requirements.
I completely agree; unlike for example the "Styles and Formatting" pop-up, there is no communication between the document and the list of changes. I want more than that, but simply clicking somewhere in the text and having the "Accept or Reject" pop-up reflect which change you've selected would already help this issue a lot. In MS Word there are two ways -that I use, there might be more- to accept changes. Namely the track changes toolbar, where you can click accept or reject when you've clicked on a change, and the text itself, on which you can right click and also choose whether to accept or reject. The main issue here is one-way communication from the dialog to the document; this needs to be two-way communication, but something more Word-like could also make this more user-friendly.
P.S. This issue persists in OOo 3.0.
I support this request. This is the last _big_ drawback that keeps me from consequently using OOo! For private purposes it has become fully equivalent to me, but for work, I simply cannot use it: We're regularly 3 or more people contributing to one document, so the changes functionality is crucial. If OOo wants to win big companies, public administrations etc., it MUST improve here. Thanks to everyone who participates in improving this!
Confirmed with AOO410m14(Build:9760) - Rev. 1573062 2014-03-01_04:11:01 - Rev. 1573123 Debian