Scratch-blocks: Audit currently implemented blocks for Droppable / Non-droppable inputs

[carljbowman]

We need to update some of the 3.0 blocks to not allow reporters to be dropped into their inputs, e.g. "touching [mouse pointer]"

I will follow up with a complete audit.

[towerofnix]

IMO there should definitely be some discussion on this. I don't want to get too specific before actually seeing the audit, but - in general there's two important things I think need to be focused on:

• It shouldn't be discouraging to get stalled by putting a block in an input..
• Or by being stalled by not being able to put a block in an input.

You know, low floor, high ceiling :)

(Again, IMO -) I think the best way to see what's discouraging is to, well, do playtests. Let people try sticking reporters in weird places. See if being able to is stalling, or discouraging. Try another playtest in which these are much more rigid; one where most (if not all) dropdown inputs aren't droppable.

What makes sense to limit at first may well not be the best choice. I imagine it's most important to see what's confusing in practice. For example, when teaching kids how to use variables, would they be stalled by dropping a variable into the first input of "set (..) to"? Certainly it seems like they could be, but it still feels like it warrants a try.

It's worth taking a look at LLK/scratch-vm#709, btw; two relevant things:

We had a long conversation about this today after a play test. We believe it is important for some blocks to have non-droppable menus to avoid confusion and error states. (from @thisandagain)

Can this be a feature that advanced users are allowed to disable? It's a pain to manually edit JSON (from @MegaApuTurkUltra)

What I'm most hoping for (I hope I'm not being rude?) is that, alongside each recommended change in the audit, an explanation is given (e.g. "touching (..) should be non-droppable because..."), and that these are also practiced - I don't know the procedure for playtests, but I think it would make sense to have a time or two where people are given a sheet of the new droppable and non-droppable inputs, for them to explore and discuss?

[carljbowman]

@towerofnix - I appreciate response. I agree, we do not want to discourage people from trying new things and tinkering, but we also want to set people up for a good experience.

There are some inputs that if they accept blocks it's not conceptually clear to the creator what will happen. In some cases that can be desired, but for people are new and who are learning how blocks work that can result in unexpected behavior or doing nothing. That confusion can create false expectations about how the majority of blocks inputs work or worse discourage the creator as they think they have made an error.

We have been trying everything that we are developing in workshops with people on a regular basis and we have seen this confusion.

All that being said, we are not making any block inputs that are droppable in 2.0 not droppable in 3.0.

[towerofnix]

@carljbowman Thanks. It's definitely awesome to see you do playtest everything (which I should have figured from the start, considering you've always playtested everything else too).

Relatedly - a recent example of someone wanting to drop a block inside of the "key pressed?" block, so that they could easily make a custom text input ("repeat until this string is typed").

[carljbowman]

Overview

This simply compares the current block implementations in 3.0 with their 2.0 counterparts. For the 3.0 Preview we should make sure these 3.0 is in sync with 2.0 blocks.

Some blocks, like Video Sensing, are not implemented in 3.0 but are tracked as apart of the 2.0 lexicon.

Non-Droppable

2.0 Left and Current 3.0 on the right
Orange bands to indicate differences that need to be resolved.

• [ ] current time - should not be droppable
• [ ] key pressed? - should not be droppable

Droppable

2.0 Left and Current 3.0 on the right
Orange bands to indicate differences that need to be resolved.

• [x] broadcast message - should be droppable
• [x] broadcast message and wait - should be droppable

Non-Droppable & Droppable

2.0 Left and Current 3.0 on the right
Orange bands to indicate differences that need to be resolved.

• [ ] property of thing - (for lack of a better name, see below) - the property field should not be droppable
  

[thisandagain]

Thanks @carljbowman !

[mrjacobbloom]

(I know this is just an audit of the current status, but I want to make sure this gets said) Regarding the "property of thing" block, I'd definitely prefer to keep the property field droppable. The whole discussion in https://github.com/LLK/scratch-blocks/issues/573#issuecomment-270948989 about adding "myself" to the sprites list was to allow for dynamically getting variables by name without hacked blocks, and making property non-droppable would make that moot.

[thisandagain]

@carljbowman @ericrosenbaum Moving to January milestone. I think we should consider resolving this a blocker for the preview release.

[AmazingMech2418]

@thisandagain @paulkaplan There are a lot of projects that would no longer be possible on Scratch 3 if the key press block isn't droppable. Word processors wouldn't ever work again. Advanced coding apps would also not work anymore. It could also cause a lot of conflicts when converting projects including ASCII detectors. Also, the "hacked blocks" wouldn't be able to be made to fix the problem like in 2.0.

[thisandagain]

@amazinigmech2418 I'm a little confused. The "when [space] key pressed" hat block is currently not droppable in Scratch 2.0. Can you please provide an example or clarify?

[towerofnix]

@thisandagain I believe @amazinigmech2418 meant the "key pressed" sensing block, not the event block. This block, of course, is also not-droppable in 2.0, but maybe they mean to make it droppable (need clarification obviously). Here's a small example which lets the user type "into" a variable display:

when green flag clicked
set [Input content] to [] // Empty
show variable [Input content]

when [any] key pressed
set [keys] to [abcdefghijklmnopqrstuvwxyz]
set [parse] to [1]
repeat (length of (keys))
    if <key (letter (parse) of (keys)) pressed> then // Note that we put a reporter in "key pressed"
        set [Input content] to (join (Input content) (letter (parse) of (keys))
        stop [this script]
    end
    change [parse] by (1)
end

Griffpatch's Word Processor project is a good example of using the "key pressed" sensing block as a way for detecting general keys without using many, many "key pressed" blocks; think "if key a pressed?, append a; if key b pressed?, append b; if key c pressed?, append c...". It also uses the block to detect keys which aren't even in the dropdown menu at all, such as backspace.

Edit: That said, assuming that the "key pressed" sensing block is implemented to detect backspace/etc depending on the given ascii code (admittedly a bit of a hack) and can handle a reporter being passed to its input (i.e. no crash if a reporter is put into a no-reporters input), then that script would work fine. I'm not sure why they said "Also, the "hacked blocks" wouldn't be able to be made to fix the problem like in 2.0."

[thisandagain]

Thanks @towerofnix this use case makes sense to me (funny enough I looked at Griffpatch's word processor project before responding earlier just to make sure I wasn't missing something regarding "hacked" blocks). I think making the sensing boolean reporter droppable may make sense. I'm going to split that out into a new issue.