Yeah, I dunno. The padding issue isn't really perfectly solvable, especially (I grant you) with a scan line here and there taken up with shadow. As for the font itself, any font is fine as long as it's Baskerville. But I think even then I'd go for semibold.
If you're using HTML and CSS...couldn't you just insert "padding:1px;" (or any other amount) into a file? I'm assuming that blocks have a specific class. You could add that line into the styles for the class.
Scratch 3 had the right idea, but they went a bit overboard. The blocks should have some more padding...just not the same amount as Scratch. As you can see in the screenshot, the blocks have excessive padding.
Yeah, I don't understand why the input slots for +-*/ are so much bigger than in the other blocks. That's hideous.
Alas, we can't use simple CSS approaches. As far as the browser is concerned, the entire Snap! window is one big Canvas; widget management within that canvas is handled by Snap! itself, by way of the Morphic graphics system, which Jens chose because it allows for better "liveliness": the ability to modify code while it's running and see the effect immediately. He pays a big cost in development effort, but liveliness is a really important goal for him.
Personally, being old and farsighted, I would turn all that padding into a larger font; I have to squint to read the text of those blocks.
Scratch has made a bunch of more substantive UI design decisions in recent years that, to me, emphasize how our goals have diverged, e.g., making all input slots round. We've adopted or semi-adopted some of their ideas; we now have a "single palette" option which I personally would never use (because it's harder to scroll down to your custom blocks within a category, not an issue for them because they put all your custom blocks at the end) but is popular among teachers for some purposes, for which they hide all but a few blocks, from more than one category, and want them all to appear in the palette at once.
In our early days we thought really hard about the UI. I think Scratch would benefit from some of our innovations, such as zebra coloring and visible spaces (those brown dots) in text input slots. I'm very proud of those. Recently we've been more concentrated on semantic support for applications, things like first class costumes and sounds, and high-speed programmability of bitmaps. We do still make small UI improvements targeted to specific user problems, e.g., allowing users to specify the line breaks in custom blocks with a lot of text, such as those speech or AI-training ones people have been inventing. Maybe someday When Things Slow Down™ we can think about things like shapes of blocks again.
That’s hilarious 
(WTSD = either one’s dead or irrelevant)
Scratch 3.0 looks awesome!
No they don't
Yes, they do…
Scratch 3 looks amazing, but there is excess padding. You don’t need to have extra space in blocks. There’s enough space for you to drag them and insert inputs.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.