Colors and Shades differ from Scratch 2.0

[ghost]

The Color numbers and Shade numbers produce different results on Snap! and Scratch 2.0.

The following scripts demonstrate the differences (colors left, shades right):

Scratch Color Range:

Snap! Color Range:

Scratch Shade Range:

Snap! Shade Range:

[jguille2]

Hi! let's continue...

Precision values

• I've fixed precision of all params (hue, saturation, shade and opacity) to 0.01.
• Explaining reasons and trying to answer to Brian questions...
  • We can represent all RGB colors into HSL codification (and vice versa)
  • No problems with precision in the results (color observation). But I want to have consistency in all cases. There is no problem with Snap params (hue, shade... they are the same codification), neither with HSL.
    RGB have no observational problems, but if one person wants to go further with the RGB lib will have problems. What's the problem? In some cases, I put RGB values and, when I check these values later they are changed (+-1). This is the afectation of the precision in the algorithm calculus. Then we fix precison to 0.01 in hue, saturation, shade and opacity, and this ensure RGB calculus are consistent with a precision of integers (I've tested all cases).
  • This is done! You can test it!

Color Palette

• Testing I add to the colorPalette a gray scale and a palette of 16 colors.
• Color params are for people who wants to play with colors (with their light, saturation...). But everybody must be able to change pen color easier. Current palette has two problems: there are not grays, nor browns... and is a continous palette, and some times we want to pick a known (defined) color.
• We must wait to First-Class colors to rethink this... but a good idea would be to stablish a numerated color palette. No hue! This would be an easy way to manage (set and change) colors.
• In the meantime, we can improve our palette. I want one small palette, because is thinking in a basic user.
• I put: 7 rainbow colors + magenta + black + white + 3 grays (silver, gray and darkgray) + 3 "browns" The result is just like this: You can play this!

Other questions

All is been documented. One question, are you agree with a new reporter block for 'pen color params' like a primitive block? I think it will be fine.

Joan

[brianharvey]

We are definitely converging.

Yes, certainly there must be the reporter block!

This is a really finicky point, but I'd be inclined to list shade before saturation in the pulldowns. You're thinking HSL, but I'm thinking that hue and shade are the ones Scratchers know and the ones in the color picker. I don't insist if you have a strong preference.

About the small palette, I don't see any particular virtue to a power of two. As you know I think 20 is a lot better than 16. I'm happy with your three greys, and your selection of browns is fine although different from mine. But I really want X11 green (the darker green) and navy blue. I think teal is a beautiful color. To make room for the two extra greys, I could easily live without pink, although, you know, neither of us is a girl, so maybe instead I should sacrifice red-orange and royal blue. Also I guess your first brown, which is sort of maroon, is a better choice than my goldenrod. Putting pink next to magenta (similar appearance) instead of next to red (more logical) is better because the multiple-of-ten colors are a more sensible set this way.

It would be okay with me to show these 20 colors as two rows of ten in the color picker. Or not, whatever works for you. (EDIT: Multiples of ten in the first row, odd multiples of five in the second row?)

