Alternative to dragging - click to connect

[kmcnaught]

Check for duplicates

• I have searched for similar issues before opening a new one.

Problem

1. Holding a mouse click down while dragging can be an accessibility barrier for some, including (but not limited to):
   a. Users of assistive technology
   b. Users with a low quality trackpad
   c. Young users with small hands and not much experience with mouse control
   d. Users struggling with the cognitive mapping between hand movements and cursor control.
   e. Touch screen users who struggle with the motor control required to maintain a drag action (but otherwise prefer touch over keyboard/etc)

2. Current mouse drag implementation requires that you line up the connection point of a block, which isn't generally information that's presented to the user, and so doesn't always translate to intuitive behaviour. For standard mouse usage, the connection preview gives feedback that helps learn to workaround this, but sometimes using assistive tech to complete a mouse drag in two stages (selecting initial click location and then target), this becomes impossible.

For an example of (2), consider using eye gaze to define an initial click location and then a drag target. If you've clicked on a value block anywhere other than the left hand edge, you are required to look at a target offset an arbitrary amount from the connection you are aiming for in order to make a connection work.

Request

Provide an alternative way to move blocks, for mouse/pointer users, that circumvents the need for a mouse drag.

The minimum delta required for this could be:

1. Make all potential connection targets visible when in move mode
2. Provide a mouse-based trigger to enter move mode (such as a double click)

We may also wish to explore:

• Providing a way for a block to stick to the cursor while moving, in a new 'click and stick' style operation. This gives access to the preview feedback while allowing the move operation to be formed using sequential actions.

Alternatives considered

Using keyboard move mode

• It is indeed possible to avoid drag operations by using keyboard controls
• I do advocate for encouraging keyboard controls for mixed mode use cases, to allow people to develop their own preferred workflows and to be exposed to the potential efficiencies of keyboard controls

But...

• For those who can click/tap a point comfortably, direct access is preferable compared to several arrow key presses
  • less physically demanding (fewer actions), and
  • less cognitively demanding (direct spatial targeting rather than indirect mapping between keyboard presses and navigation)
• Touch screens are more accessible than keyboards for many users with motor difficulties, BUT the click and drag can be a challenge.
• Switching between cursor-based workflows and keyboard-based workflows adds cognitive switching demands on users of assistive tech or users of touch screens.

Using O/S level mouse options.

MouseKeys or ClickLock /Drag Lock or Chromebook's "Tap and drag to move items" all give you ways to perform a drag operation in steps. They are all a bit problematic (for example, Windows Click lock gives zero feedback when it triggers, and has an innate ability to not trigger when I want it, but always triggering when I don't). Also

• Students may not have access to O/S settings
• Students may not want this setting in their other apps
• Students and teachers may not know they exist

Other

I wrote a whole article here with workarounds: Guide on click and drag

I believe that this is a universal enough 'value add' that it deserves to be standard behaviour rather than signposting hacky workarounds.

Additional context

I've made a prototype implementation to play around with this. You can try it at click stick demo 15-oct-25).

Note that:

• this is not intended to be production-ready, it's just a UX prototype that Claude Code helped me build.
• double click trigger won't work on iOS
• you can change options in the left hand pane to play around with different options

How it generally works:

