Rethink a part of the Scratch teams mentality

sonic__fan

We're not saying “add advanced blocks”, we're saying “rethink the mentality of ‘less features=better user experience’ and allow new features to come to Scratch”.

Jackson49_test

Bump

k0d3rrr

Bump!

Za-Chary

A lot of what I have to say about this suggestion was covered in similar long posts of mine, so I'm going to make this one a little shorter and skip some of the points you're making.

dertermenter wrote:
The priority list in scratch is flawed. Whilst I do understand server work, site performance and making the site safe are important issues, but these should only be ranked higher than new features to an extent.

I would kind of expect these to always take priority, though. For lack of a better example, let's suppose that implementing dark mode would somehow make the website extremely slow and unsafe. (Obviously I know that wouldn't happen for dark mode — it's just an example.) Well, I don't think it's worth implementing dark mode if that means the website is now very slow and unsafe to use. If the Scratch Team had to pick dark mode versus making the website as safe as it is now, I think they would rightfully pick that the website should be safe to use.

dertermenter wrote:
with no new features, the community […] start to have second thoughts using scratch due to it becoming stale, making them reconsider over rivals in the block-based coding market, like Snap! and beetle blocks.

I believe it. But that's not necessarily a bad thing. I don't know to what extent Snap! and Beetle Blocks are “rivals” — I would expect the Scratch Team views them simply as more advanced version of Scratch. There's nothing wrong with a Scratcher wanting to leave Scratch for something more advanced. I'm pretty sure that's the Scratch Team's goal. Once Scratchers feel that they have learned enough with coding to pursue more advanced languages, then Scratch has effectively done its job.

It's kind of like saying that Scratch should implement text-based coding (which is rejected) because otherwise Scratchers will want to leave Scratch and go to Python. …and what's the problem with that?

dertermenter wrote:
with no new features, […] educators start to have second thoughts using scratch due to it becoming stale, making them reconsider over rivals in the block-based coding market, like Snap! and beetle blocks.

I'd need a source that educators are considering moving to other block-based languages. I'm sure Scratch appeals to most educators due to its simplicity — which is extremely important for someone who is learning block-based coding (or coding in general) for the first time.

dertermenter wrote:
Will dark mode ever be implemented?

I hope this isn't related to your points about Snap! and Beetle Blocks. First, I doubt that anyone is leaving Scratch purely because there is no dark mode. Second, from what I saw, Beetle Blocks doesn't even have a dark mode.

dertermenter wrote:
It is always said it is being considered, but then the Scratch Team get no work done because they talk about it for ages

