Skip to content

Conversation

@rachel-fenichel
Copy link
Collaborator

Proposed fix for #439

@microbit-robert @microbit-matt-hillsdon I'd appreciate your opinion on this.

Two parts to the change:

Initial offset

In mover.ts, call info.updateTotalDelta immediately after onDragStart.
If the drag immediately shows a preview, this will update the block's location accordingly.
If a preview is shown, the block is moved down and to the right of the target connection.
image

Rationale

Without this change, the block was wrong about its position until the first constrained movement occurred. I think this change is necessary no matter what.

Offset during drag

In keyboard_drag_strategy.ts, only force the block's position offset if the most recent movement was constrained.
image

If the movement was unconstrained, the insertion marker still shows or hides as appropriate, but the dragging block can translate relative to the insertion marker. All of these become legal:
image
image
image
image

Moving away more causes the insertion marker to disappear:
image

And here's an example as a gif. All movements in this gif are unconstrained.
582f55d7-5595-49db-a068-621fd105c8c7

Rationale

In discussion with Robert and Matt I suggested making the drag step larger during keyboard drags, or making it larger only when showing a preview and trying to do an uncosntrained movement. But as the drag step size increases, so does the chance of missing a connection entirely. This is especially acute when working with value inputs, where the connections may be very close to each other in a row.

While investigating, I realized that part of the issue is that the user has no feedback: there is no visible change on the first unconstrained movement away from a connection (or, in MakeCode, the first four). In mouse mode the feedback is that the block moves along with the mouse pointer. The insertion marker sticks at the new position, but the dragging block moves around. In fact, this is half of the reason for using a separate insertion marker as a preview.

This change mimics mouse dragging by moving the dragging block around while still showing the preview. It may take multiple keypresses to move away from a connection, but users get feedback that a movement is happening.

@rachel-fenichel rachel-fenichel requested a review from a team as a code owner April 18, 2025 22:50
@rachel-fenichel rachel-fenichel requested review from gonfunko and removed request for a team April 18, 2025 22:50
@rachel-fenichel rachel-fenichel merged commit b4d18e2 into RaspberryPiFoundation:main Apr 19, 2025
8 checks passed
@rachel-fenichel rachel-fenichel deleted the move-sticky branch April 19, 2025 00:03
microbit-matt-hillsdon pushed a commit to microbit-matt-hillsdon/blockly-keyboard-experimentation that referenced this pull request Apr 20, 2025
@microbit-matt-hillsdon
Copy link
Contributor

I think this works really well, thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants