SNAP label command blows up for stage

[normanbauer]

The label command to write (using the pen) is on the pen palette for the stage, but the command blows up as the stage does not have an x, y like a sprite. The only pen command for the stage should be clear. You get the following error when executing the label command from the stage

labelerror.jpeg

[jguille2]

Yes @normanbauer ,

But this is not a label command issue. It is the current general operation of custom blocks (and library blocks are also custom blocks).

Custom blocks can be local (for one sprite (or for the stage)) or global (for all sprites (and also for the stage)). And yes, you can make a global block that has no sense in some context, and then it will return errors in these wrong contexts.

Really this is not perfect... But if we want to fix this, we will have to think globally in our design. The simplest solution will be to add the only option to custom blocks (just like primitives have the tag only: SpriteMorph). The global design is no so simple... because we have the tell and ask blocks, we can copy blocks from a sprite to the stage... But maybe it would be a quite simple and clear solution.

Joan

[normanbauer]

What??? I am not familiar with SNAP internals, you guys should fix it or disable the label command for the stage. Beginning students are not sophisticated enough to understand this. What I really would like:

1. the ability to add text in the paint editor (like BYOB and Scratch)
2. the ability to import a costume into a costume and place it (you can do in BYOB and Scratch -Example in BYOB - import a hat and put on Alonzo)

I know it is an imperfect world, but one does not like giving up capabilities when "upgrading".

[normanbauer]

I did not close this.

[jmoenig]

Yeah, I'm sorry. Better text handling is on our - long! - list. In the meantime I'm really grateful for the label block that has been contributed by @cycomachead . I'm using it a lot myself and have found it incredibly versatile. But it doesn't work on the stage, that's true. Now, mind you, it's only showing an error, Snap! doesn't actually "blow up" or crash. And yes, that error message is confusing, but you can sorta find out that the stage doesn't have a "direction" and therefore cannot use that block. Not ideal, I know....

[normanbauer]

OK, but why have the command on the pen palette for the stage in the first place? I discovered this by trying to display text in SNAP. For high school students, BYOB has some cool capabilities that are not available in SNAP. I do like the capability to capture the pen drawing and putting it in a costume, cool. But even this is a kludge to get text displayed.

[brianharvey]

You brusquely rejected @jguille2's explanation of why that block is visible for the stage. Let me try again:

Yes, you have found a problem with our user interface, and we are grateful that you reported it. But it's not as easy as you think to fix it. Here's why:

LABEL is not a Snap! primitive block. It is a user-defined block. So Snap! doesn't know what it does or whether that makes sense for the stage. Make this experiment: Define this block as a Motion-category block: You'll note that you can't define it while the stage is selected in the sprite corral, because there is no MOVE block. So define it with a sprite selected.

Now select the stage and look in the Motion palette. There's the FOO block! Since it's a user-defined block, Snap! can't, and shouldn't, decide for the user not to show it for the stage. If you try to run that block on the stage, though, you'll get a (hard to understand) error message. The same is true for the LABEL block--Snap! doesn't know anything about it.

This doesn't mean we're going to ignore your issue. What it does mean, though, is that it's not something trivial to fix, by adding LABEL to a list of non-stage blocks. We have to think about it, so we can't fix it today.

@team: I have two ideas for how to ameliorate this issue.

1. We should never show a Javascript error message except in dev mode. Instead, when a JS error is caught that we didn't specifically anticipate, give a generic message like "This block can't be used in this situation." This doesn't solve the problem, but it ameliorates it quite a bit, imho.

2. We had talked, before 4.1, about having a generic Sprite object from which all sprites would inherit. At the time of that discussion it was just a nice-in-the-abstract idea without a use case. But now we have one, and I'd like to revive the idea. Libraries (and savvy users) could then make blocks that are local to Sprite instead of global. We'd need to make careful design decisions, so that naive users aren't needlessly confronted with things they don't understand. So this isn't a quick fix, but I think it's more Snap!ly than the notation @jguille2 proposed.

[brianharvey]

3. We could also take care of the narrow problem in this bug report by rewriting LABEL to check for being run in the stage, and just put the text in the top left corner, or at the origin, or something. That would be the Scratchly approach: Try to make what the user did mean something, rather than give an error message.

[cycomachead]

I should have taken care of 3. It is on my list now. But I have many things on my lists. :) Anyway, that’s not too hard to fix.

One 1. I totally agree. We don’t do a great job of handling errors. I have many old branches dealing with various aspects. IMO, a high priority for Snap! in general.

