Bug 87538 - COLOR PICKER: New default color palette
Summary: COLOR PICKER: New default color palette
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.5.0.0.alpha0+ Master
Hardware: Other All
: medium enhancement
Assignee: Heiko Tietze
QA Contact:
URL:
Whiteboard: target:5.4.0 target:5.3.0.1
Keywords: needsUXEval
Depends on:
Blocks: Color-Picker-Widget Color-Palettes
  Show dependency treegraph
 
Reported: 2014-12-20 22:15 UTC by Yousuf Philips (jay)
Modified: 2017-04-13 14:45 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
what the new palette would look like (18.69 KB, image/png)
2014-12-20 22:15 UTC, Yousuf Philips (jay)
Details
color palettes used in other office suites (22.63 KB, image/png)
2014-12-20 22:18 UTC, Yousuf Philips (jay)
Details
RGB color palette (320.18 KB, image/png)
2014-12-20 22:44 UTC, Yousuf Philips (jay)
Details
Color wheel base (17.38 KB, image/png)
2014-12-20 23:06 UTC, Yousuf Philips (jay)
Details
onlyoffice color palette (61.91 KB, image/png)
2015-03-20 15:18 UTC, Yousuf Philips (jay)
Details
Screenshot of new standard palette (6.21 KB, image/png)
2017-02-18 23:38 UTC, Heiko Tietze
Details
Porposed new standard palette (7.04 KB, application/xml)
2017-02-18 23:39 UTC, Heiko Tietze
Details
Perfect palette (7.45 KB, image/png)
2017-02-19 20:40 UTC, Heiko Tietze
Details
Perfect palette - soc (7.07 KB, application/xml)
2017-02-19 20:41 UTC, Heiko Tietze
Details
RYB 8 and 7 variants soc files (2.85 KB, application/zip)
2017-02-25 22:58 UTC, Yousuf Philips (jay)
Details
document with tables showing the RYB 7 and 8 variants (22.58 KB, application/vnd.oasis.opendocument.text)
2017-02-25 23:00 UTC, Yousuf Philips (jay)
Details
RYB screenshot (13.96 KB, image/png)
2017-02-26 09:54 UTC, Heiko Tietze
Details
Extension with luminance variation (9.22 KB, application/vnd.openofficeorg.extension)
2017-02-26 11:59 UTC, Heiko Tietze
Details
Extension with saturation variation (9.28 KB, application/vnd.openofficeorg.extension)
2017-02-26 11:59 UTC, Heiko Tietze
Details
how color widget looks for me (18.49 KB, image/png)
2017-03-02 10:30 UTC, Yousuf Philips (jay)
Details
complete version of my proposal mentioned above (2.69 KB, image/png)
2017-03-14 00:03 UTC, tomaskeb
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) 2014-12-20 22:15:30 UTC
Created attachment 111090 [details]
what the new palette would look like

The current default color palette (standard.soc) used in LO has 167 colors across 14 rows and this is way to many colors for users to choose from, and the new color picker drop down only showing 10 rows at a time also doesnt help the situation.

I would like to suggest that we crop this list to 8 rows by taking the first 7 rows and row 12. Also in the first row, we should move the black color to the right end of the row so the gradient is consistent on that row.
Comment 1 Yousuf Philips (jay) 2014-12-20 22:18:55 UTC
Created attachment 111091 [details]
color palettes used in other office suites
Comment 2 Yousuf Philips (jay) 2014-12-20 22:44:29 UTC
Created attachment 111092 [details]
RGB color palette

An alternative is to convert the attached palette into a suitable sized palette that suits our purposes. Likely 12x8.

Palette taken from < http://websafecolorcodes.com/colors-palette/color-wheel-palette/ >
Comment 3 Yousuf Philips (jay) 2014-12-20 23:06:54 UTC
Created attachment 111095 [details]
Color wheel base

Another alternative is to simply use the attached color palette along with a white to black gradient row.
Comment 4 V Stuart Foote 2014-12-21 15:18:55 UTC
@Jay, *,

