The ugly violet dome for new blocks (especially for those with a very long specification, see http://mv.ezproxy.com.ezproxyberklee.flo.org/projects/10033647/#editor) makes the otherwise excellent look of the new editor really bad to me

I understand what the goals are:

• identify the script as the definition of something
  
• make it clearly visible
  
• do not confuse the “dome” with a “hat”
  

But, after all, the definition “dome” IS an event hat. Indeed, WHEN you use the block (so, when HAPPENS that you use it) the script under the dome is run. The only difference is that this time you have parameters and the execution cannot be stopped (so, you use a sort of “clone” of the script each time this is started). How could these goals be achieved?

1. by giving the definition hat the shape of a classic Scratch hat block
   
2. giving the definition hat the color you like, selected among the other Scratch blocks' colors (or a new one, violet too can work, if you like)
   
3. giving the definition block the “correct” name, that is, for example, “WHEN the square BLOCK IS RUN”
   

An alternative, that I like a lot, is to have the definition block like a regular C-shape block in the Control category (it could be for example called “do”):

• you can give the block a name with a menu (similar to the “new message” menu)
  
• you can add parameters by clicking a small black arrow to the far right of the block
  
• you can collapse the block content (the block definition) by clicking a small “up/down” arrow.
  

When you drag a new “do” block and you select the name of an already definited block, the C mouth is automatically collapsed (so you don't have to do it yourself every time).

So this is similar to messages with parameters (something that Scratch users are asking since a very long time) and different (being a real block, you cannot interrupt its internal running until it is finished). And I think it would REALLY work better.

I agree, it also covers scripts above it. It also gets really crowded for the important scripts that you may need to modify more often. I think the BYOB idea might be a little cleaner, especially once you start changing the block type to a reporter or boolean.

s_federici wrote:

The ugly violet dome for new blocks (especially for those with a very long specification, see http://mv.ezproxy.com.ezproxyberklee.flo.org/projects/10033647/#editor) makes the otherwise excellent look of the new editor really bad to me.

Cool project!

Yes, those domes certainly do get tall when you have long specifications!

Thanks for your suggestions. We thought a lot about the process of creating procedures and considered some the ideas you suggested. We settled on the current approach partly because it makes the first step towards abstraction, naming as simple as possible, while de-emphasizing parameter specification until people need that. The idea is to create a gradual path towards understanding for those just learning about procedures rather than presenting all the options at once. I think we'll probably continue with the current approach for a while to see how well it works with beginners, but we can always revisit the design later, so we'll keep your suggestions in mind.

Meanwhile, it might be possible to tweak the shape of those procedure definition blocks so they scale better. Thanks for pointing out the problem.

s_federici wrote:

But, after all, the definition “dome” IS an event hat. Indeed, WHEN you use the block (so, when HAPPENS that you use it) the script under the dome is run. The only difference is that this time you have parameters and the execution cannot be stopped (so, you use a sort of “clone” of the script each time this is started).

The definition hat is different from an event hat, because you can only have one per sprite. You have to exactly one definition for each block and can't throw it away. So it seemed important not to make it seem similar to a WHEN block.

The team considered having blocks be customizable colors, but it was decided the priority was on making clear to people at a glance which are custom defined blocks.

It will be interesting to see how people make use of them!

natalie wrote:

The definition hat is different from an event hat, because you can only have one per sprite. You have to exactly one definition for each block and can't throw it away. So it seemed important not to make it seem similar to a WHEN block.

I understand what you mean. Usually in a programming language you cannot define the same procedure twice and keep both definitions (usually you get and error, or the last definition override the first).

But Scratch, and this is its wonderful strenght, is very dissimilar from regular programming. So, even having the same function defined more than once could be handled by calling all its definitions at the same time. As it happens for scripts starting with the same hat. But, if we don't want it instead, warning the user that the same name has been already used could really work really well. I don't think the Scratch user would be upset by this. They will think “ok, with this hat I cannot use twice the same name”. And they will use another name.

johnm wrote:

Meanwhile, it might be possible to tweak the shape of those procedure definition blocks so they scale better

And could we do something about the color too ? Maybe light/bright yellow? (to me, they keep being something very close to control/events, so it shouldn't be the source of misunderstanding)

s_federici wrote:

johnm wrote:

Meanwhile, it might be possible to tweak the shape of those procedure definition blocks so they scale better

And could we do something about the color too ? Maybe light/bright yellow? (to me, they keep being something very close to control/events, so it shouldn't be the source of misunderstanding)

I like the color, but there is a lot of purple blocks.
Looks and Sensor/Lego WeDo blocks are also purple.
Wouldn't bright yellow blocks be hard to see though? Since the text is white?
See what I mean here

The block is pretty hard to read, right? You have to squint to see it.
Maybe a black block would be cool :p

Dark gray, like in BYOB, seems like a good middle ground between easy-to-see and cool-looking.

Hardmath123 wrote:

Dark gray, like in BYOB

Incidentally, this is the only color of BYOB blocks that I don't think is really appropriate for Scratch…

With a single character new block, the define block goes higher than all other blocks. This is fine. But is there a reason it becomes taller than this? I find the presence of the resultant mega-sized blocks disconcerting. And do not like the loss of scripting screen real estate.

ETA: I think it could help the learning curve for how the new custom blocks work to append the text “for this sprite” to the definition cap.

So instead of

define [block name]

change it to be

define [block name] for this sprite

Shorter blocks and adding “for this sprite” make sense to me. Though I think they likely won't make the short list for release –for the editor that involves fixing bugs, minimizing lags, and refining saving– but think they could potentially be features that are added.

@s_federici It's really interesting what you suggest about blocks having more than one definition, though I think there are a couple of reasons to leave procedure definition at a single definition.

natalie wrote:

though I think there are a couple of reasons to leave procedure definition at a single definition.

Would you like discussing them?