But if you're going to build what's essentially my color wheel into the color picker, then we might as well build it into the blocks, too. I guess you could add "number" as an option in the pulldown menus (maybe the reporter would report a number only if the color was most recently set to a number, rather than trying to find the closest match). I still say the 20 colors have numbers that are multiples of five, and the in-between numbers are interpolated in RGB space (or HSL space; it shouldn't matter that much, right?).

[jguille2]

Ok,

• Reporter 'color pen param↓". Added to the basket :heavy_check_mark:
• Changing order saturation ←→ shade :heavy_check_mark: I like it too (I did it for hsl relation)
• Adding and changing colors (palette - Brian's wheel) I agree with you and I'll return to this. I've spent a lot of time... choosing colors and the order in the palette. I tried with olive, dark green, teal... but my result it was not fine. Really I did'nt want to create anything... and I want to implement an standard palette... but I don't find any full satisfactory (16 first html colors, primary+second+tertiary ....)
  I'm convinced that we need an small palette (12-20 colors) and not a large one, because we already have the continuous palette... and this one is to fix a set of colors (our crayons). Marked to review. :heavy_check_mark:
• And the "set color to number"!! I also agree with you. But I think this is the most difficult aspect. That's why I wanted to find an standard scale. The relationship between colors and numbers will be our invention. And it will not be evident. We can implement the palette and think better the number relation. It would have to be a well thought-out thing, since it would not have to change later (for compatibility with future projects). :heavy_exclamation_mark:

Joan

[brianharvey]

Again, once you've settled the mini-palette in the color picker, you've settled the color numbers; it would be confusing for them not to agree.

[brianharvey]

No, wait! It's even better if we put the browns where they belong spectrally, between red and orange. And if we do that, pink goes where it logically belongs, too. And I interchanged teal with aqua, and saddle brown with chocolate:

And here's the bottom part of the color picker:

[brianharvey]

Oh god, I shouldn't be allowed near a color chart.

I couldn't help noticing, once I made that picker, that the greens through violets line up really elegantly vertically, with the "pure" color on top and a darker or lighter shade on the bottom. But everything left of orange is shifted by one, and it's because there are five greys and only one yellow. Wouldn't the picker look nicer this way:

Here are the RGB numbers:

I am slowly convincing myself that it's a feature, not a bug, that if you start at zero and go up by tens you don't get white. It's a feature because most of the time the background is white, so none of the main colors are invisible. ☺

[jguille2]

Hi Brian,

I continue (and we are near the end).

• I added the 'pen color param↓' reporter block and changed the params order ( hue -> shade -> saturation -> _opacity). Updated to test online.
• The palette is not closed for me, but I pushed your 20 color palette to test it and show it clear.
• As I said, A palette with 10-20 colors is fine to me. I want to think about this selection better... and also about their numeric relation. Some thoughts to continue working:
  • About 16 colors. For me, it does not matter if the palette has 15, 16...20 colors. Let's try to find a reasonable number (the smallest but enough). Looking for palettes I found some good ones (like this image) but they had so many colors for us. I think your initial compasion with the box of crayons was good.
  • Numbers! I think your 1-100 proposal was started trying to get a new hue scale (compatible with "old hue"). I think now I don't need this 1-100 scale, and you can rethink values. I like a simple numerical order. If I have a palette with 20 colors, then we have colors from 1 to 20. Really 1st, 2nd... 20th. It's the same idea that costumes.
  • I understand your concern for the relationship between the two rows (I also have it), but more important is the set of colors. For example, initial sprite hava a (80,80,80) pen color. It must be into he palette... or we can change this default color.
  • Default color in all ColorSlotMorph is (145, 26, 68). I suggest to change it (may be to red (255,0,0)). But if you want this default color, then, I would like to have it into the palette.

Let's continue... Joan

[brianharvey]

Yes, nearing the end. I love that color picker.

I think "number" should be the default option showing in the SET PEN COLOR block, since people sophisticated enough to use HSL values will be clever enough to pull down the pulldown.

About [0,99] vs. [0.19]: I'm not at all trying to be compatible with the meaning of hue (for example, teal is out of chromatic place), but I guess I'm trying to be compatible with certain aspects of Scratch color number behavior, namely, that changing the color number by 1 should never be an abrupt change, but changing by 5 and changing by 10 both give rise to sensible small collections of colors. I think this fits with Scratchers' intuitions, and also with the fact that the default CHANGE BY value is 10. And, you know, numbers are cheap, there are lots of them. :-) And the color wheel is a pretty thing that makes a simple project suggestion.

In particular, I think it's useful to have a relatively large set of greys accessible as color numbers. That's the only case in which I have a special fondness for any particular non-multiple-of-five color, except that there's a nice range of browns surrounding maroon: (Color 37 is the one I want to paint my car!)

Other colors also have interesting usable ranges:

About default colors, it was only quite recently that I even noticed that the default sprite isn't black! We should ask @jmoenig if there's any particular reason for that. I'd be happy for it to be black, which would have the added virtue that it's color number zero, so CHANGE PEN COLOR BY would have an intuitive starting point.

And as for the default colorslotmorph color, I've always hated it. What an ugly color! What's its history? Red would be fine with me.

---

I think your initial compasion with the box of crayons was good.

So, this inspired me to visit crayola.com. I'm not sure I learned anything helpful, but here goes:

They offer an eight-color box: red, yellow, green, blue, brown, black, orange and purple.

They have a 16-color box: Red, Orange, Yellow, Green, Blue, Violet, Brown, Black, Blue-Violet, Blue-Green, Red-Orange, Yellow-Green, Red-Violet, Yellow-Orange, Carnation Pink, White.

They have a 16-color box of construction paper crayons for which they don't provide a color list in text, but you can observe: http://shop.crayola.com/color-and-draw/crayons/construction-paper-crayons-16-ct.-5258170008.html

24-color box: apricot, black, blue, blue green, blue violet, brown, carnation pink, cerulean, dandelion, gray, green, green yellow, indigo, orange, red, red orange, red violet, scarlet, violet (purple), violet red, white, yellow, yellow green, yellow orange.

(But there is a big internet fuss going on because they recently announced that they're going to replace dandelion with something new.)

And all the gory details, of course, in Wikipedia: https://en.wikipedia.org/wiki/List_of_Crayola_crayon_colors

[brianharvey]

P.S. The multiple-of-5 colors are all official X11 named colors. Instead of just interpolating, if you want, we could explicitly pick more X11 colors for the other 80 slots. Then we could publish the official names for all 100 color numbers. It would make the color wheel less continuous-feeling, though.

[jguille2]

Hi Brian,

I have something to say about the colors selection... but I think the most important thing is to define the model, because we are talking about different paradigms. Let's look at the options:

1. Brian's wheel with 100 values. This palette is really a color chart. I understand your proposal... but also I think this is a creation of an alternative color system. We have hue, shade..., and with the color library we have RGB, HSV and HSL. Will not it be too complicated?

2. A small collection of colors. Here we haven't a color chart. Only a "box of crayons". It looks more like the management of costumes. We will not have a "change pen color by" (not a problem the idea of the default "by 10"). Maybe we'll have a "next color" block... or a "color #" reporter. Or maybe not... but the idea is the same.

3. And I don't want to complicate more anything... but maybe for the future... with the idea of a defined palette, we can think later in a 'costumizable palette'. I'm talking about a new 'Color' Tab beginning in every sprtie with the default palette, but with the posibility to customize it: changing colors, adding more, resorting ... This is a first thought (just to think).

We need to have clear which is the model... and after this, we can recheck the color values.

Joan

[brianharvey]

I agree, we need clarity on the model. But in my view it's two models, one for color experts and one for the rest of us. If you look at https://scratch.mit.edu/statistics/, you'll find that (1) hardly anyone uses the pen color blocks at all, compared with pen up and down, etc.; (2) of the hardly anyone, way more use the color picker than anything else; (3) CHANGE PEN COLOR is used more than numeric SET PEN COLOR; and (4) the SHADE blocks are by far the least used.

I think the third of those points is especially important for this discussion. There is much more interest in moving through an essentially random set of colors than in giving a precise specification of some particular color. That supports my view that having a good color number selection (and being able to escape from black) is much more important than which of RGB/HSV/HSL underlies our color space.

Basically, I am shamelessly piggybacking on your interest, which is in the precise color space, to sneak in my interest, which is to get a good set of color numbers in which it's easy to find greyscale and brown.

But I think our two interests are entirely compatible, as long as we don't let one infect the other. The biggest problem with Scratch colors is that COLOR means Hue, rather than allowing for a range of easily-chosen colors with different lightnesses. (And saturations, except that all people mostly care about is 0 vs. 100%.) We are solving this problem by making HUE an explicitly controllable parameter separate from the default color wheel. We'll let people operate in RGB space, too, since that's so ubiquitous, again totally separate from the color wheel.

In the documentation we have to make it clear that NUMBER is a different kind of parameter from HUE, SHADE, SATURATION, and OPACITY. I'll take care of writing the manual section on color. :-)

I think the core of your objection is "Will not it be too complicated?" But for most users there will be no complication at all. They'll have 100 colors to choose from, ranging from vivid to pastel to greyscale, and won't have to think about the dimensionality of color space at all; for them it'll be one-dimensional. (Yes, by the way, you're right that I'm distorting the idea a little by displaying the space as a color wheel, which was originally used by people wanting to make points about hues opposite each other on the wheel, or being the vertices of an equilateral triangle. My wheel doesn't have those geometric relationships. I just think the wheel is pretty.)

I can imagine ways in which we could make it more complicated. For example, there are colors in my color wheel that aren't in the (all 50% lightness and full saturation) continuous 2-D part of the color picker; we could decide that if you hover over a crayon for a while we open a secondary 2-D color picker that shows the part of color space near that crayon color. But really it doesn't bother me that not all 2-D color picker colors are Brian-color-wheel colors and vice versa, because most people aren't so worried about precise color control, and the people who are worried about it will have full HSL control.

There are a few design decisions to be made that are complicated for us (you and me, I mean), but the the big design principle underlying our choices should be not to complicate the lives of color number users. Here's an example. Suppose you say SET PEN COLOR NUMBER TO (whatever) SET PEN COLOR OPACITY TO 50 CHANGE PEN COLOR NUMBER BY 5 What happens to the opacity? Is it still 50, or back to 100? The reason this is a hard question is that I think the answer is different from the answer if you put HUE instead of OPACITY in the example. For opacity, I think it should stay at 50. For hue, I think the new color should be 5 more than the last color number chosen, even if the hue has totally changed in the meantime. (But an alternative answer is that we could find the color number closest to the new hue and change that by 5.) Putting it another way, if you intermingle color numbers with explicit control of hue or shade, you're asking for trouble and deserve whatever you get, but if you intermingle color numbers with saturation or opacity, we should do what you mean. (Yes, if the color number is in the greyscale region, changing the saturation is more complicated. Maybe we should remember the saturation value you give, but not actually change the visible color until you switch to a non-greyscale color number, which will then be saturated as you said.)

As for customizable palettes, that's a great idea. We don't need new blocks for that, though; we just add "crayon colors" to the global getter/setter blocks in the library; it gets/sets a list of 20 colors.) Including this feature is orthogonal to the number of color numbers, if the non-multiples of 5 are made by interpolation between the neighboring multiples of 5.

By the way, I think it's important that I chose X11 colors for the crayons. I want the color library to recognize all the X11 colors, because they're human-centered rather than color-space-centered. Being able to ask for "sky blue" or "powder blue" or "steel blue" without knowing anything about color space is awesome. I'm starting to warm to the idea of 100 X11 colors in the color numbers (while still keeping the same 20 crayons I have now) instead of interpolating. We could even have a library block with the Crayola color names! Or Pantone names and numbers, if we can get a license for them.

[brianharvey]

Of course if I could do anything to color handling, I'd change the hue numbers to make them nonlinear, so each top row crayon color (minus black, silver, brown; plus magenta) gets an equal number of hue colors, sort of like this:

I haven't tweaked the magic numbers quite right, but the goal is to divide the hue numbers 0-100 into eight regions of width 12.5 each, in which each of the eight crayon colors and its environs goes into each region, but with smooth transitions at each 12.5 border. The graph shows that I haven't quite gotten it right; there are jiggles at the turning points of your hue number as a function of my hue number, and the blue/purple border isn't right. Also you'll see that I think your hue numbers 96-100 are more nearly red than magenta.

I'm ptobably not really serious about this idea; I don't want to make waves (believe it or not). But it's still the Platonic right thing.

[jguille2]

Hi Brian, I do not really agree with your proposal. Of course, it's only my opinion... and I have no problem to implement what is decided. I think you can reopen the discussion on basic parametres (hue, shade... ranges, wrappings...) but introduce another 'basic system' is not the way. Let me explain with more details.

• We'll have a library with RGB, HSL and HSV. With this lib and the possibility of custom blocks (using this library, or with the "basic" color blocks, or with JS (we'll have a consistent and documented API)), I think we can do everything (very advanced or very basic)... This is the power of Snap!