I'm not opposed to this. But if the color picker at 12 columns but showing just 10 rows is a problem, it might be a better option to expand number or rows, or even columns shown.

Q: what would be the best layout of the color picker to accommodate a new standard.soc pallet? 

And, regards the standard.soc pallet, two issues with that:

1.) kind of feel like we are obliged to support our LibreOffice branding, https://wiki.documentfoundation.org/Marketing/Branding#Color_Table most of which are in our standard.soc table now.  Reworking as you suggest probably would require that we move this entire branding color chart into its own pallet--an addition to your bug 87541 suggestion. Leaving us free to reduce and adjust the standard.soc;

2.)  Wade Peterson's did some very compelling work for a device neutral color pallet, in bug 80196 -- it could/should occupy the lower rows of the standard pallet.

@Wade, @Owen opinions please...

Stuart
Comment 5 Yousuf Philips (jay) 2014-12-21 18:02:41 UTC
(In reply to V Stuart Foote from comment #4)
> I'm not opposed to this. But if the color picker at 12 columns but showing
> just 10 rows is a problem, it might be a better option to expand number or
> rows, or even columns shown.

Expanding the number of rows doesnt solve the primary problem with the color palette, which is that there are two many colors in it. Most users need a small range of colors to choose from and now that we have the color picker dialog available in the drop down, those that want to choose an exact color now have easy access to doing so.

> Q: what would be the best layout of the color picker to accommodate a new
> standard.soc pallet?

I believe the current layout of 12 columns is fine, as all three of the suggestions fit it.

> 1.) kind of feel like we are obliged to support our LibreOffice branding,
> https://wiki.documentfoundation.org/Marketing/Branding#Color_Table most of
> which are in our standard.soc table now.  Reworking as you suggest probably
> would require that we move this entire branding color chart into its own
> pallet--an addition to your bug 87541 suggestion. Leaving us free to reduce
> and adjust the standard.soc;

We have a libreoffice.soc and i would have assumed it does cover any colors related to the branding.

> 2.)  Wade Peterson's did some very compelling work for a device neutral
> color pallet, in bug 80196 -- it could/should occupy the lower rows of the
> standard pallet.

Seems interesting and it would be great for Wade to fill in the upper rows so it could be put into an .soc file so it could be tried.
Comment 6 Owen Genat (retired) 2014-12-22 03:13:08 UTC
I tend to agree with Stuart. These are the problems I see:

- We should not be limiting users from creating custom palettes with greater than 8 rows or a set number of swatches. The user mailing list has some threads with very large palette file attchments containing many hundreds of swatches. I am not a fan of these SOCs but people do create and use them. For example, it would be unlikely that the Inkscape palette would fit within 8 rows.

- A scrollbar should appear for palettes with a greater numbers of rows than can be displayed. If anything the color picker dialog should resize, as possible, to display the largest number of rows / swatches.

- Palette swatches in the current standard.soc affect legacy documents. There would at least need to

- Given the format of the XML entries it is both more logical and easier IMO to create palettes on a hue-per-row than hue-per-column basis. I explain the reasons for this in bug 80196. It certainly makes it easier to have a block of entries named "10% Magenta", "20% Magenta", rather than have such entries broken up one to a block.

