Should scripts only "re-layout" once you *drop* a block?

[towerofnix]

I'll quote a forum post I made:

---

Has there been discussion on only "re-layoutting" scripts only once you actually drop a block you just picked up from that script? The trouble I'm having is, I pick up a block from a script, and then the entire layout changes while I'm dragging, so it's harder for me to move the block where I want it to go.

I guess a diagram is better at explaining.

This is what I want to do:

This is what happens:

(The important difference is that in the picture of what actually happens, the layout changes once I lift up the blocks. What I want is for the layout to only change once I drop the block, since then I'm done moving blocks around.)

[jmoenig]

Naw, of course scripts should layout as soon as you pluck something out of them

[brianharvey]

Don't say "of course." I think this is a sensible suggestion. Among other reasons, sometimes I click on something without meaning to drag it, but I do drag it slightly, and everything jumps around so that if I let go (because I was only trying to click, not drag) it ends up moving; this happens to me pretty frequently, not every day, but often enough to annoy me. The worst thing is if this unintended move bounces some other expression out of the unintended target slot; it can be really hard to figure out how to put your code back together.

The way to think about it is that the "pluck" -- the drag -- isn't complete until you release the mouse button.

[jmoenig]

you're mixing up several issues, clicking vs. dragging was fixed a while ago when we introduced a dragging threshold and doesn't happen anymore. Accidentally dropping something into an unintended slot and kicking out what was in there before can be fixed with "undrop", and now we even have unlimited undrop, so that's also been addressed a while ago.

"Of course" is the right thing to say here. No use beating around the bush just to be nice.

[brianharvey]

I wasn't trying "just to be nice"; I think this is a good idea. I guess you're not gonna be convinced, which is okay, but I think it would be an improvement, although not a necessity.

[towerofnix]

Discussing an idea isn't being nice, it's being constructive. Closing an issue with "of course" and without an explanation is not being constructive, it's shutting down an idea without any apparent reason.

What's the reason blocks should re-layout as soon as you pick up a block?

I've given a reason they shouldn't. You've given me workarounds, like using undrop/undo, and mentioned the click/drag issue which was fixed a while back, but you still haven't given me a reason the suggestion wouldn't work anyways. Making layouting only happen when a block is dropped would fix this inconvenience (even if it's just an inconvenience) that both @brianharvey and I semi-frequently have (and I imagine many others do too).

[jmoenig]

Sigh. Yes, I'm not being constructive here, and you're right, "of course" is not an argument. To me it's obvious that a friendly user interface is what's nowadays called "reactive", "fluid", or - more to my taste - "morphic", and adapts to user gestures in a lively and interactive way. In Snap (as in every single block programming IDE I'm aware of) that includes that blocks go back to assuming the shape that's familiar to users, and do not stay in what appears to be a "stretched" or otherwise distorted state. As soon as you've picked up the reporter you wish to move into another slot, the situation is exactly the same as it was before you dropped it into the previous one, you get a "clean" slate, not one that's been affected ("tainted", even, if you will) by previous actions you're trying to set right.

[jguille2]

Oh Yes! Our beloved liveness environment is the key.

While I'm dragging the blocks are already removed. If the script is running in this meantime, the blocks are not there (they are not executed!) ... So, it's coherent the layout dynamic change.

Joan

[towerofnix]

Ah, right! That makes sense, @jmoenig and @jguille2; thanks.

[brianharvey]

I remain unconvinced. I get that liveliness is a religious issue, and I don't think I'm opposing it by saying that we should make it easy for people to complete their intended gesture. Otherwise, liveliness becomes a shackle rather than a responsive environment, like that old joke modal window program on the early Macs that said "Erase disk?" with Yes and No buttons, and whenever you got the mouse near the No button, the whole window would jump away so that you were over Yes instead. If the lively environment makes the target slot jump away from you, it's not cooperating with you, which is what liveliness is meant to do.

I think we should view a chunk of code held with the mouse down exactly like a chess piece held in the hand and not touching the board. The player is allowed to put it back! And, by the way, one reason a player might do that is that holding the piece hovering over a possible destination can help visualize what the result would be of moving it there. Same with code. If it's still in my hand, I haven't committed to moving it.

By the way, I think it's relevant that Scratch code rarely involves huge composition of functions, so the motion of the rest of the code is mostly only in one dimension -- and, maybe more important, when it comes to command blocks you can't grab an internal subset, but only from-here-to-the-end. So the situation we're talking about, in which some later input slot moves up to where the lifted code fragment is, doesn't happen.

I think we've learned several times before that slavishly doing exactly what Scratch does, once you have custom reporters, can end up violating the Scratch spirit while adhering to the letter.

I'm not digging in my heels about this, just saying that the discussion so far hasn't convinced me, even if it did _nix.

[towerofnix]

(@brianharvey I'm just bad at arguing. Which is why I mostly read old arguments and don't participate in new ones :) - Now I'm just as inclined towards my idea as you are and as I was before. 'Coz I'm most impacted by the thing I've just read! :) - PS, I was thinking "hmm, but isn't an IDE still supposed to be helpful..." Too bad I didn't put more thought into it.)

[brianharvey]

@towerofnix Hey, I have this great bridge for sale... :-)

Actually I have the same problem about reflexively believing the last thing I read. It helps when you build up a collection of past arguments, so you can look for similarities with the new one. It also helps when you have a few core principles (e.g., the class analysis of society) with which to evaluate new ideas -- although that also helps you be closed-minded in genuinely new situations, so you have to be careful about that too!

[jmoenig]

There's nothing religious about this debate, this is all about how you can shoot yourself in the foot. If you want the input slot to always stay where it is you can insert a hard new line into your synchronous JS-ify 𝝀 block, problem solved.

I maintain that whoever encounters an awkward situation while writing and using stuff like synchronous JS-ify 𝝀 is way above the level of being a representative (i.e. novice) Snap! user anyway.

Come on, Brian, if we really did what you claim to recommend here I don't want to be reading the scathing criticism of our regular users. Do you really, honestly believe that our BJC / TEALS / Young Thinkers teacher, volunteers and students would not be totally freaked out. You cannot be serious about this, it's only because we - of course! - love reporters like synchronous JS-ify 𝝀 and the astoundingly clever Scratch-forum kids who come up with them that we have this discussion.

[jmoenig]

It doesn't even have to be a ring. @towerofnix can simply use a C-shaped slot and an implicit parameter. There, yet another way to solve this issue....

[brianharvey]

Jens, I don't see why you think this issue has any special relationship with the particular example in those pictures. It's not even about blocks in rings. Unless I'm misunderstanding the suggestion, it's about any situation in which a user picks up a subexpression and wants to move it somewhere else, but the "somewhere else" moves away as soon as they pick up the subexpression. It can be a plain old arithmetic expression with nothing fancy about it. One of the two of us is seriously misunderstanding the subject under discussion!

[jmoenig]

it only moves away because Snap's blocks are word-wrapping their labels. You can control this by either using explicit new lines or a C-shaped slot.

The blocks you define, the scripts you write are a user interface, you can mold it, it's malleable. That's what makes Snap! cool.

[brianharvey]

Sigh. Here is an example using nothing but primitive blocks. It's a stupid example, not real code, just to make this point. Here's the "before" picture:

I want to pick up the indicated × block and move it into the SQRT block as shown. So I pick up the block and here's what I see:

(oops pretend the orange rounded rectangle is where it would actually be...) The red arrow now points to the THINK block. This confuses me, a novice user, for two reasons:

1. I've started moving left and down, but in order to complete this operation, I must instead move right and not down.
2. If I change my mind and let go, the expression doesn't go back where it came from. Instead it goes... where? I can see the halo, underneath my block, but I can't see which input to which subexpression is at that position.

Postponing the rearranging of blocks until I let go would solve both of those problems.

Your suggestions about putting newlines in custom block prototypes misses the point. This isn't about a block designer anticipating a particular user gesture. It's about something that happens all the time, not under the user's control, that's not helpful.

P.S. The reason I got that orange rounded rectangle in the wrong place is that I didn't notice, and therefore didn't think about, the fact that part of the rearranging that happened when I picked up the subexpression was to move the input to SAY onto a different line.

[towerofnix]

(@brianharvey's last post is exactly what I was talking about, yeah. And that's a better example than mine :) )

[jmoenig]

Discussions like these suck.

See, I get it that I should not have said "of course". But making me suffer through this is unfair.

You think that something like this sounds like a good idea:

and you claim, that something like this is what you want:

and you want users to see this:

Of course not. Right?

What you maybe want is that "re-layout" indeed happens when you pick up a reporter, and that input slots get restored, but that they assume the dimensions of whatever was just picked up. And you think that's a good idea because you further presume that you typically want to move something inside the same script, not to another one, and not back to the palette to delete it. Plus you claim that users memorize the distance and direction of an intended movement and blindly execute that in one gesture.

I am sure that if Snap! did what you did not even care to think through to the end it would freak out all users that aren't you. I also think we're having this argument just because you encouraged a kid to open an issue that has the word "should" in it.

[brianharvey]

