Snap! Team development discussion, vol. 2

_nix

bharvey wrote:
So, my question is, do those of you who've been using the dev version feel the same way?

I haven't been using Snap! too much lately, but wow, I'm really glad arrows are in loops, for one! It's a really good subtle idea in the design of Scratch blocks, and of course it fits nicely into Snap! too.

I tend to disagree with people who talk along the lines of "Hold on, we've moved on from Scratch, now we're too good for those kiddy features.“ It just doesn't make sense as an argument to me. They aren't kiddy features, they're helpful indications, especially (but not only!) to people who aren't experienced with the idea of loops. It feels, to me, like the same as asking to remove the block help feature, because just reading the block names are ”good enough“.

(PS, I think the loop blocks could use an extra pixel or two of padding above and below the arrow - as it is, they touch up right against the border of the block, which I think looks kind of scrunched. PPS, it's possible to add this icon to custom blocks, right?

If they get kept as a feature (I hope they do!), they should be added to the loop blocks in the libraries (e.g. ”for n =“, ”for each item"), too.)

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

PullJosh

_nix wrote:
They aren't kiddy features, they're helpful indications, especially (but not only!) to people who aren't experienced with the idea of loops.

Absolutely.

I think one of the temptations people have as they become better (but not perfect) programmers is to think that the more complicated something is, the better it must be. (I know I went through that phase.

) But the best programmers aren't the ones who write complicated, difficult-to-read software. They're the ones who distill complicated processes down to simple solutions.

Plus, even if you can understand something complicated, as long as your ego doesn't get in the way, you'd always prefer something simple.

tl;dr Good GUIs are easy to understand.

Convert your Scratch projects to JavaScript automatically with Leopard!

djdolphin

I personally like the arrows. They're helpful indicators, especially if your script is long and you can't see the label on top of the block.

If you want infantilizing, double the size of everything and crank up the saturation.

!

bharvey

djdolphin wrote:
If you want infantilizing, double the size of everything and crank up the saturation.

djdolphin

Speaking of Scratch 3.0, I've been messing around with the SB3 format and should be able to get Snapin8r3 working pretty quickly once midterms and the other end-of-semester torture is over with. It should also be easy to add SB1 support now that there's an official SB1->SB2 converter written in JS.

My fear with Scratch 3.0 is that the redesign will further cement Scratch, and by extension Snap!, as “kiddy” languages. I personally passed the point of caring long ago, but I've met plenty of teenagers who wouldn't be caught dead near Scratch, or even something similar to it. We have fragile egos, as the arrow situation shows.

Another possibility is that now that Scratch has changed to look more childish, and Snap! has stayed exactly the same, it could help to establish Snap! as the more “adult” version of Scratch, which probably isn't preferable either. My ideal situation would be to have one age-neutral block language that makes digital creation accessible to everyone, but that's obviously not the direction Scratch is going with its branding. At least its feature set is still improving.

!

bharvey

djdolphin wrote:
Speaking of Scratch 3.0, I've been messing around with the SB3 format and should be able to get Snapin8r3 working pretty quickly once midterms and the other end-of-semester torture is over with. It should also be easy to add SB1 support now that there's an official SB1->SB2 converter written in JS.

Awesome, thanks!

My ideal situation would be to have one age-neutral block language that makes digital creation accessible to everyone

Yeah, we tried hard for years to talk them into that. But I'm very proud that Snap! has been so popular as a basis for other people's languages, Edgy and NetsBlox and Turtlestitch and all those. That pushes us into universities, beyond our CS Principles breadth course (BJC). It pushes us into special interests that we (I, at least) know nothing about, such as sewing. (“Wide walls.”) And my friend and colleague Paul Goldenberg is using Snap! in an elementary school math curriculum, so we're moving down into the Scratch age range, too!

cycomachead

djdolphin wrote:
We have fragile egos, as the arrow situation shows.

Another possibility is that now that Scratch has changed to look more childish, and Snap! has stayed exactly the same, it could help to establish Snap! as the more “adult” version of Scratch, which probably isn't preferable either. My ideal situation would be to have one age-neutral block language that makes digital creation accessible to everyone, but that's obviously not the direction Scratch is going with its branding. At least its feature set is still improving.

Teenagers have fragile egos, try college students! (Only half serious, but IMO people at Berkeley are can be way worse than teenagers.)

I've always wondered whether Scratch 3 will be seen as more childish just because the blocks are bigger, or if it will be seen more with touch screens in mind? We have this odd sensation that “small” means adult when it comes to UIs and text, even though I think that's rather backwards. It's the young people who have the best eyesight!

Hardmath123

djdolphin wrote:
Speaking of Scratch 3.0, I've been messing around with the SB3 format and should be able to get Snapin8r3 working pretty quickly/quote]

Snapin9r, perhaps? I completely forgot about having written Snapin8r back in the day…

cycomachead wrote:
Teenagers have fragile egos, try college students! (Only half serious, but IMO people at Berkeley are can be way worse than teenagers.)

Can confirm, am at college, have ego as brittle as fortune cookie.

Last edited by Hardmath123 (Jan. 23, 2019 09:09:29)

djdolphin

cycomachead wrote:
I've always wondered whether Scratch 3 will be seen as more childish just because the blocks are bigger, or if it will be seen more with touch screens in mind? We have this odd sensation that “small” means adult when it comes to UIs and text, even though I think that's rather backwards. It's the young people who have the best eyesight!

Young children and touchscreens increasingly go hand-in-hand, so I think it might be both. A lot of children's first exposure to computers is now with tablets and smartphones rather than with old-fashioned computers with keyboards since they're so easy to use. They're so easy to use that more and more parents are giving their kids tablets at stupidly young ages.

I suppose the difference between Scratch 2 and Scratch 3 is comparable to regular Lego bricks vs. Lego Duplo. Small children are given Duplo because they're easier to handle with underdeveloped fine motor skills and harder to choke on than the smaller bricks. Likewise, it's almost certainly easier for small children to learn how to drag large blocks on a touchscreen rather than learn how to use a mouse to drag small blocks.

Improved touchscreen accessibility is definitely an improvement. Kids are going to get more out of using their tablets for Scratch or ScratchJr over playing mindless games or watching the horrid content on YouTube Kids. But making it touchscreen-accessible shouldn't be done at the expense of ease of use on desktop and laptop computers, even though that seems to be the trend nowadays. Maybe it will change in the future, but touchscreens are seen as devices for less serious use than desktop computers, so it's harder to take a development environment that's only optimized for touchscreens seriously.

!

djdolphin

Hardmath123 wrote:
Snapin9r, perhaps?

I think I considered that name for Snapin8r2, but I decided that it would probably be unclear for people who don't know it's referencing Snapin8r.

Maybe just “Snapinator” would do. I'm getting tired of the popular drop-letters-from-words naming scheme.

!

bharvey

djdolphin wrote:
I'm getting tired of the popular drop-letters-from-words naming scheme.

Back in the day, the Digital Equipment Corporation, which made the PDP-8 minicomputer (12 bits wide!), launched a series of PDP-8 systems bundled with hardware and software products to fit the needs of particular industries, e.g., a Navig-8 (I don't remember what this did, since it predated GPS. Maybe for boats?), an Educ-8 for schools, etc. (I used to remember more of these…)

djdolphin

bharvey wrote:
PDP-8

SNAPIN-8?

It's much better without the “r” with no vowel before, which makes it look like a web 2.0 startup circa 2008.

Last edited by djdolphin (Jan. 24, 2019 19:21:41)

!

Hardmath123

djdolphin wrote:
a web 2.0 startup circa 2008.

The first Snapin8r was written in 2013…

djdolphin

Hardmath123 wrote:
The first Snapin8r was written in 2013…

I realize that. It's just what the name reminds me of.

!

djdolphin

Also: Since previously core features of Scratch like musical instruments and video sensing have been moved to extensions in 3.0, implementing the new Scratch extension API in Snap! would mean instant access to those features.

I've probably inadvertently volunteered to do that just by mentioning it, knowing how this thread goes, but I need to finish Snapin8r3 and the mobile UI first.

!

_nix

djdolphin wrote:
Also: Since previously core features of Scratch like musical instruments and video sensing have been moved to extensions in 3.0, implementing the new Scratch extension API in Snap! would mean instant access to those features.

I've probably inadvertently volunteered to do that just by mentioning it, knowing how this thread goes, but I need to finish Snapin8r3 and the mobile UI first.

Oh yeah, that's a really neat idea! It totally seems possible. I'm invulnerable, though. Since you mentioned it first, you're the one who volunteered for it - I just commented, so I am not legally bound to try making it happen!

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

bharvey

djdolphin wrote:
Also: Since previously core features of Scratch like musical instruments and video sensing have been moved to extensions in 3.0, implementing the new Scratch extension API in Snap! would mean instant access to those features.

That's a great idea! I can see lots of potential difficulties, e.g., do their block specs match ours? They had the same starting point, but they've had a decade to diverge. I'm sure glad you're writing it instead of me!

djdolphin

bharvey wrote:
Do their block specs match ours?

Not at all.

I think the easiest way to implement this would be to add an extension block class with a custom spec parser, which of course wouldn't be fun, but it's doable.

!

PullJosh

djdolphin wrote:
which of course wouldn't be fun

Sounds like a job for whoever mentioned the idea.

Convert your Scratch projects to JavaScript automatically with Leopard!

djdolphin

It looks like Apple is finally un-breaking progressive web apps on iOS, which is good news for Snap!. Before, if a web app was added to the home screen, its state would be lost every time the app lost focus. This made Snap! pretty much unusable unless it was opened in Safari or a wrapper application like the BirdBrain one. Soon, users should be able to add it to their home screen with no problem, making it behave close to a native application while circumventing the App Store and its potential AGPL-incompatible licensing problems.

Now I just gotta finish the mobile UI.

!

Discuss Scratch