Open ewpatton opened 4 years ago
In the long run, as the number of blocks and functionalities tend to grow, would it be plausible to introduce some option to hide certain options from blocks as well?
For example, in the is number?
block, we could hide Base 10?
, Hexadecimal?
, Binary
choices, but keep the number?
choice, as it is far more straight forward and simpler.
@elatoskinas That sounds reasonable. The design therefore needs to be able to specify not only groups of blocks but groups of blocks and optional field values. The technical design is going to need some work and we'll also need to think about how to best present these to the user.
We would possibly also want to not affect the current users of AI, so it's a bit less confusing for people already familiar with the current set of blocks. Maybe in the initial step of the user registering it would make sense to prompt them with a dialog that asks them on their familiarity/experience with coding/development/apps in general and adjust the mode based on that?
I also know of blocks editors that have a "level" menu above the toolbox, to allow people to easily switch between complexity levels. This can be useful because people often have trouble judging their own ability, and may pick the wrong option on startup. This also makes switching to the advanced option more discoverable.
OzoBlockly is a good example, where they have 5 different levels of blocks with different complexity. AppInventor probably doesn't want to do exactly that, but I just wanted to mention mode switching as an option. Even two tabs like "Starter" and "Advanced" might work.
Describe the desired feature
In order to reduce the blocks clutter, provide groups of advanced blocks that are disabled by default but can be enabled by the user. This could be added to the new Settings menu. Include an option to "enable all" for advanced users.
Give an example of how this feature would be used
@halatmit raised a concern that the number of blocks is becoming too overwhelming for new users and we should have a means of controlling the scope of what blocks are seen by new users.
Why doesn't the current App Inventor system address this use case?
The closest thing we have is BlocksToolkit, which is a per-project filter on blocks. For most users, they may not need many of the blocks.
Why is this feature beneficial to App Inventor's educational mission?
Given that we are focused on education, having too many blocks can be overwhelming to new users and by reducing the number of options we create a more approachable interface.