https://bugs.documentfoundation.org/show_bug.cgi?id=103064
Yousuf Philips (jay) <philip...@hotmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |c...@nouenoff.nl,
| |rb.hensc...@t-online.de,
| |vstuart.fo...@utsa.edu
See Also| |https://bugs.documentfounda
| |tion.org/show_bug.cgi?id=38
| |295,
| |https://bugs.documentfounda
| |tion.org/show_bug.cgi?id=89
| |232
--- Comment #24 from Yousuf Philips (jay) <philip...@hotmail.com> ---
(In reply to Luke Kendall from comment #20)
> I don't understand the usability thinking behind this. Just as there is no
> single "optimal font size" for a document, there is the need from users to
> be able to change the size and font within a comment.
The purpose of comments is to discuss segments of a document without editing
the segment being discussed, just like we are making comments in this bug
report. We dont need to set font attributes to these comments, though some
people do throw in text emphasis marks, to have such a discussion, so i wouldnt
compare formatting of comments with the the styling of a document.
> I assume you are suggesting this because it would make the code simpler. I
> can't think of any other reason for suggesting it. I would prefer it if you
> could put the user's needs first, rather than the programmers' convenience.
No i'm saying this as i'm part of the design/UX team and also deal with
interoperability. If you open documents created with large font size in other
office suites, the set font size and sometimes the font name wont be displayed.
> I assume you're not suggesting a single "comment paragraph style"? Or if you
> are, that it can be overridden on a case-by-case basis as the user needs.
Yes i'm suggesting a single comment paragraph style to define the base font
name and size, where individual comments can have character styles to change
things as needed.
> I just read that. Since a comment can grow very long indeed, all those
> changes would address the problem for about another 10% of comment length.
> After that, allowing the reduction of font size addresses maybe another 20%.
> (These numbers are, of course, my gut-feeling estimates: they're not backed
> by data.) Beyond that, the scrollbars of course become essential - unless
> you were to propose a separate document window could be popped up just to
> view the comment.
Yes the mechanism to deal with many comments, large comments and nested
comments need to be addressed, as also discussed in bug 89232. If you would
like to discuss that issue further, please comment there.
> Comments can grow arbitrarily large. There is finite screen space available
> no matter how you improves the comment box layout. Therefore, reducing the
> font size will remain a useful option.
Large comments could easily be shrunk when they are not needed or in not focus,
rather than reducing their size.
> Please also consider that some people are viision-impaired: so for them,
> being able to increase the font size would be more than just helpful.
Visually impaired users would resize the entire document view larger with the
zoom functions and not increase the size of the document text and comments, or
else they would have difficulties collaborating with non-visually impaired
users on the same document.
> My suggestion was to reduce the code size and reduce the chance of new
> sections of code that could then have there own bugs. It was not because
> the features are needed: e.g. footnotes and such. You might consider just
> limiting the UI for the comment editing so that the extra functionality
> wasn't available.
Yes the simplest thing would be to disable the functionality from working when
editing comments, in the character dialog and from being displayed if already
set.
> As things stand, comments already have several other bugs in the operation
> of their existing text editor, such as wrong sized or placed scrollbars,
> wrong text selected or insertion point chosen when you click into them, etc.
> I think the bug in which font size changes to comments weren't being stored
> has been fixed, though. I'm only pointing this out to indicate that the
> existing comment display and editing code does not work anywhere near as
> well as the general, more powerful text editing and display functionality of
> Writer proper.
Yes quite aware of the current bugs and fixes that have gone into LO related to
comments over the last few years and hope that fixing this one bug will resolve
many of the bugs from occurring.
> Please consider getting some opinions from the UX people before you remove
> functionality which I find very important in my everyday use of LO. I am
> depending on these existing features. I think many other users would be,
> too.
As stated above, I am part of the design and UX teams and we also have Heiko in
this discussion who is also part of the team and lets bring Cor and Stuart in
as well for their takes on the issue. And of course Regina for her valuable
insights. :D
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs