Consider moving to Scratch Blocks

Describe the desired feature Scratch developed its own version of Google Blockly, called Scratch Blocks. While it can't do everything that Blockly can, it is graphically superior and simplifies some of the concepts significantly.

I'm a teacher who teaches kids in both Scratch and App Inventor. I noticed that my students often complain about inconveniences in App Inventor's blocks that aren't a problem in Scratch.

Comparions of App Inventor and Scratch code

when this sprite clicked delete all of list, add thing to list

when Button1.Click do set global list to create empty list, add items to list list get global list item “thing”

repeat until a = 50 change a by 1

while test get global a < 50 do set global a to get global a + 1

insert item 1 of list at 2 of list

insert list item list get global list index 2 item select list item list get global list item 1

Pros of Scratch Blocks

better visuals (the screenshots here are actually from Kodular, not App Inventor whose colors are objectively worse)
the code reads like a sentence
they are more linear and easier to follow
numeric and string fields have a textbox (⇒ much faster workflow)
they don't blindly follow the structure of typed code, making certain constructs far more natural for the “block”-ed code
dragging a block back to the left panel deletes it (⇒ faster workflow)
they share the Blockly API (⇒ almost a drop-in replacement)

Cons of Scratch Blocks

they lack several advanced blocks of MIT AI, eg. dictionaries
the lack of „puzzle connections“ could make some complicated code look like spaghetti
they don't have mutators which is the only part where the workflow is worse than in Blockly

We will take this into consideration as we think about our UI refresh as part of our CoolThink project. However, I want to note that:

The App Inventor language is more sophisticated than Scratch, so design decisions that were made for Scratch may actively work against the use of Scratch blocks in App Inventor. We're also looking at adding new language constructs such as inline procedures for map-reduce style operations that as far as I know have no equivalent representation in Scratch.
App Inventor has a broader audience than Scratch as it includes people who use it to develop apps for their businesses, which are then published on the Google Play store. Making the interface more Scratch-like may discourage further engagement with those folks if it becomes too much "for children."

There is also a lot of existing curriculum content around App Inventor, which means that a change in the style of the blocks will require everyone to update screenshots. We still have people trying to use App Inventor 2 using blocks screenshots from App Inventor 1, and wondering where some of the blocks went more than 5 years after shutting down AI1. Significantly changing the blocks language means invalidating many years of existing work by our team and others. If anything, I expect that we will provide this as an option for people transitioning to App Inventor from Scratch, with the caveat that the corresponding blocks language may have fewer features, and let users choose the style that works best for them.

cc @SusanRatiLane

@kdclang @stezelMIT I'd also be curious what your thoughts are on this.

Hey @ewpatton, Thanks for your reply!

“[Scratch is simpler] so design decisions that were made for Scratch may actively work against the use of Scratch blocks in App Inventor.” In a mostly procedural-style code, I think Scratch Blocks will do much better than Blockly. How will Scratch Blocks deal with the spaghetti code that sometimes comes up in AppInventor, that is an open question. My guess is that it will be a little worse. However, since Scratch Blocks are designed to read naturally like a sentence, they may end up being more readable as well. I can help with making demos and proofs-of-concept in Scratch Blocks to help investigate this.

“We're also looking at adding [...] inline procedures [which] have no equivalent representation in Scratch.” I think this is a limitation of Scratch, not Scratch Blocks. “Native” inline procedures are already present in Scratch, so making custom ones shouldn't be a problem: letter (1) of (apple)

AppInventor shouldn't become too much “for children”. Agreed, but I don't think Scratch Blocks are inherently “for children”. I think that the modifications made in Scratch Blocks made them more convenient for both kids and adult programmers. I can make a set of showcases (screencaps, demos) of the things Scratch Blocks do better than Blockly, if you want. At the very least this could serve as an inspiration for the future AppInventor, even if it still uses Blockly.

“[A] change in the style of the blocks will require everyone to update screenshots. [...] Significantly changing the blocks language means invalidating many years of existing work” The changes I had in mind were mostly minor, quality-of-life changes. A code like this should still be quite easily rewritable from the screenshot below it: Especially if the keywords used in the block's fields are the same, eg.: Or even: However making the new blocks optional, at least for some time, sounds like a great idea.

I personally would love a smoother transition to App Inventor from Scratch but this may not be possible unless we have a beginner's version of App Inventor with less much components and with Scratch like blocks. However, I agree with all of Evan's concerns outlined above. Re-writing of old tutorials with a new UI is an on-going concern not just for us but other organizations that produced curricula around App Inventor. But even in our current development scheme we encounter needs to revisit and rewrite old curricula to match the new blocks, features etc.

One extra suggestion I have is to study Snap! (https://snap.berkeley.edu/) as its creator Jens Moenig (a dear former colleague, happy to introduce) already spent much time rethinking the Scratch interface to allow of advanced functionality such as procedures with return values etc. and all kinds of other stuff.

I agree with Evan's points. While Scratch is great for a particular audience, our 14 millions+ users are used to our syntax and are comfortable with it. The amount of work redoing all the screenshots in hundreds of documents/webpages to accommodate a change like this would be overwhelming.

mit-cml / appinventor-sources

Consider moving to Scratch Blocks #2186