<p>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.</p>

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

CC BY-SA 3.0
2017-06-07T12:43:22.377Z
This answer is great, but could be expanded upon to really cover and address the points in the question.
ItamarG3
CC BY-SA 3.0
2017-06-07T13:41:02.663Z
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
CC BY-SA 3.0
2017-06-07T17:24:26.217Z
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
CC BY-SA 3.0
2017-06-07T12:29:56.937Z
2017-06-07T12:29:56.937Z
D. Czechowski
<p>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 <strong>categories</strong> of blocks—the colours just provide a way of visually showing what category a block is in, without an information overload of <em>too much text</em>.</p>

<p><a href="http://ccl.northwestern.edu/testsite/2014/Weintrop%20and%20Wilensky%20-%202015%20-%20To%20Block%20or%20Not%20to%20Block,%20That%20is%20the%20Question%20St.pdf" rel="nofollow noreferrer"><em>To Block or not to Block, That is the Question: Students’
Perceptions of Blocks-based Programming</em></a> makes a great case for well thought-out categories:</p>

<blockquote>
  <p>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 <code>forever</code> 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. </p>
</blockquote>

<p>Your concern of 'too many blocks' is a real, valid one:</p>

<blockquote>
  <p>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.</p>
  
  <p>— <a href="http://s3.amazonaws.com/academia.edu.documents/6721160/scratchlangandenvironment.pdf?AWSAccessKeyId=AKIAIWOWYYGZ2Y53UL3A&amp;Expires=1496945599&amp;Signature=I2ZK4KcwZgoq5Gm437VxSxZHsHc%3D&amp;response-content-disposition=inline%3B%20filename%3DThe_Scratch_Programming_Language_and_Env.pdf" rel="nofollow noreferrer">The Scratch Programming Language
  and Environment</a></p>
</blockquote>

<p>Scratch even actively <strong>removes</strong> 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 <a href="https://wiki.scratch.mit.edu/wiki/Block_Categories" rel="nofollow noreferrer">has 10 categories</a>).</p>

<p>But, <strong>shape</strong> also has an important place:</p>

<blockquote>
  <p>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</p>
  
  <p>— <a href="https://canvas.auckland.ac.nz/files/869920/download?download_frd=1&amp;verifier=1gFIy9nSx7VwVP4MfJ5PtrcSvN94jUznjqAK6Wpk" rel="nofollow noreferrer">Tackling the Transition from Block-based to Text-based
  Programming Languages</a></p>
</blockquote>

<p>Typically, these guidelines apply:</p>

<ul>
<li><p><strong>Shape</strong> works well to show <em>syntactic constructs</em>—a block with a gap in the middle clearly has an effect on the blocks inside (e.g. an <code>if</code> 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)</p></li>
<li><p><strong>Colour</strong> works best to show <em>category</em>—all green blocks obviously have a similar purpose, and students quickly recognise that.</p></li>
<li><p><strong>Too many</strong> shapes and colours just lead to confusion; try and have the <strong>least</strong> amount of shapes and categories while remaining logical and consistent.</p></li>
</ul>

CC BY-SA 3.0
2017-06-08T17:33:06.750Z
2017-06-08T17:33:06.750Z
Aurora0001
<p>I, too, was going to form part of my answer around the article Aurora shared on the development of Scratch.</p>

<p>Snap! makes its debt to Scratch explicit. In the <a href="http://snap.berkeley.edu/about.html" rel="nofollow noreferrer">"About" section</a>, the its creators discuss their design choices for that which is an extension from Scratch:</p>

<blockquote>
  <p><strong>Visual Representation for Advanced Ideas</strong></p>
  
  <p>Part of the genius of Scratch is the way it uses pictures to represent
  ideas such as loops, Booleans, and threads. The three different block
  shapes, for example, aren’t just a way to prevent syntax errors;
  they’re a way to teach the idea that some procedures return values and
  others don’t.</p>
  
  <p>In Snap! we extend this visual teaching to ideas that have previously
  been considered too hard for young learners. For example, the
  screenshot on our home page includes this picture of a list of blocks.
  Experienced Scratch programmers will never have seen anything quite
  like this before, but they recognize the pictorial representation of a
  list in Scratch, and they know what blocks look like, and so it’s
  immediately obvious to them what they’re seeing. They realize without
  explicit teaching that blocks, which they’ve until then used only as
  program control elements, can also be used as data.</p>
