Hi, In my personal view, the Notes feature at present is designed in such a way as to be confusing if a document contains a significant number of notes. This view is based on personal experience dealing with large documents such as thesis drafts. Here's a demonstration of what it looks like at the moment (http://wiki.services.openoffice.org/w/images/thumb/f/fd/Notes2_Screenshot_CurrentVersion.png/800px-Notes2_Screenshot_CurrentVersion.png). Notice the sticky notes in the margin and the arrows following from those notes to the relevant text within the document. If the user mouses over a note the arrow that follows from that note to the relevant text, becomes more solid and hopefully more readable. Unfortunately, this is only helpful if the document contains a small number of notes, where the notes are relating to text that is not on nearby lines. If the document has a large number of notes or notes relating to text that is close together, visually following the arrow from the note to the text and comprehending to which piece of text the note pertains, becomes an arduous task indeed. I would like to suggest this feature be redesigned to allow for a more effective Notes solution in Writer. For example, instead of the notes requiring space in the margin and having the user need to follow the arrow from the note to the text, perhaps a more helpful implementation would be to have some sort of visual que indicating a particular piece of text has a relevant note and reveal the content of that note on extended mouse over? Such a solution if I am not mistaken exists in other office suits such as Microsoft Office. Thanks!
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Created attachment 57998 [details] Notes example.odt Thanks for new idea! > If the document has a large number of notes or notes relating to text ... Please, attach example document that demonstrates this problem (I never seen such document and can not imagine that, but it is very interesting) > visual que indicating a particular piece of text has a relevant note Please, do some experiments in Calc with notes and say: is this desired behaviour or should be somehow different?
Sasha, Thank you for your comment. I have crafted an example document to demonstrate the problem. It is certainly extreme in the amount of notes I've added but I believe there are cases like my own where it is common to have that many notes. I tested Calc and see that as a starting point for a solution. My only comment would be that for the visually impaired such as myself perhaps the "dot" indicating a note could be more visible and of a different colour? I have no UI experience so will leave such deliberations to those who know more about them. Please let me know if I can provide anything that will be of assistance. Regards, - Sam
Thanks for attachment. It demonstrates problem with comments in Writer Thanks for investigating problem in Calc: comment indicator is too small I agree that those things may be improved Meanwhile, try export document from Writer to pdf, comment will be as tooltips
CCing UX-Advise.
(In reply to Adolfo Jayme from comment #5) > CCing UX-Advise. Indeed the issue is still present and annoying. As a simple solution I recommend to highlight the document pointer and to focus/highlight the respective note when a word/paragraph with a comment or the note itself is clicked. (The Calc way of dealing with notes seems to be counterproductive to me.) That could be done for instance in a slightly darker color (today there is only a frame around the marked area which is not helpful for notes at a single character). I wonder if this is an Easyhack (NEEDINFO for the codepointers). Changing component to Writer as it affects only this tool.
LO's current behaviour is to shrink cluttered comments to show 3 lines and show a scrollbar to access the rest of the text. Instead it would be useful to keep the main comment intact or partially shrunk and collapse the nested comments until the user chooses to expand them by clicking a 'show X nested comments' below the main comment and once clicked, it would expand the hidden nested comments and collapse other opened nested comments. This showing nested comments behaviour could also be triggered by clicking on the comment highlighted text. But ultimately the entire comment design and behaviour needs to be revamped.
(In reply to Yousuf Philips (jay) from comment #7) > LO's current behaviour is to shrink cluttered comments to show 3 lines and > show a scrollbar to access the rest of the text. Instead it would be useful > to keep the main comment intact or partially shrunk and collapse the nested > comments until the user chooses to expand them by clicking a 'show X nested > comments' below the main comment and once clicked, it would expand the > hidden nested comments and collapse other opened nested comments. This > showing nested comments behaviour could also be triggered by clicking on the > comment highlighted text. But ultimately the entire comment design and > behaviour needs to be revamped. I cannot follow your nested comment idea. What do you mean with "to shrink cluttered comments..." when you open the attached example?
Created attachment 127323 [details] sample (In reply to Heiko Tietze from comment #8) > I cannot follow your nested comment idea. What do you mean with "to shrink > cluttered comments..." when you open the attached example? I wasnt using the attached example as the basis of my comment, as all of the comments in that doc are 1 or 2 lines and none are nested comments, which you would find in real world examples. I've attached the document i was using to give my explanation.
Code pointer, difficulty<foo> missing
(In reply to Yousuf Philips (jay) from comment #9) > I've attached the document i was using to give my explanation. So you mean a reply to a comment. I'd say this question has to be covered in a different ticket. When you reply on a comment it creates another comment that is directly attached to the previous (whereas all other have some margin between). And it is labeled as "Reply to...". Not too bad. But your example shows clearly the need to deal with long comments, the scrollbar is awkward. To keep this ticket an easyhack I'm still in favor of putting the issue into another ticket. However it would be an idea to enlarge the selected comment to show 20 lines or so (and shrink it down to 3 after deselection). And that might be solved when someone touches the highlight on selection thing.
Just bringing all the issues and variations that need to be dealt with about comments to your attention, so you can take it forward. Likely we should do a design session about it.
(In reply to Yousuf Philips (jay) from comment #12) > Just bringing all the issues and variations that need to be dealt with about > comments to your attention, so you can take it forward. Reading through hundreds of comments is counterproductive since no dev will do so. Lets stick to the bug, and file another when needed. And of course we can discuss issues. There will be a list of tasks...
Changing status: NEEDINFO -> NEW Adding keyword 'needsDevEval' [ninjaedit]
Seems the UX team need to decide how it should be, at least I cannot understand the demand Maybe this is not an easyHack depending on the outcome.
Suggestion from comment 6 is sill valid, ideally with a solution to comment 7. Removing UX to bring this forward into production.
*** Bug 125976 has been marked as a duplicate of this bug. ***
Created attachment 153331 [details] example styling in html (should work properly in firefox) My suggestion for the UI regarding coloring looks as described below. Example: ========= - The attachment writer_comment_UI_example.html shows a living example of the description below (without lines for comments, because they are difficult - The attachment writer_comment_UI.png shows an example of the transparency of unfocussed comments. Not selected / focussed comment: ==================================== - transparency of background / marking / text is 50%. - marked text has dashed border Comment selection: ================== - Definition: - mouse cursor is hovers over comment area. - mouse cursor is hovers over marked text. - transparency of text marking border becomes 0%. - transparency of marked text becomes 0%. Comment focus: ================== - Definition: - typing cursor is inside a comment - like selected comment, but: - border width increases. - dashed lines are solid. Further improvement ==================== There is still a problem, if comments and text are so far away, that both cannot be shown on screen. As solving that problem makes things more difficult, I only focussed on coloring / styling in this post.
Created attachment 153332 [details] example styling as png
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
(In reply to DarkTrick from comment #18) > There is still a problem, if comments and text are so far away, that both > cannot be shown on screen. As solving that problem makes things more > difficult, I only focused on coloring / styling in this post. Two things to consider in this context: 1. Making the note font constant regardless of document zoom: The notes are not part of the document, and should just keep their font size. This will mean that as you zoom in, you'll only need to consider the notes for less of the text. 2. Allowing notes to take up more of the viewport: Not just a bar on one side, but as there are more and more notes - bars on both sides, and eventually the talmudic style of surrounding the main text with the commentary, see: https://people.ucalgary.ca/~elsegal/TalmudPage.html of course, that doesn't have any graphics relating the point in the text to the point in the commentary, but you can see the small central area and the large area surrounding it.
> This will mean that as you zoom in, you'll only need to consider the notes for less of the text. Then I would "at least expect" a separate zoom functionality for the comments - for people, that cannot read the default font size. (Sometimes systemwide Font-size change is no option)
Esperanto: (English below, Español debajo) Mi pensas, ke kiam estas multaj notoj kun longa teksto pri ĉiu, ne estas legeble, ke iuj notoj eĉ estas metitaj en alian paĝon pri la teksto, al kiu ili aludas. Mi pensas, ke solvo estus duobla (ambaŭ fareblas samtempe): 1.- Permesu plilongigi la larĝon de la kolumna komento ĉar la monitoroj estas tre larĝaj nuntempe. 2.- Permesu meti plurajn tipojn de videbloj, elekteblaj en menuo de la titolo de komentoj kaj en la vidbenda menuo por diversaj manieroj vidi la komentojn, la formoj povus esti: a) Vidu montratajn komentojn b) Vidu nur unu linion kun + por aperigi la komenton, kiun ni elektas. Triono estus povi movi la komentojn por flosi kiel balonoj sur la ekrano, krom povi ekspansiiĝi aŭ retiriĝi per + butono sur ili. Dankon English: I think that when there are many notes with a long text on each one, it is not legible that some notes are even put on another page regarding the text to which they refer. I think a solution would be twofold (both can be done at the same time): 1.- Allow to lengthen the width of the comments column because the monitors are very wide nowadays. 2.- Allow to put several types of visualizations, eligible in a dropdown from the comments title and in the view menu for different ways to see the comments, the forms could be: a) See displayed comments b) See only one line with a + to display the comment we choose. A third would be to be able to move the comments to float like balloons on the screen, in addition to being able to expand or retract with a + button on them. Thank you. Español: Pienso que cuando hay muchas notas con un texto largo en cada una, es poco legible que incluso se pongan unas notas en otra página respecto al texto al que hacen referencia. Creo que una solución sería doble (ambas cosas pueden hacerse a la vez): 1.- Permitir alargar el ancho de la columna de comentarios porque los monitores son muy anchos hoy día. 2.- Permitir poner varios tipos de visualizaciones, elegible en un desplegable desde el título de comentarios y en el menú ver para distintas formas de ver los comentarios, las formas podrían ser: a) Ver comentarios desplegados b) Ver solamente una línea con un + para desplegar el comentario que elijamos. Una tercera sería poder mover los comentarios para flotar como globos en la pantalla, además de poderse expandir o retraer con un botón + en ellos. Gracias.
> 1.- Allow to lengthen the width of the comments column because the monitors are very wide nowadays. In general I think this is a good idea. I think there have been already a bug about this. > b) See only one line with a + to display the comment we choose. I'd say `...` is usually used in these cases. I like both.
Bug summary is not very specific and we have some specific proposals. So I would either treat this bug as a meta bug for enhancements or I would close it and open a new bug report for every idea, that is collected here and reported somewhere else.
(In reply to Dieter from comment #25) > So I > would either treat this bug as a meta bug for enhancements or I would close > it and open a new bug report for every idea, that is collected here and > reported somewhere else. I would like to ask that developers use this bug to propose/discuss/announce their overall strategy for addressing the comment UI shortcomings, and then open individual bugs about parts or aspects of that work, rather than we starting to open a half-dozen conflicting bugs.
(In reply to Eyal Rozenberg from comment #26) I would like to ask that developers use this bug to propose/discuss/announce > their overall strategy for addressing the comment UI shortcomings, and then > open individual bugs about parts or aspects of that work, rather than we > starting to open a half-dozen conflicting bugs. Good idea => Keyword needsDevEval
(In reply to Dieter from comment #27) > (In reply to Eyal Rozenberg from comment #26) > I would like to ask that developers use this bug to propose/discuss/announce > > their overall strategy for addressing the comment UI shortcomings, and then > > open individual bugs about parts or aspects of that work, rather than we > > starting to open a half-dozen conflicting bugs. > > Good idea > => Keyword needsDevEval 1. needsDevEval is used for potential easy hacks https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Keywords#needsDevEval 2. What Eyal proposed is not the job of developers, but QA contributors
(In reply to Buovjaga from comment #28) > 1. needsDevEval is used for potential easy hacks > https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Keywords#needsDevEval > 2. What Eyal proposed is not the job of developers, but QA contributors Thanks for that information. I'm not so familiar with it. So please change, what has to be changed.
I'd say that this feature is very important! LO is a great piece of software but working with document with lots of comments is still a big issue. It's hardly possible to follow. The visible part of a comment is tiny (you have to scroll within the comment which makes it hard to follow); comments are not aligned with the text, etc. I had to open the doc with LO online to be able to work (which handles the display of comments a bit better, though also has issues). As much as I resent Google, LO could do with getting a little inspiration from Google Docs hen it comes to usability. Since collaboration on docs has become very normal, I thin it should be a priority for LO to address the redesign of the comment function. Adjusting the width of the comment column/pane seems like good first step to address issues with the display of comments. In addition, making it easier and more dynamic to select comments in a doc so it's more aligned with where the comment relates to in the text (again, in docs with lots of comments it's currently difficult sometimes to find / select the right comment).