Hi Pranav,
I doubt that we can modify the format- those changes are handled by OASIS
(http://opendocumentformat.org/, https://www.oasis-open.org/). But there are more experience people
around, and maybe your idea is being discussed as a future enhancement.
From the UX and RE point of view we have a large number of tickets regarding comments in Writer
(meta is tdf#106179). Users requests or have trouble with
* direct formatting (61242,62150,81458,89741,90401,102950,106149)
and styles (103064)
* threads and long comments (64181,91519,95759,106227)
* insert comments for objects (60976,86387)
* issues with the reference (64731,81018)
* search for/in comments (96474,101936)
* placement (86188, 97487)
* look and feel (38295,95329, 95759,97341,101714)
* accessibility (102950,106180)
* confusion with track changes (90725)
This list is likely not complete, and all the bugs are not listed. But a solution could start with
a separate deck for comments (tdf#106316). It would support a11y, allow normal threads in a tree,
supports quick access (which should be the fact today but the Navigator has serious limitations),
and could offer more interactions.
So far as a quick, though late (sorry) reply. If you want support by the design team we could make
a proposal of a future UI. Don't hesitate to ask.
Cheers,
Heiko
On 03/02/2017 11:38 AM, Pranav Kant wrote:
Hi all,
I have been looking into improving the comments support in LO, mainly
bringing the feature of marking comments as resolved[1], other things
being better root-reply comments relationship, ability to reply to
comments in spreadsheets and presentations.
I have done some research around comments in OOXML, ODF for text
documents, spreadsheets and presentations and there were couple of
changes I have in mind that we would need to make to ODF (introduce
LO extensions). Please let me know if there are any
concerns/thoughts/ideas that come to your mind.
Firstly, talking about proper root-reply comment relationship for
writer (because we support reply comments in writer only), the
current situation is that if you have a comment thread (one root and
several reply comments) and you put the visible cursor around the
anchor position and press enter or any other key, the comment thread
breaks (c.f [2]). This is because the current code assumes that
root-reply comments are the ones which have same anchor position.
This is wrong in my opinion, and doesn't just give rise to [2], but
also prevents starting another comment thread at same anchor position
which maybe be required in some situations.
To deal with it, my plan is to use 'office:name' attribute with each
and every <office:annotation> element corresponding to a comment. ODF
spec already allows a office:name attribute but currently, this
attribute is used only when the comment has a text range associated
with it. In addition to using office:name attribute, we would need to
introduce an attribute, say loext:parent-annotations-name, which
would point to their parent comments.
Changing the application logic from interpreting root-reply comment
relationship from anchor positions to interpreting it from their
explicit mapping with help of office:name,
loext:parent-annotation-name attribute should address all existing
problems as mentioned above.
We don't have any ability to reply to comments for spreadsheets and
presentations as of now, but the above approach would also help
whenever we would introduce reply comments in them.
Now talking about adding the ability to mark comments as resolved, an
attribute like, office:resolved='true/false' to each
<office:annotation> element should do.
An office:resolved=false will mean that comment is in opened state
and an office:resolved=true means that comment has been resolved.
Whenever a comment thread is marked as resolved, we would add a new
annotation with text '<comment resolution remarks>' with its
office:resolved='true'. Applications can find out if a comment thread
is resolved or not by just checking the office:resolved state of the
last comment in the thread. Reopening a comment would be possible by
just adding another annotation with office:resolved=false to our
annotation chain.
Summarizing, these are the LO extensions that we would end up with -
a) loext:annotation-parent-name attribute in <office:annotation>
element b) loext:resolved=true/false attribute in <office:annotation>
element
Let me know what you think.
[1] https://bugs.documentfoundation.org/show_bug.cgi?id=106126 [2]
https://bugs.documentfoundation.org/show_bug.cgi?id=106227
--
Dr. Heiko Tietze
UX Designer
Tel. +49 (0)179/1268509
--
To unsubscribe e-mail to: design+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Context
- [libreoffice-design] Re: Improving comments support · Heiko Tietze
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.