• But the primitive pen color blocks are not only for advanced users! I didn't love HSL... And all the proposal (and our long discussion) was centered in the "best" metaphor for colors. We have talking about Scratch compatibility (the original metaphor), the sense of wrapping, the name of the params, their range... to get the best "natural parameters" to program coloring.
  If these params are not good, we can change them. But for me, to create another "basic approach" is not a good idea.
  We are talking about parameters to program coloring. With hue we can move color over the rainbow, with shade we can move color over the light (black-dark to white-light). Both wrapping over infinite. And with saturation we can move between a "coloring world" (100%) and a "gray world" (0%).

• And yes. I agree that color parameters are not so easy. Then, we agree that we need a more basic pen color picker. The visual picker is easy... but a numerical picker is needed to introduce programming with this. But this basic thing, for me, is the box of crayons. Without adding complications (gradations, interpolations...). We have a box, with a number of colors and a definite order (of course, we are thinking in the best default order).
  For me, "CHANGE PEN COLOR NUMBER BY" is not a good block. This denotes an idea of continuity. We'll take a color (the first, the second... the last). We can implement "SWITCH TO PEN COLOR x" and "NEXT PEN COLOR" action blocks and a "PEN COLOR #" reporter. I anyone wants more (change the light of a color, a continous color change...) he can use our basic blocks with hue, shade...

