How should change tracking be implemented?

Have a problem? A question? This is the place for answers from other Express users.
JBL
Posts: 170
Joined: 2003-04-25 14:33:59

How should change tracking be implemented?

Post by JBL »

The main feature that forces me to use Word sometimes is tracking changes. People with whom I share documents insist on using this feature even though I beg them not to. I really really hate Word's implementation of this feature, so I am hoping that the good folks at Nisus can do them one better.

First let me say that Word 2004 is a lot better than Word X wrt to tracking. The primary improvement is that deletions now show up in their own little balloons like comments. You can thus quickly see what was deleted and accept or reject individual deletions. Unfortunately, in a very Microsoft like manner, insertions work completely differently. They get underlined in the document and then you have to control click on them and select accept or reject in a popup menu. This is slow and awkward at best, and often gets confusing because it is not clear what exact change you are accepting. Which brings me to my second complaint about tracking changes in Word, Word is really dumb about what constitutes a change. Typically I will get a document from some guy where there are a couple sentences he just couldn't figure out how to word. So he makes it passive, then he makes it active, then he makes it first person, then he corrects some spelling errors.... Word thinks these are all separate changes and I end up having to click accept a dozen times.

So here is my first pass idea for a change tracking interface. First, steal Word's balloons for deleted text. Then make similar balloons that show you the added text. Finally, aggregate all the changes on a single sentence into one change balloon (if a change consists of both additions and deletions, put the before and after text in the same balloon). If there are changes in adjacent sentences, aggregate those sentences into a single change. For changes that are very long, you could display the first dozen words or so with a box to expand the balloon.

What do you all think?
lmvincent
Posts: 1
Joined: 2006-04-17 07:30:55

No Baloons

Post by lmvincent »

I agree with you that MS Word's implementation of change tracking is cumbersome and bad design, but I can't stand those baloons. When I have docs with extensive markup, the baloons reduce the size of the printable area making text very hard to read.

I'm surprised no developer has come up with a simple utility to independently track changes between versions of documents -- and Nisus needs to make this feature a priority in the next release. A whole segment of the user base (e.g., attorneys) will stay away without this feature.
Bob Stern
Posts: 170
Joined: 2006-03-12 12:32:47

Document Comparison v. Change Tracking

Post by Bob Stern »

lmvincent wrote:I'm surprised no developer has come up with a simple utility to independently track changes between versions of documents -- and Nisus needs to make this feature a priority in the next release. A whole segment of the user base (e.g., attorneys) will stay away without this feature.
As an attorney, my 2 cents is that document comparison (between the current document and a specified earlier version) is more important than change tracking. Essentially everyone I exchange documents with uses MS Word for Windows, so a change tracking feature that requires all participants to use NWE would be useless.

The typical scenario would be: I send someone a NWE document in RTF format, they return a revision in DOC format, and then I'd import their DOC document into NWE and compare it with my original document.
cchapin
Posts: 424
Joined: 2004-02-25 18:28:40
Location: Nagoya, Japan

Post by cchapin »

I would go along with Bob. Rather than incorporating a change log in the document, I'd rather be able to compare versions. This gets around the difficulty of trying to be compatible with everyone else's change-tracking systems.

As for how to display differences, I'm content with old-fashioned redline and strikethrough rather than balloons, side-by-side views or what have you. I currently use redline and strikethrough character styles for marking up documents. This by itself doesn't reveal formatting differences, and it's not as glitzy as those awful balloons, so it might not satisfy everyone.

Almost as important as displaying version differences is a method for reviewing. There should be an easy way to navigate through the differences in a document and accept them, reject them or edit that part of the document. The few implementations of this that I've tried in other applications are frustrating, and I think Nisus could come up with a method that really shines.

--Craig
gemboy27
Posts: 355
Joined: 2003-09-30 21:33:58

concur

Post by gemboy27 »

I also agree, but I know a professor who would argue.

He likes to track changes so he can send it back to his students with those noted --- for him, teaching an on line course, this is better.

Me on the other foot, have people edit my work and the changes are so small, I want to know what they are --- a comparison would be great
I have never let my schooling interfere with my education/Mark Twain (1835-1910)
JBL
Posts: 170
Joined: 2003-04-25 14:33:59

Post by JBL »

A few comments.

First, I agree that a nice way of comparing two documents would be great! Although, if people are complaining that the balloons use up too much screen width, compare really works best if you can see the two versions side by side.

Second, I don't see why a better implementation of the track changes feature should be in compatible with Word. The problem with Word isn't the way it saves the changes; it is the way it displays them and the way you interact with them in order to accept or reject them. Nisus could encode changes into the file the same way Word does, just display them differently (much like styles).

Third, the reason I like the balloons is because they are much easier to accept or reject them. If someone could make the underline/strikethrough system as easy, that would be great.
cchapin
Posts: 424
Joined: 2004-02-25 18:28:40
Location: Nagoya, Japan

