Current location visualization

[BeksOmega]

The "cursor" is where the user currently "is" in the workspace.

For the cursor to work well it will need to fulfill a bunch of requirements, here is a draft list (there may be unnecessary or missing things):

1. It should be easy for people with low vision (e.g. Maria persona) to locate.
2. It should indicate which blocks will be deleted if you trigger the delete action.
3. It should indicate which blocks will be copied if you trigger the copy action.
4. It should indicate where blocks will be inserted if you trigger the paste action.
5. It should indicate which fields will be edited if you trigger the edit action.

Currently we have options for the cursor to outline the top and sides of the block, which indicates the blocks will be pasted at the top. (The cursor flashes to make it easier to locate)

And to put a bubble around fields:

Is this the best option? What are other ways we could handle this?

[rachel-fenichel]

One confusing part is that the cursor currently surrounds an entire stack of blocks when it really only has selected the first block. In this image there is a "draw" block with a stack of three blocks inside. The selection is on the first block ("set stroke color to"), but it surrounds all three blocks.

This is a bug in the rendering code rather than an intentional decision.

[BeksOmega]

There is an extra complication I should have included in the original post! Some applications treat actions on the selected block differently than other applications.

E.g. by default in Blockly copy operations only serialize the directly selected block, however in Scratch it copies the whole stack (e.g. the block and following children). So in some situations this is the correct visualization of what the action will be applied to.

It's unclear to me whether the correct thing to do is change the visualization, or to make the actions consistent.

[kmcnaught]

Yes, this is inconsistent in different places, but I'd argue it's the visualisation that is "most wrong" and we should work to make the actions consistent.

In the micro:bit MakeCode editor:

• The currently-selected block is visually identified
• All these actions apply to one block:
  • Delete key
  • Ctrl+C, Ctrl+X, Ctrl+V
  • Right click -> duplicate, comment, or delete blocks
• Mouse drag applies to the whole stack

In Scratch:

• The currently selected block is not visually identifiable, but is selected
• The following actions apply to the "current" block:
  • Delete key
  • Ctrl+X deletes one block but puts the whole stack in the clipboard (?!)
  • Right click -> Comment, or Delete
• The following actions apply to the stack:
  • Ctrl+C
  • Ctrl+V after a Ctrl+C/X
  • Mouse drag
  • Right click -> duplicate

In the current Blockly keyboard nav prototype:

• The visual indicator shows the stack (current block + any below it)
• These actions affect the single block:
  • Delete key
  • Ctrl C/X/V
• Mouse drag applies to the stack.

Are there other actions I'm missing, or popular editors we should cross reference with?

Personally I think it would be best to make a set of consistent actions most appropriate for keyboard-based UX, and let other applications increase the scope for other interaction methods if they want to. I think that it would be clearest to start from a place of all actions affecting a single block, and allowing Shift-selection for more blocks, or potentially shortcuts to include a whole stack. I would imagine this would also be simpler to communicate to a screen reader, as it follows standard conventions for line-based editing.

[rachel-fenichel]

There are also visualizations of three different "current locations" right now:

1. Where the cursor is. This moves around with the navigation keys, and is shown above.
2. Where the marker is. A marker is a special cursor that can be associated with a connection or block. This lets the user mark a location as a target for insertion, then open the toolbox to select a block to be inserted.
3. Where the mouse selection is. Clicking on a block gives it a yellow stroke as a highlight. This can be disconnected from where the navigation cursor is, but I think that clicking on a block should jump the navigation cursor to that block.

[cpcallen]

I was going to suggest that the cursor and the mouse selection should use the same visualisation, but upon reflection I don't think that's true—but I do think the marker and the mouse selection should use the same visualisation.

Moreover, I think we should typically have the selection follow the cursor, so the cursor can be a slightly less prominent indicator. If we were to implement multiselect then the overall effect would be very much like a in a spreadsheet, where the current cell is normally selected, you can select multiple cells, and when there are multiple selected cells one of them still is designated as the current cell within the selection. (Though in our case we might want the cursor to be able to travel outside the selection—certainly to the toolbox/flyout, perhaps to other parts of the main workspace.)

[kmcnaught]

What's preventing the cursor and the mouse selection being one and the same? i.e. clicking a block with the mouse puts the keyboard focus there too, and moving the cursor with key navigation moves the equivalent mouse selection. This is what I'd expect, particularly in the scenario where someone is using a combination of mouse and keyboard control. Are you picturing some kind of workflow where mouse selection is used like a marker?

[microbit-lucy]

I definitely agree with your suggestion @kmcnaught if that's possible. That also mirrors behaviour in a spreadsheet - you can move around cells with the arrow keys or jump with a mouse there is only ever one current location based on the most recent action.

[microbit-lucy]

Also, there can be a 4th "current location" which is the position in the web page if the users presses the tab key. It would be good to unify that position too so that there is only one (with a possible 'marker' point separately only). Is that possible?

[rachel-fenichel]

As currently rendered, the cursor grays out/de-emphasizes the current block. Should we flip that, so that the current block is emphasized and all other blocks are slightly grayed out?

[microbit-lucy]

If we can unify the mouse selection and keyboard selection (as described above), then I think we should stick to the yellow highlight used by mouse selection currently for everything.

This would mean it is most familiar and that the many educational materials that show the user what is selected will not need updating and will be appropriate for mouse, keyboard or mixed users. I also think this is more visually prominent that the greyed out look and offers better contract. I suspect the colour contrast on this greyed out version would be too low to pass AA WCAG compliance but I haven't checked that.