Can we make an un-editable block

[jcaldw737]

A colleague wants to make a reporter block and have his students guess what might be the rule by trying various inputs without peeking inside the definition.

Thanks for any help!

[cycomachead]

I feel like this has been asked before, but I can't find a relevant issue.

It's not currently supported, and not really a high priority, but we do see the uses.

Out of curiosity, how secure would you need it to be? I.e. Could a student just read the XML file to figure out what's inside or lookup some code that is saved which would allow it to be re-edited?

[jcaldw737]

Thanks! You have answered my question, which is about the current situation,

Let me pass on your comments to my colleague, and open a new issue about the future when he replies.

Once again, actually twice tonight, I am greatly appreciative of the rapid responses I get on this site!

[cycomachead]

No problem! :) Glad I can help!

I'm gonna leave this open, since I can't find another issue about preventing editing of blocks. That way others can still find it- and it's on the table as something to think about.

[brianharvey]

I vote no.

Generally speaking, our mission is to help people do things, not to restrict them from doing things. So, for example, we support building simplified microworlds by hiding primitives selectively, but the student can always click "show primitives" to get them back.

If your kids are older than 10 or so, you should be able to say, "Okay, the rules of this game are that you're not allowed to look inside the block; your job is to choose good input values so that you can guess the function quickly." And if you do things like that enough times, they'll understand that it's both no fun and preventing their learning to cheat.

Unless of course you're grading this activity, in which case, don't. :-)

[cycomachead]

There are plenty of legitimate reasons to want to prevent editing a block. Even in a non-graded session, students may give up trying before you want them to. There’s no beating temptation. I’m not so sure if I as a student would listen to the don’t open the block rule. Well I might for a little while but not as long as I should. 😝

I think we can build tools and do things like check how they are being used. I don’t see this as hindering students exploration.

-- Michael Ball From my iPhone michaelball.co

On Jul 6, 2017, at 8:21 PM, Brian Harvey notifications@github.com wrote:

I vote no.

Generally speaking, our mission is to help people do things, not to restrict them from doing things. So, for example, we support building simplified microworlds by hiding primitives selectively, but the student can always click "show primitives" to get them back.

If your kids are older than 10 or so, you should be able to say, "Okay, the rules of this game are that you're not allowed to look inside the block; your job is to choose good input values so that you can guess the function quickly." And if you do things like that enough times, they'll understand that it's both no fun and preventing their learning to cheat.

Unless of course you're grading this activity, in which case, don't. :-)

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

[cycomachead]

Also, there's some interesting uses for this for the autograder - where we could build more of it in Snap!.

[jmoenig]

So, this request comes up rather frequently, and I have given in after a long discussion with a German teacher who also works for the Bavarian ministry of education after she showed me some really awesome projects that more or less would benefit greatly from what @jcaldw737 wants to do.

So far I haven't gotten around to implementing this (although it wouldn't be hard), but eventually I'm willing to do it. My only concern was that there always should be a way - even for students - to unlock everything again, i.e. there could either be setting in the gears menu or - perhaps less optimal - a switch in the URL that unlocks these blocks.

Once you go down that avenue therea are, of course, other features that call out for a "lock" feature as well, that we could then consider: deleting a custom block, disabling rings, importing a library, deleting a sprite, editing a sprite's script, using certain blocks in scripts etc.....

[jcaldw737]

FYI, most recently I used SNAP with a 2nd grade class, none of whom, I imagine, were 10.  :>) Sent from a cell phone.

[brianharvey]

Ah. I wouldn't want to predict about preoperational/early-childhood kids; they're very cute, but they think like aliens from another planet. :-)

[brianharvey]

@jmoenig You'll have to show me the awesome projects; I'm going to be hard to convince!

[cycomachead]

I think with an system like Snap!, where we are running code client-side and such, there's going to be a way for people to game the system. (Also people cheat on paper exams and it's like incredibly trivial to do...) As long as we're clear about the limitations, and set proper expectations, I still see a use.

Once you go down that avenue therea are, of course, other features that call out for a "lock" feature as well, that we could then consider: deleting a custom block, disabling rings, importing a library, deleting a sprite, editing a sprite's script, using certain blocks in scripts etc.....

This is true. Though, like we wanted to do with the Hour of Code, and some stuff with the autograder, I think it's worth exploring how to do some of these things in a way that doesn't complicate the Snap! UI, but allows interested people to dive in and setup a custom world. All of this would be possible (manually) with some project initialization functions.

[jmoenig]

Well, I certainly was hard to convince :-)

Wait! Didn't I share those projects with you? It's been a while now, but she was essentially hacking the stupid Bavarian highschool CS curriculum that requires kids in grade 6 to learn "OOP and the dot notation". Now, this wording got my blood pressure going through the roof, but the requirement isn't her fault. So, she tried to hack the stupid curriculum by letting her students find out about objects, messages and attributes in Snap rather than Java, because she wanted an explorable interactive "live" system that avoids syntax errors. For this she created a set of custom OOP blocks that display the "dot notation" on them, but internally she used Snap's first-class sprites to model it all (extremely well, I had to concede, she's a real CS PhD, which you don't get that often in German schools).

So, basically, what she did was - kinda like what Stefano Federici does - create her own programming environment using Snap that is custom tailored to some stupid curriculum requirement. See, this is problematic, no question. But, in Germany, we only get the chance to actually change the curriculum only about once every decade, and in the meantime I admire teachers who want to help their students.

[brianharvey]

No, I've never seen that, I'm pretty sure.

And why does this require hiding block innards?

[jmoenig]

Well, she doesn't want to confuse her kids by showing them how her DSL is made, because that's not what they need to learn. To her students, they are learning something like JAVA, and they're 6th graders.

[brianharvey]

Well, she can just tell them "if you're tempted to look inside these blocks, do it after class on your own time"! It's not even as if they would be cheating by reading the code.

[jmoenig]

Oh sure, and that's totally what I would do. But you have to acknowledge that most regular teachers who are using her DSL don't know about Snap's first-class-ness stuff and would be perplex by the innards of it. They've been given a Greenfoot training and they've been trained in some JAVA and that's it. So, in part it's also about helping teachers.

Okay, I admit that I was (and still am) very skeptical about this approach, but I do honor a goodwill attempt to "hack the system" of a bad curriculum.

[cycomachead]

Also, there's a reasonable pedagogical argument to hiding information until people are ready for it. Exploring stuff even on your own time can lead to seeing things that are more confusing than informational - you have to be careful but it's not always awful to hide things.

[brianharvey]

If it's easy to unhide I guess it's tolerable, but in general I'm nervous about curriculum that thinks there's one right way to solve a problem and presents you with only those blocks.

[SimHacker]

How about I implement the hardest to use kind of Pie Menus possible: Screw Menus, which you have to turn around and around and around and around and around to open, but you still can open them if you're persistent. Then we can secure the sensitive parts of the system with really long Screw Menus, and the teacher can watch for frustrated students turning the mouse around trying to cheat.

[brianharvey]

Ha ha.

I think this thread is probably dead, since nobody's said anything in it for a year. And that's a good thing.

However, there's a related feature we should implement that would solve the OP's problem: There should be a way to declare that a custom block is a primitive. What this would mean is most importantly that if an error is caught while this block is running, it should be considered an error in the caller. The idea is that when you have a library that you're sure works, and it has an error, it must be because it was called with invalid inputs. If we had that, I wouldn't mind if the edit command were only in the shift-context menu for pseudo-primitives.

[jcaldw737]

This idea would be very helpful to my work and I believe also to the person who first mentioned no-edit blocks to me.