- Unless the colour picker layout reaches some sort of stability (so far there is no sign of this occurring) the number of rows displayed and the creation of SOC files to suit a given layout will remain problematic.
Comment 7 Owen Genat (retired) 2014-12-22 03:19:53 UTC
(In reply to Owen Genat from comment #6)
> - Palette swatches in the current standard.soc affect legacy documents.
> There would at least need to

... be a separate palette created to include the excluded swatches. This could easily become messy.
Comment 8 Yousuf Philips (jay) 2014-12-22 08:13:01 UTC
(In reply to Owen Genat from comment #6)
> - We should not be limiting users from creating custom palettes with greater
> than 8 rows or a set number of swatches. The user mailing list has some
> threads with very large palette file attchments containing many hundreds of
> swatches. I am not a fan of these SOCs but people do create and use them.
> For example, it would be unlikely that the Inkscape palette would fit within
> 8 rows.

There hasnt been any discussion in this bug report about limiting the number of rows to 8 for custom palettes. We were discussing what the default palette should be and ideally how many rows it should occupy.

> - A scrollbar should appear for palettes with a greater numbers of rows than
> can be displayed. If anything the color picker dialog should resize, as
> possible, to display the largest number of rows / swatches.

The scrollbar does appear when there are more than 10 rows in a palette, so there isnt a need for the dialog to resize to accommodate more rows. The dialog currently takes up 360 pixels, which is 40% of my screen height, and each color row takes up 18 pixels. Available palettes that are more than 10 rows are web.soc (20 rows), scribus.soc (46 rows), cmyk.soc (18 rows), html.soc (11 rows), and standard.soc (14 rows).

> - Palette swatches in the current standard.soc affect legacy documents.
> There would at least need to be a separate palette created to include the
> excluded swatches. This could easily become messy.

We discussed this issue in the weekly design meeting a few weeks back and it will not negatively effect legacy documents, as the colors are stored in the documents as their rgb values, but yes we should duplicate the current standard.soc as a new palette file if we change the default palette.

> - Given the format of the XML entries it is both more logical and easier IMO
> to create palettes on a hue-per-row than hue-per-column basis. I explain the
> reasons for this in bug 80196. It certainly makes it easier to have a block
> of entries named "10% Magenta", "20% Magenta", rather than have such entries
> broken up one to a block.

The XML format simply provides the details of the palette colors, but not the manner in which it should be displayed. Most color palettes have gradients going top to bottom or bottom to top and i feel that is best to stick with this norm. Even LO's color picker dialog shows it in this manner when hue, saturation or brightness are selected.

> - Unless the colour picker layout reaches some sort of stability (so far
> there is no sign of this occurring) the number of rows displayed and the
> creation of SOC files to suit a given layout will remain problematic.

I think SOC files should define the number of columns per row, so that color palettes which were designed with a specific number of entries per row that isnt 12 (e.g. 10 or 16) can be shown as they were designed.
Comment 9 V Stuart Foote 2014-12-22 15:21:30 UTC
(In reply to Jay Philips from comment #8)
> (In reply to Owen Genat from comment #6)
> > - Unless the colour picker layout reaches some sort of stability (so far
> > there is no sign of this occurring) the number of rows displayed and the
> > creation of SOC files to suit a given layout will remain problematic.
> 
> I think SOC files should define the number of columns per row, so that color
> palettes which were designed with a specific number of entries per row that
> isnt 12 (e.g. 10 or 16) can be shown as they were designed.

Actually that would be a very valid UI change for the ColorPicker. 

In https://bugs.freedesktop.org/show_bug.cgi?id=80196#c19 Owen had to rotate the pallet because that scheme would require 13 columns rather than the 12 he had to work with in demonstrating Wade's proposal. 8-10-12-13-16 columns all might result in appealing pallets to work with.

Q: Can the Widget for the ColorPiker be made dynamic to respond to the .SOC? 

Q: Failing that, could we agree change the ColorPicker column count to match what ever best fits our new standard.soc?
Comment 10 Yousuf Philips (jay) 2014-12-23 03:15:25 UTC
(In reply to V Stuart Foote from comment #9)
> Actually that would be a very valid UI change for the ColorPicker. 
> 
> In https://bugs.freedesktop.org/show_bug.cgi?id=80196#c19 Owen had to rotate
> the pallet because that scheme would require 13 columns rather than the 12
> he had to work with in demonstrating Wade's proposal. 8-10-12-13-16 columns
> all might result in appealing pallets to work with.

When i looked at Wade's proposal, my first instinct was to have white to black as the first row of the palette and then have the colored ones going columns wise, as that is similar to how our current palette is now and white to black is not a color blend which could fit next to the other color range column wise.

> Q: Can the Widget for the ColorPiker be made dynamic to respond to the .SOC? 

You would likely have to ask a dev familiar with the code to know this, but i dont think the drop down width changing multiple times when you go from palette to palette would be a good thing. What i think would work is that size of the palette color boxes change depending on the the number of columns per row. If we can set width of the palette color area to 230 pixels, we can accommodate 16 columns at 10x10, 12 columns at 14x14, and 10 columns 18x18 (these numbers are excluding the 2 pixels padding on the left and right of each color palette box).

> Q: Failing that, could we agree change the ColorPicker column count to match
> what ever best fits our new standard.soc?

Yes it should primarily accommodate whatever is our default color palette optimally, as other palettes are secondary, though i believe that a 12 column palette will cover all the bases we need and we will have 3 other 12 column palettes also in the palette list (web.soc, cymk.soc, and the current standard.soc).
Comment 11 Yousuf Philips (jay) 2015-01-08 10:14:40 UTC
Came across a tweet today of someone doing a color palette based on google's material design colors. https://twitter.com/boky8/status/553123925497225216

I've created a #libreoffice color palette that does not suck, based on #materialdesign. Get it here: https://imgur.com/gb96Uoa
Comment 12 Yousuf Philips (jay) 2015-03-20 15:18:42 UTC
Created attachment 114210 [details]
onlyoffice color palette

stumbled on this today. :D
Comment 13 V Stuart Foote 2015-03-20 15:44:33 UTC
(In reply to Jay Philips from comment #12)
> Created attachment 114210 [details]
> onlyoffice color palette
> 
> stumbled on this today. :D

Details? Is it a .soc that you're proposing to add? Can you attach it, or you've only just a screen clip?
Comment 14 Yousuf Philips (jay) 2015-03-20 19:55:11 UTC
(In reply to V Stuart Foote from comment #13)
> Details? Is it a .soc that you're proposing to add? Can you attach it, or
> you've only just a screen clip?

Saw it while i was watching this youtube video.

https://www.youtube.com/watch?v=KZCzXZKWfzw&t=22
Comment 15 Robinson Tryon (qubit) 2016-08-25 05:26:50 UTC
We're replacing our use of the 'ux-advise' component with a keyword:
 Component -> LibreOffice
 Add Keyword: needsUXEval

[NinjaEdit]
Comment 16 Commit Notification 2016-12-19 15:19:48 UTC
heiko tietze committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=765826abcaa441d4d90ffbe75bc3c626c42e639b

tdf#87538 New standard color palette, tdf#104052 Add LibreColour HLC palette

It will be available in 5.4.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.
Comment 17 Commit Notification 2016-12-22 14:38:27 UTC
heiko tietze committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=89488baf09d2e7580041462b409f587ce43af214&h=libreoffice-5-3

tdf#87538 New standard color palette, tdf#104052 Add LibreColour HLC palette

It will be available in 5.3.0.1.

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.
Comment 18 Heiko Tietze 2017-02-18 10:35:01 UTC
Jay reopened the ticket because of missing pastel tones. Similar request comes from the blog post https://design.blog.documentfoundation.org/2016/12/30/new-color-palettes-in-libreoffice/#comments linking to http://www.imgup.cz/images/2016/12/30/proposal.png.
Comment 19 Heiko Tietze 2017-02-18 23:38:51 UTC
Created attachment 131330 [details]
Screenshot of new standard palette

With another algorithm to modify luminance it looks more flexible now. First lines are gray scale and basic colors, followed by saturation of 60%, 30%, and 15% and then luminance increased by 9.5, 7.5 and 5.0. Push or change?
Comment 20 Heiko Tietze 2017-02-18 23:39:28 UTC
Created attachment 131331 [details]
Porposed new standard palette

And the palette itself.
Comment 21 Heiko Tietze 2017-02-19 20:40:03 UTC
Created attachment 131342 [details]
Perfect palette

Hopefully the final version.

Row #1: Grey scale (White, Gray 1..10, Black)
#2 basic colors (Blue to Violet)
#3 50% saturation (<Blue> 50% Sat)
#4 25% saturation (<Blue> 25% Sat)
#5 x8 luminance (<Blue> x8 Lum)
#6 x5 luminance (<Blue> x5 Lum)
x7 -x5 luminance (<Blue> x1/5 Lum)
x8 -x8 luminance (<Blue> x1/8 Lum)

Saturation is done per ColorRGBToHLS(), luminance with ColorAdjustLuma().
Comment 22 Heiko Tietze 2017-02-19 20:41:10 UTC
Created attachment 131343 [details]
Perfect palette - soc

And the soc file.
Comment 23 Yousuf Philips (jay) 2017-02-25 22:58:42 UTC
Created attachment 131468 [details]
RYB 8 and 7 variants soc files
Comment 24 Yousuf Philips (jay) 2017-02-25 23:00:26 UTC
Created attachment 131469 [details]
document with tables showing the RYB 7 and 8 variants
Comment 25 Heiko Tietze 2017-02-26 09:54:33 UTC
Created attachment 131473 [details]
RYB screenshot

Serious issue is that it has one line over the max. And I miss darker colors either by reduced lumination or saturation. Difference between RYB7 and 8 is unclear to me, 7 has better distribution with bright colors, 8 is better at darker. Both make rose and magenta rather a red and the red morphs into orange.
Comment 26 Heiko Tietze 2017-02-26 11:59:11 UTC
Created attachment 131474 [details]
Extension with luminance variation

If we go with a different standard palette the variations of saturation and luminance should be available as an extension.
Comment 27 Heiko Tietze 2017-02-26 11:59:39 UTC
Created attachment 131475 [details]
Extension with saturation variation
Comment 28 Yousuf Philips (jay) 2017-03-02 10:30:43 UTC
Created attachment 131574 [details]
how color widget looks for me

(In reply to Heiko Tietze from comment #25)
> Serious issue is that it has one line over the max.

I have 9 rows, so not over the max. The max seems to have been jumping up and down between versions for some strange reason.

> And I miss darker colors either by reduced lumination or saturation.

We have a limited number of rows, so we can please everyone, we just need the colors to be sorted from lighter to darker.

> Difference between RYB7 and 8 is
> unclear to me, 7 has better distribution with bright colors, 8 is better at
> darker.

I find the colors better in 8, specifically the red's in 7 look more orangish.

> Both make rose and magenta rather a red and the red morphs into orange.

Rose and magenta are RGB colors variants and not RYB.
Comment 29 tomaskeb 2017-03-14 00:03:28 UTC
Created attachment 131869 [details]
complete version of my proposal mentioned above
Comment 30 Heiko Tietze 2017-03-14 07:51:43 UTC
(In reply to tomaskeb from comment #29)
> Created attachment 131869 [details]
> complete version of my proposal mentioned above

Unfortunately you are a bit late https://design.blog.documentfoundation.org/2017/03/12/survey-standard-palette/. And actually I miss the grey scale.
Comment 31 tomaskeb 2017-03-14 16:01:13 UTC
(In reply to Heiko Tietze from comment #30)
> (In reply to tomaskeb from comment #29)
> > Created attachment 131869 [details]
> > complete version of my proposal mentioned above
> 
> Unfortunately you are a bit late
> https://design.blog.documentfoundation.org/2017/03/12/survey-standard-
> palette/. And actually I miss the grey scale.

I know, but I wanted to address the fact that the saturated colors in the third variant (which seems to be the most popular) don't match the ones with different shades (e.g. there are shades of orange under red). Of course I did not intend to omit the grayscale, it was just a quick mockup that did not include it out of laziness.
Comment 32 Yousuf Philips (jay) 2017-04-06 19:48:03 UTC
Patch is in

https://gerrit.libreoffice.org/36202
Comment 33 Commit Notification 2017-04-13 14:45:41 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=78869ad9d4c904e665529befe5181ea5121fba1d

tdf#87538 New standard color palette

It will be available in 5.4.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.