Description: change names of some conditions for "Cell value is" in dialogue "Conditional Formatting": top 10 elements -> top N elements bottom 10 elements -> bottom N elements top 10 percent -> top elements in percents from all bottom 10 percent -> bottom elements in percents from all reasons: 1. For "10 elements" you should enter number of elements in right field and conditional formatting will be apply not for top/bottom 10 elements and will apply for entered custom numbers 2. For "10 percent" you should enter percent in to right field and conditional formatting will be apply not for top 10 percent (percent from what??!) and will apply with cells, that will be contain max/min value from range anr their amount will equal (count of cell in range) * (entered custom percent) Steps to Reproduce: 1. Open dialogue Conditional Formatting and try to use these four variants of conditions Actual Results: we have four conditions with wrong names, that not understandable for users Expected Results: we must have names of conditions, that will be "to say" with users Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36
Yes, the condition is unclear with the text as it doesn't states any need to enter a value. And the limitation to 10 is actually wrong as you can have less or more items. So we should do what Kompilainenn suggest. Plus, the field should be filled with a default value, e.g. 5, to have some effect when setting this option. And ideally the value is implemented as a constrained numerical edit for values above 0. Is that feasible, Timur? The function is not well documented, so CC'ing Olivier. And Sophie for l10n/i18n.
(In reply to Heiko Tietze from comment #1) > Yes, the condition is unclear with the text as it doesn't states any need to > enter a value. And the limitation to 10 is actually wrong as you can have > less or more items. So we should do what Kompilainenn suggest. Plus, the > field should be filled with a default value, e.g. 5, to have some effect > when setting this option. And ideally the value is implemented as a > constrained numerical edit for values above 0. Is that feasible, Timur? > > The function is not well documented, so CC'ing Olivier. And Sophie for > l10n/i18n. These names come directly from Excel and where selected to make the behavior more consistent with the Excel UI, see e.g. https://exceljet.net/lessons/how-to-highlight-top-and-bottom-values
(In reply to Markus Mohrhard from comment #2) > > These names come directly from Excel and where selected to make the behavior > more consistent with the Excel UI, see e.g. > https://exceljet.net/lessons/how-to-highlight-top-and-bottom-values I don't agree. We should make LibreOffice better than MSO. In Excel for this case field "10 elements" already contains number 10 be default, therefore it is name of field. In Calc this field is empty by default and field name is "10 elements" all the same. I offer make better, than in Excel, and rename fields in Calc to the more obvious
Don't reopen this bug again!
kompilainenn, if senior LO member makes a decision, you may object and comment and ask for a rethink, but not reopen the bug yourself. Please see https://www.documentfoundation.org/governance/. You may use "Search By People" at https://bugs.documentfoundation.org/query.cgi?format=advanced to see the contributions. Thank you.
In Excel, there is a button that reads "Top 10 elements", which inserts a rule for top N elements, where N is 10; this is a "specialization" of a generic rule, which allows to quickly insert some "useful" value. After inserting, if one changes the 10 to, say 20, the rule in the management dialog starts to read "Top 20 elements". And Excel doesn't look stupid doing that. In Calc, we try our best to look stupid by hard naming a rule "Cell value is: Top 10 elements: 20". Undoubtedly, it increases consistency with Excel.
(In reply to Timur from comment #5) > kompilainenn, if senior LO member makes a decision, you may object and > comment and ask for a rethink, but not reopen the bug yourself. > Please see https://www.documentfoundation.org/governance/. > You may use "Search By People" at > https://bugs.documentfoundation.org/query.cgi?format=advanced to see the > contributions. > Thank you. And what should I see by your link? I see, that I'm TDF member and Markus not. Where should I see, that Markus has more weight in community or may be that he is "mr.always right"? Yes, Markus wrote huge number of code in our project. I know about this. But, this does not give him the right to consider his point of view the only true.
At the risk of kicking hornet's nest, people please reopen this bug. The user experience here is really abyssmal Selecting e.g. 'Top 10 elements' from the list * it is almost impossible for the user to figure out they can change '10' to a different value * the field where this can be done is not labelled (and with some widget themes, it is almost invisible) * once changed to a different value, the listbox value still says 'Top 10 elements' even if this is no longer the case * "the field should be filled with a default value" <= oh yes, so much this! Addionally, suboptimal user interface often goes hand in hand with suboptimal a11y and it is true about many controls in this dialog that they are not properly labelled and thus completely invisible to screenreaders Sure you can always invoke Bubli's 1st law of interoperability ("If MSO does the thing, it can't be bad") and one can always say, users are lazy to learn, they want to see familiar UI, but come on people, LibO can and should do better So pretty please at least: label the field and fill it with the default value
We discussed the topic in the design meeting and agree to modify the label. "Top n elements" is simple to change, easy to understand, and improves the UI; the workflow is different to Excel in details anyway according comment 6 and comment 8.
heiko tietze committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f5b7eb35bfbb80690d6d8191336e14859b9e4d60 tdf#117647 - Conditional formatting of "Top 10..." misleading It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.