Lightnin wrote:

This is a cool hack, but my concern is that when anyone who doesn't know what you've done (or how you've done it) tries to view your project, they won't be able to understand your scripts - they won't even make sense.

I wouldn't mind at all if this was being done only with downloaded, local projects. But these are public, shared ones, that people are likely to “see inside”.

Any thoughts on the issue?

Hardmath123 wrote:

@blob I discovered that trick independently

tpaley wrote:

Lightnin wrote:

This is a cool hack, but my concern is that when anyone who doesn't know what you've done (or how you've done it) tries to view your project, they won't be able to understand your scripts - they won't even make sense.

I wouldn't mind at all if this was being done only with downloaded, local projects. But these are public, shared ones, that people are likely to “see inside”.

Any thoughts on the issue?

I think that you should make it so that you can't do the JSON hack but let reporters go into dropdown menus

nXIII wrote:

I think limiting the format to prevent stuff like this is not a good idea. We're not introducing Scratchers to any really new concepts—they've seen all the argument types we can use, they've seen custom block inputs, and they've seen reporters answering their value in place of input slots. We're just putting some of these concepts together to achieve specific functionality that helps us write better, more concise, and more useful Scratch projects.

A curious Scratcher can leave a comment like "How did you do X?," and I'm sure everyone here would be happy to reply with a short message and a link to this topic if the Scratcher is interested.

Lightnin wrote:

Hardmath123 wrote:

Hardmath123 wrote:

Lightnin wrote:

This is a cool hack, but my concern is that when anyone who doesn't know what you've done (or how you've done it) tries to view your project, they won't be able to understand your scripts - they won't even make sense.

I wouldn't mind at all if this was being done only with downloaded, local projects. But these are public, shared ones, that people are likely to “see inside”.

Any thoughts on the issue?

Hmm. It's definitely a problem. I personally see doing this JSON-hacking a lot in the future, and not just for nefarious purposes—putting together an abnormally large script is much easier with a simply Python program. Also, being able to do this allows us to read Scratch projects, too, so I can imagine being able to implement a nice Scratch 2.0 to Snap! converter for Jens and Brian, or do a similar fun project.

That said, it would definitely be confusing and intimidating to a new user; when I saw nXIII's highscore project I was totally lost (ok, intrigued, impressed and curious, but still admittedly lost).

One possible solution may be to change the way block definitions are stored, so that you can't hack in special inputs. You should only be able to have string and number and boolean inputs, the rest can gracefully become string inputs. That lets us continue messing with blocks in the JSON, but prevents odd-looking blocks. One issue with that is being able to stuff blocks into others offline—it can be awkward to explain how I fit a reporter into a dropdown to every new Scratcher who asks. Yet having, for example, a variable in the <key {} pressed?> block, is extremely useful.

I suppose the truth is that you can't completely disallow hacks just like you can't completely disallow chat rooms—there will always be the ingenuous, enterprising people who get around any walls you put up. But making the source completely closed and not letting anyone explore is pretty unfair, too. So I think the best ways is to actively discourage making scary-looking hacked blocks, but allow smaller things like stuffing reporters into dropdowns or making really long scripts with external programs.

Bump. Lightnin? Can you please read this?

Sorry, I did - just didn't get to respond to it. Thanks for pinging me about it with a comment to remind me.

A couple days ago we started a discussion on this by email, and John said:

“His suggestion would prevent making user-defined blocks with drop-down menu parameters via JSON. That's pretty easy and probably worth doing. It doesn't prevent all ”impossible to construct“ scripts but it would prevent user-defined blocks with input slots that can't be created via our block definition dialog.”

So it's likely on his list, with the 2000 other things.

The main concern I have about this technique is that if we have a ‘public code repository’ - which is one way of seeing the Scratch website - it's important that code is legible, makes sense, and corresponds accurately to what the project actually does. If hacking the JSON makes projects that don't behave how their scripts indicate they'd behave, or which can't be re-created with the normal editor, then I think it's potentially really confusing for anyone viewing the code. If some way of doing that becomes common, I'd recommend we think about validating uploads and rejecting hand JSON edits that can't be recreated in the editor. But if it's not much of an issue, we won't have to.

But as for making scripts by hacking the JSON that *can* be accurately represented / recreated in the editor - knock yourself out!

lalala3 wrote:

An even better way to prevent confusion would be to remove the source of the confusion: the belief that such isn't possible, i.e. adding every single one of the special inputs/drop-downs/etc. into the standard editor. We get cool input options without having to go through that lengthy process and nobody's confused by the blocks. Problem solved.

Lightnin wrote:

Hardmath123 wrote:

Hardmath123 wrote:

Lightnin wrote:

This is a cool hack, but my concern is that when anyone who doesn't know what you've done (or how you've done it) tries to view your project, they won't be able to understand your scripts - they won't even make sense.

I wouldn't mind at all if this was being done only with downloaded, local projects. But these are public, shared ones, that people are likely to “see inside”.

Any thoughts on the issue?

Hmm. It's definitely a problem. I personally see doing this JSON-hacking a lot in the future, and not just for nefarious purposes—putting together an abnormally large script is much easier with a simply Python program. Also, being able to do this allows us to read Scratch projects, too, so I can imagine being able to implement a nice Scratch 2.0 to Snap! converter for Jens and Brian, or do a similar fun project.

That said, it would definitely be confusing and intimidating to a new user; when I saw nXIII's highscore project I was totally lost (ok, intrigued, impressed and curious, but still admittedly lost).

One possible solution may be to change the way block definitions are stored, so that you can't hack in special inputs. You should only be able to have string and number and boolean inputs, the rest can gracefully become string inputs. That lets us continue messing with blocks in the JSON, but prevents odd-looking blocks. One issue with that is being able to stuff blocks into others offline—it can be awkward to explain how I fit a reporter into a dropdown to every new Scratcher who asks. Yet having, for example, a variable in the <key {} pressed?> block, is extremely useful.

I suppose the truth is that you can't completely disallow hacks just like you can't completely disallow chat rooms—there will always be the ingenuous, enterprising people who get around any walls you put up. But making the source completely closed and not letting anyone explore is pretty unfair, too. So I think the best ways is to actively discourage making scary-looking hacked blocks, but allow smaller things like stuffing reporters into dropdowns or making really long scripts with external programs.

Bump. Lightnin? Can you please read this?

Sorry, I did - just didn't get to respond to it. Thanks for pinging me about it with a comment to remind me.

A couple days ago we started a discussion on this by email, and John said:

“His suggestion would prevent making user-defined blocks with drop-down menu parameters via JSON. That's pretty easy and probably worth doing. It doesn't prevent all ”impossible to construct“ scripts but it would prevent user-defined blocks with input slots that can't be created via our block definition dialog.”

So it's likely on his list, with the 2000 other things.

The main concern I have about this technique is that if we have a ‘public code repository’ - which is one way of seeing the Scratch website - it's important that code is legible, makes sense, and corresponds accurately to what the project actually does. If hacking the JSON makes projects that don't behave how their scripts indicate they'd behave, or which can't be re-created with the normal editor, then I think it's potentially really confusing for anyone viewing the code. If some way of doing that becomes common, I'd recommend we think about validating uploads and rejecting hand JSON edits that can't be recreated in the editor. But if it's not much of an issue, we won't have to.

But as for making scripts by hacking the JSON that *can* be accurately represented / recreated in the editor - knock yourself out!

lalala3 wrote:

Well, a solution to the custom inputs confusing people would be to add them into the standard/base editor. We don't have to hack them in anymore, and Scratchers unfamiliar with the technique are not confused.

nXIII wrote:

lalala3 wrote:

Well, a solution to the custom inputs confusing people would be to add them into the standard/base editor. We don't have to hack them in anymore, and Scratchers unfamiliar with the technique are not confused.

http://beta.scratch.mit.edu/forums/topic/1810/?page=2#post-13305

lalala3 wrote:

nXIII wrote:

lalala3 wrote:

Well, a solution to the custom inputs confusing people would be to add them into the standard/base editor. We don't have to hack them in anymore, and Scratchers unfamiliar with the technique are not confused.

http://beta.scratch.mit.edu/forums/topic/1810/?page=2#post-13305

Sorry. I failed. I forgot there was a second page and my post mysteriously disappeared.