Changing Colors behavior

[jguille2]

Hi @brianharvey,
I open a new issue to continue (and try to end) the Color discussion from #1659 and #1723 (I think you can close them)

• I agree we can look at costume effects later (in another thread), but certainly, users will expect similar behavior to the same thing: color. And we can offer the same params, ranges, wrappings...

• I've changed pen blocks name as you requested.
  
  I still like the other option (set pen color [param] to). Of course, if we only have two criteria ... yours is more important than mine. Let me explain this (it will be the last time):

  • I think pen color hue/shade/saturation/opacity are not bad. Yes, pen hue/shade/opacity are not bad too. But maybe pen saturation is really not clear.

  • We are migrating set pen color to %n block from previous projects to the new block. Maybe the change to set pen color hue to %n is more clear. And also, users using set pen color will find it easier.

  • If we try set pen param option, size is another pen param. Then maybe has no sense the separation. We can separarate color params of other params (here, the sense of color param) or build only a section.

  • Brian, for your option, do you want to build only one "set pen param to" with params= [hue, shade, saturation, opacity, size] ?

  • All these comments, also for "change" blocks

  • And for the separate option (with or without "color"), do you want to build a pen size reporter?

• I don't implement Palettes. You know I disagree to implement another pseudoHue param. But I've updated ColorPalettes into the InputMorph and into Paint Editor (with hot pink and wheat). Then, if you want to implement later your 100 palette with 20 main colors, PickerPalettes will be consistent with your idea.
  
  

Brian, if you want another change... or you want to change the order, I will do it.

• Wrappings are not clear for me.
  • Hue is clearly wrapping.
  • To make shade wrapping, I made a double scale (0-400) to ensure "soft changes". 0 is black, 0->200 increasing lightness, 200 is white, 200->400 decreasing, and 400 becomes 0 (black again). This wrapping is good. It is not a % scale, and shade is related to light (but not lightness nor darkness).
  • Saturation and Opacity are well-defined parameters, and we have a % scale. We can't get an opacity/saturation greater than 100% nor smaller than 0%. And for a "soft transition" we'll need another "double scales" (we don't want 100% +1 -> 0%)
  • Brian, I understand your idea of CHANGE BY doing always something... but when I have the full param value, I can increase it... and when I have 0% I can't decrease it... I think.

---

Let's continue...
You know changes are documented, and you can run current proposal online.

Joan

[brianharvey]

Now that the forum gang have talked me into

I withdraw my objection to you using the word "color" in the name of SET PEN COLOR [HUE etc]. :)

Also I think we should consider using the standard names and ranges for RGBHSL, e.g. 0-359 for hue, 0-255 for blue. For the fractional ones (SL) we can use percent. This doesn't change the plans about wrapping; hue wraps in the obvious way, lightness 101-200 goes backwards, etc. We would have a Scratch compatibility library that would have pen color number, pen shade, etc., on the 0-100 scale.

[jguille2]

Hi @brianharvey,
I had already forgotten all this mess...

I'm not sure what are you asking me now ??

• Now (current and proposal) hue is a 0-100 scale. In Scratch is 0-200. Do you want to change it to 0-360?
• Shade is now 0-100 (black to full color). Our proposal was 0-200 (black to white, with a 100 full color for backward compatibility). Do you want to change to percent (like Scratch, full color in 50 value)?
• RGB library is clear (0-255 values). It is the current behaviour (and also, the proposal way).

Let me know what changes I have to make.

Joan

[brianharvey]

I'm thinking if we're calling it "hue" it should be in degrees, like the rest of the world. We'll have a compatibility library that will translate "color number" (0-100) to hue 0-359.

Similarly we should have "lightness" which I guess is generally in percent, right? So 0-100, with a "shade" compatibility block that takes 0-200 (with the up-and-down wrapping of course).

And saturation in percent, right?

The compatibility blocks will be in a library; the primitives should be in real-world names and values. So, including the libraries, we'll have three distinct ways to think about color:

1. compatibility mode, just like now only HSL instead of HSV, but with Scratch names and with Snap!-compatible values.
2. expert mode, HSL/RGB in just the way everybody else does it.
3. crayon mode, in which you select a crayon by name from a pulldown menu and you see its crayon number. That, too, can be in a library.

Does that sound good?

[brianharvey]

P.S. All the fighting (for which I apologize; I fight too much) was about the meaning of "color number" and whether or not it has some connection with hue. But since I'm now thinking "crayon number" which clearly doesn't sound like anything we had before, everyone should be happy.

[cycomachead]

I'm thinking if we're calling it "hue" it should be in degrees, like the rest of the world. We'll have a compatibility library that will translate "color number" (0-100) to hue 0-359.

