I’m designing an UI for adding blocks in visual pr...
# thinking-together
j
I’m designing an UI for adding blocks in visual programming (similar to Scratch) without having to drag-and-drop, and wondering if there are any good ideas in other tools. Any block or outline UI:s for visual programming that handle keyboard navigation and/or focus caret (edit point) well?
👀 1
“Semantic Editors” here are maybe somewhat related (Hazel, Syntactor, Fructure), even though they are not based on blocks. https://github.com/pel-daniel/mind-bicycles
j
The Fructure approach would be very interesting for a block editor. 👍🏻
👍 1
g
IMO: Emacs’ mark and point 1. set cursor, click key, graphical object appears at cursor 2. set mark, set cursor, click key, graphical object appears between mark and point (I like to think that every operation must be bound to a keystroke. A mouse requires a whole hand, a keyboard allows the use of 10 fingers.)
👍 1
1
j
Blockly Developer Tools is an eat-your-own-dogfood method of generating block definitions using a block interface, and Blockly supports a rudimentary keyboard navigation.
👍 1
Blockly generally has an approach to variables and functions where you declare them, and then they become new blocks in the interface. I'm using a similar approach in Blawx for categories, objects, and attributes.
j
Keyboard control of block-based programming is a really interesting direction. I haven't seen it done before. With structure editors modeled after textual code (Hazel / Fructure / Lamdu), there's a clear target of "make keyboard interaction emulate keyboard interaction with text". Your situation feels more open-ended. You might want to look into how spreadsheets handle keyboard navigation. Or what @Glen Chiacchieri's done with his latest Flowsheets demo, linked to from https://twitter.com/Glench/status/1488185413516857347.
👍 1
j
@jaukia, I've been thinking about this problem a little, today, and I have an idea. The blocks in Blockly all have a default textual representation. You could build a blockly plugin that allows the user to type, but everything is auto-completed to the text representation of the blocks that are currently available, so you can't type anything that doesn't generate blocks. new line creates a new block in the current stack, increasing and decreasing the indent moves the cursor in and out of stacks and fields. You could also allow the blocks to define their own alternative name for use in the auto-complete field, so you could type "rule", and you would auto-complete to "when we know _ we also know ___". Whatever you have currently entered shows up on a scratch-pad. Hit enter twice in a row, and whatever you currently have (including spaces you haven't filled in the text version) gets dropped onto the workspace for you. Targetting is hard, so to start I would say put the first one in the middle of the workspace, and if the user continues to type without scrolling, put subsequent entries below that one. I think that could work, and I think it could be written in such a way that it would work for anyone using Blockly, not just for a particular block set, as long as the blocks all have text on them. But it might be a good idea to add details to the block definitions for how the text version should read, since internal inputs and fields can be named pretty arcanely. I think it would be a really smart way to combat the "visual programming is not for experts" nonsense.
👍 1
Actually, that's such a cool feature idea, I'm adding it to my backlog.
👍 1
w
With Scratch, I thought at first that dragging blocks would be tedious in a way that it mostly isn't. Fairly standard code completion techniques may play well with a block language: just show me what blocks would likely fit here. Two other surprisingly nice Scratch things: (1) you can change the selector popups for blocks in your well, giving them more of a tool/template feel, (2) double clicking on lone groups of blocks in the middle of your workspace executes them. Now I'm reminded of Acme's middle click to execute code.
👍 1
j
Yeah, I get a lot of pushback from "traditional programmers" about the downsides of the visual syntax. But the fact of the matter is that I can type, and I don't hate using it. Pair programming, mob programming, code review, all of these are attempts to increase the ratio of thinking to typing, so going slower may not be a bad thing.
What I do find tedious is how difficult it is to navigate your code. Line-wrapping means that text has a fixed width, and there are lots of good methods for page-up, page-down, etc. The same don't exist in the visual interfaces I've used.
I didn't know about the double-click feature in Scratch, that's cool. I might add it to question blocks in Blawx. Thanks for the tip!
w
Keep in mind that traditional programmers are relatively good at what traditional programming entails. Many other people take one look at that and back away... slowly.
j
Thanks for all of the comments and ideas! I did a bit further research on this and had a look at automation tools as well, such as PowerAutomate and Automation Anywhere. They have some similarities with Scratch and Blockly. What was interesting with automation tools was the there is a stateful selection / edit point for the blocks, which you can move up/down with the keyboard arrows. Then, you can double-click on blocks from the sidebar to add them after the edit point (or inside containers, such as loops and if-statements). When there is no selection / edit point, new blocks are added after the last ones. Something like this could be a quite nice “power-user” feature for block editors as well: if you have a block selected in the canvas, you could double-click on blocks in the side bar to add them to the correct place in the canvas.
n
I believe Scratch's double-click to run originally came from Smalltalk's DoIt (select some text, right click to get popup menu, and run DoIt to execute)
👍 1