I'd need a source for that. I agree that it's being considered (as it's not rejected), but “considered” does not mean “they are talking about it every day that it's not implemented.”

dertermenter wrote:
With features, the ST talks about it a lot and then decides if it's a good feature for scratch. However, this process is far too slow, and they may think differently to the community - and the community is what matters.

Recall that educators and students are also part of the Scratch community. When many Scratch users don't even have accounts, and even those that do are not always vocal in the community, careful research has to be done somehow.

dertermenter wrote:
Like the2000 said, it is a shame that teenage coders who are not pros have made more progress on the site than pro coders.

“Progress” means different things to different people. The 3.0 studio update is “progress” to some because that means the studio pages were finally updated to 3.0. On the other hand, many users thought it was a “step back.” What some users think is “progress,” others think of as useless.

dertermenter wrote:
And why is that? The teenagers want people to have the best scratch experience with toggles and cool features? But I'm starting to wonder, do the scratch team want that?

The Scratch Team doesn't want, for example, text-based coding in Scratch. While many would argue text-based coding is a “cool feature,” it goes against the main point of Scratch being a block-based programming language. The Scratch Team choosing not to implement text-based coding does not mean the Scratch Team is trying to inhibit Scratch from being as cool as possible.

dertermenter wrote:
Another reason is that the ST take too long in adding things whilst the teenagers do stuff very quickly. But is that a bad thing? More features, the better.

You are conveniently not addressing the Scratch Team's position here that “reducing the number of features often improves the user experience” despite the fact that you are arguing against that. The core reason why “more features, the better” is not always true is that when you're new to Scratch, seeing so many features can be very overwhelming, and can cause new users to get confused or leave Scratch without even trying it. Rather than leave without even trying it, the Scratch Team would rather see someone leave Scratch because they feel they have learned so much from Scratch that they want to keep learning more. The point of Scratch is to introduce others to coding, particularly to those who have never learned coding before. If Scratch was filled with a large number of features, and that caused many new users to never even try Scratch, then I don't think all those features are really worth it.

I remember finding Scratch 1.4 overwhelming at first. Recently I tried a new sound-editing software that I quickly got overwhelmed with due to all the features it had (an upgrade from iMovie for sure). One of the reasons I don't use Snap! is because I find all the new blocks overwhelming — and I've used block-based programming for years.

I feel that you are adopting the mindset of “more features is automatically better” without considering the Scratch Team's point of view. Nothing in your post, from what I see, even addresses the fact that new users can get overwhelmed with many new features.

dertermenter wrote:
So yeah, the Scratch Team should think less and implement more.

Implementing features while disregarding the safety of the website is not a good idea.

dertermenter wrote:
How long does it take for feedback? A year? I do not think it does, and of course, they have already made the blocks.

Feedback for the Scratch 3.0 editor certainly took more than a year despite the fact that most of the editor has already been made.

SuperMarioHome

scratch is a feature

Gato_Amigo111

Support!
Why would this make sense? More features is usually a good thing.

k0d3rrr

This is a great suggestion! Sure, less is more, but in the end, sometimes more is better than less.
Also, an example of a feature that was removed from Scratch (that I'm surprised wasn't mentioned on this topic already) was the Echo effect.
Oh, the Echo effect was the best! I messed around with the effect and made terrible-sounding songs with it! It was catastrophic!
But yeah, this is a great idea.

dertermenter

Za-Chary wrote:
For lack of a better example, let's suppose that implementing dark mode would somehow make the website extremely slow and unsafe. (Obviously I know that wouldn't happen for dark mode — it's just an example.) Well, I don't think it's worth implementing dark mode if that means the website is now very slow and unsafe to use. If the Scratch Team had to pick dark mode versus making the website as safe as it is now, I think they would rightfully pick that the website should be safe to use.

Your contrast in your argument, in my opinion, is flawed, as you are talking about a hypothetical suggestion that has cons that outweigh the pros. They should still implement features that have had discussion and have come to the conclusion it is a good decision, but I think that process can be quicker. Hopefully, you commented on that as well.

Za-Chary wrote:
There's nothing wrong with a Scratcher wanting to leave Scratch for something more advanced. I'm pretty sure that's the Scratch Team's goal. Once Scratchers feel that they have learned enough with coding to pursue more advanced languages, then Scratch has effectively done its job.

This is a decent point, but I am sure Scratch still wants to maintain its status as “the largest block-based coding language” and have a large community that respects Scratch for pulling out good and new updates. Sure, due to Scratch being a beginner programming language and not being moving over to a language more advanced is bound to happen for some users, but some may just want a feature that meets Scratch design goals. Finally, people leaving could pull away donations from Scratch, which they need more than Snap!.

Za-Chary wrote:
I'd need a source that educators are considering moving to other block-based languages. I'm sure Scratch appeals to most educators due to its simplicity — which is extremely important for someone who is learning block-based coding (or coding in general) for the first time.

I agree and will remove that.

Za-Chary wrote:
It's kind of like saying that Scratch should implement text-based coding (which is rejected) because otherwise, Scratchers will want to leave Scratch and go to Python. …and what's the problem with that?

This seems like another comparison that, in my opinion, is flawed. The reasoning for rejecting text-based coding in Scratch is not due to competitors so I do not see this comparison as a valid argument.

za-chary wrote:
I hope this isn't related to your points about Snap! and Beetle Blocks. First, I doubt that anyone is leaving Scratch purely because there is no dark mode. Second, from what I saw, Beetle Blocks doesn't even have a dark mode.

Of course not, just pointing out if a suggestion that is in high demand, has little to no drawbacks and positives, with easy implementation (it is just a simple CSS switch. I am a noob and I can create one) will ever be implemented.

za-chary wrote:
I agree that it's being considered (as it's not rejected), but “considered” does not mean “they are talking about it every day that it's not implemented.”

Well, surely they have discussed its implementation a few times. What conclusions have they gathered?

za-chary wrote:
Recall that educators and students are also part of the Scratch community. When many Scratch users don't even have accounts, and even those that do are not always vocal in the community, careful research has to be done somehow.

This is a good point, for your information I consider anyone to have an account in the Scratch Community. Whilst they may not be vocal in the community (and personally I have seen many student accounts be vocal from personal experiences) I do not think that teachers and students are going to have completely different opinions on a decision most vocal people in the community agree on.

By this logic, I could say “we cannot implement dark mode as we need to assume that the silent bystanders do not support this”. we should believe that silent bystanders have opinions similiar to the rest of the community.

Za-Chary wrote:
“Progress” means different things to different people. The 3.0 studio update is “progress” to some because that means the studio pages were finally updated to 3.0. On the other hand, many users thought it was a “step back.” What some users think is “progress,” others think of as useless.

I mean good updates which go with the design goals.

Za-Chary wrote:
The Scratch Team doesn't want, for example, text-based coding in Scratch. While many would argue text-based coding is a “cool feature,” it goes against the main point of Scratch being a block-based programming language. The Scratch Team choosing not to implement text-based coding does not mean the Scratch Team is trying to inhibit Scratch from being as cool as possible.

Man, I hope my post did not come across as “implement bad/rejected suggestions” as I am seeing a pattern with your arguments. Like I said before, the features implemented should still be considered and come to the conclusion it is a good addition to Scratch.

Za-Chary wrote:
You are conveniently not addressing the Scratch Team's position here that “reducing the number of features often improves the user experience” despite the fact that you are arguing against that. The core reason why “more features, the better” is not always true is that when you're new to Scratch, seeing so many features can be very overwhelming, and can cause new users to get confused or leave Scratch without even trying it.

I agree that this argument needs to be altered as more features can be bad - I more meant that they should implement new features if it still makes the website look beginner-friendly, which Scratch certainly has room for.

On the other hand, not many features can equal a bad user experience and I still think they can add more. It is good that the Scratch UI is so good that there is probably room and no confusion for this to happen. Like, did anyone really think the “echo” effect was cluttering the sound editor? I do not think that feature was being a negative of the website as the sound effects bar could be less cluttered. What next shall we remove? Should be replaced with “What shall we next implement”.

Za-Chary wrote:
Implementing features while disregarding the safety of the website is not a good idea.

Still not disregarding the safety or design goals and/or encouraging the Scratch Team to implement a new suggestion for the sake of a new feature.

za-chary wrote:
Feedback for the Scratch 3.0 editor certainly took more than a year despite the fact that most of the editor has already been made.

I do not think 2 new extension blocks that the Scratch Team has already made are comparable to an entirely new version of the editor. Just because the 3.0 editor took a year on feedback does not mean it is acceptable that the features on Scratch Lab have - 2 features are not comparable to loads more.

Last edited by dertermenter (April 30, 2022 12:57:44)

Za-Chary

dertermenter wrote:
This is a decent point, but I am sure Scratch still wants to maintain its status as “the largest block-based coding language” and have a large community that respects Scratch for pulling out good and new updates.

Both statements require a source. I wonder if being the largest block-based coding language is not a priority for the Scratch Team. There are also many ways/reasons to respect Scratch aside from them pulling out good/new updates. For instance, I respect Scratch for being a safe website to use, and I'm sure many others, including educators, feel the same way.

dertermenter wrote:
Finally, people leaving could pull away donations from Scratch, which they need more than Snap!.

This would also require a source. I suspect that some community members leaving Scratch would not affect donations. I don't think some collaborators like Google would stop donating just because some cool features are not implemented.

dertermenter wrote:
This is a good point, for your information I consider anyone to have an account in the Scratch Community.

I think anyone who uses Scratch is part of the Scratch community, even if they don't have an account, but that might be beside the point here.

dertermenter wrote:
Whilst they may not be vocal in the community (and personally I have seen many student accounts be vocal from personal experiences) I do not think that teachers and students are going to have completely different opinions on a decision most vocal people in the community agree on.

You'd be surprised. One of the reasons “Set the editor to look like older versions of Scratch” is rejected is because, with such an option, educators may find it difficult to teach Scratch when students are using visually-different versions of Scratch. It seems that educators would prefer not to have this as a feature, despite the fact that many Scratchers think it would be a nice feature.

dertermenter wrote:
By this logic, I could say “we cannot implement dark mode as we need to assume that the silent bystanders do not support this”. we should believe that silent bystanders have opinions similiar to the rest of the community.

That's difficult. Educators are a large part of Scratch's target audience. They are also very different from Scratchers: different ages, different priorities, etc. I'm sure many educators could not care less if Scratch had a dark mode, for instance — that would not affect the way which they teach Scratch.

dertermenter wrote:
I agree that this argument needs to be altered as more features can be bad - I more meant that they should implement new features if it still makes the website look beginner-friendly, which Scratch certainly has room for.

It would have been nice to make that clear.

dertermenter wrote:
On the other hand, not many features can equal a bad user experience and I still think they can add more.

Obviously there is a difficult scale to balance here.

dertermenter wrote:
It is good that the Scratch UI is so good that there is probably room and no confusion for this to happen. Like, did anyone really think the “echo” effect was cluttering the sound editor? I do not think that feature was being a negative of the website as the sound effects bar could be less cluttered.

I have no idea, but I wouldn't be surprised if that was the case. Neither of us really know to what extent the Scratch Team was given feedback on that sound editor.

dertermenter wrote:
What next shall we remove? Should be replaced with “What shall we next implement”.

I don't think that's what the Scratch Team usually thinks. Any removals of features is likely due to community feedback.

k0d3rrr

Just going to bump this topic because:

There seems to be no posts yet.

This is a good suggestion.

I'm bored.

Quinnixx

