Interesting graphic there @Arthur_Rallu … New Viewtype called “iframe”?
Thank you Koichi.
We are in the process of understanding more about the priority of the icons/options at this moment, labels are definitely an option, we just might need to prioritize some options in favor of others, as we offer too many buttons right now. Will keep this in mind, thank you again.
Is there any chance you would allow an Enterprise Account to opt in early at their own risk?
FWIW, the iFrame UX feature idea has a status of “Planned”.
@Arthur_Rallu , in my AppSheet account that has the new editor UI, the “With these inputs” property does not appear as expected for an “Execute an action on a set of rows” action whose “Referenced Action” property has selected an action that uses the INPUT function. The issue exists regardless of whether I switch the app editor to the legacy UI.
The exact same scenario indeed still works as expected in my AppSheet account that has not yet received the new editor UI:
@scott192 Good catch.
Hi everyone. This is my experience and opinion about the new changes.
First of all, I think this is so much easier and quicker to create apps than the previous version, but it has some bugs and parts I would change:
- The responsive of tables isn’t working properly, it should fill all my screen
- Format rules should be a tab next to views. It was complicated to me to find it
- A little bit more space for system generated views
- As it is on the Views section, I think that system generated actions should be separated from the created ones
- As someone have also posted, the most of the configuration of a bot is done on a minimum space on the screen. It doesn’t make sense
- when errors, we have can’t find quickly where it is. Something like this, would help: (Mark on red colour the table/view/whatever is wrong)
Thanks a lot for all your work and I hope my point of view is helpful
Thank you Guillermo,
I am happy to see that most of these are in-progress we will keep the community update as we update the experience.
Hi @marizmelo
Here is a gif of jumping from one table to another when modifying a column name. I highlighted some points.

-
when modifying a colunm name directly from the column pane ==> get jumped on the first table pane.
-
when using the pencil icon close to the column name ==> the option frame disappears and we get jumped to the first table pane
-
when clicking on the other table pane ==> the option frame is still here
Thanks for reporting that, will add it to our list of items to look into.
I really like the new navigation panels. But could we please get:
- some “Collapse All” and “Expand All” capabilities?
- Remembrance of how we left the state?
Most of the time I know where things are and don’t want to have to scroll through a bunch of expanded nodes. I will operate in a fully collapsed state and just “tap-tap” and be right where I want to be. It’s especially helpful to have this collapsed state when I am back and forth between two items I’m working on.
However, there are times when I can’t remember the exact name or which node an item belongs to. In these cases it is most helpful to Expand All and then scroll down the list to find the item I need. Once found I prefer to return to the collapsed state.
Currently, the Editor is expanding all nodes every time the app is opened. It would be a much better experience if it could “remember” how we left things. I do know the effort and resources required to implement this feature which makes “Collapse All” and “Expand All” even more enticing - and for me, more required.
Thanks for the feedback, those are things that I want to get to as follow up improvements - as you mentioned, remembering the previous state does get a bit tricky to do right (especially as other editors could have added/delete things). Having it at least remember while in the same session is something I want to tackle though.
We noticed yesterday that the editor is reponsive again, thank you! (no blank on right side)
A small request though: in the Columns setting interface, when using a “normal-sized screen”, would it be possible to freeze the columns name while scrolling toward the right?
For example, let’s say I would like to edit the “display name” of a column, so I will scroll toward the right…and lose the visual contact with the column name.
Thanks !
I believe there are other better “naming” for this menu item rather than “performance”… Very much confusing.
I prefer “Sync settings” instead of “performance”.
When I firstly clicked this option, I expected performance/audit log will appear, but it was not.
Also there is another menu for off line mode, but it should be wrapped inside “Sync settings” as we have in legacy editor.
Separate menues for Settings/Manage are just adding confusion. Not intuitive at all.I m not perfectly sure whatsort of option will be available by clicking either of those options. Current legacy UX is more intuitive. It is getting worse, if this is really GA-ed and introduced as supported layout.

Why the basic UX is not consistent between editor and app (new desktop ux)?
New desktop UX is promising and wait it will be GA-ed soon. However, the new editor layout is not actually. Even a tiny thing is giving me confusion and frustration.
Action icon alone not telling all so we should get the full navigation menu by toggling as we see in new desktop UX (which looks great). However, on new editor layout, we have no option to expand/close the menu… Not sure why. I would say this is inconsistency, not sure what the Google Standard will be in terms of recommended UXs…

I mentioned in other thread before, but my biggest concern on new upcoming editor layout is the available actions will be “nested”, not presented initially and easily to the app creators. Probably we need to click “three dots” icon to display the available option for config, but it is for sure it is difficult for new comers to found them out.
Ideally all the available options should be presented in intutive way, rather than hiding them behind the “three dots”. This is not a hide/seek games.
Due to this, the number of “click” on the editor will be increasing as well to access to the required options… It will make our development works less productive, so I still prefer the legacy UX, due to this.
Thank you Guillermo for the feedback.
On point #6, we were thinking that app creators would be using the “error and warning” status icon in the upper right corner to open the list of errors and then use that to navigate directly where needed.
It seems you prefer to navigate through the primary and secondary navigations to get to the components with the error - even though that may take more clicks. Why is that?
We would love to do that, but… it’s actually not a small request for the engineering team to tackle that. We have it on our radar and we make improvements to that area, we’ll want to address it. However, it won’t happen in the short term - it’s not a simple follow-up item that Ben can tackle.