Post by cchapin »

JBL wrote:I don't see why a better implementation of the track changes feature should be incompatible with Word.
I assumed that Word's change tracking was saved in its binary format but not in RTF. That apparently is not the case, so I retract my objection to change-tracking. If it is implemented, though, I hope it will not be at the expense of a document comparison feature.

I'm still not crazy about the balloon idea, but perhaps a really good implementation could win me over. I do think there needs to be a convenient, intuitive way to navigate the changes in a document and to accept them, reject them or edit that portion. That's what my current method is missing.

Going back to JBL's earlier idea for packing all changes to a sentence into a single balloon--or whatever (the post that started this conversation), I like the simplicity of the idea, but for the way I work, it wouldn't be practical. Of the various changes to a sentence, I might accept some and reject others. For that control, I'll accept the bother of clicking multiple times.

--Craig
Ryan
Posts: 211
Joined: 2005-01-31 14:36:45
Location: Portland, OR
Contact:

Post by Ryan »

I call for both change-tracking and document comparison! Wish for both, eh?

The key is to keep it simple, intuitive, and unobtrusive. One idea instead of the balloons (*shudder*) is to use the styled text (underline or whatever) and have a small icon at the end of changed text for accept or reject. This would be fast and easy, but it wouldn't cover up large portions of the screen.
midwinter
Posts: 333
Joined: 2004-09-09 18:07:11
Location: Utah
Contact:

Post by midwinter »

Ryan wrote:I call for both change-tracking and document comparison! Wish for both, eh?

The key is to keep it simple, intuitive, and unobtrusive. One idea instead of the balloons (*shudder*) is to use the styled text (underline or whatever) and have a small icon at the end of changed text for accept or reject. This would be fast and easy, but it wouldn't cover up large portions of the screen.
That's actually an interesting idea... have a little indication of the text that's been changed and then a faded green check and a faded red circle with a white "X."
cchapin
Posts: 424
Joined: 2004-02-25 18:28:40
Location: Nagoya, Japan

Post by cchapin »

I like the simplicity of the inline buttons idea. The trick is in the implementation. Perhaps they could be shown or hidden at the user's discretion.

Another approach, not necessarily better, is a mark-up navigation palette with a few simple buttons: Next Edit, Previous Edit, Accept Edit, Reject Edit. I like this idea because some editing changes, especially those involving punctuation, are hard to spot. But I suppose inline buttons would draw attention to them.

As I mentioned earlier, I already use character styles for marking up documents with redlined and struck-through text. The tedious part of this method is removing the styles, so inline buttons or a palette for this would be welcome.

--Craig
midwinter
Posts: 333
Joined: 2004-09-09 18:07:11
Location: Utah
Contact:

Post by midwinter »

I'm thinking of something simple like this:

Image

Sorry for the crappy image. I'm most definitely not a graphics guy!
cchapin
Posts: 424
Joined: 2004-02-25 18:28:40
Location: Nagoya, Japan

Post by cchapin »

The image works fine. Thanks for creating it.

I thought you were proposing that the buttons appear inline, immediately following the modified text. Your proposal looks cleaner than what I imagined, but it runs into a problem when there are multiple edits on a single line. How would it look in those cases?

What do you think of the idea of a mark-up navigation palette like the one that I described earlier?

--Craig
midwinter
Posts: 333
Joined: 2004-09-09 18:07:11
Location: Utah
Contact:

Post by midwinter »

Surely no one would have more than one edit per line! ;)

Seriously, though. I suppose that there's no reason the buttons couldn't be placed adred the modified text or above it or shrunken and placed in the margins.
cchapin
Posts: 424
Joined: 2004-02-25 18:28:40
Location: Nagoya, Japan

Post by cchapin »

Since you gave us a helpful visual representation of your idea, here's a mock-up of a mark-up palette. (If you think yours was crude, this is even cruder.)

Image

From left to right, the buttons would do the following.

* Permit user to type redline text (or convert selected text to redline style)
* Convert selected text to strikethrough style (or permit user to type strikethrough text)
* Jump to previous mark-up
* Jump to next mark-up
* Accept the proposed edit (for redline, this would remove the redline format and leave the text; for strikethrough, this would delete the text)
* Reject the proposed edit (for redline, this would delete the text; for strikethrough, this would remove the strikethrough format)

In my mind the two rightmost buttons would apply to the entire contiguous string of redlined or struck-through text even if it were not all selected.

Any reactions? Obviously if the buttons need explanation, the palette isn't terribly intuitive. This is just an idea.

--Craig

P.S. -- You'd be surprised how many edits I can fit on one line!
midwinter
Posts: 333
Joined: 2004-09-09 18:07:11
Location: Utah
Contact:

Post by midwinter »

I kind of like that, although I think the buttons should be listed vertically rather than horizontally—one of the key benefits of the toolpane/palette approach is that you can maximize vertical space without compromising usability.
Post Reply