Rendangbike2 wrote:

banana439monkey wrote:

Rendangbike2 wrote:

banana439monkey wrote:

err
well
i hate to be the part pooper
but i'm unsure that this will work
here's why
to my knowledge, block colours were stored in ram. what this means is that when you navigated away from the page, they wouldn't stay consistent in the project. they'd disappear off. this was extremely unintuitive, and i'm not entirely sure how block colours would work in scratch 3. if this were to be implemented, i have one tip for the scratch team: please store the block colours in a json file in the scratch binary and NOT in ram. this means that the block colours are more consistent.

Banana

What about cookies?

then it's browser-specific and is likely to get reset. why don't we store it in json? that's the format of scratch projects anyway.

Banana

But how would we store the JSON? That's the users fault for clearing the cookies.

within the project
and also, not necessarily

Banana

banana439monkey wrote:

But how would we store the JSON? That's the users fault for clearing the cookies.

within the project
and also, not necessarily

Banana

I think the OP was trying to suggest that 1 user would be able to have the color of the blocks changed, not 1 project gets a different color. Sorry if this doesn't make sense to you

Rendangbike2 wrote:

banana439monkey wrote:

Rendangbike2 wrote:

But how would we store the JSON? That's the users fault for clearing the cookies.

within the project
and also, not necessarily

Banana

I think the OP was trying to suggest that 1 user would be able to have the color of the blocks changed, not 1 project gets a different color. Sorry if this doesn't make sense to you

yeyeye i know what they mean but it was always extremely unintuitive to understand, so storing new block colours in the project's json would be better

Banana

banana439monkey wrote:

Rendangbike2 wrote:

banana439monkey wrote:

Rendangbike2 wrote:

But how would we store the JSON? That's the users fault for clearing the cookies.

within the project
and also, not necessarily

Banana

I think the OP was trying to suggest that 1 user would be able to have the color of the blocks changed, not 1 project gets a different color. Sorry if this doesn't make sense to you

yeyeye i know what they mean but it was always extremely unintuitive to understand, so storing new block colours in the project's json would be better

Banana

Why the projects JSON? 1 user several colors, not 1 project several colors

Rendangbike2 wrote:

banana439monkey wrote:

Rendangbike2 wrote:

banana439monkey wrote:

Rendangbike2 wrote:

But how would we store the JSON? That's the users fault for clearing the cookies.

within the project
and also, not necessarily

Banana

I think the OP was trying to suggest that 1 user would be able to have the color of the blocks changed, not 1 project gets a different color. Sorry if this doesn't make sense to you

yeyeye i know what they mean but it was always extremely unintuitive to understand, so storing new block colours in the project's json would be better

Banana

Why the projects JSON? 1 user several colors, not 1 project several colors

because it used to be specific to the project, though the colours were one-time use

Banana

For people that reads in colors, I wouldn't support this. You know Monopoly? It's a hard game, especially the money part, but it's easier to read money with colors. Editing Block Colors cannot be a universal color to the color-reader and that can make them confused. However, having the color edits back can look great.

GunesKing wrote:

For people that reads in colors, I wouldn't support this. You know Monopoly? It's a hard game, especially the money part, but it's easier to read money with colors. Editing Block Colors cannot be a universal color to the color-reader and that can make them confused. However, having the color edits back can look great.

block colours only show the cat

Banana

Bump.

YEAH ADD THIS AGIAN SCRATCH TEAM!!!!!!!!!!!!!!!!!!!!

trfgbs wrote:

AnAccount_StopAsking wrote:

i would say no support but i may end up being proven as a good-for-nothing all over again

Why don't you support?

A really nice idea, but I don't think it's necessary. The colors of the blocks do not matter that much, so I don't quite understand where Scratch could improve it. That's only my opinion.

support!!! i dont get why they removed it

mcsquaggle wrote:

support!!! i dont get why they removed it

Because it was just a decorative feature, and didn't add any educational… stuff to Scratch.

k0d3rrr wrote:

mcsquaggle wrote:

support!!! i dont get why they removed it

Because it was just a decorative feature, and didn't add any educational… stuff to Scratch.

o.

I recently learned that there was a hidden blocks menu within Scratch 2.0 that allowed you to manually define your own block colors for each block palette.

With high-contrast blocks coming to Scratch eventually (and currently being tested via Scratch Lab) I feel like the return of this feature would be a nice accessibility addition in the event that the high-contrast blocks hindered someone who may not be able to easily read the text on the new blocks.

It would be within the Edit menu as it was in Scratch 2.0, though this time it would be visible all the time instead of requiring you to shift-click the button.



When clicked it would reveal a menu similar to the one that existed in 2.0. Ideally this would use the same color picking system that the painter uses.



You would be able to flip between choosing block and text color so that whatever block color you choose doesn't make the block unreadable. A dropdown menu would let you edit any of the standard block palettes (save for extension blocks because I feel like it's important to separate those as ‘special case’ stuff.)

When you're done, you'd click “save changes” and the block palette you selected would update with the color you chose. Something I forgot to include in my mockup is a “reset color” option in the bottom right that would turn the block palette back to its default color.

Not only would this be good for general accessibility purposes, it'd also be good for colorblind users as they could edit the block palette to something more accustomed to whatever form of it they have. It would also be very satisfying for all the 2.0 oldies who miss when the Custom Blocks stuff was purple instead of pink. The hardest part is obviously implementation because I'm not sure if Scratch-Blocks currently supports dynamic color changing, and it'd require the creation of a whole new system.

I don't see me using this but I can see how useful this is to colorblind people and is way better then what scratch is trying to present.

Vaibhs11 wrote:

Duplicate

the shortest lived topic record goes to… NanoRook!
With an astounding, 4 minutes! *cheer* *applause*

Going to object on this one because the OP of the duplicate is just ‘bring back the feature’ without any elaboration as to how or why. At least I bothered to throw up some mockups I made in mspaint.

NanoRook wrote:

Going to object on this one because the OP of the duplicate is just ‘bring back the feature’ without any elaboration as to how or why. At least I bothered to throw up some mockups I made in mspaint.

Doesn't matter. If it's a duplicate, then it's a duplicate.

NanoRook wrote:

Vaibhs11 wrote:

Duplicate

the shortest lived topic record goes to… NanoRook!
With an astounding, 4 minutes! *cheer* *applause*

Going to object on this one because the OP of the duplicate is just ‘bring back the feature’ without any elaboration as to how or why. At least I bothered to throw up some mockups I made in mspaint.

That's nice work! Rather than lose it, I'll merge this with the original topic.

Euglena73 wrote:

A really nice idea, but I don't think it's necessary. The colors of the blocks do not matter that much, so I don't quite understand where Scratch could improve it. That's only my opinion.

Colorblind people


Support because it can make it easier for them
And because it might be fun too change the block colors