Za-Chary wrote:
(#104)
Recall that educators and students are also part of the Scratch community. When many Scratch users don't even have accounts, and even those that do are not always vocal in the community, careful research has to be done somehow.

The people who take time to be vocal in the community deserve some respect, honestly. Educators and students are ALSO part of the community. Do you know how many educators are supporting the rest of Scratch. Already today, I saw a teacher who was supporting that we should have a dark mode. Educators and their students are in our community too. Just because they are in school, doesn't mean they aren't represented in our community. Many educators have requested and supported ideas, just like everyone else. However, is that an excuse to not listen to the people who aren't? That's just more of a reason to listen to us. The people who use Scratch without an account, aren't Scratchers, or part of the Scratcher community. Listening to the Scratcher community, the people who are impacted the most by the changes may help Scratch Team to listen to the rest of the community.

Za-Chary wrote:
I don't think that's what the Scratch Team usually thinks. Any removals of features is likely due to community feedback.

In my personal opinion, we need more Scratcher-Scratch Team communication. 2021's studio update is a perfect example of the result of the Scratch Team misunderstanding the community's wants and suggestions. If we have more of the Scratcher-Scratch Team communication, people will be less angry and less people will be knocking at the Scratch Team's door with torches. I respect the fact and effort the Scratch Team puts into thinking, but adults can't assume what a community of mostly minors (kids, tweens and teens) wants that well. This is why the Scratch Team shouldn't do all the thinking, the community should do some too.

/neu /srs

Last edited by Quinnixx (May 31, 2022 22:07:44)

Quinnixx

Bump

k0d3rrr

Za-Chary wrote:
Educators are a large part of Scratch's target audience.

…Not to mention students, developers (probably), and also programmers (similar to developers).
Not to mention guests wanting to check out Scratch.
And so on it goes…

Za-Chary wrote:
You'd be surprised. One of the reasons “Set the editor to look like older versions of Scratch” is rejected is because, with such an option, educators may find it difficult to teach Scratch when students are using visually-different versions of Scratch. It seems that educators would prefer not to have this as a feature, despite the fact that many Scratchers think it would be a nice feature.

But, a solution could be educators choosing the main visual style of Scratch for their class!
Although, that would take too long to work on, considering the fact that the Scratch Team has to first get the archived assets needed from earlier versions of Scratch in order to make it look older.
Also, the only workaround is the easiest workaround, and that is just downloading both offline editors (1.4 and 2.0).

Za-Chary wrote:
I wonder if being the largest block-based coding language is not a priority for the Scratch Team. There are also many ways/reasons to respect Scratch aside from them pulling out good/new updates. For instance, I respect Scratch for being a safe website to use, and I'm sure many others, including educators, feel the same way.

I agree with this. Scratch is meant to be a safe place, not a block-based programming language*, nor a social media platform, nor a place where people can bully/harass each other, and name and shame, and so on…
*As in, not everything about Scratch has to be a programming language.

-iviedwall-

bump

-iviedwall-

Za-Chary wrote:
#104
I would kind of expect these to always take priority, though. For lack of a better example, let's suppose that implementing dark mode would somehow make the website extremely slow and unsafe. (Obviously I know that wouldn't happen for dark mode — it's just an example.) Well, I don't think it's worth implementing dark mode if that means the website is now very slow and unsafe to use. If the Scratch Team had to pick dark mode versus making the website as safe as it is now, I think they would rightfully pick that the website should be safe to use.

But the fact is- it is simply some changes to the variables in CSS and doesn't even affect how Scratch functions.

var(--darkMode-theme, #color);

raininq-aesthetics

(long unnecessary quote removed by moderator - please don't spam)

I agree with you. Big isn't always better and less isn't always better either. If they cared about insert an issue here, then surely they would be taking action, such as the studio layout being too cluttered for some people?

If you claim something matters and is important, you act where you can, and here, the Scratch Team is in charge of the site thus they can implement any changes, or am i mistaken?

Last edited by Paddle2See (June 3, 2022 08:52:07)

Quinnixx

raininq-aesthetics wrote:
(long unnecessary quote removed by moderator - please don't spam)

I agree with you. Big isn't always better and less isn't always better either. If they cared about insert an issue here, then surely they would be taking action, such as the studio layout being too cluttered for some people?

If you claim something matters and is important, you act where you can, and here, the Scratch Team is in charge of the site thus they can implement any changes, or am i mistaken?

You literally deserve a high-five. *virtual high-five* Anyways, I just hope the Scratch Team actually takes this into mind. /g

sonic__fan

bruh no one has posted here for 217 days

bump

SONIC_ULTIMATE23

sonic__fan wrote:
bruh no one has posted here for 217 days

bump

cool, also I support this because WE NEED DARK MODE WHERE IS IT!?
well it's not like I use dark mode anyways, its so users can shut up about begging for dark mode. Adding it would make everyone happy.

Last edited by SONIC_ULTIMATE23 (Jan. 9, 2023 22:09:21)

sonic__fan

SONIC_ULTIMATE23 wrote:
sonic__fan wrote:
bruh no one has posted here for 217 days

bump
cool, also I support this because WE NEED DARK MODE WHERE IS IT!?
well it's not like I use dark mode anyways, its so users can shut up about begging for dark mode. Adding it would make everyone happy.

This topic is not about getting dark mode, it's just used as an example of a suggestion that is somehow not implemented yet despite how easy it is to do so.

Last edited by sonic__fan (Jan. 11, 2023 00:05:40)

Discuss Scratch