Bug 106316 - New sidebar deck for comments
Summary: New sidebar deck for comments
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL: https://design.blog.documentfoundatio...
Whiteboard:
Keywords:
: 158647 (view as bug list)
Depends on:
Blocks: Sidebar-New-Decks Writer-Comments
  Show dependency treegraph
 
Reported: 2017-03-04 13:53 UTC by andreas_k
Modified: 2024-02-11 18:51 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
wider comment sidebar (151.77 KB, image/png)
2023-12-17 05:52 UTC, Jim Raykowski
Details
screenshot of the 2 Overleaf review pane modes (946.20 KB, image/png)
2023-12-18 11:47 UTC, Stéphane Guillou (stragu)
Details
Screenshot MSO / GDocs (334.15 KB, image/png)
2023-12-19 10:53 UTC, Heiko Tietze
Details
Mockup (35.02 KB, image/png)
2023-12-19 10:54 UTC, Heiko Tietze
Details
Writer comment pane (428.34 KB, image/jpeg)
2024-01-29 17:47 UTC, Bdac
Details
Writer sidebar deck (569.74 KB, image/jpeg)
2024-01-31 13:44 UTC, Bdac
Details

Note You need to log in before you can comment on or make changes to this bug.
Description andreas_k 2017-03-04 13:53:28 UTC
The Sidebar in writer has the tab Manage changes where you see the changes. As Comments are also some kind of Review Information, please add the Comments also in the sidebar.
Comment 1 Heiko Tietze 2017-03-04 20:56:10 UTC
The idea was discussed a couple of times, e.g. in bug 101714, but apparently never filed as an extra ticket.
Comment 2 Yousuf Philips (jay) (retired) 2017-04-24 10:15:14 UTC
Heiko has already suggested that comments go into the revised Navigator (103030), and comparing the conversion of a dialog into a sidebar deck is completely different from comparing always visible items in a document and putting them in a deck.
Comment 3 Heiko Tietze 2023-12-12 14:23:44 UTC
*** Bug 158647 has been marked as a duplicate of this bug. ***
Comment 4 Rafael Lima 2023-12-12 14:42:39 UTC
I have been planning to file a similar feature request for some time... and then I came across bug 158647, which had a similar aim.

I believe we should restart this discussion, because I firmly believe a Comments pane is needed in LibreOffice. This is not just to navigate comments, but rather to view/edit/remove comments, reply to comments, resolve comments, etc.

Competitors as MS Word and OnlyOffice already offer such feature (see attachment 191371 [details] from bug 158647). And as a user, I really miss this feature, because managing comments in Writer is not great, mainly when the documents has many comments (as in a dissertation, or a scientific paper).

My suggestion is to change this to UNCONFIRMED and further discuss this topic.
Comment 5 V Stuart Foote 2023-12-12 18:08:29 UTC
I think in addition to current exposure on the Navigator deck, that addition of a 'Comments' content panel to the 'Manage Changes' deck would support some collaborative work flows beyond current change tracking.

From bug 158647 --

(In reply to Heiko Tietze from comment https://bugs.documentfoundation.org/show_bug.cgi?id=158647#c6)
> What exactly makes it necessary to have comments in an extra deck?


A "Comments deck" makes it a lot easier to manage comments in a document. To understand that, think from the perspective of someone who adds maybe 100+ comments to a document, then send it to a student/collaborator. And later receive the document back for further review.

In this scenario, it becomes relevant to:
1) Sort comments by date, author
2) Filter comments by content, by reply status
3) Edit comments and reply to them in the "document pane" itself (see attached image; the UI fits much more text and to me is more convenient to use)
4) Mark comments as resolved or delete them
5) View only resolved/unresolved comments
6) Etc...

In summary, a Comments pane would allow to manage comments and is focused on users who heavily comment and collaborate while developing documents.
Comment 6 Heiko Tietze 2023-12-13 08:01:04 UTC
(In reply to V Stuart Foote from comment #5)
> 1) Sort comments by date, author
Does it make any sense to work on comments detached from the document? If you sort this is what happens.

> 2) Filter comments by content, by reply status
> 5) View only resolved/unresolved comments
I could imagine this with the comment in the margin too.

> 3) Edit comments and reply to them in the "document pane" itself (see
> attached image; the UI fits much more text and to me is more convenient to
> use)
> 4) Mark comments as resolved or delete them
What is easier when working in the sidebar?


