What is *your* opinion about helper blocks in App Inventor? (GSoC Project - User Feedback)

[BeksOmega]

Hello! I’m Beka, one of the students working on Google Summer of Code, and I’m hoping to gather some opinions about my project for this summer.

Short and Sweet Description

The goal of the project is to replace documented constants within the AI blocks editor with dropdown blocks.

These dropdowns would be shadow blocks, a new addition to App Inventor which makes the blocks editor more convenient. There would also be a way to access the non-shadow versions of these blocks, so that users could (for example) use them to assign a value to a variable.

Extension developers would be able to define their own versions of these blocks by extending the IDropdown interface and providing Java annotations in their components.

Giving Feedback

The App Inventor team and I have worked together to create a Design Document that outlines what we want to build, and how we want to build it. There are sections for:

• Users of App Inventor
• Extension Developers
• Open Source Contributors

But do not feel limited to “your” section! If you have an opinion about something always feel free to share it.

Each section includes an “Open Questions” sub-section. This is meant to stimulate discussion, and help us finalize the design. If you are looking to participate, but are not sure how, this is a great place to start!

But remember that just because you leave feedback does not mean that it will go into the finalized design. The maintainers at MIT always have the final say about what goes in. This is just away to explore your cool ideas

Feel free to leave your comments here, on the doc, or message me (BeksOmega) directly!

Other Info

I’ll probably leave this open until about Friday May 22nd (one week from posting), so be sure to get your feedback in before then!

I’d also like to note that this design is heavily influenced by the previous work done by ewpatton and vishwas.

So a big shout out to them!

And a big shoutout to anyone who participates in the discussion! We really believe that feedback creates better designs, so thank you guys for taking the time

[BeksOmega]

Hello! I just wanted to give this a little bump for people that might have missed it amid the weekend rush =)

We very much appreciate the feedback we’ve gotten so far, and look forward to hearing more!

[Susan_Lane]

Hey there!

I haven’t tracked all the existing conversation on the document, but I’m replying here to see if we can get some conversation going on the thread. Conversations in document comments can get unwieldy :).

I’m not sure I understand what the user experience will be like. “Shadow blocks” is the term for the way the blocks are presented, but not the terminology that will be presented to the user, correct? These are enumeration constants for specific components, and it seems to me that the educational goal of App Inventor is best served if the user can learn something about the general working of software development through discovering and using them.

The bit about custom property editors seems like it better falls under @pavi2410’s project. Right now, custom property editors cannot be built as part of an extension. We ought to have a conversation about whether we want extensions to have that capability and, if so, wrap it into that project.

[BeksOmega]

@Susan_Lane

I’m replying here to see if we can get some conversation going on the thread. Conversations in document comments can get unwieldy

Hehe I feel you there! Thank you for taking the time to reply

@Susan_Lane

“Shadow blocks” is the term for the way the blocks are presented, but not the terminology that will be presented to the user, correct?

Yes, the term "shadow blocks" shouldn't be anywhere in the user-facing documentation. For users they'll probably see things described as "Options" or "Enums".

@Susan_Lane

it seems to me that the educational goal of App Inventor is best served if the user can learn something about the general working of software development through discovering and using them.

Could you elaborate on this point a bit more? I definitely agree! I just want to know kind of how you're envisioning this.

@Susan_Lane

The bit about custom property editors seems like it better falls under @pavi2410’s project.

Absolutely agree! That was essentially just a note to myself to say "hey, these annotations might be useful for other stuffs in the future, so keep that in mind!" I think @pavi2410 is definitely better equiped to take that on hehe.

@Susan_Lane

We ought to have a conversation about whether we want extensions to have that capability and, if so, wrap it into that project.