As to the general question of sprite blocks on the stage. We have a way to show custom blocks for a single sprite only. It’s not unreasonable to have an option “for all Sprites”. I’m not sure we need it yet but it’s something to consider.

-- Michael Ball From my iPhone michaelball.co

On Jul 20, 2018, at 11:12 AM, Brian Harvey notifications@github.com wrote:

We could also take care of the narrow problem in this bug report by rewriting LABEL to check for being run in the stage, and just put the text in the top left corner, or at the origin, or something. That would be the Scratchly approach: Try to make what the user did mean something, rather than give an error message. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[cycomachead]

You brusquely rejected @jguille2's explanation of why that block is visible for the stage. Let me try again:

Also, I think when we are giving explanations, and thinking about use cases -- the internals of Snap! (or any system) are never a great reason for why doesn't work. I think it's OK for us to explain why fixes are not easy, but we should remember that it honestly doesn't matter to the end user. (And when it comes to accessibility the law doesn't care either.)

[jmoenig]

Okay, enough self-criticism. Snap's error handling is actually rather cool compared with most other educational programming languages: Other environments will crash, will stop the whole program or go into a mode where its hard or impossible to continue. Compare that to Snap! where you just get a subtle red highlight around a script where an error has occurred and a speech bubble offering some information. I mean, honestly, what do you people do when a Python error occurs, or - god beware - an error in C. C'mon, you can't break Snap! with erroneous Snap code. Try that in any other language!

[cycomachead]

I'm not being critical because I dislike Snap!. I'm being critical because there is a high standard we should hold ourselves too. I'm honestly rather embarrassed I didn't try the block on the stage and didn't consider its existence there. It's an oversight on my part and means I wasn't fully thinking of all the ways learners would approach using the block.

Other environments will crash, will stop the whole program or go into a mode where its hard or impossible to continue.

That's not always a good thing though. Snap! (and Scratch) will often do unexpected things to try to continue when an error occurs. Plus when an error occurs, especially within a custom block, there's not often a good way to know where exactly the error occurred. There's no stack trace, and while a specific script will light up red, it doesn't always tell you which block the error happened in and you need to guess.

But most importantly, errors in Snap! are not searchable. When you get an error in Python or C there is a wealth of knowledge about how to handle it, and examples and documentation. Even if there were better lists of error messages for Snap!, there's no way to copy and paste an error message somewhere else, and it's very easy to make them accidentally disappear.

And we still show far too many cryptic errors, and this is definitely one of them.

The needs and types of error handling do evolve as students are learning to program. I'm really not trying to say that Snap!'s solution is bad. However, improving error handling and messaging is in my mind the biggest (and one of the more straightforward -- if not time consuming) ways that we can dramatically improve the experience for teachers and learners.

Errors are a central part of programming -- you see them all the time when developing and exploring code. I don't think many environments pay enough attention to that experience. I have strongly recommended against using many tools in the classroom precisely because the error handling isn't up to snuff.

---

Also to the specific issue; an example: It's not unreasonable to have the label block pick defaults of 0 for x, y, and degree values for the Stage. However, that would be a confusing and frustrating scenario. You'd be left thinking label is useless or trying hard to get it to do something it wasn't meant to do.

This block would work totally fine of the stage if there were a form that had 3 parameters as inputs.

[brianharvey]

Jens, don't be defensive. Python and C are professional programming languages, not educational languages, even though some people do teach them. Our peer group are Logo and Scratch, neither of which would show a user anything remotely like "Inside: TypeError. this.direction is not a function." That's a good error message for adult programmers who have a deep understanding of the object hierarchy in the Snap! implementation -- for you, for example. A good error message for a kid would be "The stage can't LABEL because it doesn't have a position." But, given that we don't show primitive motion blocks for the stage, it's a perfectly good question why we do show LABEL. A perfect version of Snap! would probably have a tighter integration of libraries with the UI than for random user code. But a perfect version would also have a way for advanced users to control the objects for which a custom block is defined.

(I see Michael has said some of this while I was typing.)

[normanbauer]

Wow, I have poked a hornet's nest (actually I like the analogy of computer scientists as social insects). In my programming career we had a mantra "never make the user do what the computer can do". Software should be user friendly, easy to use and robust ("take a licking and keep on ticking"). For our tender young students, esoteric messages such as " You can't do that here" and such messages should be avoided. A lot of the excitement experienced by students is the thrill of creating games by doing things like customizing costumes and adding text. The pop experienced by students is palpable. Who knows, maybe one of the students could be the next Brian Harvey or Jens Monig.

[cycomachead]

Sigh... https://github.com/jmoenig/Snap--Build-Your-Own-Blocks/issues/1915