I'm not against sidebar panes in general. But it seems to me that we wont produce a killer feature by just moving the comments from the margin into a sidebar deck. Given that you comment and work on the document with change tracking on, the two decks make you continuously switching.
Comment 7 J22Gim 2023-12-16 10:35:29 UTC
Personally I prefer to have a pane laying on the bottom (ie, horizontal) to be able to full use all the available screen width. But probably the best would be to make it flexible so the user could just place and resize, right?
Comment 8 V Stuart Foote 2023-12-16 13:27:59 UTC
(In reply to Heiko Tietze from comment #6)
Again from bug 158647 where J22Gim wrote

<snip>
...

The functionality being suggested is not to navigate through the comments but to comfortably work with them (mostly reply to them) in a space that is not constrained by the margins.

The pop-up functionality may be useful only for the visibility of the comment, but it does not bring any benefit to the management of comments as a Review Pane (where you can easily go back and forth between the comment, your reply, other comments, other replies, etc).

Maybe it is worth mentioning why this is very important (and other office suites have noted) and might not be immediately evident. In 'normal' academic writing (eg. scientific articles), one of the keystones is the review process. This process consists of a number of people ('reviewers') adding comments to your text, asking for clarifications, suggesting different things, etc. Addressing those comments is a whole task itself. It is not just "navigate, then accept/reject" as in 'Track changes'. It requires that you thoughtfully consider all the comments, and the reply in a organized fashion where the final (new) manuscript has to make sense and be an improved version. It is not uncommon that this process of 'reviewing' is equivalent (in terms of amount of work) to generating a new manuscript (hopefully better than the previous one, and taking into account all comments). Some comments include quite a few previous statements to situate the reader on where the comment is going to. Sometimes comments from different reviewers are contradictory (and many times there are not written successively). So the person that has to manage all the comments really needs a dedicated space as the Reviewing Pane (or comments panel, whatever name is finally decided). It is very different from GIT-like workflow where you change some lines and then can see clearly what the changes are and decide if accept or not. It is like writing the whole software every time with new user requirements!.

...
</snip>
Comment 9 V Stuart Foote 2023-12-16 13:56:45 UTC
(In reply to Heiko Tietze from comment #6)
> 
> I'm not against sidebar panes in general. But it seems to me that we wont
> produce a killer feature by just moving the comments from the margin into a
> sidebar deck. Given that you comment and work on the document with change
> tracking on, the two decks make you continuously switching.

Could be any UI, i.e. Using the SB deck framework for a content panel, a docked TB, or a floating dialog -- any are viable UI for what would be a new Comments workflow as noted. 

All would need to link with current SB Navigator's Comments objects, and the SB Manage Changes objects, so implementing as an additional content panel on the Manage Changes deck seems appropriate. Especially given Jim R.'s work on content folding and style visualizing for the Navigator panels, expect those would be useful widgets for building a Comments panel.

@Jim, Justin what would you envision for handling an interconnected comments comment workflow?
Comment 10 Jim Raykowski 2023-12-17 05:52:39 UTC
Created attachment 191464 [details]
wider comment sidebar

Would making the comment sidebar wider help?

The attached screen shot was made with the number 1.8 in the line of code shown here[1] changed to 4.0.

[1] https://opengrok.libreoffice.org/xref/core/sw/source/uibase/docvw/PostItMgr.cxx?r=950bee91#2167
Comment 11 V Stuart Foote 2023-12-17 14:44:23 UTC
(In reply to Jim Raykowski from comment #10)
> Created attachment 191464 [details]
> wider comment sidebar
> 
> Would making the comment sidebar wider help?
> 

Sure a (selectively?) wider margin when showing the "PostIt" style comments helps a lot for readability, and the PostIt offer advantage of visual "bread crumbs" pointing back to the insertion on page, sheet or canvas.  Current state of things as in Help [1]. 

Unfortunately activating a docked SB deck already eats in to visible width of the margin (so SB decks need to be undocked to be useful for collaboration, like to use Navigator <F5> with Stylist <F11>, ie bug 73151 and bug 85905).

Comment exposure on the SB currently is limited to the Navigator deck where the first sentence of the comment is listed--visually in document ordering. All comments, with no ability to filter (by entry sequence, date, or author). 

Likewise the context menu actions available to Comments from the Navigator differ from those of the PostIt, forcing you to close the SB and 'Edit' or 'GoTo' the insertion point.

So the on document collaborative workflow is awkward moving between Navigator, canvas and PostIt. And PostIt's alone are unmanageable with more than a couple authors or a dozen comments. 

Why a SB content panel or floating dialog panel seems appropriate. And if combined with change tracking, collaborative comments should be available while the manage changes SB content panel is visible.

=-ref-=
[1] https://help.libreoffice.org/latest/en-US/text/shared/01/04050000.html?DbPAR=SHARED#bm_id3154100
Comment 12 Stéphane Guillou (stragu) 2023-12-18 11:47:52 UTC
Created attachment 191483 [details]
screenshot of the 2 Overleaf review pane modes

Some inspiration for a "Review" sidebar deck, which could be a merge of the current "Manage changes" and the envisaged "Comments" deck. (So we don't end up with too many decks, and because I think it would make for a more comfortable reviewing process.)

Overleaf has a Review pane which includes comments and changes (if they are tracked).
It offers two views:
- "Current file": tracked changes and comments are placed next to their anchor
- "Overview": tracked changes and comments are displayed in a more compact way, no space between them, and clicking them jumps to the corresponding position on document.

We could have something similar, in which comments can be replied to, marked as resolved... and changes can be approved or rejected. With an option to only show comments or changes.
I think a sort option would be useful too: spatial vs temporal.
Comment 13 Heiko Tietze 2023-12-19 10:53:33 UTC
Created attachment 191500 [details]
Screenshot MSO / GDocs

For WPS see https://www.wps.com/academy/how-to-use-the-review-feature/1862185/

I still struggle with the advantage of the sidebar over space in the document. You need to read the text anyway.

The requirements are basically
* add, edit, delete comments
* show threads
* filter by time and author
* mark as resolved
* temporarily hide?

* protect to edit, delete, (add) -> probably not at the review pane

Anything missing?
Comment 14 Heiko Tietze 2023-12-19 10:54:56 UTC
Created attachment 191501 [details]
Mockup

And for the illustration...
Comment 15 Eyal Rozenberg 2023-12-20 23:37:04 UTC
> As Comments are also some kind of Review Information

Perhaps, but they are not changes. A record of changes can be displayed in a sidebar, as it is not part of what the final document is. Comments _are_ a part of the final document, albeit not a part of its body. They don't belong in a sidebar, they belong somewhere that is more part of the document. They certainly don't belong somewhere that's interchangeable with styles, navigator, style inspector etc.

So, I'm against creating a sidebar deck for comments.

As for a comment _pane_, which is not in the sidebar, that's a different matter.
Comment 16 Heiko Tietze 2024-01-06 11:35:05 UTC
(In reply to Jim Raykowski from comment #10)
> Would making the comment sidebar wider help?

See also bug 73953
Comment 17 Heiko Tietze 2024-01-12 15:19:08 UTC
We discussed the topic a while ago on Dec/20. The outcome is summarized in this blog post https://design.blog.documentfoundation.org/2024/01/12/comments-in-sidebar/
Comment 18 Bdac 2024-01-29 17:47:16 UTC
Created attachment 192238 [details]
Writer comment pane

Hello everyone,

I tried to create a model based on the suggestions above and taking into account the current UI. If it can give ideas...

Thanks
Comment 19 Heiko Tietze 2024-01-30 08:09:25 UTC
(In reply to Bdac from comment #18)
> Created attachment 192238 [details]
Shiny!

I would not show connector lines on the sidebar as it occupies too much space. And when these lines are missing the referenced text needs to be clear somehow (my mockup shows it in the comment heading).

The "Add New Comment" function has no source, and cannot IMO, if we focus the sidebar on reading.

Besides, nice and clean layout.
Comment 20 Bdac 2024-01-31 13:44:37 UTC
Created attachment 192284 [details]
Writer sidebar deck

Hi Heiko,

thank you for your reply! Yes, sorry I'd forgotten a few things listed in your post... So I tried to insert missed elements or remove connector lines and "Add new comment" function. I've created 2 different versions (more squared and more rounded) for list and filter tabs added in sidebar deck. In the first version i've kept buttons in the same form and position, in the second version I moved buttons (resolve and reply) top right, just icon without description. The only remaining button is when user replied directly to a second comment.

On the left side, in squared version, I tried to create a balloon tip with the same color of comment that we can have on the right side (with more details);
instead, in rounded version, I tried to create a balloon tip with other design (dot above the word) with the same color as the user who created the original thread.

Thanks
Comment 21 Heiko Tietze 2024-01-31 14:08:44 UTC
I like the round variant, nice idea with the colored dots. Not ideal, though, a11y-wise ;-).
Comment 22 Bdac 2024-02-05 09:09:20 UTC
You're right. Maybe with three/four colored dots above the word. Or more classic dotted underline...
Comment 23 V Stuart Foote 2024-02-11 18:50:08 UTC
Regardless of if we implement an additional SB content panel as proposed here, or expand on the current PostIt style comments as Heiko and Bdac seem to prefer, the underlaying framework needs to provide functional keyboard navigation, with suitable shortcuts, and most importantly fire appropriate "accessible events" for a11y needs.

Current comment support, PostIt and the SB Navigator deck Comment object listing are pretty painful for keyboard only navigation, so lacking Assistive Technology support.

See also bug 92389 and bug 102054