Improving comments support

Sat Mar 4 23:02:13 UTC 2017

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20170305/ba92002d/attachment.sig>