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
Attachment:
signature.asc
Description: OpenPGP digital signature