</blockquote>

<p>The <a href="http://snap.berkeley.edu/SnapManual.pdf" rel="nofollow noreferrer">Snap! Manual</a>, while probably more information than you want or need, does also discuss the logic behind its color and shape choices. In particular, Section I and Section X provide explanation and justification of the design of the Snap! environment. I would think that in any original or modified design of a block-based language, using the development of Scratch and Snap! to inform your own is as research-based as you can get.</p>

CC BY-SA 3.0
2017-06-08T17:44:15.650Z
2017-06-08T17:44:15.650Z
Peter
<p>I am designing a blocks-based language to use in my classrooms and summer camps. Since I am using the <a href="https://developers.google.com/blockly/" rel="nofollow noreferrer">Blockly</a> framework, I am able to choose my own colors for the blocks and am looking for information to guide my selection. </p>

<p>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.</p>

<p>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?</p>

CC BY-SA 3.0
2017-06-07T00:54:12.030Z
I really like this question, but it seems like it might be a better fit on [ux.se]. While it _is_ about cs education, it's also very much about designing an interface for a specific audience.
thesecretmaster
CC BY-SA 3.0
2017-06-07T01:18:12.693Z
Wouldn't I get better information about my specific audience here? General UX design principles are certainly important, but the colors have a lot to do with programming concerns like types.
kaerimasu
CC BY-SA 3.0
2017-06-07T01:23:13.000Z
I guess you're right. I still think that the people at [ux.se] might have some interesting ideas, especially if you're looking for studies, but you'll also get good answers here.
thesecretmaster
CC BY-SA 3.0
2017-06-07T05:09:53.723Z
I'm voting to close this question as off-topic because it's more about UX than education.
Peter
CC BY-SA 3.0
2017-06-07T07:36:56.337Z
I'm voting to close this question as off-topic because it doesn't specifically deal with teaching computer science, rather it asks about color psychology in the sense of teaching, which isn't exactly in the site's scope.
ItamarG3
CC BY-SA 3.0
2017-06-07T10:10:08.650Z
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
CC BY-SA 3.0
2017-06-07T12:39:40.077Z
Block colors organize code in block languages. This seems on-topic to me.
Ben I.
CC BY-SA 3.0
2017-06-07T17:53:03.713Z
IMO this is related to the use of color for syntax highlighting & relates to how people understand the code in front of them. I'm guessing that using colors at this stage will make the first use of an IDE feel more natural.
G. Ann - SonarSource Team
CC BY-SA 3.0
2017-06-07T22:26:11.363Z
I have created a meta-question about this question [here](https://cseducators.meta.stackexchange.com/questions/103/questions-about-ide-features)
Ben I.
CC BY-SA 3.0
2017-06-08T02:04:15.810Z
As a consequence of the meta discussion, this question was discussed (and can be discussed further) [in chat.](http://chat.stackexchange.com/rooms/60102) **Before voting to reopen, please refer to the discussion in chat**
thesecretmaster
CC BY-SA 3.0
2017-06-08T02:06:18.790Z
@kaerimasu You may find this discussion helpful in discerning color choice (from UX.SE): https://ux.stackexchange.com/questions/94278/should-software-for-8-to-14-year-olds-be-colourful-and-childish
Peter
<block-based-programming>
Colors in Blocks-based Languages
# Colors in Blocks-based Languages

(Asked by: username_0 on 2017-06-07)

I am designing a blocks-based language to use in my classrooms and summer camps. Since I am using the [Blockly](https://developers.google.com/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?

**Tags:** block-based-programming

> **Comments:**
> **username_1**: I really like this question, but it seems like it might be a better fit on [ux.se]. While it _is_ about cs education, it's also very much about designing an interface for a specific audience.  
> **username_0**: Wouldn't I get better information about my specific audience here? General UX design principles are certainly important, but the colors have a lot to do with programming concerns like types.  
> **username_1**: I guess you're right. I still think that the people at [ux.se] might have some interesting ideas, especially if you're looking for studies, but you'll also get good answers here.  
> **username_2**: I'm voting to close this question as off-topic because it's more about UX than education.  
> **username_3**: I'm voting to close this question as off-topic because it doesn't specifically deal with teaching computer science, rather it asks about color psychology in the sense of teaching, which isn't exactly in the site's scope.  
> **username_4**: 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.  
> **username_5**: Block colors organize code in block languages. This seems on-topic to me.  
> **username_6**: IMO this is related to the use of color for syntax highlighting & relates to how people understand the code in front of them. I'm guessing that using colors at this stage will make the first use of an IDE feel more natural.  
> **username_5**: I have created a meta-question about this question [here](https://cseducators.meta.stackexchange.com/questions/103/questions-about-ide-features)  
> **username_1**: As a consequence of the meta discussion, this question was discussed (and can be discussed further) [in chat.](http://chat.stackexchange.com/rooms/60102) **Before voting to reopen, please refer to the discussion in chat**  
> **username_2**: @username_0 You may find this discussion helpful in discerning color choice (from UX.SE): https://ux.stackexchange.com/questions/94278/should-software-for-8-to-14-year-olds-be-colourful-and-childish  

---

## 3 answers

### Answer by username_7 on 2017-06-07. Score: 6

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.

> **Comments:**
> **username_3**: This answer is great, but could be expanded upon to really cover and address the points in the question.  
> **username_8**: 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.  
> **username_9**: 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.  

---

### Answer by username_10 on 2017-06-08. Score: 4

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*](http://ccl.northwestern.edu/testsite/2014/Weintrop%20and%20Wilensky%20-%202015%20-%20To%20Block%20or%20Not%20to%20Block,%20That%20is%20the%20Question%20St.pdf) 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.
>
> — [The Scratch Programming Language
> and Environment](http://s3.amazonaws.com/academia.edu.documents/6721160/scratchlangandenvironment.pdf?AWSAccessKeyId=AKIAIWOWYYGZ2Y53UL3A&Expires=1496945599&Signature=I2ZK4KcwZgoq5Gm437VxSxZHsHc%3D&response-content-disposition=inline%3B%20filename%3DThe_Scratch_Programming_Language_and_Env.pdf)

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](https://wiki.scratch.mit.edu/wiki/Block_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
>
> — [Tackling the Transition from Block-based to Text-based
> Programming Languages](https://canvas.auckland.ac.nz/files/869920/download?download_frd=1&verifier=1gFIy9nSx7VwVP4MfJ5PtrcSvN94jUznjqAK6Wpk)

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.


---

### Answer by username_2 on 2017-06-08. Score: 3

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](http://snap.berkeley.edu/about.html), the its creators discuss their design choices for that which is an extension from Scratch:

> **Visual Representation for Advanced Ideas**
>
> Part of the genius of Scratch is the way it uses pictures to represent
> ideas such as loops, Booleans, and threads. The three different block
> shapes, for example, aren’t just a way to prevent syntax errors;
> they’re a way to teach the idea that some procedures return values and
> others don’t.
>
> In Snap! we extend this visual teaching to ideas that have previously
> been considered too hard for young learners. For example, the
> screenshot on our home page includes this picture of a list of blocks.
> Experienced Scratch programmers will never have seen anything quite
> like this before, but they recognize the pictorial representation of a
> list in Scratch, and they know what blocks look like, and so it’s
> immediately obvious to them what they’re seeing. They realize without
> explicit teaching that blocks, which they’ve until then used only as
> program control elements, can also be used as data.

The [Snap! Manual](http://snap.berkeley.edu/SnapManual.pdf), while probably more information than you want or need, does also discuss the logic behind its color and shape choices. In particular, Section I and Section X provide explanation and justification of the design of the Snap! environment. I would think that in any original or modified design of a block-based language, using the development of Scratch and Snap! to inform your own is as research-based as you can get.


---

