Make moving (reordering) blocks inside a script less frustrating

The problem: If you want to move a block, or a few consecutive blocks, to a different position inside the script where it already was, currently you have to go through a relatively lengthy drag-and-drop ceremony, where you tear apart and then put together stuff. (I assume you know what I mean, but if not, try to do the above.)

Why is this important: If you just start learn programming, you will often do mistakes, and need to modify your program like above. That doing this is cumbersome (and error prone) adds to the frustration. Kids tend to become frustrated by their own mistakes. So fixing/experimenting should feel like a natural an easy thing. Also, it's basic source code editing functionality, so even I find this annoying. (Imagine if your real world code editor would only support moving lines that are between a selected line and the next "}". That's basically what Snap and Scratch does.)

How to solve this (updated based on feedback below): Blockly, and MS Arcade allows dragging a single block by holding Ctrl. If you will do that, add it to the right-click/long-tap menu as well, like "Move" (behaves like "Duplicate", but also deletes the block). This is the most frequently needed operation, and probably easy to add. But it could become much better, if Snap supported selecting multiple blocks. The context menu could have "Start selection", which after clicking allows you to select the other end of the consecutive blocks, then clicking that makes them all selected. Then, with "Move" all that could be moved at once. Selection also could work with other operations, like Delete, Duplicate, etc.


Welcome to the forum!

I would love to see that in the version 7 of Snap!.

Nice idea. Hope it would not be too hard for @jens to implement, however.

I admit I do (and I'm not a kid anymore)

+1,000,000,000,000 :slight_smile:

In GP - I even managed to implement it in my own version

(It was only 7 extra lines of code

1 Like

Is this how much you like it? :~D

Are you saying it would not be hard to implement? Do I understand correctly?

Yes :slight_smile:

I'm saying that in another block language it was just a few lines of code to implement so I'm hoping that it wouldn't be too difficult to do in Snap!

I agree about the problem. The way I deal with it now is to duplicate the block, put down the duplicate where I want it, then go back and delete the original. This does have the advantage of safety: you can't lose the block by messing up during the move. I think your single-block move item in the context menu would be easy to learn. I'm less sure about the hovering part and the checkboxes, not because they'd be hard to implement (I have no idea if that's the case) but because that's a lot of mechanism and could be intimidating to users. Plus it's not clear what to do if the user checks a non-contiguous set of blocks.

Maybe a Mark or a Start Region item in the context menu that would visually highlight the block, then an End Region option that would highlight everything from the mark to this block, and then give a choice of Move, Duplicate, or Delete.

There is also the option used in MicroBlocks, where a R-Click menu offers "EXTRACT Block" feature. When used, the block gets separated from the sequence and floats with the mouse pointer until dropped.



Yeah, it actually should be a range selection. So that's not check boxes visually then, but still something clickable next to the blocks, and clicking that thing sets the top or bottom of the selection. Really my point is that this kind of operation should be convenient, and easy to discover. Pretty much anything is better than the lack of a such basic source code editing feature.

I think if this is only available from context menu, that's not so convenient, and not so easy to discover (that the possibility exists at all). But it's still a step ahead. Still, at very least moving a single block should be more convenient than that. (Actually I think if wasn't for the Scratch tradition, dragging a single block should be the default behavior, except for "hat" blocks, and doing otherwise would be the exception. But, it's too late, I assume.)

Yeah, for a single block this is not frustrating. We probably all do the way you described. What I find frustrating is having to duplicate several blocks, but not the whole group of blocks all way down to the last one within a loop (for example) because I now need to do it one by one (which I do, when the number of blocks to be moved is less than half of the whole group of them within a loop) or duplicate the whole group, put it on the side, and delete from the duplicated ones those I don't need to move, then move (those that I didn't delete) back to where I wanted them to be.

Well, I think it is frustrating for a single bock as well, because that's a so frequent operation. Also it feels like something that should be a basic operation in a UI that's about dragging and touch.

Ahhh, yes, less stress to the fingers. Sounds nice.

1 Like

I meant to say "not as frustrating as" but my fingers were too quick ;~)

It is in fact, very stressing seeing as how I use a chromebook, so I don't have the normal mouse on a string like desktops do, I use a touchpad mouse that is attached to the laptop itself, so I have to press the touchpad while dragging my finger across it, which makes it feel like I am trying to crush my own fingers if I do it for too long.

1 Like


I got a little used to it. I wish I had a desktop, it would be easier and less of a pain. Sadly all I got is my chromebook. (In this situation, having a desktop would be better because you don't have to do the same things that you have to do with a chromebook when you drag/draw something.)

1 Like

Actually, all these Scratch-copy-cat block editors are sadistic on many ways, and one of those is their obsession with drag-and-drop. Usually you want to add a block just after the last one you added, so it should enough just to click on the new block to insert. But no, you have to drag the piece over half the screen, and then drop it precisely(!). But, I'm going off topic...

1 Like