• I thought that with this we could be closing... but I try to write down some ideas about the possibility of the "Colors tab", to see more clearly this option of the simple palette (without gradation connotations). It's only a draft proposal, to show the posibilities:

  • A "Colors" tab with a first (number 0) not eraseable Custom Color. Like our "Turtle" costume. This color is always the real color and it can get any value. It is the default color (with the random initial color) and the state selected after every color param change (hue, shade, ... RGB, HSL...)
  • We'll have an initial default palette. Each color have a number (its order) and a name.
  • We can edit every color (name and its own color value) and we can move (reorder) them.
  • We can delete and add more colors.
  • We won't be able to import/export colors. We'll import/export Palettes. We can offer different basic palettes (a rainbow, 16 colors, 20 colors...)
  • Here the idea of adding blocks like "Looks" category:
    • "PEN COLOR #" returns the color order (1, 2,... and 0 for 'Custom Color' (our 'turtle color'))
    • "SWITCH TO PEN COLOR x" has a drop-down with the colors name. But it accepts numeric values, with the color order.
    • "NEXT PEN COLOR" does nothing if I'm in the 'Custom Color'. But into the palette, it changes to the next (and looping at the end).

And I'm finishing (I'm sorry to be so heavy...) your example doubting the result shows (for me) clearly the problem of having two systems:

SET PEN COLOR NUMBER TO (whatever) SET PEN COLOR OPACITY TO 50 CHANGE PEN COLOR NUMBER BY 5

For me, when I pick a crayon, it have a definite color. I am not implementing another variation system. From this color picked, I can change color params... but then, I'm not using that crayon, I'm using a new color made by me.

Thanks for your patience. I hope this long discussion will contribute to a better implementation.

Joan

[brianharvey]

I'm not 100% sure I understand what you mean by a "basic system." In particular I'm not sure why a set of 20 colors isn't one, but a set of 100 colors apparently is one.

Crayola does make a box of 120 crayons, you know!

To me, the "box of crayons" metaphor isn't only about simplicity, as in few colors. It's about providing a way to access a wide range of colors without knowing anything about hue vs. shade, let alone saturation (always 100% for crayons) or opacity (also always 100%).

If you want CHANGE PEN COLOR NUMBER to reset the saturation and opacity to 100%, that's actually fine with me. (In fact that was my original position but someone talked me out of it.)

One reason why I want CHANGE PEN COLOR NUMBER BY, rather than only NEXT COLOR NUMBER, is that inside my set of 20 colors is hiding a set of ten full-vividness (i.e., half-lightness) colors that I would expect people who are just cycling through colors, without caring much exactly what they get, to use. That is, if it were only 20 colors, I'd expect CHANGE BY 2 to be more popular than CHANGE BY 1. (In my actual proposal, the numbers are 10 and 5, respectively.)

I'm not sure I understand your palette proposal. I would just say that a palette is a list of color numbers, we provide one such list, and you can make others. I don't understand the part about Custom Color.

To me, the most important part of this entire revision is that nobody should ever get trapped in black. That's what this is all about -- avoiding the Black Hole. Everything else is secondary.

Yes, of course, if you know enough, you can get un-trapped. But it took me quite a while to figure out how, and I've seen several very competent adults who know a lot about programming and about Snap! but happen not to be experts on color spaces get trapped and need my help to escape. If adults can't do it, I'm not inflicting that state of affairs on kids!

It's just not good enough to say to a kid "oh, you're trying to change the hue, but black isn't a hue, it's a shade, so you have to change that." Similarly, to a kid, grey isn't a lack of saturation, it's just another color. I want to assess what real users want, and give them that as the main interface to the color system, and then, secondarily, also provide access to the full color space for people who want to focus their attention on colors rather than, say, on making art out of rectangles that happen to be randomly different colors, but what's important is the positioning of the rectangles, not the specific colors. (That's an exercise in our curriculum.)

I suspect that part of what you don't like is making "number" part of the same category as hue, etc. I don't insist on that. My original proposal was to have two blocks: Remember, I wanted you to take the word "color" out of the name of the HSVA block? This is why. It lets me say "color" instead of "color number." It retains (with slightly different behavior) the SET COLOR TO block that everyone knows and loves. It avoids you thinking I want to make color number a dimension analogous to hue. The Scratch color number is hue, but this one isn't. It's related to hue but also controls shade and saturation -- but that's just how an implementor (you) would think about it. To a user, it's just a color!

Would two sets of blocks make you happier?

Here's why I think 100 colors would be better than 20 colors:

1. It allows for a gradual shift of color with no abrupt jumps.
2. In particular, it allows for 16 steps of greyscale.
3. If we want, we can decide to sneak other cool X11 colors in.
4. It is what Scratchers are accustomed to: 100 colors with CHANGE BY 10 as a reasonable default.
5. And it's totally compatible with thinking of only the multiples of 5 as the crayons, as seen in the color picker!

[jguille2]

Ok, We need to go further. It would be nice to hear some other opinion to help us into this discussion...

• I agreed with your "set pen color to", maybe with a drop-down of color names. But after the reflexion about a future "Color tab", I like more a and perhaps it helps us to be more different that previous "color-hue" block.

• I have no problem with a large palette (although I prefer a smaller one). But I insist that your proposal is to implement "another param" (an alternative hue), not a "set of crayons". The problem is not the large number, is that you expect numeric relations (by 5, by 10) and interpolating values.

• I totally agree with the basic questions (brown colors, scaping from black-white and from grays...) This is the reason of adding a discrete palette. If you don't want to learn anything about hue, shade... you can use this palette: you have discrete values (10, 16, 20 or 100) helping you to programm changes and also you have the complete continuous palette. But with the 16-20 palette we are already responding to this need.

• The problem of a "new" parameter is that it chains us again. If we want to implement custom palettes, but you expect a certain response (by 5, by 10...) we are chained again to a range, a wrapping...

Joan

[jmoenig]

Okay. I'm following this discussion half amused and half annoyed. Don't ever argue with Brian about colors, especially about the color brown :-)

I also believe that this is getting outta hand and overblown. I'm probably not going to turn Snap into Photoshop...

[brianharvey]

Of course color numbers should wrap! You have to be able to keep saying CHANGE COLOR BY 5 forever. (Or even NEXT COLOR -- it has to wrap.) But (and this is true for hue, etc., also) that can be done by taking the number modulo 100 (or 200 or whatever) and storing the result, same as with directions. You can say POINT IN DIRECTION 400 but if you then ask for DIRECTION you get 60.

@jmoenig Neither of us is suggesting Photoshop; both of us are trying to keep things simple, apart from @jguille2's suggestion abour custom palettes. And we are much more in agreement than disagreement. We both want a dual color system, in which most users deal with color numbers and don't get all of color space, while color experts get direct access to HSL color space (and RGB by way of a library).

@jguille2 Okay, now I understand what you mean about another param. And yes, I guess you're right, I am setting up a user-friendly alternative to hue that behaves better. But (and I'm sadly thinking that Jens is going to come down on your side because I always, always have this argument with him, too) I think we have to think about this from the perspective of a naive user who knows nothing about color space. I want that user to have it all! Namely

1. A significant greyscale with easy access.
2. A nice box of 10 vivid crayons.
3. Also, a box of 20 crayons that include the vivid ones and some shaded ones.
4. Smooth transitions between adjacent colors when desired.
5. Never get trapped in black despite no understanding of color space.

And yes, I'm hoping that many users will spend their whole lives happy with this set of colors, never needing to learn about any aspect of color space, not even shade. I think that's the big difference between us; you are eager for everyone to learn about HSL, and I don't even want them to have to learn about RGB (although, by the way, RGB is in the CS Principles curriculum framework so we/BJC have to teach it, and HSL isn't).

But I don't really think of my color wheel as a competing parameter, because I am unabashedly not trying to solve the problem of steering around in color space! I just want a box of 100 colors, arranged in a coherent order. Like crayons, these colors have 100% opacity, and they're all pretty shiny, even the pastel ones. And there are lots of shades of grey.

And yes, the transitions between multiples of five are weakest where I spliced in the greys; there's no particular reason to want a color halfway between magenta and black, or halfway between white and red. (You'd think pink would be in there, but it isn't; it's closer to magenta. That's something I learned from doing all this!) As a continuum, my color wheel is less elegant than the hue wheel. But I'm not doing color science, I'm doing user engineering. And, once again, here's what I think I've achieved:

1. A significant greyscale with easy access.
2. A nice box of 10 vivid crayons.
3. Also, a box of 20 crayons that include the vivid ones and some shaded ones.
4. Smooth transitions between adjacent colors when desired.
5. Never get trapped in black despite no understanding of color space.

Why shouldn't we do that for our users?

I don't think the color number block has to include the names, because the library will have a block that recognizes all the X11 color names, including these. It'll have a pulldown with the colors in categories (as in the Wikipedia article) of reds, greens, oranges, greys, etc., so that we don't need a single pulldown of length 121.

Would you be happier or less happy if I came up with a wheel of 100 X11 named colors? Those would definitely be crayonish, and I'd try to arrange them so as to keep the gradual-transition property.

[jguille2]

Hi Brian,

Let's look forward...

• Really, the only different is:

  • a) 20 colors into the palette, related to colors 1,2,...20 (only 20 possible values) or
  • b) 20 colors into the palette, related to colors 0, 5, 10...90, 95 (100 possible values)

  We have already explained the pros and cons. Let's repose this question for a while.

• Defining the 20 colors. I propose some minor changes:

  • Checking standard names with the W3C and their values, I've changed:
    • pink value(proposed was really DeepPink)
    • orange value(it was DarkOrange)
    • purple (violet had not the standard value... and I think purple is better)
  • I've changed wheat (or the other gray in the first proposal) for olive
  • Some order changes to show a first palette row with: black - grey - brown - rainbow
  • It looks like this:
  • And the data is: colors = ['rgb(0, 0,0)', //black 'rgb(128, 128, 128)', //gray 'rgb(192, 192, 192)', //silver 'rgb(255, 255, 255)', //white 'rgb(139, 69, 19)', //saddlebrown 'rgb(128, 0, 0)', //maroon 'rgb(255, 0, 0)', //red 'rgb(255, 192, 203)', //pink 'rgb(255, 165, 0)', //orange 'rgb(210, 105, 30)', //chocolate 'rgb(255, 255, 0)', //yellow 'rgb(128, 128, 0)', //olive 'rgb(0, 255, 0)', //lime 'rgb(0, 128, 0)', //green 'rgb(0, 255, 255)', //aqua 'rgb(0, 128, 128)', //teal 'rgb(0, 0, 255)', //blue 'rgb(0, 0, 128)', //navy 'rgb(128, 0, 128)', //purple 'rgb(255, 0, 255)' //magenta ];

• Brian, what do you thing about the "switch to pen color %n" block instead of the "set pen color to %n" one? As I said, it's a first step to the custom palette... and now, it helps us to show differences with the old "changeHue". Of course, this names will map to 1,2,3.. for option a) and to 0,5,10,15... in option b)

[jguille2]

Hi @brianharvey

Excuse me. The last message I wrote without reading your last one. Consider it earlier. I'll see this later ...

[brianharvey]

Okay, I confess, my color choices are very personal. I hate olive!!! It's barfucious. Plus, I wanted something that was clearly in the yellow family, not green. I considered light goldenrod, for example. But I'm afraid that lighter yellows will be almost invisible against a white background; yellow itself is already a weak color in that sense. So I went for a darker one that's still a yellow.

I'd forgotten that I chose darker variants of pink and orange! I made those choices before I'd decided to use X11 color names. In both cases I'd argue for changing the names rather than changing the colors; my choices are bolder colors, I think. But, damn, you're right, we should really also have pure spectral orange for people who want it.

This is more and more convincing me that I have to pick 100 X11 colors and arrange them in something like a continuum.

The ordering depends on the resolution of the continuum question. I actually had brown where you propose originally, but the interpolated transitions were weird and useless. In spectral terms, remember, brown is dark orange, so it does make sense where I ended up putting it. But I do see that users will expect the official rainbow colors to be consecutive -- but then what about cyan? It's not an official rainbow color either, although I've just been looking at actual rainbow photos and I don't see how people can not see cyan in the rainbow.

I'm actually way too busy to be doing this right now, but at some point I'll try for the 100-X11-crayons list.

[jguille2]

Hi everybody! I know you're tired of this long discussion (me too) but I ask your attention to be able to close it ... and to try that all these words (and the time spent) have served for something. (ping @jmoenig) You know that we could not agree everything with Brian ... but now it's about seeing what we can implement. I've built three steps to show it clear:

Basic color system (hsl1)

This is the basic and more consensual option. You can check the code changes and you can run it online. All this work is documented here. It's not a PR so it's simpler that you decide about each point: this is fine, this is not... change this other thing... And I'll make the changes you ask me.

Adding a block to set colors by numbers (hsl2)

I've build the block with the 20 colors used in the picker palettes. You can run this online. Here, changes are few I think it is a semi-consensual option... but certainly here the roads diverge. If you agree with the proposal of the 100 X11 colors into a "semi-continuum" range, this block must be discarded. But if you agree with the palette of 20 values, or with a future customizable palette (where values are not important... because they change continuosly) , this block is a powerful tool.

A way to the "Colors TAB" (hsl3)

And a little more...If you agree with the idea of building a new "Color tab" to play with customizable palettes, I can add two more blocs to play with the 'current' 20 colors palette that they will be fully consistent (and compatibles) with this future feature and already offer now interesting features. Test it here online!. These functions are totally analogous to the behavior of the "Looks" cat blocks. If you think this is interesting, I'll remake the code (current is not wrong, but it's made quickly, and it is necessary to redo it in the Morphic way).

---

And that's all! I hope that all this can serve for something ... and to be able to close (at least for now) this subject. Thank's for your patience!

Joan

[brianharvey]

Grump!

I disagree with every part of this except for the color-picker block, and furthermore, you know I disagree, and you know why. None of this is anything like a consensus, unless by "consensus" you mean you doing it your way.

Pen color numbers. Pen colors are not costumes, and they're not like costumes. We already know what the pen color number blocks should look like:

That's what color numbers have always looked like, and there's absolutely no reason to confuse users about that.

Colors are different from costumes in part because costumes come and go. Users rearrange their order, add new ones, delete old ones, in a very dynamic way. Mostly if they want to refer to a specific costume, therefore, they do it by name. In fact the block has noplace to enter a number! By contrast, pen color 30 (in the current system, in which it comes from the hue) is always a forest green (more or less, I don't know if it's X11 forest green, but it's always the same color, is the point).

I think it would be fine if the SET PEN COLOR block has a pulldown inside the white oval (a non-read-only pulldown) with 20 named colors, which would then (like the POINT IN DIRECTION pulldown) put the corresponding number in the slot.

Block names. Because we want SET PEN COLOR to take a number, as users expect, the HSL blocks should be named SET PEN [HUE ▼], CHANGE PEN [HUE ▼], etc. Anyone who knows what a "hue" is knows that it's a component of the color without putting the word COLOR in the block name.

Unless I've missed it, you've never actually argued against this. You've just ignored it every time I raise it.

How many colors. To me this issue seems ridiculously trivial; you don't even have to know that it's a dispute specifically about colors. We have two proposals on the table. (1) Let users keep the same flexibility about feature X that they've always had. (2) Remove 80% of the flexibility available to users about X.

How can there even be any disagreement on this question?????

If we were designing this feature ab initio, then we might want to argue about a tradeoff between simplicity and flexibility as two conflicting ways to empower users. But users have been using 100 color numbers since forever (Scratch is 10 years old this year, it says here), and we know they don't get overwhelmed.

The object of the exercise. The only reason it's necessary to make any change at all in the way our users have always used colors is to avoid beginners getting trapped in black. Were it not for that problem, there wouldn't be a problem, and we'd follow the First Law of Engineering. ("If it's not broken, don't fix it.") We're having this whole long discussion because color is broken, namely, people get trapped in black.

The solution to that is to make a modest change to the notion of color numbers, so that the first few numbers are greyscale, and the rest are more or less hue.

I've been hoping we could agree, once we are breaking the strict correspondence between color numbers and hues, to take advantage of that to get a more useful set of colors (namely, with easier access to oranges and browns, especially the latter). But, if I had to choose one or the other, better than the crippled thing you want would be to keep exactly the existing blocks, and just change color numbers so that 0-15 are greyscale and 16-100 are precisely the same hues as in Scratch, but compressed a bit.

Well, okay, I'll give you that another thing broken right now is that shade goes from black to color, rather than from black to white. But that, too, could be fixed without changing the name of anything or reducing the convenience to users. And once we fix the main problem, it'll hardly matter about the shade problem, because users will be able to get white as color number 15.

Consensus. The thing is, once we fix the broken color number system so that users can have greyscale and colors without getting trapped in black, then it makes sense also to give expert users access to a three-dimensional (plus opacity) color space. Most programmers will continue to think in terms of color numbers, as always, and it'll work even better for them than before. (As I pointed out earlier, to a first approximation nobody ever uses the SHADE blocks, so who cares what they do?) But, you know, we could just put HSL blocks in a library, the same as we now have HSV (and RGB) blocks in a library. It doesn't matter to users (i.e., it doesn't matter at all) what the underlying implementation does. What matters is that users have non-broken color numbers. But, to make you happy, I'm okay with also including HSL get/set primitive blocks, as long as that doesn't wreck color numbers! That would, imho, be a meaningful consensus: You get HSL exposed to users, and I get color numbers like always only better.

[jguille2]

Ok, I think I leave this topic.

unless by "consensus" you mean you doing it your way.

I'm sorry. Is my English so bad? Or I'm missing something more ... It was a large (too large) discussion. I think I have been continually adapting my proposals (ranges, wrappings, scratch compatibility, names, a palette creation, number of colors...) But I see it was not the way... I need to leave this topic for a while and start coloring other things (and sleeping a bit more)

Joan

[brianharvey]

Sorry I got mad. I just felt torpedoed by your post.

Reading the history I see that it took quite a while for me to understand that fixing the color number scale is at the heart of the problem (both problems, can't escape black and can't find white). But now that I see it this way, it's hard for me to see it another way. :-(

[brianharvey]

Crayon status report: I made two executive decisions, at least one of which should be uncontroversial:

1. Apart from the grayscale ones, all crayon colors should be pretty saturated, not pale or near-black. I think that just looks better.
2. White is not a multiple of 5 (so people don't get invisible pictures).

The big picture: 0-14 grayscale ... 0 black ... 5 dark gray ... 10 light gray ... 14 white 15-19 pink ... 15 deep pink 20-29 red ... 20 red ... 25 firebrick 30-39 brown ... 30 saddle brown ... 35 maroon 40-49 orange ... 40 orange ... 45 burnt orange 50-59 yellow ... 50 yellow ... 55 rubber duck 60-69 green ... 60 lime ... 65 dark green 70-79 cyan ... 70 cyan/aqua ... 75 teal 80-89 blue ... 80 blue ... 85 navy 90-99 violet ... 90 violet ... 95 magenta

The details:

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

If you guys are happy with this, then the color picker widget should use the multiples of five from this list. Thanks!

[rdococ]

I know it's been a year and I'm some random dude on the internet, but I want to give my two cents pennies.

I think that HWB should be used.

• Hue would remain the same for the most part (maybe changed to 0-360, with wrapping).
• Whiteness measures the amount of white in the color (0-100, no wrapping).
• Blackness measures the amount of black in the color (0-100, no wrapping).

You can think of it as adding white and black paint to a spectral base color until you get the shade you want. If the Whiteness and Blackness add up to more than 100%, then you get a shade of grey.

This would be more intuitive than either HSB or HSL, especially since the concept of saturation isn't very intuitive for human brains.

This would be more complicated, but it would also be cool if there were small perceptual corrections - for example, to make dark yellows appear less greenish.

[brianharvey]

We're all random dudes on the Internet... except for that dog. :)

That's an interesting idea, but it does have the weakness that half of the possible color numbers are wasted on redundant grays.

If there's anything I've learned throughout this adventure, it's that nothing about color is intuitive. But I do think the first time someone sees a 25% saturated picture, they get it. I'm guessing that's easier to understand than a color that's 75% white and 75% black. That, to coin a phrase, doesn't add up.

I'm thinking about rearranging my color wheel so that the non-gray colors appear in hue order, and then convince Jens that CHANGE COLOR BY should jump from 99 to 15, sort of the way NEXT COSTUME never chooses the Turtle shape. That way my color wheel would act more like hue, except for having enough orange and brown, and not too much green.

But I probably won't get around to this. Sigh.

[jmoenig]

Colors have been rethought and extended for the upcoming Snap5. I think this issue can now be closed. Thanks!