E
Elliott Roper
I have just come back from giving 2004 track changes an initial tyre
kicking.
It could not possibly have been worse than v.X, so count that as a
plus, but there are still a few things wrong. Mostly with comments and
keyboard navigation thereof.
As is my normal practice, I assigned keyboard shortcuts. cmd-opt-a to
add a comment and ctrl-n and crtl-p for next and previous
comment/correction. You need that to follow that descriptions below.
Grumble 1. The comment reference is bizarrely anchored. If I type
cmd-opt-a to create a comment, type the comment, hit escape to
terminate comment editing and go on typing in the body of the document,
the comment anchor is pushed along with the typing. That is, the
insertion point is returned to a mysterious point in the body, after
the last character I typed, but *before* the comment anchor. As a
work-around, I have to hit a right arrow after escaping out of the
balloon, which does nothing to the insertion point, but does leave the
reference to the comment where I first placed it. Surely that is a bug?
Grumble 2. Navigating comments forward and back behaves differently. If
I have a stack of balloons, cmd-down moves the insertion point from
wherever I am in one comment balloon to the beginning of the text in
the next balloon. Cmd-up takes me to the beginning of the text in the
current balloon and sticks there. Surely one or other of those is a
bug?
Grumble 3. Edit comment is greyed out unless I navigate to an area of
text delimted by left and right comment brackets by a method other than
'next comment' - either button or keyboard shortcut. (That *is* picky,
since I wouldn't hit edit comment in a pink fit, I'd already have the
cursor in the wrong part of the comment and be fixing that up by going
to the next one and back again on the keyboard. Yes folks, edit comment
goes to the end of the comment, but ctrl-n and ctrl-p go to the
beginning of the comment text. Who needs consistency? It's wildly
over-rated)
Grumble 4. The reviewing pane has no way of indicating where the
comment anchor is. With or without balloons. The balloon does not
darken. The balloon's dotted line does not go solid. Nothing. See also
Grumble 10.
Grumble 5. Text deletion in the preview pane is not replicated in the
balloon till you make a second mouse click in the body of the document.
Grumble 6. With balloons off, ctrl-n wakes up the reviewing pane and
places the insertion point in the reviewing pane. Not only is there no
indication of the comment's anchor point in the body, the reviewing
pane is happy to occlude the point even if there were.
Grumble 7. With all the 'show' items turned off in the reviewing
toolbar, hitting ctrl-n does nothing but bring up an unhelpful alert
telling you that everything is hidden. Cancel or cop the lot are your
choices. Why can't it behave like a hovered balloon?
Grumble 8. You can't get a hover balloon to work unless you have both
left and right comment braces. Why oh why do you have to go to so much
trouble to insert a comment? i.e shift-opt-left to highlight a word
before hitting cmd-opt-a. Else you can't hover over it.
Grumble 9. Then, if you have balloons disabled, the great ugly
reviewing pane obscures your work. Not that it matters, it is doing its
best to hide where the comment came from any way it can. Escape does
not terminate editing that comment, as it would have with balloons
enabled. Instead, I had to assign a special keystroke to toggle the
reviewing pane back off again.
Grumble 10. To further ensure that the reviewing pane does not help you
find what the comment was referring to, when you turn the pane off,
your insertion point goes back to the place it was when you first
entered the pane, no matter how many comments you visited in the
meantime. This differs from balloons on, where the escape takes you out
to the current comment's reference.
Plaintive Grumble 11. Is there any way to make the text in the
reviewing pane smaller, the headings smaller and losing all that garish
stripiness? This is a *Macintosh* we are talking about here. We don't
do garish!
Maybe I deserve a curmudgeon of the week award for this post, but I do
hope it will be useful in making the product better one day. Currently
it is wildly inconsistent, and bu^h^h not at all nice to look at.
kicking.
It could not possibly have been worse than v.X, so count that as a
plus, but there are still a few things wrong. Mostly with comments and
keyboard navigation thereof.
As is my normal practice, I assigned keyboard shortcuts. cmd-opt-a to
add a comment and ctrl-n and crtl-p for next and previous
comment/correction. You need that to follow that descriptions below.
Grumble 1. The comment reference is bizarrely anchored. If I type
cmd-opt-a to create a comment, type the comment, hit escape to
terminate comment editing and go on typing in the body of the document,
the comment anchor is pushed along with the typing. That is, the
insertion point is returned to a mysterious point in the body, after
the last character I typed, but *before* the comment anchor. As a
work-around, I have to hit a right arrow after escaping out of the
balloon, which does nothing to the insertion point, but does leave the
reference to the comment where I first placed it. Surely that is a bug?
Grumble 2. Navigating comments forward and back behaves differently. If
I have a stack of balloons, cmd-down moves the insertion point from
wherever I am in one comment balloon to the beginning of the text in
the next balloon. Cmd-up takes me to the beginning of the text in the
current balloon and sticks there. Surely one or other of those is a
bug?
Grumble 3. Edit comment is greyed out unless I navigate to an area of
text delimted by left and right comment brackets by a method other than
'next comment' - either button or keyboard shortcut. (That *is* picky,
since I wouldn't hit edit comment in a pink fit, I'd already have the
cursor in the wrong part of the comment and be fixing that up by going
to the next one and back again on the keyboard. Yes folks, edit comment
goes to the end of the comment, but ctrl-n and ctrl-p go to the
beginning of the comment text. Who needs consistency? It's wildly
over-rated)
Grumble 4. The reviewing pane has no way of indicating where the
comment anchor is. With or without balloons. The balloon does not
darken. The balloon's dotted line does not go solid. Nothing. See also
Grumble 10.
Grumble 5. Text deletion in the preview pane is not replicated in the
balloon till you make a second mouse click in the body of the document.
Grumble 6. With balloons off, ctrl-n wakes up the reviewing pane and
places the insertion point in the reviewing pane. Not only is there no
indication of the comment's anchor point in the body, the reviewing
pane is happy to occlude the point even if there were.
Grumble 7. With all the 'show' items turned off in the reviewing
toolbar, hitting ctrl-n does nothing but bring up an unhelpful alert
telling you that everything is hidden. Cancel or cop the lot are your
choices. Why can't it behave like a hovered balloon?
Grumble 8. You can't get a hover balloon to work unless you have both
left and right comment braces. Why oh why do you have to go to so much
trouble to insert a comment? i.e shift-opt-left to highlight a word
before hitting cmd-opt-a. Else you can't hover over it.
Grumble 9. Then, if you have balloons disabled, the great ugly
reviewing pane obscures your work. Not that it matters, it is doing its
best to hide where the comment came from any way it can. Escape does
not terminate editing that comment, as it would have with balloons
enabled. Instead, I had to assign a special keystroke to toggle the
reviewing pane back off again.
Grumble 10. To further ensure that the reviewing pane does not help you
find what the comment was referring to, when you turn the pane off,
your insertion point goes back to the place it was when you first
entered the pane, no matter how many comments you visited in the
meantime. This differs from balloons on, where the escape takes you out
to the current comment's reference.
Plaintive Grumble 11. Is there any way to make the text in the
reviewing pane smaller, the headings smaller and losing all that garish
stripiness? This is a *Macintosh* we are talking about here. We don't
do garish!
Maybe I deserve a curmudgeon of the week award for this post, but I do
hope it will be useful in making the product better one day. Currently
it is wildly inconsistent, and bu^h^h not at all nice to look at.