The interface designer in me immediately wants to scream "Fitt's Law!"¹ and move the header with run/select/save from above the output to between the output and the code blocks though.
EDIT: Actually, Fitt's Law tells us not to do that. But scrolling to find those buttons is also wrong. Why not make it a sticky header?
I remember getting into a discussion on Reddit where someone claimed tagging on to a bus was faster by pressing the card right up against the card reader. Always felt like an abuse / misinterpretation of fits law to me.
If I understand your sentence correctly it's a bit of an edge-case (pun not intended).
When designing interfaces for a screen, the edges (assuming that moving the mouse to the edge doesn't cause scrolling) can be considered "infinitely" wide or tall for the purpose of Fitt's law. This is a really old insight:
Pressing your card against the card reader is the same idea: you don't have to be precise with your motor functions, because as soon as you hit the card reader you know you're close enough. So people can be faster with this approach.
(with that in mind, my earlier solution is actually wrong: the buttons shouldn't be put between the output and the code, they should be made sticky)
I wouldn't know, I never took them. However, looking at the "people behind" page¹ I can say that they have an impressive list of well-known experts in the field there. So at the very least they have that going for them.
I'm really curious if this could be used for people who need to write code but aren't trained for it or because it's not their job. A lot of people are not willing to learn coding, and I really feel there are possible effort to make it more simple.
The first thing that scare those people is the whole "plain text" thing. Spelling errors in programming are not forgiving and that's the first thing learners have trouble with.
One example that comes to mind is science. There often is data to process, and excel can obviously do many things, but I'm really confident that more could be done.
Programming feels like something that is often done by experts, but it really really doesn't have to.
Of course, programmers often disagree that beginners should be given tools to replace experts programmers, but it's still better to have someone who can do the job of a programmer.
I've had some success teaching workshops to adults who aren't familiar with programming for the product I use it on. A lot of them are able to really grasp how to get things done within a session, but figuring out more advanced things (e.g. loops, functions, dictionaries) is still somewhat clunky.
Exactly - it still takes a programming mindset. In my experience watching people using Scratch et. al. When ppl start to acquire that mindset, the guardrails of visual programming turn into hurdles.
I've been using this and a custom React wrapper at work to build an automation tool for legacy Windows apps with a lot of success: https://etacautomation.com
Blockly is vanilla JS and very easy to extend as needed (I added a better type system, for example), and their new plugin system is super helpful. Its performance isn't quite there, but I have high hopes for the future with the changes I've seen so far. The devs have been wonderful to work with, too.
One thing I love about blocky vs scratch is that it outputs regular code, in several languages. This means you can use it as "guard rails" up until you understand the concepts, then start using the generated language when you need more. It's also a DSL, in the sense that you can generate regular code from any blocks you make, at any level of the code flow, and you can mix that with already-made blocks for your target language. I started work on a Minecraft bot/mod tool that outputs JavaScript, for example, and added the full API (that is available in JavaScript code) so if you feel limited by the the blocks, you can just focus on the code. I stopped working on it, because the library it depends on to interact with Minecraft stagnated (and got really out of date with Minecraft versions) but a similar approach could be applied to pretty much anything. https://github.com/konsumer/botmodblock
I used that blockly maze to teach kids at my son's primary school some programming. It starts out simple, and then you progress through loops, conditions, and eventually they have to implement a real wall-following algorithm.
I had 3 students at a time so I could help them a lot, which some kids definitely needed. But some didn't, and came up with some really interesting algorithms.
I've just spent half an hour searching through my saved contalks folder trying to find a talk from (I think) last year where a someone talks about their new compiler research regarding block-based languages, specifically to make it easy to design and implement custom block based languages. Does this ring a bell with anyone?
BlocklySQL: A new block-based editor for SQL - https://news.ycombinator.com/item?id=25517043 - Dec 2020 (38 comments)
Blockly is a library for building visual programming editors - https://news.ycombinator.com/item?id=10763057 - Dec 2015 (40 comments)
Google Blockly is a library for building visual programming editors - https://news.ycombinator.com/item?id=9987641 - Aug 2015 (1 comment)
Google's Blockly Games - https://news.ycombinator.com/item?id=8211031 - Aug 2014 (18 comments)
Google Blockly - a visual programming language - https://news.ycombinator.com/item?id=4050426 - May 2012 (123 comments)