Fundamental design concerns

I played around with the demo for a while, and I have some thoughts. (Paraphrasing my messages on Discord)

In my opinion it’s absolutely critical for a blocks interface to be intuitively obvious, super accessible to new programmers, establish a clear and consistent mental model, and be as simple as possible while still powerful. This blocks interface isn’t really any of these at the moment unfortunately? There’s like thousands of blocks with unclear code based names, a ui so complicated it needs a tutorial(????), no way for students to intuitively learn how to do things other than reading the docs, since you’re using the base Blockly theme you don’t have any of the intuitive typing of Scratch that everyone’s used to (this one isn’t your fault the default Blockly theme is insanely cooked I don’t know how they made it as bad as they did), and there’s so much unnecessary and complex stuff going on (two tab bars?? mechanism support??).
Like I feel bad being super critical because you guys clearly worked hard on it, but I'm struggling to understand who this is for?
For comparison, making a basic auto in spike prime that drives around a corner takes 15 seconds and an 8 year old with no programming experience can do it:

I spent like ten minutes poking around in this blocks interface and I genuinely couldn’t figure out how to do any of this even with all of my programming background…defining a motor you can use is far too many steps, there’s no clear way to group motors together or make a drivetrain, there’s no clear way to drive for a distance or for rotations, there’s no clear way to wait for 5 seconds.

Also, Scratch and Spike Prime teach async trigger based event programming in such an intuitive way that I struggle to make my Spike Prime summer camp kids do it with a loop. The event blocks, “when sensor sees red” and all of that would make it so simple and obvious how to make a teleop. The LEGO Mindstorms app even includes gamepad support defined this way!

To get a better point of comparison, PLEASE play around with Scratch and Spike Prime, even if you don't have any hardware for it. They are ridiculously intuitive for so much and even express commandsv3 style events and triggers honestly better than any text based programming language I’ve ever used. Scratch taught me so much about coding just from me playing around in it and learning from quick experiments. The Scratch Design Principles are also an amazing read.

Some examples of more direct issues I have:

The naming of blocks in this interface was seemingly designed to be as similar to the Python ones as possible. While this could theoretically make the transition from Blocks to Python easier, it comes at the cost of making learning Blocks for the first time just as hard as learning Python, at which point there's no real reason to use Blocks. It also makes transitioning from Spike Prime to SystemCore much harder for no reason; it would be much better to keep the Systemcore blocks interface as similar to Scratch and Spike Prime as possible, allowing you to reuse all of their super optimized and tested well-thought-out design decisions and make things much easier for students with previous experience with those languages.

The blocks interface seems to require a huge amount of prior knowledge about the system to be usable. In my opinion, no blocks interface should ever require opening any docs. It should be fully understandable to someone who's never programmed before in their life. For example, the concepts of Mechanisms, OpMode init and periodic, hidden opmodes, and errors, are all totally unnecessary complexity that should be either completely removed or hidden behind an extensions option like Spike Prime. I think the biggest indicator of this is the tutorial; the UI needs to be really obvious and intuitive to use on its own, without one. (For example, in Spike Prime the deploy/start button is separated from everything else in the bottom right and in its own color to make it really clear what it does.)

Many of these issues are also visible in the FTC blocks interface, and is why I encounter a lot of teams extremely confused by it.

I expect a lot of these problems to be difficult to properly address without a complete rewrite, unfortunately. I started some initial work on a handwritten one at https://github.com/j5155/SCBlocks2, and Graham vibecoded a prototype that showcases a lot of these ideas here.

The issue names no repository files, tests, or entry points. Start by using the current blocks interface and compare its workflows with Scratch and Spike Prime, as requested; the issue does not define a concrete scope or measurable “done” state for the proposed redesign.