[Libreoffice-ux-advise] [Bug 95357] TRACK CHANGES: Change tracking movement/ action are inconsistent for replacements

https://bugs.documentfoundation.org/show_bug.cgi?id=95357

Heiko Tietze <tietze.heiko@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needsUXEval                 |
             Status|NEEDINFO                    |NEW
           Severity|minor                       |normal

--- Comment #11 from Heiko Tietze <tietze.heiko@gmail.com> ---
(In reply to Björn Michaelsen from comment #6)
> a/ using next change jumps first to the dog -> lamb replacement, then to the
> truck -> farm replacement, then to the there -> here replacement.
> b/ accepting the changes works consistent with a/
> c/ rejecting a change, rejects the deletion (dog), but does _NOT_ reject the
> addition (lamb). Movement is consistent with a/ and b/ though.
> d/ moving backwards through changes walks over every tracked change
> separately: so each deletion and insertion is handled individually. This is
> consistent with the rejection in c/ but not consistent with the movement in
> c/, nor with the behaviour in a/ and b/
>
> Adding needsUXEval: We need some input on the desired handling of
> replacements: Should they be handled like one action as per a/ and b/ or as
> a insertion and a separate deletion as per d/? Keeping this in NEEDINFO
> until UX has an answer.

The problem is that a change is done with two modifications, delete and add.
When I replace McDonald by Trump it adds two entries to the list of changes in
the sidebar. The same is true for MS Word where also both operations are shown
separately in the sidebar, and I can also accept the deletion but reject the
addition. (Deletion is visualized like a comment and the addition inline when
the sidebar with all changes is not open.)

Ideally we flag this as _override_ additionally to the pure add and delete.
When the user selects a word/paragraph and enters text the change is treated as
override and accept/reject are applied at once as expected in this ticket. When
the word is deleted first and the replacement added as a follow-up, these steps
are done separately and should be stored as such.

If this is not possible I'd rather keep the current behavior because a) it
works the same in other word processors, and b) it's safer to click twice.

-- 
You are receiving this mail because:
You are on the CC list for the bug.