Bug 107141 - Proposal about First condition is not a good way to identify conditions in Manage Conditional Formatting(MCF)
Summary: Proposal about First condition is not a good way to identify conditions in Ma...
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.3.2.2 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks:
 
Reported: 2017-04-13 13:31 UTC by pajaro
Modified: 2017-06-26 20:28 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
CF name mockup 1 (26.83 KB, image/png)
2017-04-13 13:31 UTC, pajaro
Details
CF name mockup 2 (28.57 KB, image/png)
2017-04-13 13:31 UTC, pajaro
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pajaro 2017-04-13 13:31:15 UTC
Created attachment 132537 [details]
CF name mockup 1

In #105542 I was commended to make a propoposal

A simple Name attached to the conditions. Or even a optional description (not showed in mockup)

After this, showing the first condition its not really needed
Comment 1 pajaro 2017-04-13 13:31:44 UTC
Created attachment 132538 [details]
CF name mockup 2
Comment 2 Buovjaga 2017-04-13 19:48:54 UTC
Design team: what do you think?
Comment 3 Heiko Tietze 2017-04-14 09:28:40 UTC
To rephrase the request:

* the dialog Manage Conditional Format identifies the conditions based on the type
* varying properties of the type are not shown in this dialog; the user has to go into the edit mode
* when more than one condition is used only the first is listed

Example: 
A1:A10 ColorScale (in red-yellow-green)
B1:B10 ColorScale (green-blue for <10 and magenta-pink for >10)

Suggested solution is an additional property "name" that _can_ be used for identification of the condition (otherwise the old behavior is kept).

Example: 
A1:A10 "TrafficLight"
B1:B10 "G2B for <10, ugly colors above"

If there is no restriction from the file format I think that makes sense (-> NEW). 

Alternatively, a tooltip or even better another column could show the key properties (we have plenty of space in this dialog). The more elaborated solution is a WYSIWWYG preview where ColorScale, for instance, is replaced by a symbolic representation of the colors. To show more than one condition the dialog needs to get closer to the edit box, ultimately making it obsolete. That means the conditions and properties for the selected range are shown (and edit) inline. If there is need for an overview of many ranges we could go with a tree rather than the current accordion style.

On the other hand a lot of effort for information that is just a double-click away. The simple naming might be a good compromise.
Comment 4 Markus Mohrhard 2017-06-26 20:28:48 UTC
I"m sorry but this will not be implemented. This just causes interoperability issues and I see no use. Conditional formats are not identified through the condition but through the range.