Scratch

Vee is cool.

bharvey wrote:

scimonster wrote:

Vee is cool.

I like my version better than Jens's version.  (He left out the scripts to add and remove vee in the list of end shapes.  The way this lesson works is that you start without vee in the list, get students to understand how the procedure works, then add vee to the list and ask them to predict the results.)

PS  ... except I can't get it to work in Firefox.  It works in Safari and Chrome. 

PPS ... even though I made the xml in Firefox to begin with!

PPPS:  It works for Jens in Firefox.  Firefox hates me.

Doesn't work on FireFox for me. I'm using 3.1 (!), and am surprised normal Snap! works so well. 

Jens wrote:

Brian's link is wrong, it tells Snap to open an'html file instead of "vee.xml", please try the original link to Vee (the actual file is now Brian's version of Vee) and let me know if that one works in your Firefox. Thanks!

Yes, the link above and in the original post now open Brian's version of vee in both Firefox and Safari.

Thanks, guys!

The History.txt file, says:

120703
------
* GUI: open a project from URL via #open:URL
* GUI: run a project from data via #run:XML or from URL via #run:URL
------

What is the distinction between #open: and #run:?
When I #open a url, I see the full IDE as expected. But, when I change #open to #run, I don't see any substantive changes to the interface. I thought I might see a full screen representation of the Stage. Alternatively, does this difference simply accomodate differences in file formats?

Or after further reflection, does it open the project and then hit the green flag button? In this version of vee, the #run is very subtle because the shape list does not initially include the two vee blocks.

Just tested the latter hypothesis and observed that the terminal shapes change with most page reloads when I use #run and they are consistently square, star (over five reloads) when I use #open. I conclude that this feature is probably more applicable to other Snap! projects.

Last edited by scspaeth (2012-07-04 16:41:25)

I FINALLY FIGURED OUT HOW TO EDIT BYOB.
Now I can make pink, black, white, whatever color blocks! 

Idea:

Instead of having to right click a block to see it's definition, it should show the definition in the scripting pane under a special hat block that is the block's prototype that would be collapsible so you could hide the definition but still see the block's header. This would make blocks a little more self-documenting because you could see the names of the inputs and the comments attached. This can be useful if, say, you defined your own type using data abstraction with blocks, and it was then unclear what kind of input another block you made should take, you could give the inputs meaningful names and hide the definition so a user (someone else, or you in a few months time) can see the header to see what inputs it takes, without having to concern themselves with the definition, which might be complex.

I like the idea of generating a human-readable (formal) explanation of custom blocks. But I'm afraid I don't get why you need to expose the names of formal parameters to the users of a custom block. The block prototype merely determines the appearance of the block instances. The beauty of Scratch is that you don't have to know about the formal parameters, because you can see the argument slots in every block. And part of the beauty of Snap! is that you can document the slot types in the long form input dialog. So, really, everything the user needs to know about using a custom block is "documented" in the appearance of its instances. Or what is it I'm not understanding here?

Last edited by Jens (2012-07-06 02:17:28)

Jens wrote:

I like the idea of generating a human-readable (formal) explanation of custom blocks. But I'm afraid I don't get why you need to expose the names of formal parameters to the users of a custom block. The block prototype merely determines the appearance of the block instances. The beauty of Scratch is that you don't have to know about the formal parameters, because you can see the argument slots in every block. And part of the beauty of Snap! is that you can document the slot types in the long form input dialog. So, really, everything the user needs to know about using a custom block is "documented" in the appearance of its instances. Or what is it I'm not understanding here?

Well what I was thinking is that if you defined your own type via data abstraction techniques, it can sometimes be ambiguos what kind of input a block should really take. For that reason, if you could see the names of the parameters, it would be a little more self-documenting. Also, if you could see the prototype in the scripting area, users could read comments attatched to it.

joefarebrother wrote:

if you defined your own type via data abstraction techniques, it can sometimes be ambiguos what kind of input a block should really take. For that reason, if you could see the names of the parameters, it would be a little more self-documenting. Also, if you could see the prototype in the scripting area, users could read comments attatched to it.

I agree with both of you.      There should be a goof way to document the domain of a block, and for custom blocks, the input shapes don't really suffice because of abstract data types.  (In some of my projects, pretty much all the inputs are of type List, but in my mind there are half a dozen distinct kinds of lists.)  On the other hand, the formal parameter isn't necessarily the best way to provide that documentation.

When we can attach comments to code, we should adopt the convention that a comment at the beginning of a procedure is meant as external documentation for the caller of that procedure, so when you ask for Help on the procedure, that comment should appear (along with the prototype, with its formal parameters) in the helpscreen.  (These can be generated on the fly, I hope.)

I don't think the user needs to see this document about all custom blocks all the time  If using helpscreens isn't good enough, I wouldn't mind a feature that when you hover over a block in the palette, it temporarily fills all the input slots with their parameters.  But often the parameter isn't enough help anyway; hands up if you've never used "list" as the parameter for a list input. 

Last edited by bharvey (2012-07-06 10:28:47)

shadow_7283 wrote:

Incidentally, I think a more practical and less obtrusive way to display the block editor would be as a separate tab (i.e. "scripts, costumes, sounds, blocks").

That's not a bad idea.

PS  Oh, wait, you mean to do that instead of having a block editor window?  I think that would be confusing, partly because by default a custom block doesn't belong to a particular sprite, like those other tab things.  Also I want to be able to drag easily between the scripting area and the block editor while editing a block, and to be editing two blocks at once (but not all blocks at once), etc.  But I think a tab like that could be a place to put the programming interface information that joefarebrother wants.

Last edited by bharvey (2012-07-06 11:07:55)

Press the blue check mark button next to it.

joefarebrother wrote:

IDEA: Build your own hat blocks! (first-class events)

This was suggested very early for BYOB3.  The way we'd do it is just to have a hat block WHEN <hexagon> in the Control palette.  Jens was a little nervous about how much it might slow things down, and also there is a small question about what happens after you click the stop sign; should this condition still be checked?  Or not until the user does something like click the green flag?  (All the existing hat blocks are either triggered by a user action or not triggerable when all scripts are stopped.)  But, yeah, we'll get to it.