Snap! Team development discussion, vol. 2

bobbybee

I don't know how well it would on paper either, but it's worth a shot, I think

“Ooo, can I call you Señorita Bee?” ~Chibi-Matoran

bharvey

Presumably there is already an official solution to the problem of red-green color-blindness, because of traffic lights. So I guess you don't have to reinvent it. I'm too lazy to check right now.

jokebookservice1

bharvey wrote:
Presumably there is already an official solution to the problem of red-green color-blindness, because of traffic lights. So I guess you don't have to reinvent it. I'm too lazy to check right now.

I believe the solution to traffic lights tends to be to remember that red is highest light. I might be wrong though

PullJosh

jokebookservice1 wrote:
bharvey wrote:
Presumably there is already an official solution to the problem of red-green color-blindness, because of traffic lights. So I guess you don't have to reinvent it. I'm too lazy to check right now.
I believe the solution to traffic lights tends to be to remember that red is highest light. I might be wrong though

This would be correct.

My dad is color blind, and he uses the position of the light rather than the color of it. Whenever we're driving past a blinking red or a blinking yellow, he has to ask me what color it is (because there is only one light, so position is meaningless.)

Convert your Scratch projects to JavaScript automatically with Leopard!

birdoftheday

bharvey wrote:
all for $7K (or $8K if you want a private bath)

Public baths still exist? Are they the Roman ones?

Am I the only person who likes 3.0 better than 2.0, or do the people who do just not talk about it?

jokebookservice1

Why not do it the GitHub way, highlighting the code with pink or green. If you indent the code, then the highlighted area is visible – and you could use a darker colour to highlight the particular inputs that have changed. But this would require also padding all the inputs, and that would make all the blocks look like Scratch 3.0, but I think it's fine. You just put the diff on inputs next to each other, pink on the left – and green to the right.
There will be enough space in the margin of this padding to let you put crosses and ticks to help those that cannot easily distinguish green and pink.

bharvey

birdoftheday wrote:
Public baths still exist? Are they the Roman ones?

Ha ha. The alternative is sharing a bath with two or three other people.

jokebookservice1 wrote:
I believe the solution to traffic lights tends to be to remember that red is highest light.

Hmm. That doesn't help us. Although I'm seeing more and more horizontal light arrangements when they put in new traffic lights.

Why not do it the GitHub way, highlighting the code with pink or green. If you indent the code, then the highlighted area is visible – and you could use a darker colour to highlight the particular inputs that have changed.

That's reasonable too.

cycomachead

The web solution to confusing colors, is that you are never allowed to use _only_ color to convey necessary meaning. So, in this case you could color the ring, but also annotate with something like a + or -, or come up with some other convention that people can learn. When you're putting 2 colors next to each other, then they need to have a high contrast ratio so that the if you have low vision, you'd probably be able to perceive the difference in brightness.

(This might actually be a legal requirement, if it's in a place where tools are required to be accessible.)

As far as traffic lights, yeah, positioning is one aspect – though some modern lights also use arrows and X's.

bobbybee

I stand by (revised)

bobbybee wrote:
Exactly like git does. Display the context (surrounding stack blocks). Put a grey ellipsis stack block in between diffed sections, if necessary. For blocks that have not changed, desaturate them and/or ghost them a bit. For changed blocks, add a + or - prefix to the part that changed along with slightly tinting the block (or using a coloured ring that is) green or red respectively./quote]

“Ooo, can I call you Señorita Bee?” ~Chibi-Matoran

bharvey

cycomachead wrote:
The web solution to confusing colors, is that you are never allowed to use _only_ color to convey necessary meaning.

So, if Tim crosses out old blocks in red, and halos new blocks in green, is that okay despite the color-blindness issue? I like that much better than plus and minus in the margin.

I also like the idea of desaturating the unchanged part of the code a little.

It occurs to me that in Snap! we use ghosting in the palette to indicate blocks etc. that are inherited from a parent. Does that count as using only color?

cycomachead

bharvey wrote:
So, if Tim crosses out old blocks in red, and halos new blocks in green, is that okay despite the color-blindness issue? I like that much better than plus and minus in the margin.

Yeah, that would be OK. Though, I personally think a strikethrough makes things very hard to read, that's something that effects everyone equally.

Fun fact, if this were to be truly accessible and semantic, there are `ins` and `del` tags in HTML. (Though, there's not much support for them currently.)

bharvey wrote:
I also like the idea of desaturating the unchanged part of the code a little.

It occurs to me that in Snap! we use ghosting in the palette to indicate blocks etc. that are inherited from a parent. Does that count as using only color?

Oh I forgot about that, but I'm pretty that counts as color only. There's a lot of edge cases to things. Like the fact that we use colored categories is OK because you can figure out that “move” belongs to “Motion”, even if it didn't look that way. If there's another easy way to see that something is inherited, then this case would probably pass, but I don't think there is?

bharvey

cycomachead wrote:
If there's another easy way to see that something is inherited, then this case would probably pass, but I don't think there is?

If you right-click on a sprite-local block in the palette, and your parent also has a sprite-local block with the same prototype, there's a checkbox called “inherited?” you can examine. (If there's no checkbox, your parent doesn't have one, so inheriting isn't an option.)

bharvey

Okay, one of you Javascript experts, teach me how to do what I want, which is to put a button in the top left corner of a window that stays visible when the page is scrolled, and opens another page when clicked. (Code removed b/c apparently we can't post user scripts. In my defense, it wasn't a user script for Scratch, or even for Snap!.)

Last edited by bharvey (Dec. 14, 2017 22:40:36)

blob8108

@Brian “Girl Genius”?

You don’t want all that offsetTop / onScroll fluff; just use `position: fixed;`.

button.style.left = ‘10px’
button.style.top = ‘10px’
button.style.position = “fixed”

tosh · slowly becoming a grown-up adult and very confused about it

BookOwl

@bharvey, you know that we are not allowed to talk about userscripts anymore, right?
(Not that I agree with the rule or anything, but I'm not in charge)

Last edited by BookOwl (Dec. 14, 2017 22:01:40)

who needs signatures

bharvey

blob8108 wrote:
@Brian “Girl Genius”?

You don't like GG? Umm actually any minute now BookOwl is going to tell me I can't talk about it because it's sort of PG-13 (occasional mild questionable language) so we can talk about it offline.

just use `position: fixed;`.

Thanks, did that, still no love. I also tried commenting out everything about position (so it should go at the end of the page) and that doesn't work either.

bharvey

BookOwl wrote:
@bharvey, you know that we are not allowed to talk about userscripts anymore, right?

No, I did not know that. Thanks for telling me before I got yelled at officially. Of course now I'm dying of curiosity about what went wrong to cause that.

But, I must say, we are having similar discussions about what to do about JSFunction once the Snap! social-media-esque site is up. It's all too likely that someone will post a project that lets you play a cool game while collecting your password. We're thinking of popping up a warning when you load a project that uses JSFunction and isn't your own.

(Edit: But I hope it's still okay to talk about teaching Brian Javascript.)

Last edited by bharvey (Dec. 14, 2017 22:45:46)

_nix

bharvey wrote:
(Edit: But I hope it's still okay to talk about teaching Brian Javascript.)

Honestly as long as you don't add a userscript header to the top of the JS code and you obviously aren't trying to get anyone to run it as a userscript, I'd (maybe not the ST, but I'd) say it's probably fine.

══ trans autistic lesbian enbydoggirls // 16 17 18 19 20, she/they ════
sparrows one word to the paragraph // <3 // ~(quasar) nebula

bharvey

_nix wrote:
Honestly as long as you don't add a userscript header to the top of the JS code and you obviously aren't trying to get anyone to run it as a userscript, I'd (maybe not the ST, but I'd) say it's probably fine.

OK, well, the first line after the header is

GM_log("GGWiki running");

and it isn't logging. But when I click on the downarrow next to the little monkey, the script is checked on a GG page (and not on other pages), so my include is correct. I am banging my head against the wall.

cycomachead

bharvey wrote:
cycomachead wrote:
If there's another easy way to see that something is inherited, then this case would probably pass, but I don't think there is?
If you right-click on a sprite-local block in the palette, and your parent also has a sprite-local block with the same prototype, there's a checkbox called “inherited?” you can examine. (If there's no checkbox, your parent doesn't have one, so inheriting isn't an option.)

I guess this is OK, but if there were some audit, I'd expect someone to say that there should be a better solution. I'm not sure this counts as “easy”, but then the rules around that are vague.

As far as scripts: As long as you've added the button, you're dealing with CSS issues. Use the Inspector and try editing the CSS properties. If you can't see the button at all, you miiiiiight need to look at the z-index property.

Discuss Scratch