Description: I was asked not to reopen bug #91415. So here we are, with a new bug report (“enhancement request”), to request reversing https://bugs.documentfoundation.org/show_bug.cgi?id=91415#c3 https://git.libreoffice.org/core/commit/d395b42cdf3ef517d215dee905e5ccf2ae73b2b8 Scale Calc's comment indicator with zoom level I explained the reasoning extensively in: https://bugs.documentfoundation.org/show_bug.cgi?id=91415#c5 and in: https://bugs.documentfoundation.org/show_bug.cgi?id=91415#c8 In short, as of LO 7.4.4, users can use the built-in zoom to easily overcome almost all inconvenience regarding the comment indicator. Most probably, a user having such problem as of LO 7.4.4 is simply unaware of the existence of Calc's zoom (ctrl-+, ctrl--, ctrl-rotate_mouse's_wheel). Alternatively, instead of scaling the indicator (as the linked committed change will achieve), which would have detrimental consequences (as explained in those linked comments to bug#91415), the comment indicator could be changed: _ first, from square to triangle; _ and if that first step were to result in not being enough, then have some degree of transparency for the comment indicator. Steps to Reproduce: Read long description for reasoning in bug 91415#c5 and bug 91415#c8. Actual Results: The behavior should remain as it is in LO 7.4.4.. There is an easy workaround already; users just need to be aware of it. Expected Results: Avoid detrimental consequences of the commited change. Reproducible: Always User Profile Reset: No Additional Info: According to the screenshots shown to me in irc #libreoffice-design, the change committed would not actually solve the original problem, and would have negative consequences.
Blocks #91415
I read what you wrote in bug 91415, but I don't understand why you talk about the indicator covering the text while it's the other way around as shown in attachment 184764 [details]. It rather sounds like you would benefit from an option to hide the indicators entirely. Then you could switch between comments being shown or hidden.
The screenshots that I saw in irc and the one you just posted here, in the way I am seeing them in my system, show some interference between the comment indicator and the text. This is what the original OPs complain about. So, before the committed change, zoom would solve the issue; after the committed change, it will not. As of LO 7.4.4, when there is any kind of interference between the text and the comment indicator, users can temporarily use the built in zoom feature, and almost all interference is immediately gone. It takes 2 seconds to zoom in, another 2 seconds to clearly read whichever symbol (letter, number, etc.) was interfered (in whichever way) by the comment indicator, and another 2 seconds to go back to the original zoom factor. Steps: 1. If the relevant cell is not in focus, click once on it (or move to it with arrow keys). 2. Try ctrl-minus, ctrl-plus, or ctrl-rotate_mouse’s_wheel back and forth. From my own experience in using spreadsheet software since the mid-late '80s, many users complaining about the interference of the comment indicator are not even aware of such zoom factor existence in current software (and the easily available keyboard shortcuts as of LO 7.4.4). Now, instead of suggesting that the current bug report about the matter should be replied with a link to some wiki page so users would learn about how to use zoom (and then close such tickets with wontfix :o) ), I have suggested alternatives to actually improve the case even without bothering users with learning some feature. Such alternative (triangle) seems to be reasonable and with no negative effects in the UI department (but I could be wrong, e.g. regarding lower screen resolutions or systems with low resources?). Whether it is worth investing development time, that's not for me to say. Instead of those paths, a new change, that will not solve the matter (as far as I can see in the screenshots) is committed, while users will still be unaware of the 6-seconds solution of using zoom. Regarding an option to hide the comment indicator, there is one already. So, that's another alternative for users, who are simply unaware. On a side-note, just to provide relative context, as I commented elsewhere, there are issues that have no alternative and no influence nor workaround in the hands of users, depending on UI improvements to be developed (i.e. in the hands of developers and such, but not in the hands of simple users). The font type and font size in the formula bar is only one of those, constantly bothering the most basic usage of Calc, with many users waiting to see improvements, especially since the built-in UI scaling option went away and the answer has been, repeatedly, for users to "use the OS’s zoom" (not Calc's zoom, which doesn't apply to the formula bar, among other areas of the UI). So, several alternatives are already available as of LO 7.4.4. Unless I am seeing the screenshots differently than others, I don't really know what else I could say to explain it.
Indeed, it's in Calc's Options - View - Comment indicator.
I don't have a strong opinion on the topic but wanted to mention that the committed change is consistent with a change in version 7.3: the spellcheck wiggly underline also scales with the zoom level. https://wiki.documentfoundation.org/ReleaseNotes/7.3#General
(In reply to Stéphane Guillou (stragu) from comment #5) > wiggly underline also scales with the zoom level. I am aware of that change. In the case of the comment indicator, the whole issue is initiated by one artifact interfering with another (hopefully no user has such interference with the underline), and the committed change (according to the screenshots that I saw) will prevent the most simple solution to be relevant (using temporarily the zoom to effectively see both, the text and the indicator). It is also mentioned that some cases (20% zoom, and 200% zoom, IIRC) are considered extreme. I am, sadly, no stranger to 200% zoom factor. So, I have to wonder, what exactly this is going to improve? Users avoiding being aware of how to use zoom? Where are the original users that asked for this improvement so many years ago in so many bug reports, to provide some evidence that temporarily changing the zoom factor in LO 7.4.4 doesn't solve the issue in most (if not all) cases? I could take almost any cell, with a clear visible text and indicator, scale the zoom factor to, say, 20%, and show how it is an inconvenience. The opposite is also true: use a higher zoom factor and the interference goes away. How is it that "use OS's zoom" is a valid reply to the request to improve the Formula Bar (a constant source of UI problems), but it is not an acceptable answer to use the built-in zoom feature in Calc? Anyway, I don't want to repeat myself. I think I have provided the arguments requested, and I think my concerns about negative effects are valid.
Created attachment 185187 [details] Four screenshots demo (In reply to ady from comment #6) > I could take almost any cell, with a clear visible text and indicator, scale > the zoom factor to, say, 20%, and show how it is an inconvenience. The > opposite is also true: use a higher zoom factor and the interference goes > away. I am attaching a 7z archive, containing 4 screenshots, as follows: * 153106_7_6alpha.png : comment indicator in A1:A2 as seen in LO 7.6.alpha, zoom 100%. * 153106_7_4_5.png : comment indicator in A1:A2 as seen in LO 7.4.5, zoom 100%. * 153106_7_6alpha_zoom400.png : comment indicator in A1:A2 as seen in LO 7.6.alpha, zoom 400%. * 153106_7_4_5_zoom400.png : comment indicator in A1:A2 as seen in LO 7.4.5, zoom 400%. To be clear, the values of zoom are from LO Calc itself. There is no other difference between the screenshots, except for what is included in the above descriptions. See the differences in how the comment indicator looks in each case, and how much it covers (or not) the text / values in the cells. These screenshots clearly demonstrate that the comment indicator covering or interfering with the content of the cells as of LO 7.4.x is a non-issue, and that there is no improvement in this regard in 7.6 with the change committed (it even seems that more area is covered with such change). All that is really needed is to better document the correct use of the zooming feature included in LO Calc, and to promote such usage to common users accordingly.
How about the compromise to reduce the size by 1px? More makes it very hard to spot.
No idea what it would do for performance as it would increase graphics calculations, but what about drawing the indicator, so there is a small buffer of cell background where there would be contact with text? So kind of like the text would have an extra border where it meets the indicator.
Hi Ady, (In reply to ady from comment #7) > I am attaching a 7z archive, containing 4 screenshots, as follows: Thanks for the images. > These screenshots clearly demonstrate that the comment indicator covering or > interfering with the content of the cells as of LO 7.4.x is a non-issue, and > that there is no improvement in this regard in 7.6 with the change committed Do I understand that the commit, that is asked to be reverted, does not make things worse or better for your use > All that is really needed is to better document the correct use of the > zooming feature included in LO Calc, and to promote such usage to common > users accordingly. And that better use of zoom will help people with the use of the old version of the indicator? You know that explaining features in documentation, has it's limitation in effect.. ;)
(In reply to Cor Nouws from comment #10) > Do I understand that the commit, that is asked to be reverted, does not make > things worse or better for your use It makes things worse, not better. And this is not just my use case; it is that those users with the original request as in Bug 91415 are simply unaware of the usage or existence of the zoom feature. The zoom feature's whole purpose is to allow changing the clearance distance between screen artifacts. If you cannot read clearly, if the lines that form a character are "too-crowded", if two independent items on screen are "too-close" to each-other, use a higher zoom factor: the lines and other items look more distant between each-other and you can distinguish between them. Being visually challenged, I don't have a choice but to be aware of this feature, and I'm thankful for it. This is one of the things that can be seen in attachment 185187 [details]. Using a higher zoom factor, the cell's content grows, while the traditional comment indicator remains as it was (i.e. relatively smaller). This is a good thing. The other thing that can be seen in attachment 185187 [details] is that the comment indicator newly introduced (for LO 7.6alpha+) is not better than the traditional one. I can argue, based on those screenshots, that it takes more screen area, not less, and by scaling it, users are less able to distinguish things apart, since the clearance distance is not higher/better (precisely because of the new scaling). The comment indicator will no longer be relatively smaller when zooming in (or at least not as much), so the main purpose of the zoom feature is lost for this item, while the original problem is not completely gone. Additionally, IIUC this change requires more graphic resources. Please someone clarify this for me: What exactly is the positive consequence or advantage of scaling the comment indicator? Isn't the built-in zoom feature already available and already solving the original problem? > > And that better use of zoom will help people with the use of the old version > of the indicator? Yes. In LO. In AOo. In any spreadsheet program since they use GUIs including zoom features, it has been this way. For those users that are aware of this feature, there is no reason to request to solve this non-issue. > > You know that explaining features in documentation, has it's limitation in > effect.. ;) As an example, we see complaints about Cal's accuracy of calculations several times a year, every year. The typical reply is "read this or that wiki page, or help page, or...". For almost every little thing that users don't know yet, we are instructed/hinted/pointed to some document, or to some ask.lo.org, or to some email, or... Nothing new. As another example, there have been many requests to allow changing the font type and font size in/of the formula bar, or even of the whole UI in LO. The formula bar can be a _real_ permanent problem (I know it is for me). Yet, since the time the built-in option to scale the UI was gone, the answer has been "use your OS's scaling and zoom features". In the case of the comment indicator, with a minor and temporal issue for some user in some circumstance, users will be happy to know that there is a simple solution already available (in addition to being able to hide all the comment indicators, also already available). Having an adequate documentation about the built-in zoom features in Calc – bug 153108, although it is a bit vague ATM – and use-cases for it, will help users be aware of it.
My understanding of bug #91415 and the motivation for the patch was that zooming out makes the comment indicator overly large. Alternatively to the requested revert I can offer to make the triangle a bit smaller and to adjust it in different steps, eg. not growing further above n pixels. Though not blocking, if the decision is to revert.
Created attachment 185294 [details] Mockup of contour between indicator and text (In reply to Buovjaga from comment #9) > No idea what it would do for performance as it would increase graphics > calculations, but what about drawing the indicator, so there is a small > buffer of cell background where there would be contact with text? So kind of > like the text would have an extra border where it meets the indicator. Mockup of this.
(In reply to Heiko Tietze from comment #12) > My understanding of bug #91415 and the motivation for the patch was that > zooming out makes the comment indicator overly large. And then zooming in will reduce it back to a few pixels, in less than 2 seconds. Please let me know whether I should attach an additional screenshot, but instead of 100% and 400%, using 20% or 10% this time. As I said already, you can always take any zoom factor and keep zooming out (i.e. using a lower zoom factor) up to a point where you will inevitably find an inconvenience. No matter the kind of indicator or any artifact whatsoever, it *will* "bother" you to clearly read the cell's content at lower zoom factors. But the opposite is also true. If someone is using a zoom factor of 20%, just increase the zoom factor and the inconvenience will go away. A small zoom factor allows users to see more cells, which is sometimes necessary, but it won't allow the same user to see more details simultaneously. That's just not possible, not simultaneously. Either you zoom in to see more details (or more cell's content/text, more clearly), or otherwise you zoom out to see more area/relations/big picture. You cannot read Liberation Sans/Mono 10pt font in an A4 or Letter page size from either a ridiculously long or ridiculously short distance; you have to be at an adequate reading distance. To anyone saying "I cannot read the content of the cell when I use 10% zoom", I say, change the zoom until you can. Then, if you want to go back to 10% zoom, just go for it. It will take you about 6 seconds (or less), with either 2 fingers of one hand, or one hand on your keyboard and the other on your mouse's wheel.
See also bug 97551 / https://gerrit.libreoffice.org/c/core/+/147914.
Personally, I find the triangle marker of Heiko's patch for 7.6 and trunk to be much more visually appealing, and functional, than previous non-scaling square. -1 for reversion. Rather than focusing on how to improve/change the marker, seems what is needed is a convenient way to toggle the marker hidden -- an UNO action to assign to menu, context menu or the most likely keyboard assignment. Current Show Hide comments or notes does not affect the marker. Avoid any need to zoom to visualize partially obscured text or digits.
(In reply to V Stuart Foote from comment #16) > Personally, I find the triangle marker of Heiko's patch for 7.6 and trunk to > be much more visually appealing, and functional, than previous non-scaling > square. -1 for reversion. The comment indicator is not supposed to be appealing. Almost the contrary, it is supposed to be _almost_ inadvertent. You should be able to read and work with Calc without distraction from the indicator, except when you are interested in reading the comment, or being aware that a comment exists. It's not that I am against the change because "I don't like how it looks". It is a matter of practical usage, in accordance with the goals of the comment indicator. IMO, the change was not a functional improvement (to a non-issue). > > Rather than focusing on how to improve/change the marker, seems what is > needed is a convenient way to toggle the marker hidden -- an UNO action to > assign to menu, context menu or the most likely keyboard assignment. > > Current Show Hide comments or notes does not affect the marker. > > Avoid any need to zoom to visualize partially obscured text or digits. FWIW, I wold be "for" bringing the switch of showing comments to the "View" toolbar(s) (instead of being available in the menu only). In the same direction, I would be "for" having the option to hide/show the comment indicator more easily available, instead of having it (just?) within the Option dialog as it currently is.
(In reply to Heiko Tietze from comment #15) > See also bug 97551 / https://gerrit.libreoffice.org/c/core/+/147914. I don't want to keep repeating myself. For whoever didn't see it already, please see what I wrote in that same bug 97551 comment 11 and the next one to that. Partial quote: That's in contrast to bug 91415 and the follow up discussion in bug 153106, in which users would have no choice, no alternative.
Again, NO for "revert" it is appropriate to scale the marker for the comment. It would also be appropriate to be able to toggle the markers invisible (for comment as here, or for formula [1]) with UNO available to assign to menu, contextmenu or keyboard action. =-ref-= [1] proposed bug 97551 https://gerrit.libreoffice.org/c/core/+/147914
There are (at least) two usability considerations/problems regarding comment indications: 1. On one hand, it's a problem when comment indicators hide content. 2. On the other hand, it's a problem if comment indicators are not clearly-visible, as I might inadvertently miss them Bug 91415 was opened regarding the first usability problem, not the second one. Also, bug 91415 did not ask for any changes at high zoom levels - it regarded the situation without playing with the zoom level. The patch introduced in 91415#c1 did two things: Replace the square with a triangle, and scale the triangle during zoom. The first change is relevant to that bug. I don't see how the second change is relevant. While I may personally "like" the scaled comment indicators' look - such a change does not IMHO belong on that bug. So I agree that that part be backed out for now. Heiko, or someone else, should open a separate bug to discuss whether or not comment indicators should scale. Having said that... Ady, the images you attached here do not serve your case well enough. The 7.6 examples, with the scaling, do not exhibit hiding of cell contents. Could you replace the screenshots with cases which are actually problematic? In bug 91415, we got a link to https://i.imgur.com/3Ejqm9t.png - which shows very problematic content hiding. How bad is the situation now? Also, Ady, > You should be able to read and work with Calc without distraction from the indicator I disagree with that. On the contrary, I see it as a problem if the comment indicator does not draw your attention.
(In reply to Eyal Rozenberg from comment #20) > There are (at least) two usability considerations/problems regarding comment > indications: > > 1. On one hand, it's a problem when comment indicators hide content. > 2. On the other hand, it's a problem if comment indicators are not > clearly-visible, as I might inadvertently miss them > > Bug 91415 was opened regarding the first usability problem, not the second > one. Also, bug 91415 did not ask for any changes at high zoom levels - it > regarded the situation without playing with the zoom level. That sounds as if the request explicitly said "I cannot use the zoom feature to solve this" or "I have "X" problem with the zoom feature, so it doesn't help in my case". The reason users do not mention zoom in bug 91415 is because they are simply not aware that the zoom feature resolves the problem. I explained this several times already. There is no physical way to _simultaneously_ see more details and to see "the big picture" in the same UI. That's the reason to use zoom. Quote: -- -- I could take almost any cell, with a clear visible text and indicator, scale the zoom factor to, say, 20%, and show how it is an inconvenience. The opposite is also true: use a higher zoom factor and the interference goes away. -- -- Please re-read that quote and think about it. The solution to the non-issue in bug 91415 is to use a feature that already exists. Some users are not aware of its existence, that's all. In a similar way, a user may just ask "is it possible for Calc to give me the results that I need without having to learn anything about functions, whatever that may be? I don't want to learn about functions and formulas." Well, the answer would be "no, you have to learn how to use the available features". Generally speaking, there are 2 kinds of popular zoom methods: either you zoom in/out using the same window, or you have an additional small window where some area around the mouse pointer is expanded. The goal: either users want to see more details (zoom in), or want to see a "the bigger picture" (zoom out). When you scale the comment indicator, you are maintaining the ratio (or using a similar ratio) between the content of the cell and the indicator. As I explained at length already, this doesn't solve the original problem, while it adds inconvenience to other users (such as visually challenged users that already use the zoom features of both, Calc and the OS). > > The patch introduced in 91415#c1 did two things: Replace the square with a > triangle, and scale the triangle during zoom. > > The first change is relevant to that bug. I don't see how the second change > is relevant. While I may personally "like" the scaled comment indicators' > look - such a change does not IMHO belong on that bug. So I agree that that > part be backed out for now. > > Heiko, or someone else, should open a separate bug to discuss whether or not > comment indicators should scale. > > Having said that... Ady, the images you attached here do not serve your case > well enough. The 7.6 examples, with the scaling, do not exhibit hiding of > cell contents. Could you replace the screenshots with cases which are > actually problematic? In bug 91415, we got a link to > https://i.imgur.com/3Ejqm9t.png - which shows very problematic content > hiding. How bad is the situation now? I already offered the possibility to attach the result of the same screenshot while using 10 or 20% of zoom factor in Calc, to make it more evident. Have you noticed that the picture in bug doesn't show the zoom factor? Let me mention, again, other things that could trigger the same visual problem: * the row's height is too small in relation to the font size; * the width of the column is too narrow, so not all the text gets into the cell. There are several possibilities to solve those 2 issues, and they both are not letting the content be seen clearly. At some point, users need to learn how to change the size of the cell, or the size of the font, or to change the zoom factor. That's how users resolve that problem. What about the "###" error? Users can: * expand the column width; and/or, * change the font type; and/or, * change the font size; and/or, * use a different alignment; and/or * change the zoom factor. All of these have some influence on whether the "###" is seen. A user could report "I changed the column width, I then saw the content of the cell, but then the problem returned again". I would answer "have you changed the font type and/or size, or the zoom factor? Please find the combination that fits your needs." > > Also, Ady, > > > You should be able to read and work with Calc without distraction from the indicator > > I disagree with that. On the contrary, I see it as a problem if the comment > indicator does not draw your attention. Yes, if that were to be a problem. There is no report claiming that the comment indicator cannot be seen. The user should be able to see it, but it should not be "the main thing"; that would be distracting. Again we are talking about a non-issue. You all know the expression "RTFM". Just as we reply in so many "bug reports", in this case the answer should had been a link to a help page explaining how to use the zoom feature in Calc. Oh, that's the problem! It did not exist :-o, and no one replied anything about its existence. Well, it just happens to be that visually challenged users are more aware of this feature, that's all. BTW, by now there is such bug report, requesting that such help page would be created.
(In reply to ady from comment #21) > > I disagree with that. On the contrary, I see it as a problem if the comment > > indicator does not draw your attention. > > Yes, if that were to be a problem. It has definitely been a problem: bug 56677. But the "fix" was insufficient in my opinion. Things have certainly not gotten to the level of visibility of MS Excel, and in absolute terms - it's really not good enough. > There is no report claiming that the comment indicator cannot be seen. There is now: Bug 154080. > The user should be able to see it, but it > should not be "the main thing"; that would be distracting. It _needs_ to distract - while not interfering with the visibility of the actual cell contents. > (In reply to Eyal Rozenberg from comment #20) > > There are (at least) two usability considerations/problems regarding comment > > indications: > > > > 1. On one hand, it's a problem when comment indicators hide content. > > 2. On the other hand, it's a problem if comment indicators are not > > clearly-visible, as I might inadvertently miss them > > > > Bug 91415 was opened regarding the first usability problem, not the second > > one. Also, bug 91415 did not ask for any changes at high zoom levels - it > > regarded the situation without playing with the zoom level. > > That sounds as if the request explicitly said "I cannot use the zoom feature > to solve this" A bug was reported in the behavior without the user applying zoom. Whatever changes in the behavior when zooming in or out cannot resolve the bug. > The reason users do not mention zoom in bug 91415 is > because they are simply not aware that the zoom feature resolves the problem. No, that's not the reason, and no, it doesn't resolve the problem. ... which is also why the patch should not have included scaling at different zoom levels - because zoom is irrelevant to the bug. > There is no physical way to > _simultaneously_ see more details and to see "the big picture" in the same > UI. That's the reason to use zoom. Of course there is. More than one way even. The use of the triangle shape rather than the dot/small square is one such way. One can think of others. > I could take almost any cell, with a clear visible text and indicator, scale > the zoom factor to, say, 20%, and show how it is an inconvenience. It doesn't matter what happens at zoom 20% nor at zoom 500%. Both cell contents, and comment indicators, must be clearly visible at zoom 100%. (or rather - it does matter, but not in the context of bug 91415.) Anyway, I don't understand why you're arguing with one of the people who agrees with you. In fact, you're undermining your own request for back-out by claiming that what happens at different zoom levels has bearing on 91415.
(In reply to Eyal Rozenberg from comment #22) > (In reply to ady from comment #21) > > > I disagree with that. On the contrary, I see it as a problem if the comment > > > indicator does not draw your attention. > > > > Yes, if that were to be a problem. > > It has definitely been a problem: bug 56677. But the "fix" was insufficient > in my opinion. Things have certainly not gotten to the level of visibility > of MS Excel, and in absolute terms - it's really not good enough. You are mixing different issues; it is all about comment indicators, but still different issues. I have never had a problem with not seeing a comment indicator (someone that has "less than perfect" vision), but I'm not going to claim that my case is the same as for everyone else. Being able to distinguish the comment indicator doesn't have to be about scaling. It might be about contrast, or about other peripheral information on screen. I still think that the comment indicator should not be a distraction, much like "stop" o "speed limit" signs on the road should not be a distraction; they are to be seen, but not the main thing to be focused on. If a user wants more, the comment themselves can be all shown, and then users can hide them again and keep working (2 clicks, than another 2 clicks). The difference with making the comment indicator to scale with zoom is that the user has no control, no influence anymore. For someone like me that has to use the zoom features of Calc and of the OS all day long, it will be either to accept the scaling, or to hide them for good (_not_ just 2 clicks). > > > There is no report claiming that the comment indicator cannot be seen. > > There is now: Bug 154080. Again, different issue. The original report that brought all this was "It is hard for some users to read the content when the comment indicator is there". The answer should had been to either: * modify the cell's size; or * use a different alignment, or alignment attributes; or * change the font type; or * change the font size; or * hide the comment indicator; or * use the built-in zoom, which is the fastest, more flexible and easiest of all these; or * a combination of all the above. Instead, after 7 (or more) years and multiple duplicates and who knows how many forum posts, in which no reply was about any of the aforementioned alternatives and we only see screenshots, not actual files. suddenly someone decided to scale the comment indicator, without pondering the negative consequences. Has anyone noticed that no users have yet confirmed that scaling the comment indicator was what they wanted? Where are the sample files with specific fonts types, font sizes, cell sizes, alignment attributes and zoom factor to test with? They do not know the zoom exists; otherwise they would had used it instead of opening a bug report, simply because it takes (much, much, much) less time to use the built-in zoom than to write the report. > > > The user should be able to see it, but it > > should not be "the main thing"; that would be distracting. > > It _needs_ to distract - while not interfering with the visibility of the > actual cell contents. Perhaps we are just using different terms. I disagree. A speed limit sign should not be distracting; you only need to be aware of the info it provides. And, the comment indicator is not the problem; lack of knowledge about the use of the built-in zoom feature is. > > > (In reply to Eyal Rozenberg from comment #20) > > > There are (at least) two usability considerations/problems regarding comment > > > indications: > > > > > > 1. On one hand, it's a problem when comment indicators hide content. A non issue. As with any other spreadsheet software that shows additional info on the main area, use the zoom, to either see more details, or zoom out to see the big picture. Or, use any or all the alternative settings I mentioned above. Is there a claim that all default values for cell size, font type, font size, alignment and zoom factor are all ideal for each and every case for each and every user? Users sometimes need to alter the default settings; we don't "report" that the default setting "doesn't work for me" when there are alternatives. And, please keep in mind that these are settings in the hands of the user; whereas the indicator being scaled with zoom is not. > > > 2. On the other hand, it's a problem if comment indicators are not > > > clearly-visible, as I might inadvertently miss them Which was not part of the report. This was also not the goal of the patch. If that were to be the intention, then it would had been connected to a different report, and the pros and cons of it would had been different. There is not even a mention of pros and cons in this case, and the concern about clear visibility of the comment indicator (which I don't share at all, but OK) can be thought as being _against_ the initial report (i.e. "the comment indicator is bothering me, and I have no clue what to do and no one has explained to me any of the alternatives"). > > > > > > Bug 91415 was opened regarding the first usability problem, not the second > > > one. Also, bug 91415 did not ask for any changes at high zoom levels - it > > > regarded the situation without playing with the zoom level. We agree; the comment indicator being scaled with zoom should had not been a "solution", especially to a non-issue. > > > > That sounds as if the request explicitly said "I cannot use the zoom feature > > to solve this" > > A bug was reported in the behavior without the user applying zoom. Whatever > changes in the behavior when zooming in or out cannot resolve the bug. I don't think the patch is a solution for the original user's problem. If there had been a proposal to the reporter(s) to use the zoom and report back with feedback, they would had said "you know what? I'm OK with this zoom feature and the comment indicator is not a problem anymore, works for me, you don't need to do anything". > > > The reason users do not mention zoom in bug 91415 is > > because they are simply not aware that the zoom feature resolves the problem. > > No, that's not the reason, and no, it doesn't resolve the problem. ... which > is also why the patch should not have included scaling at different zoom > levels - because zoom is irrelevant to the bug. If users knew that there is a 2 to 6 seconds solution for a once in a while minor inconvenience, they wouldn't even bother opening a report. But I do agree that the patch scaling the comment indicator is not the solution for that non-issue. > > > There is no physical way to > > _simultaneously_ see more details and to see "the big picture" in the same > > UI. That's the reason to use zoom. > > Of course there is. More than one way even. The use of the triangle shape > rather than the dot/small square is one such way. One can think of others. Again, you seem to be mixing matters. Or perhaps you didn't realize yet that the triangle thing was the "extra", not the main. The initial patch was to scale the indicator, and the triangle was supposed to make it less prominent when zooming in. The triangle, turns out, is bigger than the original square, so it contradicts the intention. Thus I wonder, how the scaling and/or the bigger triangle solve any of the original (non-)issue? They don't, while they have negative consequences. > > > I could take almost any cell, with a clear visible text and indicator, scale > > the zoom factor to, say, 20%, and show how it is an inconvenience. > > It doesn't matter what happens at zoom 20% nor at zoom 500%. Both cell > contents, and comment indicators, must be clearly visible at zoom 100%. > > (or rather - it does matter, but not in the context of bug 91415.) My point was/is that the original claim that "users can't read the content of the cell" is not accurate, by far. I presented a logical explanation as to how to use a feature that is there exactly for the kind of situations the users were reporting. The claim would had been valid, only if there was no zoom feature. I was explaining the solution/reply that should had been given several years ago already. We, users, have been replied with similar answers many, many times. You can search and read the replies about the formula bar content not being clear enough. since some other users/devs think that the formula bar is perfectly readable (under their conditions, context, eye's powers/capabilities), the popular answer (since the UI scaling went away) has been "use the OS's zoom and or the OS's text scaling features". Again and again users explain that such actions were not good enough, because there are additional consequences and those are not positive. In contrast, here I am saying that the answer to the "indicator vs content" problem should had been to use the built-in zoom feature, and/or any of the additional items that I mentioned above, which don't have negative consequences (because they are the hand of the user, and are already available and they don't affect any other program nor the entire OS/DE). How is that inadequate? It isn't. The thing that is not adequate, IMNSHO, is to scale the comment indicator as an answer to the non-issue. "Do something to solve a non-issue while generating negative consequences". > > Anyway, I don't understand why you're arguing with one of the people who > agrees with you. In fact, you're undermining your own request for back-out > by claiming that what happens at different zoom levels has bearing on 91415. Maybe because the initial patch was not about the triangle, but about the scaling? In both cases, the area of the comment indicator gets bigger, not smaller; it covers more, not less, and the zoom feature is now less effective to solve the original problem than it was before. I am being clear; I am providing logical reasons to being against the committed change. I am talking about a specific change that was pushed to solve a specific report. If we are going to discuss a different problem, lets first agree here that the relevant change doesn't – or rather, "don't", because there is the triangle shape and the scaling – solve the report it was supposed to solve. If there is a problem for some users to even notice that a comment indicator is present, then lets discuss _that_. I don't have such problem, but I don't oppose logical discussions and I don't claim that my situation is the same as for everyone else. But _that_ was not the reason for the change to scale the comment indicator, nor the bigger triangle shape. There was no reason, other than someone (or several people) thinking that scaling the comment indicator would solve the problem. It doesn't, and users of Calc with enough experience know that at some point or another, some artifact might bother the clear reading of some cell. There are solutions in place already (e.g. for "###", expand the width of the column, among other things, including the zoom factor).
Created attachment 185865 [details] Screencast We discussed the topic in the design meeting. It's clear that zooming out is supposed to make the indicator less overlapping. Although some comments here argue that we should find alternatives. The introduced triangles are widely appreciated and in fact make better use of the the space than rectangles. A compromise might be to adjust the steps. Screencast with a proposal attached.
(In reply to Heiko Tietze from comment #24) > Created attachment 185865 [details] > Screencast > > We discussed the topic in the design meeting. > > It's clear that zooming out is supposed to make the indicator less > overlapping. Although some comments here argue that we should find > alternatives. The introduced triangles are widely appreciated and in fact > make better use of the the space than rectangles. > > A compromise might be to adjust the steps. Screencast with a proposal > attached. I thought the meeting was on the 15th, next week. Regarding the screencast, I'm not sure what I am suppose to look at. In the first row, I see text that demands more space than the width of the column, which is not related to the current topic. Then there are cells with numbers or text, with two kinds of triangles, in opposite corners. Are users trying to read the content of each cell when the zoom factor is, say, 40%? I don't know how I am supposed to compare the 2 situations. Is the height of the cells increased? IDK. Anyway, I have repeated the logical arguments several times already, just to answer to the same viewpoints that were not really solving the original "problem". My guess is that not many are actually reading them. And I keep investing my time too. === Let me propose a simple alternative === Having the possibility to display/hide the comment indicator, not just within the Options dialog (where it currently resides), but in the menu and/or the toolbar (as comments themselves currently are). To be clear, this would be independent to whether to display or to hide the comments themselves. Being able to toggle the comment indicators "on/off" in (rapid) sequence helps to notice the presence of a comment indicator (for Eyal) and it also helps when the content of a cell is not readable because it clashes with the comment indicator: the user turns it off for a second, reads the content of the cell and brings the comment indicator on again. With this alternative, you can leave the comment indicator just as it was until LO 7.5.
(In reply to ady from comment #25) > I thought the meeting was on the 15th, next week. LO has a design mailing list in which the session agenda is announced in advance (hopefully a week or so in advance): https://listarchives.libreoffice.org/global/design/ but I assure you that in the meeting, it was stressed that we want to reach a resolution which everyone can live with, and it wasn't as though we were saying the final word on the matter. > Regarding the screencast, I'm not sure what I am suppose to look at. Please look at several things: 1. The readability of the text before any zoom, with the triangle. 2. How the triangle "recedes" from the text as you zoom in 3. How the triangle grows as you zoom in - but not as much as the text (and not as much as in your screenshots) and see also my comments below about our compromise proposal. (In reply to Heiko Tietze from comment #24) > It's clear that zooming out is supposed to make the indicator less > overlapping. Zooming out may not be "supposed to" reduce overlap, but it's clearly _useful_ that it does that. So, as we were thinking about how Heiko's commied scaling triangles look, and how no-scaling triangles look (my position of partial backout of the patch), two things occurred to us: * We could scale _partially_, i.e. the triangle grows slower than the text as the zoom increases. * Even without any scaling, the triangle visibility improves somewhat when increasing the zoom. this creates a spectrum between the two extremes (Ady's request and Heiko's patch) - and we believe it should be possible to satisfy everyone with some point on this spectrum. This is doubly true because, regardless of scaling, the use of triangles already improves visibility _and_ seems to improve readability relative to the square form, at any size.
(In reply to Eyal Rozenberg from comment #26) > LO has a design mailing list in Yes, and the meeting was for the 15th according to the list. > but I assure you that in the meeting, it was stressed that we want to reach > a resolution which everyone can live with, and it wasn't as though we were > saying the final word on the matter. UX is no longer CC'ed. > > > Regarding the screencast, I'm not sure what I am suppose to look at. > > Please look at several things: > > 1. The readability of the text before any zoom, with the triangle. > 2. How the triangle "recedes" from the text as you zoom in > 3. How the triangle grows as you zoom in - but not as much as the text (and > not as much as in your screenshots) If I had a sample file that triggered the original request, I would had imitated the conditions in my 4 screenshots (same font type and size, same cell size, same zoom factor). But we don't have it, IIRC. There is no real method for me to objectively compare, unless I can reproduce the effects with the current (LO 7.5) indicator vs the newly proposed one. > > and see also my comments below about our compromise proposal. > > (In reply to Heiko Tietze from comment #24) > > It's clear that zooming out is supposed to make the indicator less > > overlapping. > > Zooming out may not be "supposed to" reduce overlap, but it's clearly > _useful_ that it does that. Both statements seem either incorrect, or we are using different terminology. > > So, as we were thinking about how Heiko's commied scaling triangles look, > and how no-scaling triangles look (my position of partial backout of the > patch), two things occurred to us: > > * We could scale _partially_, i.e. the triangle grows slower than the text > as the zoom increases. > * Even without any scaling, the triangle visibility improves somewhat when > increasing the zoom. These go against "solving" the original problem. > > this creates a spectrum between the two extremes (Ady's request and Heiko's > patch) - and we believe it should be possible to satisfy everyone with some > point on this spectrum. > > This is doubly true because, regardless of scaling, the use of triangles > already improves visibility _and_ seems to improve readability relative to > the square form, at any size. Please carefully re-read the 2 topics (and now a third with the request to make the comment indicator more prominent, in some sense going partially against the original "problem". I have already explained this in detailed multiple times. The triangle was supposed to be smaller, not bigger, and the scaling shouldn't had been part of the "solution", because of the negative consequences and because it still doesn't solve the original issue. We don't seem to be trying to solve the original problem anymore. In comment 25 I proposed a real solution from the POV of users. It is also proposed as one alternative in the other topic.
(In reply to ady from comment #27) > (In reply to Eyal Rozenberg from comment #26) > > LO has a design mailing list in > > Yes, and the meeting was for the 15th according to the list. The agenda for 15th March does not contain this topic: https://listarchives.tdf.io/i/kVptNEI6ppZyiNJvqYwgocdV It also linked to the agenda of the 9th, saying "The next meeting is on Thursday Mar/09...". The earlier agenda was announced on 28 Feb.
(In reply to Buovjaga from comment #28) > The earlier agenda was announced on 28 Feb. OK, TY. My bad. At any rate, UX is no longer CC'ed. My proposed alternative to the original problem (plus the other alternative solutions that are already available without any change at all) are effectively set aside. The original problem is no longer part of the discussion.
(In reply to ady from comment #25) > Having the possibility to display/hide the comment indicator, not just > within the Options dialog (where it currently resides), but in the menu > and/or the toolbar (as comments themselves currently are). Acceptable compromise; I wonder if the "distraction-free mode" should be enabled temporary while a key is pressed or be some combined on/off switch. The bottom-left indicator marks cells with formula, recently introduced, the top-right comments. If we introduce true threaded comments and make the current one notes, as done by Excel, another type (or rather flavor) of information is added. And we should discuss whether to hide the content overflow indicator too (middle right triangle). The option to be introduced should replace the current view options, while the tools > options set the default.
(In reply to ady from comment #27) > In comment 25 I proposed a real solution from the POV of users. It is also > proposed as one alternative in the other topic. Like Heiko, I also support your suggestion of having a readily-available comment indicator toggle. With that said... 1. We need to discuss what it's going to toggle, since we also have the formula indicator and the clipped-extra-text indicator. 2. This should resolve the grievance about the indicator interfering with reading the text, but it does nothing to address the desire/need to make the comment indicator more visible and eye-catching (which you may not share, but many/most users do share). So, if that's implemented, we still want to have the comment indicator be a triangle, which scales to some extent when zooming in. > (In reply to Eyal Rozenberg from comment #26) > UX is no longer CC'ed. Because a UX evaluation was conducted. Heiko is CCed, as am I, and other key QA people - Stuart and Ilmari. Also, it is possible to bring up bugs for repeated discussion by setting their needUXeval flag and adding the UX-advise list as a CC. (Please don't do that though, we're having a discussion here.) > There is no real > method for me to objectively compare, unless I can reproduce the effects > with the current (LO 7.5) indicator vs the newly proposed one. Heiko, would you mind attaching the ODS file used in the screencast, to make it easier for Ady to evaluate our proposal? > If I had a sample file that triggered the original request, It's a file with a cell with the number 13 in it. You can generate that and play with the zoom effects to your heart's content...
(In reply to Eyal Rozenberg from comment #31) > 1. We need to discuss what it's going to toggle, since we also have the > formula indicator and the clipped-extra-text indicator. Toggling comments is already available in menu and toolbar. You can have similar icons and menu entries for each kind of cell's "meta" info (comment indicator, formula indicator, comments, etc.), and one additional icon (and menu entry) to toggle all of these on/off. Have a sidebar too. The icons could be individual and/or have them all arranged together (similar to borders' icons, for instance). Some users might eventually ask for shortcuts. I would direct them to the Customize > keyboard dialog instead. > 2. This should resolve the grievance about the indicator interfering with > reading the text, but it does nothing to address the desire/need to make the > comment indicator more visible and eye-catching (which you may not share, > but many/most users do share). So, if that's implemented, we still want to > have the comment indicator be a triangle, which scales to some extent when > zooming in. "Eye catching, but for one moment only, then leave me alone and don't interfere with my view nor my work". A user would toggle in (rapid) succession the relevant icon or keyboard shortcut. Having even the current square on/off raises its contrast (because we respond visually much better to dynamic view vs static). If I have a "wrong" cell size, any artifact might clash with the content of the cell (even borders themselves could). Same goes for font type and font size, and alignment. I also presented additional alternatives for that other problem in the relevant topic. The area that the indicator covers doesn't need to be bigger in order to be more notable. In particular, I presented in that topic the possibility of "blinking". Think about a toggle for "blinking" the indicators. I wrote additional options in bug 154080 (such as timed blinking). You could also add some "bigger size when hovering over/closed to a cell", or different color, or shape (while hovering on/close to the cell _only_). IMHO, this is more distracting, not just letting the indicator be more discover-able. Other spreadsheet tools have additional info displayed, not _within_ the relevant cell but around it, and only when hovering. This behavior of displaying additional indicators is also a "toggle", on/off. But, beware not to increase the request for so many (graphic) resources that makes older systems unusable for LO. > > > (In reply to Eyal Rozenberg from comment #26) > > UX is no longer CC'ed. > (Please don't do that though, we're having a > discussion here.) OK. I wasn't planning on it anyway. > > > There is no real > > method for me to objectively compare, unless I can reproduce the effects > > with the current (LO 7.5) indicator vs the newly proposed one. > > Heiko, would you mind attaching the ODS file used in the screencast, to make > it easier for Ady to evaluate our proposal? The ods helps because anyone can replicate _all_ the attributes. Eyal previously mentioned that my screenshots were not a good enough representation of the original problem. That's because I am not using an inadequate combination of cell's height / width, font type, font size, alignment, and zoom factor. This is why I am convinced that the real (original) problem is on the user's side. There is a limit how much a UI can do without negatively affecting others; spoon-feeding cannot be endless. The way I previously generated the 4 screenshots was by using 7.6alpha vs 7.4.x. One has the patch, and the other still uses the current indicator. I simply used the same exact attributes in both versions. Now, even if I had the ods file from Heiko, I cannot compare it to the indicator seen in the screencast, because I don't have a version of Calc that generates them. After all, I am a simple final user, not a developer. > > > If I had a sample file that triggered the original request, > > It's a file with a cell with the number 13 in it. You can generate that and > play with the zoom effects to your heart's content... Not the same as having the ods (as I would had asked from the original reporter to attach). I could post an example of an incoherent cell size, font, alignment, even without comment indicator, and then we could all see that the real problem is on the user's side. As I explained, having the ods file would not be enough (for me) in this case, unfortunately.
We do have a checkbox to switch off the comment indicator at tools > options > calc > view (going to move this into application color, bug 154080). We can discuss means to quickly switch this option on/off in a different ticket. Resolving this one now as we will not remove the comment indicator patch, as requested here.