Laternenpfahl
The old blocks need to stay though…

Which old blocks? I'm not removing any…

I did change hue to a percent, though.

EDIT: …but hue makes no sense as a percent, since the scale is cyclical. I changed it back; I would prefer 0-359 but Scratch already has 0-199, so I kept that.

nXIII
snip

Use 0 - 360. 0-199 aint good

Laternenpfahl
Use 0 - 360359. 0-199 aint good

0-199 is the Scratch convention, though; changing it might confuse new users…

EDIT: However, since PEN COLOR would be renamed to PEN HUE and a Google search for hue instantly reveals that the scale is in degrees, you're probably right.

EDIT2: Do you agree with my category assignments? I though about putting the constructor and accessor blocks in Operators, but ( of ) looks a lot like ( of ) even though they are semantically different, so I decided to put them in Pen with most of the other color-related blocks. (color at) should definitely go in Sensing.

Thanks for the well thought out proposals. However, I'm still skeptical. Real estate on the Scratch palette is very precious, and any increase in the number of blocks also increases complexity / potential for confusion or intimidation of new users. So to me, the benefit of increased ceiling height here doesn't outweigh the costs of the increase in floor height.

Everyone already knows what “color” is. But a great deal of our users will never have heard of HSU, RGB, or the concept of color space in general.

Lightnin
Thanks for the well thought out proposals. However, I'm still skeptical. Real estate on the Scratch palette is very precious, and any increase in the number of blocks also increases complexity / potential for confusion or intimidation of new users. So to me, the benefit of increased ceiling height here doesn't outweigh the costs of the increase in floor height. Everyone already knows what “color” is. But a great deal of our users will never have heard of HSU, RGB, or the concept of color space in general.

That doesn't mean they have to use it, does it?

Lightnin
Real estate on the Scratch palette is very precious, and any increase in the number of blocks also increases complexity / potential for confusion or intimidation of new users.

What about <next costume>, <say () for () secs>, <think () for () secs>, <change x/y by ()>, <set x/y to ()>, and many of the hat blocks? They all have trivial workarounds, unlike the three blocks I'm proposing (some of which don't have any workarounds).

Also, two of the three blocks go in the Pen category, one of the categories with the fewest blocks. They wouldn't affect screen real estate much, and neither would the one new Sensing block.

Lightnin
So to me, the benefit of increased ceiling height here doesn't outweigh the costs of the increase in floor height.

To me, the <color at x: () y: ()> block is immediately understandable, and in my experience the words “hue,” “saturation,” and “lightness” are all fairly common outside of computing and have exactly the meanings one would expect. My proposal never mentions color spaces or the abbreviation HSL, so I think if people didn't immediately get what the hue/saturation/lightness block did they could experiment a little (by clicking the block and looking at the color that pops up in the “reported value” bubble) and figure out what each argument did. After that it's easy to see what the <(component) of (color)> block does (simply the reverse of the <color hue: () saturation: () lightness: ()> block) and how you can use the colors (as the displayed colors in the “reported value” bubble should look identical to the ones in color arguments).

nXIII
Lightnin
Real estate on the Scratch palette is very precious, and any increase in the number of blocks also increases complexity / potential for confusion or intimidation of new users.
What about <next costume>, <say () for () secs>, <think () for () secs>, <change x/y by ()>, <set x/y to ()>, and many of the hat blocks? They all have trivial workarounds, unlike the three blocks I'm proposing (some of which don't have any workarounds).

Also, two of the three blocks go in the Pen category, one of the categories with the fewest blocks. They wouldn't affect screen real estate much, and neither would the one new Sensing block.

Lightnin
So to me, the benefit of increased ceiling height here doesn't outweigh the costs of the increase in floor height.
To me, the <color at x: () y: ()> block is immediately understandable, and in my experience the words “hue,” “saturation,” and “lightness” are all fairly common outside of computing and have exactly the meanings one would expect. My proposal never mentions color spaces or the abbreviation HSL, so I think if people didn't immediately get what the hue/saturation/lightness block did they could experiment a little (by clicking the block and looking at the color that pops up in the “reported value” bubble) and figure out what each argument did. After that it's easy to see what the <(component) of (color)> block does (simply the reverse of the <color hue: () saturation: () lightness: ()> block) and how you can use the colors (as the displayed colors in the “reported value” bubble should look identical to the ones in color arguments).

But the block that takes most screen space vs. usability is forever if can't we have a switch instead?

(unrelated)

bump
up
my
post

(sorry, it's so lightnin sees this)

How about simplifying the color constructor to turn named colors like “blue” or “vermillion” into the corresponding colors. As a bonus for advanced users, it should support an input of rob(x,y,z), hsl(x,y,z) and #XYZ.

Then you need a set of only two blocks, and no constructor:
Note that this says code because it returns the hsl of the color.
The terms color and shade should be retained, and grayness sounds like a good, clear word. Alternatively, only allow full-color and grayscale colors, where the “color” of a grayscale is -1.

You can also replace the two pen color setting blocks with just one:

Visually selecting a color from a palette with a string argument would be really odd, and you're using “color” to mean two completely different things.

Also, you just made Scratch colors into a subset of CSS colors. I'm not sure that's a good idea.

We retain the block with the color picker as a separate block:

set pen color to <colorpicker>
set pen color to <stringinput>

Also, you don't go from code to name, you go from name to code. So I don't see how allowing named colors shrinks the set of colors. You can always describe a new color with the code, but new programmers can use the names instead. Kind of like BBcode colors: you use names when you're new and move on the hex colors when you're a pro.

As lightnin said, RGB would seem a bit confusing, and could scare new scratchers

Also, Color names seem good, but would take an extra space. The Hue, Saturation, Lightness is understandable to new Scratchers.

We could have a thing where you move the sliders in the help section!

This drowned.

Lightnin? You there?

SUPPORT TO INFINITY AND BEYOND

massive bump-
I wanted to make this suggestion but I found this lol

starlightsparker
massive bump-
I wanted to make this suggestion but I found this lol

That explains the notification :P

Also, maybe stuff like transparency (since that was added in 3.0 I think for pen)

{what method did you use::control hat
answer on profile ::motion
} ::operators

I think the rgb colour picker for pen would make more sense to use and it would make colour detection and rendering easier. It also might make more sense since, the colour picker in costumes users tthe rgb colour format and having the same colour format in all of the colour systems in scratch would make things easier. Maybe something similar could even be a applied to the color effect block (so you can set the colour to an rgb colour value)?