Bug 117647 - change names of some conditions for "Cell value is" in dialogue "Conditional Formatting"
Summary: change names of some conditions for "Cell value is" in dialogue "Conditional ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.1.0.0.alpha1+
Hardware: All All
: medium enhancement
Assignee: Heiko Tietze
URL:
Whiteboard: target:6.2.0
Keywords:
Depends on:
Blocks: Conditional-Formatting
  Show dependency treegraph
 
Reported: 2018-05-16 14:27 UTC by Roman Kuznetsov
Modified: 2018-07-26 13:34 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Kuznetsov 2018-05-16 14:27:18 UTC
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
Comment 1 Heiko Tietze 2018-05-17 09:07:02 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.
Comment 2 Markus Mohrhard 2018-07-14 00:13:39 UTC
(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
Comment 3 Roman Kuznetsov 2018-07-14 07:06:15 UTC
(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
Comment 4 Markus Mohrhard 2018-07-15 22:13:41 UTC
Don't reopen this bug again!
Comment 5 Timur 2018-07-16 08:35:02 UTC Comment hidden (obsolete)
Comment 6 Mike Kaganski 2018-07-16 09:56:13 UTC
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.
Comment 7 Roman Kuznetsov 2018-07-16 10:29:57 UTC
(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.
Comment 8 Katarina Behrens (CIB) 2018-07-17 18:09:42 UTC
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
Comment 9 Heiko Tietze 2018-07-26 08:39:27 UTC
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.
Comment 10 Commit Notification 2018-07-26 13:34:16 UTC
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.