# Colors in Blocks-based Languages

I am designing a blocks-based language to use in my classrooms and summer camps. Since I am using the Blockly framework, I am able to choose my own colors for the blocks and am looking for information to guide my selection.

Personally, I find the number of colors in Scratch and Snap! and others to be overwhelming, and I hypothesize that young learners don't rely much on a block's color as much as its shape. But this is pure speculation—I welcome any reports from the front line or pointers to studies about block color.

Particularly, I'm interested in the method of grouping and organising the blocks into the color groups, rather than selecting the colors themselves: how should I select groups in order to help students understand each block's purpose? Are there any proven approaches of grouping certain types of blocks (e.g. flow control) together, or is the choice relatively arbitrary? Does the color choice have more of an impact than the shape and way of connecting blocks together?

• I really like this question, but it seems like it might be a better fit on User Experience. While it is about cs education, it's also very much about designing an interface for a specific audience. – thesecretmaster Jun 7 '17 at 0:54
• I'm voting to close this question as off-topic because it's more about UX than education. – Peter Jun 7 '17 at 5:09
• This is on-topic. Let's build a community here. It's related to understanding why indentation is important. I don't know of research on this, but I am curious to hear others'thoughts. I am an App Inventor user and the main color I notice is the Event Handlers are purple. Other than this I don't find the colors helpful in this language. – fgmart Jun 7 '17 at 10:10
• I have created a meta-question about this question here – Ben I. Jun 7 '17 at 22:26
• As a consequence of the meta discussion, this question was discussed (and can be discussed further) in chat. Before voting to reopen, please refer to the discussion in chat – thesecretmaster Jun 8 '17 at 2:04

Students use the colors for more than just interpreting the purpose of the block. In my introductory classes, the color assists early-learners with locating the blocks within an extensive collection of choices.

When give a chunk of pre-existing code to recreate, a block's color helps communicate where in the collection to look for it.

• This answer is great, but could be expanded upon to really cover and address the points in the question. – ItamarG3 Jun 7 '17 at 12:43
• I think this is suggesting that the colours are less useful than the groupings which are coloured - being an answer which supports this being CS related. – Sean Houlihane Jun 7 '17 at 13:41
• They do help students find the blocks they're looking for. When I taught Scratch I'd get a lot of questions about where to find a specific block. Saying the "purple group" was usually the easiest way to explain it. – Ryan Nutt Jun 7 '17 at 17:24

The colour of a block is a 'way in' for students, helping them to figure out what type of block they have. Ultimately, the important thing here is that there are logical categories of blocks—the colours just provide a way of visually showing what category a block is in, without an information overload of too much text.

To Block or not to Block, That is the Question: Students’ Perceptions of Blocks-based Programming makes a great case for well thought-out categories:

The utility of the organization and ease of browsing of the blocks was evident throughout the interviews. For example, during an interview with a grade ten student, we asked if he could draw a square on the screen, he successfully did so, but relied on the forever block in his program. When asked how he would change his program so it would be possible to draw a second square next to the first, he opened, the Control category where looping blocks were stored, read through the blocks, and said “I’m not really sure, I think it's in the tab somewhere though,” showing how the organization of the blocks within the environment can support novices in constructing programs.

Your concern of 'too many blocks' is a real, valid one:

Scratch strives to minimize the number of command blocks while still supporting a wide range of project types. One might argue that flexibility, programmer convenience, and extra features are more important than a small command set. However, in Scratch, unlike a text-based language, every command consumes screen space in the command palettes, so there is a higher “cost” to increasing the command set. Adding more commands requires either adding more categories or forces the user to scroll down to see all the commands within a given category. Either way, a larger command set makes it harder to find a given command in the palettes.

Scratch even actively removes blocks to ensure that the number of blocks and categories doesn't get too large—if students can't find a block, it may as well not exist at all. This links well to the issue of colour: too many categories will mean that you begin to reach an unreasonable amount of colours. I suspect anything more than about 10 or 15 colours would be excessive (Scratch 2.0 has 10 categories).

But, shape also has an important place:

Novice programmers identify the shape of blocks as a key feature that makes block-based programming easy. In an interview with students that had programmed in both Snap! and Java, four out of nine students said the shape of blocks was a key reason for why block-based programming is easy

Typically, these guidelines apply:

• Shape works well to show syntactic constructs—a block with a gap in the middle clearly has an effect on the blocks inside (e.g. an if block). It can also effectively denote 'type' (e.g. Scratch uses a hexagon to represent a boolean, and the shape gives a hint of the expressions that can produce booleans)

• Colour works best to show category—all green blocks obviously have a similar purpose, and students quickly recognise that.

• Too many shapes and colours just lead to confusion; try and have the least amount of shapes and categories while remaining logical and consistent.

I, too, was going to form part of my answer around the article Aurora shared on the development of Scratch.

Snap! makes its debt to Scratch explicit. In the "About" section, the its creators discuss their design choices for that which is an extension from Scratch: