fdreerf wrote:

“implement more suggestions”. Why should they? Scratch is already good enough to make every project that has ever been made.

If this were true, then no popular programming languages would ever be updated. You could make good websites before HTML5 came out, but that doesn't mean that HTML5 was unnecessary or that most people would willingly go back.

fdreerf wrote:

dertermenter wrote:

Yes but to go with that scratch should also add some advanced features to make it easier for these advanced users.

The Scratch Team shouldn't focus on one specific community because they find it too hard to make things that are hard to make.

Exponents aren't “hard to make.” I'm pretty sure I learned them in fourth grade, and in pretty much every efficient programming language ever you can calculate them.

fdreerf wrote:

dertermenter wrote:

fdreerf wrote:

If the Scratch Team were to implement one suggestion, they'd have to implement another..

What? No they wouldn't lol.

Yes, they would. If they added one very easy suggestion, there would be tons of complaints to add another easy suggestion as it shows that the Scratch Team is able to.

This sounds a textbook example of the slippery-slope fallacy. And I'm not sure what your worst-case scenario actually is here. “If they improve an aspect of their program, then what's next? Improving more aspects of their program?” If the things being suggested are bad, they can reject them. If the things being suggested are good, they can implement them. Is there anything I'm missing?

bump

bump
Sorry, you have to wait 60 seconds between posts.

Full support. I don't like the Scratch teams less-features-better-user-experience mindset. Some suggestions have been since 2013 and they are still up for discussion! I want more feature, more blocks in the pallete, and features to be implemented sooner. also why are you saying this mindset is a 12 year old mindset. I'm not 12.

I've posted here before, but that was a while ago, so I'd prefer to say something else.

Correct, less features is not equal to better experience, as it really depends on the features.
However, more features is not equal to better experience, either.
Having not too many, but not too little is, in fact, equal to a better experience. This also depends on the features, and these features need to be talked about thoroughly and they should be made and improved before implementation. What use is adding features that are buggy, but not fixing anything because they have no time to, since they have to add another good suggestion? Doing things quick is not, and never was, the way to do things when programming something. It takes time to implement suggestions.
For example, lets say that Example Suggestion would take 60 hours to create, 30 hours to debug, and 2 hours to implement fully. If you expect the ST to only take 92 hours (4 days, 4 hours) to have it implemented on the site, ready for use, then you're wrong. The ST are human, so they can't (and won't, who would?) do everything non-stop. For the sake of this example, let's say that they complete 6 hours of work a day. It would take them 15 days, 2 hours to have it on the site and ready to use. Had they done your mentality of “Do It Quick,” then they would only have 62 hours (2 days, 14 hours) of work, because they need to shave off time, so why bother debugging? Assuming that they still do 6 hours of work a day, then that would mean 10 days, 2 hours of work before it's ready to be used by the community. At this point, the implemented suggestion is very buggy and the community hates it. Do the ST bother to fix it? No, they are already choosing another suggestion.

1Oaktree2 wrote:

Support. This mentality is basically just trying to avoid updates to be brutally honest.
Where would we be in Scratch without updates or features:
Picture this, we're back in Scratch 1.0, Loves and Faves got removed as they are a feature. There are only a blocks left as the rest were classed as features:

go to x: (--) y: (--)

when green flag clicked

switch costume to [ --v]

and

set [ --v] to [--]

You can't comment, the forums don't exist

Just imagine.

and no accounts, no projects, nothing.


that's the direction scratch is heading, apparently.

IHaveToBlink wrote:

-snip-
that's the direction scratch is heading, apparently.

I don't think scratch is changing it's direction only because of the studio updates and the 3.0. There were good (well i don't know about the studio one) and bad features. Don't forget the main point of Scratch: education.

I support this, as if fewer features equals a better experience, let's remove every single feature Scratch has!

Let's remove the forums!
Let's remove the profiles!
Let's remove the commenting!
Let's remove the ability to make projects!

DarthVader4Life wrote:

For example, lets say that Example Suggestion would take 60 hours to create, 30 hours to debug, and 2 hours to implement fully. If you expect the ST to only take 92 hours (4 days, 4 hours) to have it implemented on the site, ready for use, then you're wrong. The ST are human, so they can't (and won't, who would?) do everything non-stop. For the sake of this example, let's say that they complete 6 hours of work a day. It would take them 15 days, 2 hours to have it on the site and ready to use. Had they done your mentality of “Do It Quick,” then they would only have 62 hours (2 days, 14 hours) of work, because they need to shave off time, so why bother debugging? Assuming that they still do 6 hours of work a day, then that would mean 10 days, 2 hours of work before it's ready to be used by the community. At this point, the implemented suggestion is very buggy and the community hates it. Do the ST bother to fix it? No, they are already choosing another suggestion.

We don't mean “rush updates”, we mean “rethink your mentality and allow some suggestions to come to fruition, but don't take too long”.

sonic__fan wrote:

DarthVader4Life wrote:

For example, lets say that Example Suggestion would take 60 hours to create, 30 hours to debug, and 2 hours to implement fully. If you expect the ST to only take 92 hours (4 days, 4 hours) to have it implemented on the site, ready for use, then you're wrong. The ST are human, so they can't (and won't, who would?) do everything non-stop. For the sake of this example, let's say that they complete 6 hours of work a day. It would take them 15 days, 2 hours to have it on the site and ready to use. Had they done your mentality of “Do It Quick,” then they would only have 62 hours (2 days, 14 hours) of work, because they need to shave off time, so why bother debugging? Assuming that they still do 6 hours of work a day, then that would mean 10 days, 2 hours of work before it's ready to be used by the community. At this point, the implemented suggestion is very buggy and the community hates it. Do the ST bother to fix it? No, they are already choosing another suggestion.

We don't mean “rush updates”, we mean “rethink your mentality and allow some suggestions to come to fruition, but don't take too long”.

Or in other words, “rush updates.”

DarthVader4Life wrote:

sonic__fan wrote:

DarthVader4Life wrote:

For example, lets say that Example Suggestion would take 60 hours to create, 30 hours to debug, and 2 hours to implement fully. If you expect the ST to only take 92 hours (4 days, 4 hours) to have it implemented on the site, ready for use, then you're wrong. The ST are human, so they can't (and won't, who would?) do everything non-stop. For the sake of this example, let's say that they complete 6 hours of work a day. It would take them 15 days, 2 hours to have it on the site and ready to use. Had they done your mentality of “Do It Quick,” then they would only have 62 hours (2 days, 14 hours) of work, because they need to shave off time, so why bother debugging? Assuming that they still do 6 hours of work a day, then that would mean 10 days, 2 hours of work before it's ready to be used by the community. At this point, the implemented suggestion is very buggy and the community hates it. Do the ST bother to fix it? No, they are already choosing another suggestion.

We don't mean “rush updates”, we mean “rethink your mentality and allow some suggestions to come to fruition, but don't take too long”.

Or in other words, “rush updates.”

No.
I think you may not understand the “don't take too long” part. That essentially means “don't take 5 years discussing an easy-to-add, helpful feature before adding it”.

dertermenter wrote:

This suggestion is going to be a bit different today, as this suggestion is for the ST to rethink their mentality of ‘less features improves user experience’

Do we know what the Scratch Team means when they say “user experience”? I’ve read Mitch Resnick’s book and “user experience” just seems to mean taking people back to kindergarten, before there was tests, homework, and rote learning and let them continue the development process of being creative by putting things together, pulling them apart, making sometime new, seeing how something was made, and the other things that we did with blocks, clay, crayons, string, paste, and bits of paper. (Sorry, that was a long sentence.) It’s possible that Scratch 1.1 met that goal.

You can see how much they took out of the earlier 0.x beta versions before releasing the first public version. Was it’s minimal set of features more like the clay that we used in kindergarten? If you wanted store more values then just use part of the screen. Cloning? Just duplicate sprites. Characters could be encoded as numbers - haven’t we had to learn how to do that anyway?

But the Scratch Team did add features, so why? I think we now have to talk about the merchandizing of Scratch. Scratch is made interesting to people by being a free, easy way to learn programming. It has to be interesting enough that a large number of teachers, clubs, and anyone finding the website will to choose to use it. It needs to have some challenge but it also needs to provide a really good “out of the box” experience.

The Scratch about page does say it is designed for an age range that includes teenagers. I’m not sure that is or was ever true. But the statement has been out there for twenty years or so and I think we’re stuck with it.

We also now have SNAP! as an example of a feature rich block-based programming language. They have made some interesting choices about what to add and what to remove (Why can’t I add text to my costumes?). Is this giving users a better user experience? (For me it might be better if it did not take 60 seconds to save a 1MB project).

It would be helpful to get a response from the Scratch Team about a couple of things. Are our suggestions being recorded somewhere internally for future consideration when it is in the best interest of Scratch to update its features (to make it more engaging)? What does “user experience” mean to the Scratch Team?

sonic__fan wrote:

DarthVader4Life wrote:

sonic__fan wrote:

DarthVader4Life wrote:

-snip-

-snip-

-snip-

-snip-
I think you may not understand the “don't take too long” part. That essentially means “don't take 5 years discussing an easy-to-add, helpful feature before adding it”.

A good example would be the Dark Mode suggestion.

No support.

akbolon wrote:

(#74)
No support.

Why do you don't support this suggestion? It is rather rude to bluntly say that without any reason.

I guess this makes sense but too many blocks can make a lot of people confused and like some others have already stated, the ST doesn't reject every block suggestion, they will accept some and eventually implement them if deemed necessary.

Myst-- wrote:

I guess this makes sense but too many blocks can make a lot of people confused and like some others have already stated, the ST doesn't reject every block suggestion, they will accept some and eventually implement them if deemed necessary.

Anyways, it's not only blocks.

redid most of the topic, forgot about this one. I thought it was poorly written so removed 2 weak points and added 1 big chunky one

dertermenter wrote:

…with no new features, the community starts to turn on the Scratch Team. …

I have already posted once today - which I messed up by quoting all of the OP’s message instead of just the part that I meant to quote. However, all that I said a few replies up I was, I think, a good reply even if I did have an editing mistake.

But I wanted to comment on “starts to turn on the Scratch Team”. It might be better, if you are trying to propose something to the Scratch Team, to instead say something like “Scratch is likely to become less engaging to teachers, students, and everyone else. There is a risk of their product becoming stale and no longer considered “the gold standard” with so many other options to choose from”.

Agreed with this, I've been on Scratch for more than 5 years and though I don't know about any feature updates coding wise. The site/forums got little to no update. Of course there's the big 3.0 site change but it's taken a suspiciously long time to update all of the pages to the 3.0 style. I understand it's hard to make a webpage look good, I've had to make one of those before, but I'm just a single person. I'm sure there's a whole team making the new pages so why aren't they coming out faster? Another thing, there's a lot of site features people have been demanding for (like dark mode for example) that I'm pretty sure the ST said they were going to do but haven't gotten around to it? I have no source for that, though. But there are extensions that have done a lot of these wanted features and more before the ST did.