Hello everyone, I created this post to showcase/discuss ideas for improving App Inventor. Especially for larger projects, development can be quite challenging. I will update this list from time to time. I acknowledge that some of the ideas rank low in importance as they are less relevant for the educational use of App Inventor.
1 Improve Data Handling
Most of the apps I created are data-driven and using web APIs has always been painful. Luckily, the team is already working on dictionaries which would improve the experience with JSON drastically. The setup of a web DB takes too much steps, including fiddling with API keys (at least for Firebase, I don't know if that is also the case for CloudDB). Also what about the ideas in http://cs.wellesley.edu/~tinkerblocks/KimThesis.pdf?
2 Blocks Workspace Improvements
Handling hundreds of blocks can be quite difficult. Optimizing inline inputs and collapsing blocks manually can help a bit to overcome this. Speaking of; I just found out that you can collapse blocks by double-clicking. How did I miss this in the last years? Sub-workspaces, as described in http://cs.wellesley.edu/~tinkerblocks/LuThesis.pdf could solve this issue. Another idea would take advantage of the already existing procedure blocks. I would like to be able to send a set of procedures to another person or project. I know that the backpack can do parts of that, but I think it could be improved. I like the idea of coding a sort function once and then sending it to anyone who needs it or just pasting it into the project
3 Usability Improvements
Please simplify the width and height settings. Changing these settings takes three clicks, which is not very user-friendly. Uploading multiple files could potentially be fixed during this year's GSoC. Additionally, see the suggestions@actech pointed out
4 Extension Improvements
Improving the extensions API is quite difficult, but can help a lot because others can add features that are not existent in AI. Adding visible components and build-in blocks with extensions are in the call for GSoC 2020
Dictionaries is now out, so please give us feedback on it. Regarding API keys, this is partly just an issue of the complexity of having distributed systems. For the built in Firebase and CloudDB components, if people use the MIT ones then everything is automatically generated. Once people grow beyond what we provide, it will inevitably require them to do more work (SAAS companies want their money after all).
2. Blocks Workspace Improvements
The double click feature was added a few releases back (I think I added it in response to a request by @Anke).
I'm working with @Franklyn_A_Turbak to get this into App Inventor. It was implemented quite a while ago and made some substantial changes to Blockly at the time, so part of this is just accounting for all of the structural changes to Blockly over the years (and hopefully keep it from being a merge nightmare in the future).
We also have the capability to download a block stack as a PNG with the embedded Blockly code. You can then drag these PNG files back into App Inventor. For example, I use this for blocks images that I post on this forum, and so you can drag block images from my posts into App Inventor. When combined with Folders, it will be an extremely powerful tool for code sharing.
3. Usability Improvements
I also have a prototype of drag and drop that allows for multiple file upload. There are still a few issues with it but I also expect that this will greatly help with the usability (it also supports project and extension import).
4. Extension Improvements
This will ultimately come down to whether we get a qualified student with a good proposal for GSOC.
AI2 iOS publishing is non-existent. There has yet to be even a single AI2 successfully published to the Apple Store. Before moving fwd with AI2 in anyway this has got to change
We also have the capability to download a block stack as a PNG with the embedded Blockly code.
Evan, this is great!!! Recently, I was thinking that the inability to copy blocks from images with examples is one of the main drawbacks of visually block programming, but you solved this problem!
Regarding Usability: The ability to select multiple components which was introduced in nb181 is indeed a very useful feature. I just discovered this because for me it is necessary to ctr-click them instead of shift-clicking them
When doing more complicated projects, I always end up implementing the same code. Missing blocks, e.g. select last list item, sort list, shuffle list, startsWith and standard procedures like ask for all permissions are often needed in my projects. Currently, I either have to copy the blocks png manually or write an extension for these blocks. What I would like to have is a function similiar to the BlocksToolkit, where I can set another project as a filter. I would like to use a project only consisting of these often used blocks as an input and get all the functions in my project, but not their definitions. The function definitions are hidden from the user, but the functions are still accessible in the procedures category.
I think Folders will provide a good enough solution for this, whereby you can keep the set of common definitions in a folder in the backpack and just load it when you need it. Your proposed approach requires a lot of technical infrastructure because of the fact that projects are all independent from one another. We'd have to think about challenges like reference counting source files, etc. which we don't currently do (and Google's infrastructure isn't particularly good at since it doesn't support transactions involving multiple types).
The settings menu that was introduced recently only contains the Open Dyslexic and project autoload settings at the moment. It could be extended with default settings for theme, color, ShowListsAsJson, etc.