Skipping to another top-level stack

[BeksOmega]

How should we support skipping to another top-level stack of blocks from within one stack of blocks? (if we want to at all)

For example, jumping from the "play tone" block to the "forever" block in the following stacks:

One option (A) is to have a shortcut that skips directly to the next stack. This is faster.

Another option (B) is to have a shortcut that jumps to the root (aka highest level, top parent) block in the current stack, and then another shortcut to navigate to the next stack. This is more flexible, because both shortcuts can also be used for other things.

[kmcnaught]

One option as per #63 is to treat each stack as a tab stop, but not use tab navigation within a stack (just arrow keys). I'm not strongly voting for that, but it seems like a plausible answer to #63 that also answers this question.

Related to this, are you planning to make any changes to how different stacks are laid out on the canvas, to simplify navigation? In Milne and Ladner's paper on Blocks4All there was a significant preference for edge-aligned blocks, rather than floating, for VI users with a touchscreen. I can also imagine keyboard-only users finding it easier to have an option to coerce all stacks into a more structured alignment, rather than having to manually move stacks across the workspace to get everything easily visible. Currently on micro:bit MakeCode, and Scratch there's some minimal coercion to prevent blocks being exactly on top of each other (I presume this is core Blockly functionality?), but you could imagine a stricter version of this that also keeps stacks aligned in rows/columns, and/or nudges other stacks away as you add code to make a stack bigger. The preferences for a keyboard user might be different to those of a touch-screen+VoiceOver user, but I think both would struggle with the current almost-unconstrained layout. The downside of too much layout constraint would be less visibility of the overall program for sighted users, so I'm picturing the strictness of layout coercion being configurable, ranging from the current behaviour, an middle option or 2 whereby maybe 80% of the blocks don't overlap (you could still have stacks side by side as well as above/below, with most blocks not overlapping, allowing for outliers), and an extreme option that effectively lets you deal with one stack at a time.

[rachel-fenichel]

Summary of discussions between micro:bit and Blockly on November 12-13, 2024:

• Our baseline behaviour will be similar to Blockly's existing behaviour for drags: we won't let two blocks exactly overlap each other, but we'll otherwise let blocks overlap.
• We will make the cleanup/organize option always available, and will onboard users to know that they can call it to rearrange everything to be non-overlapping.
• We will not automatically rearrange blocks, at least at this time.
• At a later point we may implement an Auto-cleanup mode #119 or more intelligent cleanup algorithm that preserves a grid layout.
• Auto-applying the cleanup algorithm would be the last feature to add, and might need to be a user option.

Our reasoning:

• As much as possible, we're going to start by matching the behaviour for sighted users. That makes it easier to implement interoperability between keyboard and mouse.
• Kids already handle overlapping blocks, are annoyed by them--or completely unbothered--and have ways to organize them.
• Not auto-rearranging blocks means the user has fewer side effects to predict during a drag.
• The "correct" cleanup behaviour may be app-dependent or screen-size dependent.

[rachel-fenichel]

Summary of discussions between micro:bit and Blockly on November 12-13, 2024:

We will make it possible for a user to iterate through all top-level blocks and stacks in an order that somehow maps to the order on the screen (currently it appears to use the order in which the blocks were placed on the workspace).

We will also implement search functionality. The user will be able to search by text on the block and jump the cursor to locations found by searching.

The workspace search plugin is a proof-of-concept for this search functionality. It will obviously need better rendering, likely by moving selection and/or focus to the block that was found and then applying standard selection/focus rendering.