• you can put a block into 'sticky move mode' by double clicking (or one of the other triggers in the dropdown)
• in this mode you can:
  • use arrow keys as usual, or
  • move the mouse around to see previews
  • tap/click to release (as per the preview, or
  • tap/click directly on a connection to connect there, or
  • tap/click on the workspace to drop there
  • use Esc/Enter as expected

I also recorded a 12 minute presentation to argue for this. I've shared it with the CSTA listserve and am getting feedback from them on the next CSTA zoom meeting in a few weeks. I've had positive feedback from a couple of educators in private conversations, who emphasised the potential for touch screen users as well as eye gaze users.

[kmcnaught]

FWIW I've gone for the 'single block move' behaviour, but would obviously envisage a way to choose between a stack and a single block as per #763.

I was always strongly in the camp that single block move was natural, and anything else was weird. And I still get weirded out when standard mouse behaviour moves a whole stack. And I have to confess, I only learned about the Alt shortcut from @microbit-matt-hillsdon last week. But, the more I play with it, the more I notice the inconsistency between the modes.

[kmcnaught]

Some of us discussed this at the start of the CSAccess meeting yesterday. The meeting was recorded, and will presumably be shared in the mailing list in time.

General talking points were:

Everyone agreed that drag and drop was a common barrier for wide range of users including

• those familiar with mobile devices (touch interactions) and now learning to use a mouse
• those using a joystick/trackball and separate switches in various configurations
• those with broken trackpads
• those using tablets
• but also "very wide users base" generally

Richard from Blocks4All pointed out that in their app they specificially avoid any drag interaction and just use single taps to select a block and then choose where to place it. I do not have an iPad to test this on currently, but you can see a short clip of the "select select drop" behaviour on this Block4all presentation.

We discussed how many of the different variants would have value for different users, and we'd expect the need for customisability, but the "click focused block" option was called out as a potentially very simple one, and coincidentally similar to the way Blocks4All do it.

I have updated the demo prototype to iron out some inconsistencies/UX foibles in the "click focused block" variant, to give it a fairer chance.

[kmcnaught]

updated comment above ^

[kmcnaught]

I've also made a simpler testing playground if anyone is able to try it out with users. It divides up the different options in a more sensible way, and gives you a little task to carry out with 7 blocks. This hopefully makes a much easier way to test the basic principles without complication. Here's a quick video to show you what it looks like. This is the best place to play with the general feel of each interaction method, whereas the full web demo is better if you want to explore a wide range of blocks and fields.

[rachel-fenichel]

Hey Kirsty--sorry for the delay in responding to this as I manage the Blockly transition to Raspberry Pi Foundation. Please don't take silence for a lack of interest here! I think you've got something really interesting, and the demos make it easy to play with. (Can I get the demo code?)

Mode

I prefer click destination to sticky drag.
My reasoning:

• Sticky drag is similar to something you can do with OS settings, and someone who needs that setting in Blockly likely also needs it for many other parts of computer use. (Although I note your description of issues with the OS-level versions above.)
• Click destination exposes additional information about where a block could go.
  • I can see that being useful when explaining how to connect blocks, regardless of whether the beginner has issues with dragging.
  • It would work well on tablet, without the finger blocking the user's view of the block.
• Sticky drag feels very similar to unconstrained movement, and there's potential for user confusion about why there are multiple ways to do it.

Trigger

I like double-click the best.
My reasoning:

• I want it to work on tablet, and shift-click isn't an option there.
• Bodging grip handles into rendering is a scary prospect both technically and in terms of user-facing documentation.
• Single click on selected block feels like a less intentional action than a double-click (to me).

Targets

I like that the targets are filtered down to only legal connections. Again, a good way to facilitate a discussion about where a block can be moved.

Concerns/Questions

• What happens if there are enough blocks that they don't all fit in the current viewbox?
• How does placing on the workspace (e.g. dragging to disconnect) work? (Edit: I see above that it works as expected, by dropping where you click, so this is more a question about how to indicate that to users if we do click destination).
• What if the workspace is extremely crowded? (My default answer is to teach them to use F for format before taking actions)
• Sometimes moving a value block will replace an existing block. Other times it will connect to it, or will bump it out of place. Do you think it's important to show a preview? (My default is no, but teach them to undo with a quick action as well.)

[kmcnaught]

Hi Rachel, thanks for the feedback. Glad there is some interest.

Code

You can find it at my fork. I've just pushed the latest to main. Please note I've leaned heavily into Claude Code for this, to get the UX I want, rather than developing any opinions on implementation details - I figured implementation concerns are liable to change with Christopher's various refactorings anyway.

Mode

I agree that click destination adds more concrete value. I still think that having an option for sticky click in blockly itself (and exposed in platforms) would be of value, since many school settings don't have the IT literacy to be using OS level accessibility settings as much as they should, so it would contribute to education on that front. But I'm happy to park it as a completely separate feature request for the reasons you argue.

Trigger

I am currently strongly favouring single click on selected block myself. I shared your concerns that it's not as intentional as double click (or something else) but I've tried hard to ensure that clicking again puts you safely back in the state you were in, and being able to rearrange your code with only a single type of mouse action has a massive QoL improvement to those using a joystick /switch combo, or eye gaze. I accept that it's lack of intentionality demotes it from something that could be on by default. Double-click is a close second - do you think it could be something where we have double click as default and an option to allow single click?

Agree fully with your arguments agains shift+click and grip handles.

Concerns/Questions

What happens if there are enough blocks that they don't all fit in the current viewbox?

I have done nothing to support this yet. I think dragging is disabled while in the middle of a move, not particularly by intention.

From an implementation perspective we'd want to filter by "in view" blocks to avoid rendering overhead. Can't remember if we did that or not in the prototype.

From a UX perspective: Currently when you drag with the mouse you are limited to the current viewport (in Blockly, Scratch and MakeCode - not sure if anyone else lets you drag to the edge and scroll into view?) I guess you would have to drop on the workspace, scroll and then move again? Not great, but similar to the status quo. I am very open to suggestions to improve this, particularly as there's likely to be a correlation between folks who need this and those who use higher zoom and fit fewer blocks on the screen. Do you have any thoughts?

How does placing on the workspace (e.g. dragging to disconnect) work? (Edit: I see above that it works as expected, by dropping where you click, so this is more a question about how to indicate that to users if we do click destination).

Yeah, it currently 'just works' but there's no affordance to tell you. I guess that's also true of the current mouse drag behaviour, except that for this mode we are explictly enumerating the destinations, so it's more of an omission. For deliberately placing on the workspace, I imagine we can just teach it (and, if someone wants it and tries it, they learn it). Maybe accidentally placing on the workspace is more concerning - currently you can miss a connection and drop it 'over the top of the target stack', particularly if you are using touch. I have wondered whether there was a way to present it such that clicking anywhere on a block shows legitimate intent for 'insert above this block', rather than requiring an exact click on the connection highlight. But I haven't yet managed to figure out a way we could do this with it both visually and logically making intuitive sense.

Sometimes moving a value block will replace an existing block. Other times it will connect to it, or will bump it out of place. Do you think it's important to show a preview? (My default is no, but teach them to undo with a quick action as well.)

I don't think so. But I haven't seen enough of these situations to think deeply about it.

Here's one that I played with a bit:

Nothing jumps out as massively surprising when things pop out. I did notice a bug in the connection filtering though - I don't think I'm correctly permitting the block being moved to become an input to a valid output connection. I'm sure I had that working at some point!

Prior art

I was discussing this at an assistive tech conference yesterday and someone pointed out that this is very similar UX to Chess.com. Just mentioning as a useful comparison - I don't think it changes any of the discussion, but it's an interesting comparison. And I know a few eye gaze users who consider it very accessible for this reason!

[rachel-fenichel]

From a UX perspective: Currently when you drag with the mouse you are limited to the current viewport (in Blockly, Scratch and MakeCode - not sure if anyone else lets you drag to the edge and scroll into view?) I guess you would have to drop on the workspace, scroll and then move again? Not great, but similar to the status quo. I am very open to suggestions to improve this, particularly as there's likely to be a correlation between folks who need this and those who use higher zoom and fit fewer blocks on the screen. Do you have any thoughts?

We have a scroll options plugin to allow edge scrolling, although it's not a default behaviour. (I believe Code.org uses it.)

The existing code handles it by auto-scrolling to center on the next potential connection, even if it was originally out of view. I don't know what an analogous behaviour would be with click destinations.

[kmcnaught]

Ah yes, the edge scrolling plugin makes sense. This is indeed used by Code.org but doesn't seem to be used by Scratch or MakeCode.

If someone was using click destination with a joystick / headmouse / other pointing device that is directly controlling the mouse, then I think the same behaviour would work - so long as it applies the edge scrolling based on "mouse position when in this particular move mode" and not specifically "mouse position while mouse button held down".

This wouldn't work for touch, or for eye gaze when users aren't controlling the mouse continuously. When blockly handles mouse events, is it possible to robustly detect the difference between a mouse-click-as-part-of-a-drag vs a standalone mouse click? If so, then we should be able to permit dragging in move mode. Otherwise, I don't think it's a blocker to not be able to scroll while moving in this mode. If you are using an extremely zoomed in interface then you might be advised to learn keyboard move or copy/paste, or another workflow.

[kmcnaught]

Just dropping this reference - dragging movements are now explicitly referenced in WCAG 2.2 AA.

For any action that involves dragging, provide a simple pointer alternative.

The intent of this success criterion is to ensure functionality that uses a dragging movement has another single pointer mode of operation without the need for the dexterity required to drag elements.

And it specifically calls out that creating a keyboard control alternative isn't sufficient

Success Criteria 2.1.1 Keyboard and 2.1.3 Keyboard (No Exception) require dragging features to be keyboard accessible. However, achieving keyboard equivalence for a dragging operation does not automatically meet this success criterion. It is possible to create an interface that works with dragging and keyboard controls that does not work using only clicks or taps. While many designs can be created for a dragging alternative which address both keyboard accessibility and operability by single pointer operation, the two requirements should be assessed independently.