Discuss Scratch
- Discussion Forums
- » Suggestions
- » After NGP, please aim to fill in commonly suggested programming features
- HAL95131
-
Scratcher
100+ posts
After NGP, please aim to fill in commonly suggested programming features
After NGP, please aim to fill in commonly suggested programming features
I am talking about things like the following:
This one…
And this one…
Even this one…
Maybe even this one!
You might think this is a list of suggestions at first, but it's actually not.
I'm suggesting a goal after NGP is put in place. Not necessarily just for 4.0, although it could be put towards 4.0. I'd like you to think of this as a more general goal, though.
1. These are suggested pretty commonly or are obviously useful for projects with larger scopes
I'm not going to make an argument here that it's “easy to add” or that it would “take five minutes”. Although in some cases that could be true, it's not really the point. The difficulty isn't the problem, the fact that it will even be done in the first place is.
2. Isn't this just “Scratch team listens” v2?
No, I'm suggesting a goal. Although increasing transparency between the community and the Foundation WOULD help, the goal ITSELF needs to be put into place (or at least confirmed). I agree with Paymer, but this is about the general code and project area of Scratch. Those improvements can be made later, but the actual code blocks should be made more accessible.
3. But the majority of Scratch users are young and this is a beginner coding platform!
Exactly. They'll learn the motion blocks. Then the looks, sensing… then they'll move onto math, custom blocks. Then matrices, tables, physics… Scratch is meant to help you grow. You either move on, or you don't. So why not make the launchpad include the concepts you'd see later, too, if it follows your progression and growth as a coder? “Too complex” is why they will get to these more complicated features later. Everyone started somewhere, and you did too.
4. Workaround: blahblah. Workaround: blahblahblah
Now that is where it ACTUALLY starts to get too complex for younger Scratchers. You can't replace every feature with a workaround. Some workarounds are so complex they require changing the blocks yourself in order to fully implement them, or require blocks upon blocks upon blocks inside of a single function just to squeeze something into a return variable. It's clunky. There are simple workarounds, and those don't need to be tackled, but the complex ones need to be whittled down to single blocks. Yes, it's backpackable, and yes, it's easy to drag and drop into the editor, but these sorts of things really need to be in the editor by default in the future.
Surely working under constraints is a fun exercise, but it tends to become a hassle at a point. If Scratch is designed to be simple for kids, we should be going towards making those things accessible for them, too, alongside the older portion of the community who regularly needs or uses these features.
The last thing I want to go about on here is: why do we need to “reject” certain suggestions related to common features so much as just close the topic and guide the OP into rethinking and posting a better or simpler implementation? Obviously things like money blocks, cloud lists, and controlling the mouse pointer should still be banned, but code features seen in other programs should not be shunned or flat out rejected. There can and will be a way to implement certain features without them being too complex.
Part 2
How about the solutions?
1. Round up Scratchers to test out new blocks
or
2. Throw it all in Scratch Lab and see what sticks
or
3. Let Scratchers themselves do the heavy lifting so Scratch Foundation can focus on their own things.
Once they finish NGP, there are so many other things Scratch Foundation can do instead of just vetoing a suggestion that could be implemented well and moving on.
- - - - - - - - - - - - - - - - - - - - -
I am talking about things like the following:
This one…
return [] :: cap custom
And this one…
(table :: list)
Even this one…
(Ⓛ save data)
Maybe even this one!
- - - - - - - - - - - - - - - - - - - - -
You might think this is a list of suggestions at first, but it's actually not.
I'm suggesting a goal after NGP is put in place. Not necessarily just for 4.0, although it could be put towards 4.0. I'd like you to think of this as a more general goal, though.
1. These are suggested pretty commonly or are obviously useful for projects with larger scopes
I'm not going to make an argument here that it's “easy to add” or that it would “take five minutes”. Although in some cases that could be true, it's not really the point. The difficulty isn't the problem, the fact that it will even be done in the first place is.
2. Isn't this just “Scratch team listens” v2?
No, I'm suggesting a goal. Although increasing transparency between the community and the Foundation WOULD help, the goal ITSELF needs to be put into place (or at least confirmed). I agree with Paymer, but this is about the general code and project area of Scratch. Those improvements can be made later, but the actual code blocks should be made more accessible.
3. But the majority of Scratch users are young and this is a beginner coding platform!
Exactly. They'll learn the motion blocks. Then the looks, sensing… then they'll move onto math, custom blocks. Then matrices, tables, physics… Scratch is meant to help you grow. You either move on, or you don't. So why not make the launchpad include the concepts you'd see later, too, if it follows your progression and growth as a coder? “Too complex” is why they will get to these more complicated features later. Everyone started somewhere, and you did too.
4. Workaround: blahblah. Workaround: blahblahblah
Now that is where it ACTUALLY starts to get too complex for younger Scratchers. You can't replace every feature with a workaround. Some workarounds are so complex they require changing the blocks yourself in order to fully implement them, or require blocks upon blocks upon blocks inside of a single function just to squeeze something into a return variable. It's clunky. There are simple workarounds, and those don't need to be tackled, but the complex ones need to be whittled down to single blocks. Yes, it's backpackable, and yes, it's easy to drag and drop into the editor, but these sorts of things really need to be in the editor by default in the future.
- - - - - - - - - - - - - - - - - - - - -
Surely working under constraints is a fun exercise, but it tends to become a hassle at a point. If Scratch is designed to be simple for kids, we should be going towards making those things accessible for them, too, alongside the older portion of the community who regularly needs or uses these features.
The last thing I want to go about on here is: why do we need to “reject” certain suggestions related to common features so much as just close the topic and guide the OP into rethinking and posting a better or simpler implementation? Obviously things like money blocks, cloud lists, and controlling the mouse pointer should still be banned, but code features seen in other programs should not be shunned or flat out rejected. There can and will be a way to implement certain features without them being too complex.
- - - - - - - - - - - - - - - - - - - - -
Part 2
How about the solutions?
1. Round up Scratchers to test out new blocks
or
2. Throw it all in Scratch Lab and see what sticks
or
3. Let Scratchers themselves do the heavy lifting so Scratch Foundation can focus on their own things.
Once they finish NGP, there are so many other things Scratch Foundation can do instead of just vetoing a suggestion that could be implemented well and moving on.
Last edited by HAL95131 (Sept. 10, 2026 16:44:23)
- yayapoppity
-
Scratcher
1000+ posts
After NGP, please aim to fill in commonly suggested programming features
support, i dont see anything bad that could happen
- scratchy_boy106
-
Scratcher
1000+ posts
After NGP, please aim to fill in commonly suggested programming features
support, i dont see anything bad that could happenYeah
- scratchy_boy106
-
Scratcher
1000+ posts
After NGP, please aim to fill in commonly suggested programming features
Maybe we can do it 4.0
- I_wantasheep
-
Scratcher
1000+ posts
After NGP, please aim to fill in commonly suggested programming features
if they dont i will explode*
*not literally
*not literally
Last edited by I_wantasheep (Sept. 10, 2026 16:38:56)
- HAL95131
-
Scratcher
100+ posts
After NGP, please aim to fill in commonly suggested programming features
Maybe we can do it 4.0
The point of my post is to get it in in the area BETWEEN NGP and 4.0 so that they can focus on just 4.0 later.
Last edited by HAL95131 (Sept. 10, 2026 16:41:20)
- Paddle2See
-
Scratch Team
1000+ posts
After NGP, please aim to fill in commonly suggested programming features
Please create a separate topic for each suggestion you have, rather than creating a list of suggestions. That way, the conversation stays focused and each idea can get the attention it needs.
Before making a new topic, please check out the following:
Before making a new topic, please check out the following:
- The Informal and Unofficial List of Rejected Suggestions. If your suggestion is in this list, please do not make a new topic about it, as it will not be implemented anyway.
- The Suggestions Directory. If your suggestion is in this list, please continue the discussion in the existing topic, rather than making a new topic.
- Discussion Forums
- » Suggestions
-
» After NGP, please aim to fill in commonly suggested programming features