Summary: | change names of some conditions for "Cell value is" in dialogue "Conditional Formatting" | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Roman Kuznetsov <79045_79045> |
Component: | Calc | Assignee: | Heiko Tietze <heiko.tietze> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | heiko.tietze, olivier.hallot, sophi, timur |
Priority: | medium | ||
Version: | 6.1.0.0.alpha1+ | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | target:6.2.0 | ||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 87351 |
Description
Roman Kuznetsov
2018-05-16 14:27:18 UTC
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. |