Similarly we should have "lightness" which I guess is generally in percent, right? So 0-100, with a "shade" compatibility block that takes 0-200 (with the up-and-down wrapping of course).

And saturation in percent, right?

I feel like this is pretty confusing. I mean, it makes sense in a way, but you do need to know that hue is a degree. If you're new to color, this difference is hard to discover.

Perhaps we can change the block spec to indicate the parameter value, by using º or % after the input.

we'll have three distinct ways to think about color:

I think this makes sense, but definitely seems a bit confusing. I'm not sure isn't any more confusing than all the other suggestions, though, so in the absence of something better, I agree.

[jguille2]

Hi,
I try to explain my thoughts about these three ways... and my doubts...

• 'Expert mode'. Yes, we can play with standard color params using a library. In fact, I already updated this lib in my proposal to 'RGB, HSV and HSLA pen colors'
  

  • RGB has 0-255 scales. Just fine and it was already fine before.
  • HLSA (new blocks). Scale: H in º (0-360), L and S in % and A in 0-1
  • HSV maintaints their scales (0-1) for backward comp.

• 'Crayons mode'. Perfect into a 'crayon lib'

• 'Simple mode'. Here is the discussion. I think we don't need to reproduce any color standard (we have the expert mode to do this). We want a simple color metaphor (from Scratch/Snap).

  • Shade is very similar to lightness but is not the same. Our wrapping causes that increasing it, sometimes is going to black, sometimes to white. For example, in a 0-200 scale, 190 is the same result than 210. But only the same result, not the same state: increasing value we'll obtain more white or more blak.
    Then, we must fix our behavior. I like a 0-100 scale (is related to % lightness and is the same in Scratch). But you know this is not the current Snap behavior... and you chose backward compatibility. Are you sure you want to change this? The only problem is compatibility: current 'full color' (100) will be white (full color will be 50%). I'll try to change 'blocksMigration' to apply this calculation automatically.

  • And 'hue'? You know Scratch is 0-200 and current Snap is 0-100. My opinion is we don't need to use 0-360º (again, we'll have the 'expert' lib to do this). Then, I like our last proposal (keeping 0-100 scale) for backward comp. But I can change it! Maybe, like 'shade case', we can choose another name to this param to distinguish it from hue? Maybe 'color value' or 'color number'...??

Last comment. When defining crayons, we must think to connect all three modes. The connection will be with the basic set of colors. Then, our palette

must have the main crayons, with a well known rgb values.

---

Finally... Pending to define clearly shade and hue

[jmoenig]

We've since changed colors and added the missing third dimension for the upcoming Snap5. I think it's okay to now close this. Thanks!

[brianharvey]

For what it's worth, I still agree with Joan about HSL vs. HSV, and we just had a user complaint that pure black and pure white aren't selectable in the color picker. I like Joan's color picker with a grayscale bar and individual buttons for black and white.

Not reopening, to not get you angry, but we (Joan and I) formerly disagreed about details but we don't any more because of the crayon library. So we have a single proposal on the table.

[jguille2]

Hi Brian and Jens,
Avoiding long discussions (:smile: ), we can update our picker with a gray scale and some basic colors (including white and black).
One ("neutral") proposal would be the 16 initial html web named colors (with well known and clear RGB values). I have added two browns.

If you agree this, I can add this picker to the ColorSlotMorph and also to the paint editors.

One question. Is the default Color(145, 26, 68) consciously chosen? If not, we can change it for one of the defined colors.

Continue after Jens holidays...

Joan

[brianharvey]

Good that Jens is on vacation so we can get the details agreed before he sees all this. :-)

About the grayscale bar, I think it should have black and white buttons at its ends, like this:

The green background is not part of it, just in the picture to clarify its extent. The middle part is a standard grayscale 0-255, but at each end is a square button of constant color, 0 at the left and 255 at the right. The yellow lines (two different yellows for contrast) aren't to choose a yellow color but just to separate the buttons from the gradient. Again, the gradient is 0-255, not 1-254, so if you manage to click exactly at an endpoint you get black or white.

As for the selection of colors at the end, I'll be unhappy if we introduce a competing set of crayons to the ones in the crayons library. Those initial 16 HTML colors were chosen, not because they're a useful palette, but because of the narrow width of color numbers on IBM PCs in the early 1980s. And one of them is hideous olive! So instead we should have the carefully chosen crayon numbers divisible by 5:

The top row is crayon numbers divisible by 10, and the second row is the first row plus 5.

If someone hates my crayon colors for some reason, we should agree on a new set so that the crayon library and the color picker agree.

There's a slight inefficiency in that there are two black buttons, one at the end of the grayscale bar and one in the crayon box. This doesn't bother me, but it also wouldn't kill me if those first three buttons were crayons 3, 7, and 11 instead of 0, 5, and 10:

It should logically be crayons 4, 8, and 12, but these ones are empirically more striking.

The reason for including black but not white in the multiple-of-5 crayon box is that most of the time the background is white, so it's not such a useful pen color (unless you're trying to erase, I guess, in which case you choose it by program, not by mouse). (White is crayon 14.)

I agree that the default color in the color picker input slot is kind of blah, and that we should pick something more vibrant. I guess the obvious choice is red, but it's not my favorite color, so I'd urge blue (crayon 80) or orange (crayon 40).

[brianharvey]

P.S. It just occurred to me that I should make room for the block colors in the 100-crayon box: Lists in the reds, Variables in the oranges, Commands in the yellows, etc.

[jguille2]

Ok, if you both agree, I will pull these changes.
Note that:

• There will be 20 colors (in my picture there were 18). So these colors will be squares of 10x10 (smaller than my example, much smaller than Brian pictures).
• I understand your first proposal is the best, according with crayons numbers.
• Maybe the yellow line is ugly, and not necessary. There will be squares of 10x10, just the same that the color bellow... and black has its own button. So, I would paint the gradient and the squares (as you request) without any dividing line.

Waiting for your decisions.

Joan

[brianharvey]

The thing about the dividing line (the yellow line you don't like) is that without it, I think it's not obvious that it isn't a continuation of the gradient, so that only the very leftmost pixel is black, and only the rightmost pixel is white. The dividing line makes it obviously a button.

I don't insist on yellow. For example, the one on the left could be white and the one on the right could be black!

(Edit: I'm actually very proud of those one-pixel-wide lines, which, I claim, make it entirely obvious what's happening without any help text required!)

[jguille2]

Ok!
I vote for those black/white one-pixel-wide lines.

[brianharvey]

Please wait a day before implementing this. Having had the idea of including the block colors, I'm rearranging the colors within a family by hue, more or less, which will affect the second row of my crayon box. Thanks.

[jguille2]

Ok, but before reading you, I was trying ...to show a result...

And doing this, only some details-questions about your crayons:

• You fix "gray26" to #5b5b5b, but CSS gray26 is #5c5c5c
• You fix "gray71" to #b6b6b6, but CSS gray71 is #b5b5b5
• Your #ff7f00 is named "orange", but really is CSS "Dark Orange 1"
• "Burnt orange" and "Rubber duck" are not CSS colors.

I know these are only details... but I question about them for the "last" proposal.

Continue....
Joan

[brianharvey]

Nice!

There are CSS colors? I started with the X11 color chart and found more colors here:
http://www.workwithcolor.com/red-color-hue-range-01.htm
and a few other places. I'll look at the CSS chart and figure out the differences.

[brianharvey]

You mean gray36, right? I'm happy to change the two grays.

The one you want to call "orange" (which is hideous) is "web orange" in my list, crayon 46. But I think that's the one I'm dropping in favor of Variables. :-)

I'll get the official new list done this afternoon. I've reordered them, too, so that other than the multiples of 5 they're either in hue order or in brightness order, whichever subjectively looks better, within each color family.

[jguille2]

Ok Brian. I wait for your reordered crayons.

But you see the problem were not in CSS vs X11. It was about official standards.

The W3C adopts CSS color module level 3. And yes X11 and CSS names are really the same. The only little conflict is between "web color names" and "x11 names".

The only important is to respect the official names. Then:

• The main X11 colors
• Variant colors
• and Shades of gray

And you see there my notes about your "gray26", "gray71" and "orange". And no notice about "Burnt orange" and "Rubber duck". And note that I only checked the 20 crayons for the picker.

Joan

[brianharvey]

I just don't like some of the choices they made. And, as for following standards, the real standard we should be following is the Crayola crayon names! So, here's the compromise: I changed the grays to what you want, and I'm keeping orange the way I want. :-P

Honestly, I started with the X11 chart, and mostly it was usable, but, for one thing, it just doesn't have enough oranges. (For the purposes of the crayon block, I don't want to use names with numbers in them.) And we now have crayons named Motion, Looks, Sound, etc., which aren't in anybody's standard list!

So, here it is:

