scratch-blocks: 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.
About this issue
- Original URL
- State: open
- Created 8 years ago
- Reactions: 2
- Comments: 18 (3 by maintainers)
And one of its greatest strengths for beginners!
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.
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,
h1means 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 abbreviateimagetoimg, 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 rightandturn leftblocks 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.I had some random related thoughts to this that have been bouncing around in my head, let me know if its worthwhile to post separately somewhere else (and if you think if they’re decent ideas or absolutely worthless!).
For more advanced users, I feel like Scratch has a lot of pervasive blocks (I’d personally never use think or say), but can still lack some core features that some might want. What about being able to customize which blocks show up at all, and where? If I don’t want to use it, I could hide it. If I don’t like the order or its subsection, I could move it (or make a new subsection). If there’s a custom block that I feel should be more easily accessible, I could put it in one of the existing categories in the palette, or make a new category (perhaps either having the color of a custom block on its edges with the color of the category in the middle, or vice-versa, some symbol, or whatever). With all of this, it would be much easier to keep track of and use variables and custom blocks in addition to cleaning up the palette according to how the user likes it. Of course, loading a project wouldn’t necessarily (and probably shouldn’t) load that customization, how it would carry across projects for the user who is customizing is up for debate.
The fact that you need to show all commands explicitly is in my mind one of the biggest downfalls of GUI programming. 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.