I think that extensions should definitely have this ability (but I don't want to push @pavi2410 into taking that on right now though). I think being able to provide custom (to some extent) and intuitive interfaces will make extensions much more powerful. But @pavi2410 told me they might already have some ideas, so I won't push it anymore right now hehe

Thank you again for your reply! All opinions are very much appreciated

[Peter]

Hi Beka,

I like your proposal very much. I liked already the proposal from @vishwas in October so i would choose option 3.

Since the main focus of App Inventor is still, and i guess always will be, a learning tool, we have to make it as easy as possible for users to learn how to make code blocks.

If that is your starting point it is easy to decide that

Is better then

.

We see this behaviour also in languages as Scratch

What i also would like to see and that is also possible i guess in this proposal is the use of an Asset block.

Now users have to type filenames, sometimes very long.

With all the typing mistakes that are possible.

So this way it would be much easier to use the assets. With the font used it would look like this.

Just my 2 cents on a great proposal

[Point]

Great idea!
When do you think it will be ready?

[Diego]

I haven’t checked the entire document yet (but I will surely do by Friday), but I see a drawback in that “Assets.sth” block that Peter is proposing: what will happen with apps that have a large number of assets?
I think those apps cannot benefit from that block, because the selector dropdown list is going to be so big that it will be really hard to find an asset, and will take even more time than rather writing the asset name.

And also, you are kinda restricting the assets that can be used. The user can actually download assets from the Internet, and display them later from a local path using the text block (as seen here, although @Taifun might want to update that page as the limit has been increased). I just think it may be confusing for some users as it may seem like you can only use the assets in that list.

[ewpatton]

@Diego

I think those apps cannot benefit from that block, because the selector dropdown list is going to be so big that it will be really hard to find an asset, and will take even more time than rather writing the asset name.

Potentially, we could make it so that dropdowns are also filterable, so that one could type in the name and have the list filter only those that match, similar to how Typeblocking or the component search feature works.

@Diego

The user can actually download assets from the Internet, and display them later from a local path using the text block

Technically, these are not assets as defined by Android as assets are packaged into the APK. The addition of the asset block wouldn't preclude using paths to files in the file system, but would make referencing assets App Inventor is aware of at design time easier to use.

[ewpatton]

@BeksOmega

@Susan_Lane

it seems to me that the educational goal of App Inventor is best served if the user can learn something about the general working of software development through discovering and using them.

Could you elaborate on this point a bit more? I definitely agree! I just want to know kind of how you’re envisioning this.

I can't speak for Susan, but one thing I can imagine here is if we provide people the blocks to define their own enums for use in their projects. As an example, @Selim_Tezel created a rock-paper-scissors app for our AI curriculum with numbers to represent rock, paper, or scissors. Use of an enum would have been ideal here since it's a closed set.

[Diego]

@ewpatton

Technically, these are not assets as defined by Android as assets are packaged into the APK. The addition of the asset block wouldn’t preclude using paths to files in the file system, but would make referencing assets App Inventor is aware of at design time easier to use.

I know, but I was thinking about the case of an Image, when using the SetPicture method. It may cause confusion, as some users might think they can only use the Assets block to set it.

[SteveJG]

@ewpatton

Potentially, we could make it so that dropdowns are also filterable, so that one could type in the name and have the list filter only those that match, similar to how Typeblocking or the component search feature works.

This is supposed to make things simpler? More confusing in my mind. I agree with Diego... leave the assets alone please. In addition to being simple, programmers need to learn to spell, to proofread etc. ... those skills are valuable too and typing in the values should make the developers aware of what they are doing instead of mindless copying.

-- Steve

[ewpatton]

@SteveJG

leave the assets alone please. In addition to being simple, programmers need to learn to spell, to proofread etc.

This doesn't prevent more advanced users such as yourself from using strings to assign an asset. It just provides an alternative. Yes, people need to learn to spell, but my intuition here is that the frustration of having something not work due to a typo is probably more detrimental to someone learning to code with App Inventor than making use of a dropdown that ensures a correct value. For example, in the designer we don't have people type the name in, we give them a list to select from. I don't see this as being any different.

[ewpatton]

@Diego

some users might think they can only use the Assets block to set it.

It seems like this would only be the case if the shadow block was provided. Currently, with an empty socket, there's no expectation that is the case. I don't think we'd use the asset shadow block here, since it can take any string, not just assets. I imagine that we would have the assets block be the same color as the text block since it internally converts to a string with the name anyway.

[Peter]

@ewpatton

but my intuition here is that the frustration of having something not work due to a typo is probably more detrimental to someone learning to code with App Inventor than making use of a dropdown that ensures a correct value.

This is exactly what i was thinking of when i made my post. See also the below quote from the AI website.

The MIT App Inventor project seeks to democratize software development by empowering all people, especially young people, to move from technology consumption to technology creation.

So in the beginning the block i propose can have its benefits when learning AI and in the long run users will have the choice not to use the block and just opt for a textbox.

[SteveJG]

@ewpatton

This doesn’t prevent more advanced users such as yourself from using strings to assign an asset. It just provides an alternative. Yes, people need to learn to spell, but my intuition here is that the frustration of having something not work due to a typo is probably more detrimental to someone learning to code with App Inventor than making use of a dropdown that ensures a correct value. For example, in the designer we don’t have people type the name in, we give them a list to select from. I don’t see this as being any different.

Beka indicated it will not be possible to turn off the shadow blocks. What you suggest is another layer of complexity. It sounds like you have already decided.

[Susan_Lane]

@ewpatton

I can’t speak for Susan, but one thing I can imagine here is if we provide people the blocks to define their own enums for use in their projects. As an example, @Selim_Tezel created a rock-paper-scissors app for our AI curriculum with numbers to represent rock, paper, or scissors. Use of an enum would have been ideal here since it’s a closed set.

This expresses what I was thinking more clearly.

The shadow blocks concept seemed to make component constants look like something distinct from any old constant/enum. To follow the goal of building software skills that apply outside of App Inventor, it seems to me that they should be presented in a way that connects them with the broader concepts of constants and enums.

I agree with @Peter and prefer option 3, where enums are presented as [Component].[enum-dropdown]. This is close to the way enums are presented in many text languages, but still makes good use of the strength of using blocks.

In addition, as @ewpatton, the capability for a user to define enums that look visually the same/similar to the component constants would help make the connection. That could be additional work after this project.

[ewpatton]

@SteveJG

It sounds like you have already decided.

I haven't decided anything. My understanding from looking at how shadow blocks work in Blockly is that it shouldn't be hard for @BeksOmega to produce a version with a flag that would let us test this both with and without shadow blocks. Then we can make a decision about the use of shadow blocks in App Inventor.

[BeksOmega]

Wow this is really exciting! It's great to see all of the conversation happening.

@Peter

i would choose option 3.

Good to hear! It seems like there's still quite a bit of contension about what option to go with. So it's great to hear more opinions

What i also would like to see and that is also possible i guess in this proposal is the use of an Asset block.

To respond to this and all of the related discussion: I think this is a cool idea! In my mind one of the many benefits of a block based language is the ability to elliminate syntax errors (like spelling mistakes). So I think this would definitely be something worth investigating!

But this looks like one of the blocks that would require a different UI solution. As @ewpatton mentioned we would probably want to add a way to filter dropdowns before we implemented this block. That would take some time to get working, so I don't think it will be included as part of the first-pass on this project.

I have added this to my list of Further Work to investigate after the initial project is done. Here's the link to that list (since I'm mentioning it so much I want people to know it actually exists hehe).