grays={
0 black #000000=0
1 gray7 #121212=1
2 gray14 #242424=2
3 gray21 #363636=3
4 gray28 #484848=4
5 gray36 #5c5c5c=5
6 gray43 #6d6d6d=6
7 gray50 #7f7f7f=7
8 gray57 #919191=8
9 gray64 #a3a3a3=9
10 gray71 #b5b5b5=10
11 gray78 #c8c8c8=11
12 gray85 #dadada=12
13 gray92 #ececec=13
14 white #ffffff=14
}
pinks={
15 deep pink #ff1493=15
16 hot pink #ff69b4=16
17 bright pink #ff007f=17
18 raspberry #e30b5d=18
19 amaranth #e52b50=19
}
reds={
20 red #ff0000=20
21 burgundy #900020=21
22 cherry #990000=22
23 dark candy apple red #a40000=23
24 sanguine #c00000=24
25 maroon #800000=25
26 crimson #c90016=26
27 Lists #d94d11=27
28 candy apple red #ff0800=28
29 coquelicot #ff3800=29
}
browns={
30 saddle brown #8b4513=30
31 chocolate #7b3f00=31
32 kobicha #6b4423=32
33 sepia #704214=33
34 chestnut #954535=34
35 dark brown #654321=35
36 brown #964b00=36
37 golden brown #996515=37
38 copper #b87333=38
39 cinnamon #d2691e=39
}
oranges={
40 orange #ff7f00=40
41 Pantone orange #ff5800=41
42 pumpkin #ff7518=42
43 Variables #f3761d=43
44 Spanish orange #e86100=44
45 burnt orange #cc5500=45
46 sinopia #cb410b=46
47 ochre #cc7722=47
48 carrot #ed9121=48
49 tangerine #f28500=49
}
yellows={
50 yellow #ffff00=50
51 Control #e6a822=51
52 dark goldenrod #b8860b=52
53 goldenrod #daa520=53
54 saffron #f4c430=55
55 sandstorm #ecd540=55
56 mustard #ffdb58=56
57 gold #ffd700=57
58 egg yolk #fee33e=58
59 rubber duck #fbe108=59
}
greens={
60 lime #00ff00=60
61 apple green #8db600=61
62 Operators #62c213=62
63 forest green #228b22=63
64 green #008000=64
65 dark green #006400=65
66 dark pastel green #03c03c=66
67 emerald #50c878=67
68 mint #3eb489=68
69 Pen #00a178=69
}
cyans={
70 aqua (cyan) #00ffff=70
71 dark cyan #008b8b=71
72 cerulean #007ba7=72
73 iceberg #71a6d2=73
74 Sensing #0494dc=74
75 teal #008080=75
76 light sky blue #87cefa=76
77 deep sky blue #00bfff=77
78 dodger blue #1e90ff=78
79 azure #007fff=79
}
blues={
80 blue #0000ff=80
81 midnight blue #191970=81
82 dark powder blue #003399=82
83 cobalt #0047ab=83
84 denim #1560bd=84
85 navy blue #80=85
86 steel blue #4682b4=86
87 Motion #4a6cd4=87
88 cornflower #6495ed=88
89 slate blue #6a5acd=89
}
violets={
90 violet #8f00ff=90
91 Looks #8f56e3=91
92 grape #6f2da8=92
93 indigo #4b0082=93
94 x11 purple #a020f0=94
95 magenta (fuchia) #ff00ff=95
96 dark orchid #9932cc=96
97 Sound #cf4ad9=97
98 purple #7f007f=98
99 dark magenta #8b008b=99
}

[jguille2]

Ok, done!

Note that those are not "the colors that I want". I only implementing your crayons, and checking that those "numbers" are right. It's easy to make mistakes, and I need a real reference. I think that W3C was a good standard, because Snap! is running inside browsers.

My opinion, the 140 X11 names supported by browsers (without any variation nor gray%) is really enought to build a set of crayons. And we don't need to introduce "burnt orange", "sandstorm"... But this is only an opinion. For me is not a problem. And if you change crayons lib I can build our color picker related to it.

If the colors are fixed, I also build the editor pickers and then, the PR to close this. Remember we can change the "default color"...finally "red"?

Joan

[brianharvey]

I don't think even Crayola makes a 140-crayon box! So there would be some curation no matter what. I actually learned a lot from the workwithcolor.com pages, both from their grouping of colors (e.g., "pink" is distinct from both red and violet) and from their occasional weird choices. And in the opposite direction, Pantone has thousands of distinct colors.

I suppose red will do for the default color. (Unless you'd rather make it burnt orange...)

Did you have a thought about using crayons 3, 7, and 11 as the grays instead of 0, 5, and 10, so as to avoid duplicating black? I don't really care but didn't want you to have missed that idea, especially since the two black buttons are on top of each other.

[brianharvey]

Oops I didn't answer the main question: Yes, I'm done with colors at least until Snap! 7.0. :-)