search

jmoenig / Snap

a visual programming language inspired by Scratch
http://snap.berkeley.edu
GNU Affero General Public License v3.0
1.49k stars 743 forks source link

When [flag] clicked should be included by default #272

Closed novalis closed 10 years ago

novalis commented 10 years ago

When you first start up Snap!, you're presented with the motion palette. You can add (say) "move 10 steps", but then when you click the green flag, nothing happens! I think the "when flag clicked" control block ought to be included in new scripts by default, because it improves the learnability of Snap. In addition, if you don't have a "when" block at the head of each script that contains any other script elements, you ought to get an error message or warning explaining that you need a "when" block in order for something to happen.

brianharvey commented 10 years ago

I think it might be a good idea that new empty projects start with a WHEN FLAG CLICKED block. But I don't agree that a script without a hat block is necessarily an error; I make such scripts all the time while developing a project and just click on the script to run it. Maybe clicking on the flag when you don't have any flag-sensitive scripts could give a warning.

novalis commented 10 years ago

Oh, neat. I didn't even notice that you could do that. I think it might be better to have that action be an explicit "run" button, but I guess that's a separate issue. Given that, I agree with your idea.

jmoenig commented 10 years ago

I have many projects which don't use the green flag at all. Most of them use key event hats or "when ... clicked" hats, message hats, and some don't have any event hats at all.

I realize that many people believe (for some reason that would actually be interesting to find out) that a project needs to have a singe point of entry, and that it either runs or doesn't run. However, the nature of Snap (and also of Scratch from which it inherits this idea) is that it's not an IDE in the classic sense of Eclipse (a fancy code editor with built-in shortcuts for compile-link-run cycles) but more in the sense of Smalltalk, which, in fact, is much more like a fancy interactive command prompt (such as in Scheme or Python).

So, Snap is always live, regardless of whether you push the green flag or not.The green frag is only a convenient way to fire off a standardized event. (BTW you can even bypass the green flag by sending - or receiving a message named " shout go __ " (without the blanks), this underscores that it's just a message, no magic involved - and also no compiling or converting to JS or whatever some people believe it does) Even after you press the red stop sign, your scripts will stay responsive to events, the whole of Snap is always alive, and not just a fancy editor, such as other blocks based programming environments.

Therefore, Brian, I disagree about putting a default green flag hat block in each empty project. Let kids experiment!

novalis commented 10 years ago

If Snap is a teaching environment, it shouldn't require experimentation to get hello world running -- it should just work. I very nearly put Snap down because I assumed something was broken when my program didn't run when I clicked the green flag. Maybe this should only happen when you first open Snap (rather than for every new project). But it definitely needs to be super-easy to get started.

jmoenig commented 10 years ago

Well, Snap borrows Scratch's design, so I regard that as a given. As in Scratch you can click on anything to make something happen. Kids can click on any block, even those in the palette, and they can even edit the inputs of blocks in the palette and click on them just to try out what they're doing. This design has been fantastically successful in Scratch, which is the whole point of making Snap be "a Scratch".

That isn't saying that we can't do things differently, of course. And we do in a lot of places (such as lists). However, it's interesting to realize (and I didn't before) that not everybody who's coming to Snap has been a Scratcher before. So you're right to point out that we might have to do a better job of introducing newcomers to the very basics of the Scratch-ly way of programming, instead of only focusing on the "higher order" stuff in which Snap differs.

Thanks!

cycomachead commented 10 years ago

Well, Snap borrows Scratch's design, so I regard that as a given. As in Scratch you can click on anything to make something happen. Kids can click on any block, even those in the palette, and they can even edit the inputs of blocks in the palette and click on them just to try out what they're doing. This design has been fantastically successful in Scratch, which is the whole point of making Snap be "a Scratch".

I think this in an interesting point, but this is also where we have an opportunity to be a little bit different from Scratch, possibly. In general, after working with students for many a few years, the idea that you can click on any block, anywhere, and execute is lost. I agree that this is a huge asset and value of Snap, but I'm not sure including a hat block by default would diminish that.

In general, most computer programs do have a central starting point, so it doesn't seem like a bad paradigm to encourage. I think there's a lot we could do to make Snap both more friendly in terms of teaching concepts, but also being easier to use.

On that note (this deserves a separate issue), but I think we could adopt some default 'Help' or 'Guide' popup that opens the first time you use Snap, possibly in a similar way to how Scratch does it.

brianharvey commented 10 years ago

I think this issue is dead as far as changing Snap! is concerned. It's something to think about in the documentation/teaching.