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+unsubscr...@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