Blocks not laid out optimally

This is a bit of a subjective decision, but I’ll try to back things up with as much data as I can:

Currently, the Scratch 3.0 block palettes are laid out in the same way as they are in 2.0 (with the exception of groupings: #752). However, this layout isn’t the best. After taking some time to look through the block usage statistics, I found that the blocks placed at the top of the palette aren’t always the most used blocks. This is an issue because the further down a block is in the palette, the more likely it is that a user will need to scroll in order to reach it (especially with the larger 3.0-style blocks, which will require more scrolling in general).

Take, for instance, the say and think blocks. They are all placed at the very top of the “looks” palette, and take up a fair amount of room. Yet the block usage statistics (found at the bottom of the stats page) show that the think and say blocks make up a very small portion of all looks blocks used.

In order to aid with the creation of an alternate palette, I’ve created an ordered list of Scratch blocks, sorted by usage: https://gist.github.com/PullJosh/aa842db1cdfe1fe553b2a1ebe2396646

Based on these statistics, I’ve created an alternate layout for the Looks and Motion palettes: https://gist.github.com/PullJosh/85275f2b8f05ca255fa1891ec4cabdc1 (If this is something that people are interested in, I’d be happy to arrange the rest of the palettes as well.)

My goal with the new arrangement was to keep blocks grouped logically, while also ordering them based on usage. Every decision was made intentionally (I feel that I could justify every decision made), but things could always be changed if someone disagrees. The hope is that, with a new layout, Scratch could retain its user-friendliness while also saving time for users.

[rachel-fenichel]

The fact that you need to show all commands explicitly is in my mind one of the biggest downfalls of GUI programming.

And one of its greatest strengths for beginners!

Personally I wouldn’t argue if there were improved ways to organize it, or even shortcuts allowing you to not need to go digging each time you want to get something.

How would you feel about a search box for the palette? This is an idea that’s been kicking around on blockly for a while, but needs a lot of thought to handle internationalization properly.

I’ll leave discussion of the actual block ordering to the scratch team.

[PullJosh]

On the topic of a search bar:

There’s an old, now abandoned project by the ATers which was meant to be a Sctatch-like website editor. Although the project itself never turned into something especially impressive, the search function (for finding blocks) was pretty helpful. Especially in the case of HTML or CSS, where there are countless options for elements and styles, a search feature was mandatory.

You can try Elemental in action here: https://elementalcode.herokuapp.com/projects/editor (Search is in the top right.)

One of the big things that I liked about the Elemental search bar was that it acted as more than just a ctrl+f for blocks. HTML element names aren’t very descriptive (For example, h1 means nothing unless you’ve already been told). The search bar in Elemental was able to lead users to the correct element without them needing to know the name already. For instance, a user might want to add an image to their page. It might not be intuitive to abbreviate image to img, so Elemental handles that for you. Try searching for “image” in the search bar. 😉 I feel the same could be done in a Scratch search bar:

Say a person wants to make a character spin. They might not know which block to use. But if they can search “spin” and have the turn right and turn left blocks presented to them, that’s an extremely powerful feature. I’ve always been a fan of learning through trial and error, and an intelligent search bar would make that a little bit easier.