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.
[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:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Created attachment 57998 [details]
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?
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.
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
(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]
(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'
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.
- 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
- 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%.
- typing cursor is inside a comment
- like selected comment, but:
- border width increases.
- dashed lines are solid.
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