@Peter

Just my 2 cents on a great proposal

Thank you for your great feedback

@Point

Great idea!
When do you think it will be ready?

Hi @Point, thank you for asking! This is a Google Summer of Code project so I'm hoping it will be ready by the August 24th deadline. I'm pretty confident at the moment, but I haven't started coding yet so we'll see hehe

@SteveJG

Beka indicated it will not be possible to turn off the shadow blocks. What you suggest is another layer of complexity. It sounds like you have already decided.

If we go with the shadow blocks option I don't /think/ this should be an issue. One of the many great things about shadows is that you can drag solid blocks over them:

This makes it easy for you to use string constants (rather than dropdowns) if that's what you prefer.

The only reason I said we /probably/ wouldn't include a flag is because there's nothing stopping you from using constants.

But if we do decide a flag would be helpful I'm all up for that Thinking about it now I should only need a check in one or two places... so it shouldn't be difficult to add

Thank you for bringing up your concerns!

@Susan_Lane

option 3, where enums are presented as [Component].[enum-dropdown]. This is close to the way enums are presented in many text languages, but still makes good use of the strength of using blocks.

That's a good point about it being similar to other languages! I have to admit I'm still kind of leaning towards option 1 or 2 (just cuz I looove that clean interface) but I definitely see how opt 3 may better support AI's educational goals.

@Susan_Lane

the capability for a user to define enums that look visually the same/similar to the component constants would help make the connection. That could be additional work after this project.

I definitely agree with what you and @ewpatton are saying. I think that allowing users to define their own enums would be a great way to help them learn about them. That would require a /whole/ lot more UI and designing though, so I'm going to put that on the "Futher Work" list hehe

---

Thank you guys so much for continuing the discussion! I really appreciate all of the feedback

[ABG]

Coming from the data side, I see some possibilities of using enums to hang a schema off dictionaries, if the schema is coming from the Designer.

That would tighten up the loose tag possibilities in dictionaries that are intended to be used as objects (tag = attribute name) as opposed to filing cabinets (tag = autonumber key.)

This is probably wildly out of scope.

[BeksOmega]

@ABG

I see some possibilities of using enums to hang a schema off dictionaries, if the schema is coming from the Designer.

Hi! That sounds interesting, but I'm not exactly sure what you mean. I'm familiar with Blockly but I'm still pretty much a newbie when it comes to App Inventor specific stuff hehe. Would you mind explaining it a bit more for me?

Thank you for your reply!