shouldn’t the palette selector look like
instead of
Yes but it’s never made it to top of the jobs list 
I mean if it did there would only be 6 blocks in the variables category and none in the other category.
well there are 3 other primitives, they just aren’t visible by default unless you turn on “Extension blocks” in the options menu.
If we’re really being nitpicky, there are 4 more hidden under “codification support”:
I’m not sure the devs want it to work this way. In Scratch, Lists are under the Variables category as well, even as they have a separate colour. You might make an argument about the fact that lists are first class and whatnot, but I would counter that both are used to store data. I really don’t care too much about it in this respect.
Additionally, I have some aesthetic observations. The lists category underneath the pen doesn’t make a lot of sense, especially when reading up-down, left-right. Here’s my idea:
However, it would probably end up looking more like this (because the Other category would be empty):
This is both not aesthetically pleasing and also potentially confusing to newcomers.
fair, but maybe at least as an option?
i got that image from the block creation screen
In the beginning, we had Variables and Lists together because Scratch did, and there must have been thousands of design elements in which we just followed Scratch without thinking about it much.
But for a long time I’ve wanted to separate them. Jens didn’t want to, back then, because he was very worried about using up vertical space in the palette area, thereby pushing some primitives in some categories below the bottom of the window.
We had an actual fight about it when Jens and Jadga wanted to move ADD TO up above the higher order functions, on the grounds that in their workshops, ADD TO was very commonly used. I adamantly rejected the idea, because our policy was to promote functional programming rather than imperative programming, and as a counterproposal I pointed out that separating Lists from Variables would make enough room to keep everything (back then) in Lists onstage at once. I’m still not sure why Jens still rejected that idea.
But now that we have user-defined categories, it seems to me that the idea of protecting vertical space in the palette area is dead, and it’s time to revisit separating Variables, Lists, and Other. (And maybe separating Events from Control, although I’d rather solve the Augean problem of the Control palette by introducing drawers.)
@mark4sisb I hadn’t thought about rearranging the two columns to keep Lists in the right column, but now that you suggest it, of course that’s how we should do it. To avoid disconcerting users by moving Sensing, though, I would put Other in the bottom left corner.
Now we just have to convince Jens. :~)
P.S. And also I think all user-defined blocks should appear in Other as well as appearing in the category in which the user puts them. But not library blocks, which should be treated as much as possible like primitives once the library is loaded. But that’s another discussion for another day.
P.P.S. If we were starting from scratch, rather than from Scratch, I would actually argue that Lists should be under Operators, rather than under Variables, because Snap! lists are first class, and so the List blocks are (almost) all functional, like the Operators blocks, rather than side effectful like Variables.
lol
This makes sense.
Would it be possible to move the category selection to the side? because in this case, I agree with Jens.
Would it be possible to move the category selection to the side? because in this case, I agree with Jens.
You mean like this?
Aside from the fact that it makes it less obvious that the category window is related to the palette window, the other problem I see with that idea is that adding user categories would have to eat into scripting area vertical space.
Personally, I think you should keep it as it is but have a scroll feature for the top left like the blocks. Using less vertical space AND using the extra “lists and other” blocks. As well as extra custom blocks that users may add.
My thought was to do something similar to what scratch did, where all the categories are in a single column along the left side. I don’t know if this is very good or not, because that prioritizes the color over the name, due to the name having to be small in order to fit.
I meant making it vertical so that you can scroll if there are too many categories. At least as an option, because I really like being able to fit more blocks into one screen of the palette.
Oh, I see. No, to me the newer Scratch layout makes sense only if you also have their single palette design, which strongly deemphasizes categories, so the vertical array of block colors has the feel of the thumb tabs in a dictionary, as pointers into one long text, like the table of contents on long Wikipedia pages. That’s a nonstarter once we have user-defined categories.
(We have single palette as an option not so much for quotidian use, but for Parsons-problem projects in which only a handful of blocks are visible in the palette altogether, easily fitting into a single screenful, and you want all of them visible at once regardless of category.)
That has the advantage of not changing the existing logic of the palette space, but it has the big disadvantage of making some block categories not discoverable for beginners.
No, folks, I think we’re way past the stage of worrying about the tiny sliver of vertical space taken up by one row of palette category names. Our vertical space problem requires, imho, a much more aggressive solution, namely, subcategory drawers that the user can open or close at will, or maybe that pop open to the right of the palette area when you hover over its title, like submenus. This is especially true in Control, which is ludicrously long since metaprogramming (which should arguably be a category of its own, along with Events), but every category except Motion is too tall to be welcoming.
my problem is that it isn’t one row, it would be 5. How am I supposed to find that one custom block I can’t remember the exact name of when the category selector is like this?:
I really just need this as an option. Whenever I want one metaprogramming block, I have to use the search bar. When I want to find one block in the colors and crayons library, it is an absolute mess. So really, I think having vertical categories as an option, and
as a feature would nearly completely eliminate this problem.
I have Zoom Blocks set to 1.5 all the time, so I can sympathize about the lack of palette space, but I don’t see how a Scratch-like vertical category selector would work with user-defined categories, especially when there are a lot of them, as in your SciSnap! example. Those extra categories have long, complicated names, without which people couldn’t find the block they want, because, unlike the primitive categories, nobody has those categories memorized. If the vertical selector became taller than the Snap! window, it wouldn’t even be obvious to the user that those extra categories exist!
Metaprogramming should be separated out somehow, as a drawer or as its own category. Colors and crayons suffers from predating the ability to hide blocks in the palette; I should clean that up. (Although now that we have first class colors, the six blocks from that library that are meant to be user-visible should be primitive, imho. Since three of the six are extended redefinitions of primitive Pen blocks, that would only take three new primitive slots.)
Exactly the reason why I don’t think it’s a good idea as well. You can actually look at Split (the mod to make snap look like scratch), because they implemented a vertical category selector. Currently Split doesn’t wrap the text when it’s too long, but even with text wrapping, it wouldn’t be very good.
Also, the bar would be scrollable if it extends further than the window.
LMAO
snitch?
It could also just be a thing where you hover over it. Either way, I’m pretty sick of having to search for any block I want.