Currently, the comment indicators are opaque squares in the upper-right corner of the cell. This sometimes blocks a fair amount of the right-most digit in the cell. See: http://i.imgur.com/3Ejqm9t.png With a quick glance, is that 13 or 15 in cell A1? Bug #89182 removed the extra white border around the cell, but does not improve the overall design. Initial Recommendation: Change the comment indicator from a square to a right triangle. This will dramatically reduce the obscured area. Can also add an alpha value to the comment indicator to make it translucent. Further Considerations: Adding the ability for the user to set the color of all comment indicators would be an additional improvement. Adding the ability for the user to set the color of EACH comment indicator individually would represent a substantial improvement. We may also want to allow the user to change the location of the comment indicator within the cell. Similar to specifying the color, changing it globally would be an initial step, and changing it individually per cell would be a more substantial improvement.
Setting to new
Update: Issue still present in LO Calc 5.0.2 (release).
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d395b42cdf3ef517d215dee905e5ccf2ae73b2b8 Resolves tdf#91415 - Scale Calc's comment indicator with zoom level It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 121352 has been marked as a duplicate of this bug. ***
Reopening. As a visually challenged user, I very much disagree with scaling the comment indicator for every zoom factor. As of LO 7.4.4, changing the zoom also changes the relative size of the indicator regarding the cell's text, so, at least in some cases, the text is readable by temporarily changing the zoom: 1_ If the relevant cell is not in focus, click it once. 2_ use Ctrl plus +, Ctrl plus -, and/or Ctrl plus rotate the mouse's wheel. The goal is to be able to see the indicator – it shouldn’t be hidden by default, unless the user actively / specifically sets such option – while still being able to read the cell's content. As of LO 7.4.4, current workarounds I can think of are: _ to use the option to hide the comment indicator; _ to change font, font's size, cell's size, cell's "wrap text automatically" property, cell’s "shrink to fit cell size" property; _ temporarily change OS's zoom; _ temporarily change Calc's zoom (which is easy, fast, accessible and immediately modifiable again). The goal(s) is to maintain the cell's content readable while the comment indicator is visible. When both those goals cannot be achievable simultaneously, we have some partial workarounds as of LO 7.4.4. What is not acceptable is to make a change that doesn't solve the issue and reduces the currently-available workarounds. If the comment indicator is blocking the cell's content / results, scaling it will not solve the problem, but it makes it worse, because the text won't be readable in _any_ zoom factor. Setting the cell's text / results to be over (in front of) the comment indicator (instead of behind) might be tempting, but then, if the indicator is not seen at all – users expect to see the comment indicator – then the whole purpose of the comment indicator is lost. Perhaps some kind of transparency factor might be worth trying, but that's on developers to evaluate / consider / assess / judge (how much effort it would take to achieve, in relation to its usefulness). Changing it from a square to a triangle seems helpful. Changing its position and/or size (not scaling it) might help, as long as it doesn't conflict with other properties (such as cell's border or cell’s background colors). The purpose of the comment indicator must be maintained (i.e. to be visible so as to indicate a comment is available for the cell) with as little interference as possible. We can read prior issues when looking for a balance, such as in bug #89182 and bug #81032. Conflicting topics: big size vs small size, cell's border color and/or size and/or cell's background color vs comment indicator not using its own distinguishable border (with different color), back vs front... Also suggested in those tickets: using a different shape (triangle vs. square vs. dot), using some alpha factor for transparency. To users: temporarily changing the zoom with Ctrl + plus, Ctrl + minus, and/or Ctrl plus rotate the mouse's wheel should be a simple workaround for at least some of these situations. I already mentioned other workarounds too. IMO, changing the comment indicator to be scaled with the zoom factor is not an improvement as a whole, it will be worse when using higher zoom factors (as visually challenged users do), nor it will solve the particular matter in question (if the text is not readable, it won't be readable at any zoom factor when the comment indicator is scaled too).
Created attachment 184764 [details] Comparison 7.4 vs. Master I disagree with the statement that the indicator covers too much content. Adjusting the size depending on the zoom factor makes it smaller than today (the left part, at 50% zoom and scaled back here to ~100%). Plus, the text is always drawn on top of the indicator. Making it even smaller is possible but makes the comments harder to spot. Opinions?
(In reply to ady from comment #5) > Reopening. Hi Ady, I understand and respect that you are not happy with the change. From your comment, it is hard for me to understand what exactly _does_ work or _does not_ work for you, related to accessibility. Is it that there may never be any overlap in the content and the indicator? Or..? Can I see images/examples somewhere of what works and what not?
(In reply to Cor Nouws from comment #7) > (In reply to ady from comment #5) > Is it that there may never be any overlap in the content and the indicator? No, of course I'm not demanding that; just that the current workarounds be still available, especially the zoom, as it is the easiest to temporarily apply. The current change seems to prevent it. > Or..? > Can I see images/examples somewhere of what works and what not? First, apologies for the long text that follows, but this matter needs clear debate (as shown by the several bug tickets, many comments, and prior attempts of resolutions back and forth). I have encountered some case with the comment indicator blocking some text or number in a cell at some point or another in my life. Usually, I am able to overcome such situation by means of zoom. Using the zoom is something that I am used to use frequently, for other reasons, so it is natural for me to use such method. Other users might not even think about that, so they might think that they have a critical UI issue. There is very little mention of using zoom in the related bug reports (which might indicate that they don’t even try it or think about such alternative). Other workarounds, besides those I already mentioned, can be text alignment, indentation and border padding (all of which I also use for cases such as filter arrows blocking text, either within or around the boundaries of the filtering cell). When I saw the wording, "scale…", I went and asked Heiko Tietze in irc #libreoffice-design, and the screenshots and video provided show that, no matter the zoom, the resulting text is still covered by the indicator. This is not what happens as of LO 7.4.4, in which, most frequently than not, temporarily changing the zoom can resolve the relatively minor problem – I say "relatively minor", because it can be easily overcome by several currently-available methods. It is still in the hands of users. By changing the indicator to grow when we use higher values of zoom (i.e. part of scaling it), which is part of the change according to the screenshot that Heiko Tietze showed me, a relatively minor problem for some users in some cases can turn into a permanent inconvenience (especially to visually challenged users) that has no easy workaround (because no matter the zoom, if the indicator covers a text, it will cover it under any zoom value once the change is committed). There will be no longer an easy workaround in the hands of users (especially if the file is read-only, when other properties cannot be modified, but the zoom is yet available). Having some artifact covering some text is not an exclusive issue with the comment indicator. There is help text showing under the mouse pointer, and/or filter arrows, just as common examples. The user has sometimes some method to overcome or correct the situation (e.g. for filter arrows, and for comment indicators), but sometimes there is no workaround (e.g. mouse pointer over help text). The resolution proposed here seems to make useless the easy workaround currently available (as of LO 7.4.4.), and will not solve the issue really (as shown in the screenshots that Heiko Tietze provided in irc). For example (of what _not_ to do), making the indicator just one color (i.e. with no border of another contrasting color) would make it smaller, but such hypothetical change clearly clashes with using a similar background color for the cell or for the cell’s border, so you should _not_ make the indicator one_color_only and without its border (i.e. its border, with a different color, must remain). If you can make the indicator smaller but still visible (e.g. triangle, still with a border of a different color), then that’s an improvement (in UI) that shouldn't affect negatively other users. Perhaps if the indicator can be partly transparent (the alpha thing that was suggested before) then both objectives can be maintained(?): the text can be clearly seen, and the indicator can be clearly spotted. It is possible that just making it a triangle is enough, in which case no new bug enhancement requests would show up (and so, going step-by-step towards a resolution can be helpful, rather than applying several changes at one time, risking some unnecessary negative side-effects). Reading prior tickets (some of which I already linked to) on the same subject and prior attempts to improve the situation, demonstrates that there is some balance to consider, and that some changes that are centered on the comment indicator alone can negatively affect other aspects of UI and usage. Since I have to rely on using the zoom more often than not (and the comment indicator is not nearly the main reason for it, by far), I am perhaps more aware than others that using the zoom can be an easy workaround for the matter in question in many occasions, while scaling the comment indicator seems to have (according to the screenshots that Heiko Tietze showed me) detrimental consequences. When users would write to complain that, no matter the zoom value, the indicator still blocks the text behind it, then one workaround that is available as of LO 7.4.4 would be gone, and a solution for that newly created situation would have to wait for another 7 or 8 years (I wonder?). (Just in case, I don’t mean to sound rude or to complain; I’m only writing what I worry about, since the very instant I read the "scale…" phrase. So, triangle, with border, 2 different colors (one for the triangle, another color for its border, as it is now for the square), with some degree of transparency. Maybe introducing the changes step-by-step (first the shape, then the transparency) instead of all at once? I don’t know whether there are negative effects (such as more resources needed just for displaying the indicator, instead of using them for calculation power, for instance?), but others can comment on those. Now, if what I am describing that I saw in the screenshots is just my misunderstanding, and the comment indicator will _always_ be smaller than what currently is at any_and_every zoom (I am no stranger to 200% zoom, sadly) and DPI scaling factor, then please accept my apologies for the noise.
Design enhancements should be reported separately, blocking the prior ticket. Please don’t reopen fixed bugs.
In release notes: https://wiki.documentfoundation.org/index.php?title=ReleaseNotes%2F7.6&type=revision&diff=720930&oldid=714015 Verified in: Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded