List block color pallet

[PropGit]

@michel-cf - Please provide a list of the entire color pallete (and related information) allowed for the blocks in the editor.

[michel-cf]

Blockly documentation:

Blockly uses a Hue-Saturation-Value (HSV) colour model. Saturation and Value are hard-coded into Blockly, whereas the Hue is defined on each block. This ensures that developers have the freedom to choose from a wide range of colours, while still guaranteeing that all the blocks will fit together visually. It also allows the entire Blockly look and feel to be made brighter (for children) or more depressing (for businesses) by simply adjusting the two hard-coded Saturation and Value constants.

To find a good colour, visit this HSV picker, enter Blockly's Saturation and Value constants (the defaults are 45% and 65% respectively), then slide the Hue as desired

Source: https://developers.google.com/blockly/custom-blocks/defining-blocks#setcolour

[michel-cf]

The image shows the different colors for the default values. I propose that we go a bit brighter.

[JenJacobs]

I agree. Brighter would be better. Also, hello Michel! Nice to meet you.

[DarkmatterVale]

Has there been any progress on determining what colors should be used for which blocks @PropGit ?

[JenJacobs]

Is anyone working on this project able to get me a list or a screen capture of all the block colors we are currently using, please?

[PropGit]

@JenJacobs - Here's some screen captures. I don't have the color codes for these but you should be able to grab them from the image.

We need as wide a set of different hues as practical (not too close to each other) (see the above post for documentation) and I believe @michel-cf has already set the saturation and value to be brighter than the defaults but I don't know the values he used (see screenshots below) so we'll want to designate certain hues for certain categories of blocks. For now @JenJacobs, lets at least decided on a set of hues that we deem different enough from each other to be distinctive (at least when in close proximity to each other) and then we can decide which hue should apply to which category to derive a standard to stick to.

Sample

Here's the set of blocks (against the standard white editing background) that represents all the different colors we're currently using.

And for category reference, here's a set of screenshots showing the block menus individually opened. Note that the colors will have more contrast when used in the editor (on the white background) than they appear in the menu (on the gray background).

Control

Conditions

Math

Multicore

Pin states

Timing

Serial terminal

Protocols

Voltage

Memory

< Currently Empty >

Audio

< Currently Empty >

ETape liquid level

HMC5883

< Currently Empty >

2-axis Joystick

Memsic 2-axis

< Currently Empty >

MMA7455

< Currently Empty >

GPS PAM7Q

Distance: PING)))

PIR Motion

RFID

< Currently Empty>

SF02 Laser

Sony Remote

< Currently Empty >

Sound Impact Sensor

< Currently Empty >

Standard Servo

CR Servo

< Currently Empty >

Serial LCD

ActivityBot

Servo Differential Drive

< Currently Empty >

LED Control

OLED

IR Communication

EEPROM

Accelerometer

Touchpad Control

Functions

Variables

[michel-cf]

I have not yet changed the 2 other (fixed) parameters. If a change needs to be made to those, please let me know what values should be used. (this is a change in the core Blockly code and as such we'll need to make a list of what changes or done for when we update the Blockly core)

[JenJacobs]

Thank you for the screen shots, very helpful. For brighter blocks I propose green, aqua, blue, purple, and red. Mocked them up so you can see how they would look. Thoughts?

Green #2CB231 (122, 75, 70) Aqua #2CA9B2 (184, 75, 70) Blue #2C64B2 (215, 75, 70) Purple #B22C91 (315, 75, 70) Red #B22C2C (0, 75, 70)

[PropGit]

@JenJacobs - That's definitely more appealing to me.

I'm concerned it may be a tiny bit too bright because a couple of the colors feel harder to look at than others. It might just be my eyes. This is a saturation of 75% and value of 70%. What do you think of something like 70% and 65%, respectively? Maybe that's too dark?

@cbradyatinquire - Since you have students (I don't know what age range), can you give us your opinion too? Are we closer to the target?

@JenJacobs - Can you make a sample that adds more colors in-between? Perhaps a set of 10 or 12 colors all-together? I think that will give us more choices to apply to different categories of blocks and should still be distinct enough on-screen.

Thanks!

[michel-cf]

Please remember that Blockly uses the HSV model with saturation and value. So, could you please provide the fixed values and the selected Hue value for each color?

[PropGit]

@michel-cf - Okay. What Jen provided was 75% Saturation, 70% Value, and Hues of 122, 184, 216, 316, and 0 degrees.

[JenJacobs]

@PropGit Here are some less bright options in the same family (S and V both 65%). I can add more colors, how many categories of blocks do we expect to have?

@michel-cf Added HSV values.

Green #3AA53D (122, 65, 65) Aqua #3A9EA5 (184, 65, 65) Blue #3A66A5 (215, 65, 65) Purple #A53A8A (315, 65, 65) Red #A53A3A (0, 65, 65)

[PropGit]

@JenJacobs That does look a little more dull; maybe washed-out is a better term. I was hoping my suggestion would be less intense but not dingy. You're original were more appealing to me.

I can add more colors, how many sets of blocks do we expect to have?

This is hard to pinpoint and it has changed over time. Right now we have about 10 categories and it's likely to increase, at least slightly. Most human eyes can detect many hundreds (thousands?) of shades of color when they are right next to each other, but when there's distance involved between two shades of a color, the distinguishable count goes way down. In practice, I'm guessing that around about 20 shades or more (not including the white editor background) is probably counter-productive in more ways than one.

So, unless someone ( @michel-cf, @cbradyatinquire, @DarkmatterVale, @AndyLindsay ) has a compelling opinion about this, let's try out 16 shades.

[JenJacobs]

Ok. If we go in increments of 25 for the 'H' value you can have 15 colors to choose from and nice round numbers that are easy to remember.

[PropGit]

Thanks @JenJacobs. Good choice. I think that provides a nice range of colors without getting too wild.

[DarkmatterVale]

I like these colors as well.

[cbradyatinquire]

I agree in general. I'm glad to get the orangey and yellowey colors in play. I do think that Row 1 column 4 is sub-optimal, and row 1 col 5 is too close to Row 2 col 1 & Row 2 col 2 to distinguish them Same with Row 2 col 5 and Row 3 col 1; and Row 1 col 1 and Row 3 Col 4 & 5. So we probably realistically have 9 or 10 fully distinguishable colors here.

Also - does anyone know: How do these do with Color Blind users?

-C

[JenJacobs]

@cbradyatinquire I had the same concern when we were working with just 5 colors. A palette of 15 is going to be tough on colorblind users - I'm not sure there's any way around that. Seems like it's a common problem with Blockly.

[michel-cf]

We might try http://colororacle.org/index.html to see how it looks for colorblind people. Google gives plenty of results when searching for colorblind safe palette

[JenJacobs]

@michel-cf Additional color blind palettes could also be developed if it's possible to toggle between things like that in Blockly.

[michel-cf]

It's not built in, but I could create a system where we manage colors in a central place and the blocks request what color they should be instead of being hardcoded in each block. It would still only be the Hue that can changes due to the way Blockly is set up. Being able to change all 3 parameters or using a different color model will need investigation, and if possible, will require quite a bit of customization work in the core of Blockly. Which will make it hard to upgrade.

[michel-cf]

We could make the colorblindness type selection part of the profile page. I need to know everything before initializing Blockly. I don't think I can change block colors after that. So, making the selection part of the profile makes sure I have the information beforehand and it eliminated the requirement for a selection on the editor screen. (We want this to be minimal, to have as much space for the editor as possible)