Closed jcaldw737 closed 7 years ago
You - or your students - can specify the "long form input dialog" setting in the preferences menu:
The browser remembers this setting, so if you choose it in Chrome it isn't also set in Firefox. Does that make sense?
Thanks! Once again I am amazed at your fast and thorough response!
I am guessing that the short form comes up on a browser instance that does SNAP for the first time?
FYI we are dealing with 3rd graders, and perhaps more delicate than that - care-givers of 3rd graders - some of whom don't have much computer expertise.
Yes, the short form is the default setting. The idea is that you can start building your own blocks without having to think about data types for inputs. So you can build your own "jump" or "draw" block and just specify inputs, period. Later you can use the long form input to refine your designs, if you want to. The "long form input" setting is something for "power-users". Personally, I never use it myself, and I would not recommend it for beginners because of the cognitive overload. But I know many users who prefer to only get the more detailed long form input dialog, especially once they've gotten the "hang" of building their own blocks.
Wow, 3rd graders using Snap! That's very exciting! I'm very interested in your observations about what works and what doesn't. I can imagine that for elementary school children maybe even blocks with just symbols / pictures on them instead of text would be interesting...
Had great success (in my opinion) last year with a class of third graders. We used a "front end" to snap, really just this snap project http://tinyurl.com/ezSNAP833 Attached is a description that I put together to for other volunteer "teachers" Planing to have a video version of the doc up on you tube tomorrow,
I would appreciate any comments you might have.
Interesting. Since as of 2.0 Scratch can do everything in your lesson, I'm curious why you chose Snap! instead. (Not that I'm discouraging you! It's great that you're doing this.)
I'm closing this topic, which doesn't cut off the discussion, but does remove it from the list of issues we have to do something about.
@jcaldw737 @brianharvey I can see the benefit of using Snap over Scratch 2 here, because the "EZ" project completely hides almost all primitives and replaces them with easier custom blocks. This is actually a pretty cool strategy! Did you know that you can open the project template in edit mode simply by appending &editMode
to the URL?
Did you know that you can open the project template in edit mode simply by appending &editMode to the URL?
Is this different than Use #cloud
?
it's very similar, you can combine &editMode
with other switches that suppress controls and either don't or do start the project by triggering the green flag event.
THANK YOU SO VERY MUCH for the method of opening a project in edit mode. I had tried unsuccessfully to find a way to do that.
Another problem I have with SCRATCH, and this may be because I don't know it well enough, is that I don't know how to hide the contents of a custom block and only reveal them upon user "request". This seems to me to make it hard to find a particular block you want to edit because you have to go through all the contents of the various blocks. As Jens mentioned, there are many custom blocks in ezSNAP and they would add to this problem.
Also I believe that SCRATCH does not do custom functions, and I am sure that you are aware that functions play a foundational role in math,
We certainly have to become better at documenting Snap's features! :-)
Scratch does have custom blocks, but - as you say - you can't hide their definition, it's always visible in the scripting area. Also Scratch does not support custom blocks "for all sprites", instead they have to be defined for each sprite separately, or - worse - copied over whenever you make a new sprite. Even more in the "problematic" direction, Scratch does not support local variables. This is especially problematic in an environment that encourages parallelism, because having to resort to global / shared variables in every procedure produces race conditions real quick. However, worst of all, Scratch 2 does not support custom reporters, i.e. functions.
... that said I love Scratch, really! :-)
Thank you @jcaldw737 for the explanation. (I know why I love Snap!, but I'm interested to learn what's most important to actual users. :-)
Hi! Thanks @jcaldw737 for share your work. It's very interesting. I try to insist to our teachers that the starting point of a work can be (or should be) a template project and not always Snap! itself. Then, things change, abstraction is also part of the job of the teacher, and the possibilities multiply...
You can go further with the template customization. With JS block we can do anything. And we can share abstractions. No need to be an expert ... we can use the work of others. An example, editing your project in http://snap.berkeley.edu/snapsource/snap.html#present:Username=jguille2&ProjectName=ezSNAP. Note that:
Just an example... but we can get more... Yes, We need a forum!! Thanks,
Joan
I do more changes in the example in variables category blocks to show more clearly customation possibilities.
Another problem I have with SCRATCH, and this may be because I don't know it well enough, is that I don't know how to hide the contents of a custom block and only reveal them upon user "request". This seems to me to make it hard to find a particular block you want to edit because you have to go through all the contents of the various blocks. As Jens mentioned, there are many custom blocks in ezSNAP and they would add to this problem.
@jcaldw737 Call it shameless self advertising :)
When I click the + to create an input name for my block I get the "short form" when using Chrome, but the "long form" when using Firefox. Windows 7 is the operating system.
Is there a way I can control what happens? I have some people learning SNAP whom I'd like to shield from all the options on the long form - at least for the present.
thanks!