I'm sorry that you feel attacked, but you are ascribing motivations to me that are not my motivation. Way up at the top, when I said "don't say 'of course'," I didn't mean "don't say it because it's not polite and this is a kid"; I meant "don't say it because I'm not convinced; it's not 'of course' to me." It's got nothing to do with the fact that the original suggestion came from a kid.

And I'm not prolonging this discussion to punish you! I would never do that.

I agree with you, now, having seen your pictures, that this would be a big change, and that it's not a question of "of course" in the other direction either. But yes, your pictures are what I want, with the minor difference that I think there should be a white rectangle (or whatever type the input was) in the original position, so in your version of my example, there should be a white oval halfway through the top row of the light-colored + block, and it should be haloed until you move the subexpression away from it.

I guess I don't mean "halfway through"; I mean "underneath the cursor." So in your last picture you probably picked up the ring by its right edge, in which case the empty rectange for the first input to SAY should be near the right edge of the whole expression. (If you picked it up somewhere else, then the empty rectangle would be somewhere else.) This is so that if I let go without moving away, the expression goes back where it was, and also to make it easier for me to parse the script.

You're right that I haven't fully thought this out. Maybe I want a ghost outline of the picked-up thing to stay in its original place until I let go of the mouse button; that would make your admittedly strange-looking pictures less strange-looking. The input slot would help, too, though; I think your pictures look weirder than necessary because the arities of the blocks behind the expressions are wrong. (Only one input to + for example.)

Or maybe you're right and it's a bad idea. All I know for sure is that I'd like the discussion to be entirely about the merits of the idea, not about whether I'm punishing you, or whether you're abusing _nix. Those are both non-issues. Your pictures have convinced me that this isn't obviously a good idea. But yeah, even in the weird-looking case, I still wish things didn't jump around under me. I've always wished that, actually, but I never thought that it might be achievable before, because, like you, I was thinking of the action as happening as soon as the drag starts, rather than when it ends.

Edit: If you move the expression out of the script, including into the trash, then as soon as you let go, the original script will take its proper shape. In those cases, this feature wouldn't be so important, but it wouldn't hurt either, I think. And I claim that users sometimes determine (not memorize) the distance and direction of an intended movement, and if things shift around under them, they have to stop and think about it.

[towerofnix]

I also think we're having this argument just because you encouraged a kid to open an issue that has the word "should" in it.

Of course you are. Obviously I'm the one who made the issue. (I was going to make it anyways, but I asked, because I wsn't sure if this discussion already happened.)

Sorry for putting "should" in the title as a very confident "this is definitely the way it should be". I should have phrased it like a question; that was what I really meant.

And I claim that users sometimes determine (not memorize) the distance and direction of an intended movement, and if things shift around under them, they have to stop and think about it.

This is what I was thinking of, yeah. Obviously I'm not going to pause for ten seconds to think about exactly how much I should move my mouse (and in what direction) to get the block where I want it to be; but that is something I do relatively automatically, subconsciously. And if the block shifts around, I have to think consciously (just like if I'd memorized the path my mouse should take before lifting the block), which is exactly what I'm trying to avoid here!

[brianharvey]

Sorry for putting "should" in the title

Nah, don't apologize. People do that all the time, and Jens, whom I love dearly, takes it in stride unless the issue pushes one of his buttons, and this one pushed two of them. One button is that Jens hates it when I encourage a kid to write code for Snap!, but I think this is the first time he's extended that to hating me encouraging a kid to post a suggestion. That's probably because of pushing the second button, which is that he takes this idea as an attack on liveliness and Morphic, which are at the heart of his work. (I don't think it is an attack on them, but I can see that there's room for misunderstanding both ways.)

(And yes, saying all this here, instead of in an email to Jens, is how I express being really annoyed -- not about the substantive disagreement but about the ascription to me of motives that aren't my motives.)

[jguille2]

Trying to leave behind non-constructive polemics :candle:

I am fortunate to announce that just today the Three Kings :dromedary_camel: :crown: :dromedary_camel: :crown: :dromedary_camel: :crown: have left us with tons of peace, joy and fun for Snap! project for the year 2018. You are lucky that I wrote the letter ... :innocent:

And returning to this issue, we can open later other issues to think about new features or new designs... but I think the re-layout after dropping has no sense into current behaviour. Two comments about this...

• I can imagine some cases where this frozen layout has advantages... but I can also image a lot of cases where the opposite happens. A basic summary would be: Moving a large piece... when the movement is short, the frozen dragging would be better... but when the movement is long, current behaviour is great!

• But here, the important thing is not the layout! As I said before, we must look at the real operation. When we drag something, it is already removed! And while we are moving it, it is no longer in the previous place.

  An example to show this clearly:

  • I have the turn block with a large input

    

  • And if I drag the call reporter ...

• While moving we have already a [Turn [15] degrees] !!!

So, the layout, must show 15. We can not discuss if we want an empty, blue or white, large or short slot to help edition operations. We need the real value!

---

Ok. Thank you (all) for this great project and let's begin a funny and cool 2018!

Joan

[brianharvey]

Yes, I agree about needing the real value, but the white oval with 15 in it could appear at the position where the mouse was clicked inside a big empty space. So that doesn't rule this out.

Thank you for the long vs. short move point. I agree that that sums up the pros and cons. So, how does this sound: The layout is frozen until the mouse moves outside this script (which could be to the right, out of the scripting area, as long as you don't let go); then the re-layout happens. (And then you can move back into the script.)

The disadvantage of this change is that it might take users a while to learn. (Or not; maybe it would turn out to be the intuitively right thing.) So we certainly shouldn't do it until the summer, if we do it.

[jguille2]

Thanks Brian. I have to think this deeper... but it sounds good (but not easy to implement). And I think it has not to be a quick decision... and can be considered calmly.

In case this goes ahead later, I write down some comments to consider at that time (I will forget everything about this in a few days):

• The phantom space (related to the object that we are dragging) needs a special design. It has to be highlighted (to help us to return to the original position) but different that the target focus. It can be into a slot input or in the middle of the script (or at the end). The idea is it has the same shape and size of the object removed.

• This is a temporary state... but it has its complication. The original objects are gone, and it is a new morph that only decorates a point of the stack. For example, visible stepping is jumping it.

• Slot inputs must show its real value. This can be a problem... For example, if I had [Say [(a)]] and I amb dragging (a), I'll get [Say [Hello!]]. And Hello! is bigger than (a) !!! I'll say something more about this later.

• The relayout action while "dragging" passing over the palette can be great. If this is not clear, we can keep two moving actions. The main action it will be the "normal" drag and drop and the other as a menu option (like duplicate, delete ...) I don't know wich would be the main "moving action".

And some more comments related to this:

• When I drag a reporter from a slot input, this inputs take the default value. Is this good? I prefer that it took an empty value. This solves the problem related about the size... but I'm not only thinking on this. When I drag, I'm removing the contents... so I would expect an empty slot. I've looked at what Scratch does... and it is more strange: Scratch delete string inputs and put 10 into numeric inputs (yes 10, not the default value).

• When I drag an script (or only a block) and drop this over an sprite in the corral... this script is copied... but not moved (it appears again in the original position, like when I drop it in a forbidden area. I think it is not right... If we want to do this (copy), we have the duplicate option.

• In the blocks menu we have the option of "only duplicate this block". We could add an option to "move only this block". It will be useful!

Thanks for your patience... Maybe this help us when (if) we reopen this "dragging" discussion.

Joan

[brianharvey]

Thanks for all of these hugely practical ideas, and for moving the discussion to a sensible one.

For indicating the old position, one thing that comes to mind is to zebra-color it. But maybe that's more dramatic than necessary; maybe just outlining the space in zebra-color.

About things like visible stepping, I agree that we have to be sure sensible things happen, but, you know, nobody's going to sit there holding down the mouse button for ten minutes! About the specific case of visible stepping, I'm not sure why there's a problem at all. Exactly the same blocks will be highlighted as would have without this feature; it's just that some of them are shaped differently.

About the input slot growing instead of shrinking sometimes, fine, in that case we don't freeze the layout. It's not going to grow much.

Actually I would promote dragging to the right, over the stage or sprite corral, rather than left, over the palette, because the risk of letting go and losing the expression altogether is too great. (Yes, I know, now we have undo. Still.) Letting go on the right just puts it back where it was.

Default values. Don't get me started. I don't like default values because they interact badly with using empty input slots as implicit formal parameters in RUN/CALL. I keep trying to convince Jens that default input values should be gray, and should not count as filled for that purpose. (More precisely, first we try matching actual input values with fully empty slots, as now; but if that fails, then we treat default value slots as empty and try again.) Or alternatively we just flush the whole idea of default inputs. So I like your idea because it helps move us in that direction, but honestly I don't think reverting to the default (a question that arises even without this shape-freezing feature, of course) is any more of a problem with shape-freezing.

I have to disagree with you about dragging a script onto a sprite in the sprite corral. Yes, I can see why in principle that'd be better, but the feature is just way too useful to make it any harder to use. And shape-freezing would make this behavior easier, not harder, to understand.

"Move this block": great idea! I keep wanting that. And we could do that right now, separate from this larger discussion.