Further usability improvements: simplifying navigation in the Editor

Hello AppSheet Community,

One of the team’s goals is to make it easier for all app creators to build applications by bringing focus to the core concepts and tasks and by providing information and “shortcuts” in the relevant context. We rolled out some of these changes in October and shared this initial announcement.

We’re now excited to announce 2 new updates are starting to roll out today. They are follow-ups to the October changes. 

First, we’re introducing a secondary navigation that lets you see at a quick glance all your components - whether we’re talking about is your data, your views, format rules, actions and automation components. This should also let you access any individual component more quickly. 

As part of this change, suggestions will be available for all components and will be more targeted based on the context you are in (e.g. which Table you are creating a Format Rule for). You’ll also notice that error and warning messages are now shown via a status icon that is always visible in the header. 

Arthur_Rallu_2-1670366295068.png

Secondary navigation menu (left) and Error & Warning status in header bar (top right)

Second, in the same spirit as earlier changes and to be able to make a specific edit to your app without jumping into a different context, there are more direct links in your View component to the table, column or action that you want to check or edit. For example, when you are working on a Deck View, you should not need to click 3, 4 or even 5 times just to check the settings of a column or of an action. This should make more obvious what is possible, especially for users who are new to AppSheet, and make navigation throughout your app components faster

Arthur_Rallu_1-1670366254920.gif

GIF showing accessing relevant components quickly and editing them on the fly

The secondary navigation menu and its associated changes will be available to everyone. Similarly to the primary navigation menu rolled out in October, you can revert to the legacy navigation patterns if you’re facing an issue. Details are in the FAQ section below.

Let us know if you have any feedback.

 

Thank you

The AppSheet Team

 

FAQ

How do I opt in and out of the navigational changes?

App creators can currently opt-in and out of the navigation changes at will. The changes apply to the App Editor experience, independent of the app you are editing. You can opt in and out by clicking on this icon in the top navigation bar. 

Arthur_Rallu_0-1670365762343.png

Is there some documentation?

Yes, we’re updating the relevant pages in our documentation. We’re also introducing a new page that summarizes the changes across the Editor. See Summary of improvements in the app editor (preview).

Where do I report issues and provide feedback?

Contact Support or directly in this thread.

Are you planning on maintaining the two navigation models?

Long term, no, we’re moving towards the new navigational model. For the next few months, we will support both navigation models as we make additional changes to how people navigate through the Editor. We want to work out the kinks before it becomes the only one.

When will the legacy navigational model be unavailable?

We don’t have a hard set date on this. That will depend on how fast we can work out the kinks in the new navigation. 

Why don’t I see anything yet?

We’re rolling out these changes progressively and it might take a few days to a few weeks before you can see them in your own account.

I provided some feedback on the previous changes (from October). Are you taking it into account?

We did read the feedback provided by our community. We may not have addressed it yet - whether it’s making an update or it’s deciding not to make any changes. 

17 214 12.3K
214 REPLIES 214

@Rifad 

I m yet really testing deeply, as I expected such a not-improved user experiences..... It is killing me time so I m sitting with legacy editor, which is much easier to control and navigate for me.

I raise my voice here because suddenly one day they will stop old editor and force to use new editor. Looks neat but functionally it is too much time consuming expand one action at once. Edit one action at once. Cant keep side by side expanded to compare actions/tables. Too difficult.

Generally speaking, (after I spent a bit of time on new editor), my conclustion is the legacy editor should bring an easier navigation to deal with editor. Not a huge improvement at all.

My assessment is not coming from the advanced users point of view like me. I assume I m new boarder to the appsheet and then check how it is easy or not to deal with the editor.  Actions are nested (behind the three dots), and due to other bunch of reasons, it is not intuitive at all for citizen developper.

yes, if we assume this is for developper, using the Google development tool daily, they may welcome new editor. 

Google needs to know who will deal with their own tool.

 

 

The tools and services the Google provide to the market, they are 1) for devs and 2) for just users. 

However, it is possible they have own confusion that they provide AppSheet (no-code tool) to push to the developpers. The Appsheet was born to aim to help the citizen developper like me (no code knowleges and past experiences for ITs)

But the goog example is new Chat App (i m not sure when and how to use to help our daily jobs though).  Config for Google cloud Project. For average users (non developper), they will be confused and lost a way easily. Google says (on their webiner) it is easy. But such a voice is coming from the developpers perspective.  So just having a look at single example, it is obvious the Google wishes to bring Appsheet towards more non citizen developper friendly way, but toward to appeal to devs. 

This is silly story, in light of the origin of Appsheet in 2014. 

Deviation from the original concept is happening year by years, and Google should know their own contridiction what they originally intended to do and what they are currently doing.

 

It is a risk if there is a voice here in  this commuity if they welcome new editor. They should be advanced app creator.  From the new and average app creator perspective, it is getting more difficult generally to deal with the editor. Trust me.

 

I have hundreds of new and old appsheet creator we are coaching every day.

My voice is coming from the conclustions out of what we hear daily from them.

As @Rifad  said, it is obvious new design (layout) should have been made by those who never develop an advanced (relatively) app on their own.

It is pretty much clear from my point of view.

 

 


@Koichi_Tsuji wrote:

it is obvious new design (layout) should have been made by those who never develop an advanced (relatively) app on their own.


Thats my point. I spend most of my hours and days on this Editor interface and I am scared of current changes. My productivity level👎🏼📉. They are coming up with disagreements with me and says new UI is better. As a user when I am giving feedback they says i am not true. What a pathetic situation.

This thread has prompted me to meet with @Arthur_Rallu  and discuss the issues I have raised. He was incredibly understanding, asking all the questions about what we could expect in terms of new Editor UI once it is released to all developers. 

Definitely friendly and understanding, I would say. Hopefully he will pass information to the team and address all of these issues. I look forward to seeing how this turns out. It is very important for someone like me to have an interface that doesn't reduce productivity because it will affect all of my work. My hope is that the Google team understands this and updates the New UI accordingly.

Again, I want to thank him for taking the time and patience to listen to the voices of this Community. Also, I have addressed the issues we are facing with customer support these days.

@Arthur_Rallu @WillowMobileSys @Marc_Dillon 

Interesting graphic there @Arthur_Rallu ...  New Viewtype called "iframe"?

FWIW, the iFrame UX feature idea has a status of "Planned".

@scott192 Good catch.

 

@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:

dbaum_0-1670985152190.png

I tried to replicate this but wasn't able to, just checking - it doesn't appear at all for you or does but doesn't work in some way? Can you try again and save after setting the child action to have inputs? Sorry trying to help I've just tried a few ways and can't break it like you did.


@benhare wrote:

it doesn't appear at all for you or does but doesn't work in some way?


doesn't appear at all


@benhare wrote:

try again and save after setting the child action to have inputs


tried several times before reporting, including saving after setting the child action to have inputs


@benhare wrote:

tried a few ways and can't break it like you did


Thanks, @benhare. Glad to hear that; makes me worry less about my production app that already uses this feature. When I get a chance, I'll try again to replicate. Maybe I was doing something wrong (although, again, I tested several times in parallel ways in two different accounts) or maybe some glitch worked itself out in one of the releases between when I reported and you followed up.

Thanks again, @benhare, for your time troubleshooting. It turns out that the issue I observed was indeed real, but related to a wholly separate (and ultimately inconsequential) root cause.

When I reported the issue, I had been testing in a sandbox app that still had a table whose data source was an AppSheet database from the preview period of that feature. That app has had for a while a cryptic error message that I figured might be related to the wiping of AppSheet databases from the preview, but that I hadn't yet bothered to resolve. In that same sandbox app today, I was able to immediately replicate the problem I reported; then, after deleting the table linked to the wiped AppSheet database, the cryptic error message disappeared, as did the problem in the editor that prevented creation of actions related via the INPUT function. To confirm everything, I also retested today in the same account in a new app using only an AppSheet database data source, and the editor functionality for actions related via the INPUT function worked fine. 

cc @ShirleyN 

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:

1. The responsive of tables isn't working properly, it should fill all my screen

Guillermo_0-1671012599827.png

2. Format rules should be a tab next to views. It was complicated to me to find it

Guillermo_1-1671012827570.png

3. A little bit more space for system generated views

Guillermo_2-1671012928899.png

4. As it is on the Views section, I think that system generated actions should be separated from the created ones

Guillermo_3-1671013499194.png

5. 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

Guillermo_4-1671013722210.png

6. 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)

Guillermo_0-1671014525311.png

 

 

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.

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?

Hi Arthur,

In my opinion, when I have an error now I need to read sometimes a lot of text to locate where is happening the error. However if it's marked with colour red the section and table/view it is like a guide to navigate to the exact point where you have to make the change.

I think the status icon is useful but only in each table. Not for the whole editor. Or at least should coexist both.

Yes, there will be some status error adjustment, in the meanwhile you can use the new project status modal (close to the Save button) to find errors across the Editor with the "go to problem" button. That will allow you to find the errors you are looking for.

In addition to being alternate paths to navigate to an error, they also serve purposes.


@Arthur_Rallu wrote:

status icon in the upper right corner


This alerts you that the app has errors. You may or may not review them immediately, and even if you do you may or may not remediate them immediately.


@Arthur_Rallu wrote:

the primary and secondary navigations


Some indicator here on any specific component that has an error alerts/reminds you that a specific component (which you may be about to work on) has an error.

Aurelien
Google Developer Expert
Google Developer Expert

Hi @marizmelo 

Here is a gif of jumping from one table to another when modifying a column name. I highlighted some points.

Screen Recording 2022-12-14 at 04.32.22.21 PM.gif

1) when modifying a colunm name directly from the column pane ==> get jumped on the first table pane.

2) when using the pencil icon close to the column name ==> the option frame disappears and we get jumped to the first table pane

3) 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.

Aurelien
Google Developer Expert
Google Developer Expert

@benhare 

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 !

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. 

So bad, it's been a pain to me for years, but I get it: priority to the biggest impact change. Keep up the great work !

I believe there are other better "naming" for this menu item rather than "performance"..... Very much confusing.

Snag_4a93398.png

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.

AFD13221-E290-47D7-A479-F1FC0A213882.GIF

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.....

 

FB4212E0-6D7A-4B37-AE0B-346CFC41E739.GIF

It's hard to compare the Editor with the Apps. The Editor is taylored to app creation while the Apps are focused on internal business process use cases. Maybe there is some overlap, but we developed these independently. With the Editor, we were trying to optimize a number of tasks that app creators do while we were thinking of supporting a large number of use cases for apps with more generic patterns. 
That said, we heard your point around the left navigation in the Editor. Thanks Koichi

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.

 

Hey Koichi, 

To make this more specific, could you share more insight into that?
Which actions that are now hidden and that you do often (or even better, that you do more often than the actions that are not behind an overflow menu) would you like to see without any extra click?

Thanks

A couple suggestions for the Views tab in the new Editor

1)  Provide a way to identify what type of view each view is without needing to open it.  Maybe a "Hover-over" label?  We could use naming conventions much like what is done in the system generated views BUT this will then force us then to apply a "Display" name in every view - can be a time consuming task so less than ideal.

2)  It would be nice to be able to filter by the type of view.  There are times when I just want to quickly scan a list of views searching for one of a particular type and can't remember exactly where it is used in the app.  There are other times when I might be searching for a particular implemented feature but don't remember which specific view its in - only the type.

The view of settings (for user settings) have disappeared with the new changes, ¿Where can I change the name seen in the app?

When you delete a table you can't see the slices associated to this table and are shown like errors. I think the slices should remain o should be automatically erased.

 

Thanks!

Hi @Guillermo ,

Thanks for reporting these! We're tracking these internally so we can look at them once the team is back from being out for the holidays.

For the second issue you report-- you should be able to navigate to these slices by using the "Go to problem" link in the "Errors & Warnings dialog" for now. Hopefully that helps!

Shahaf_0-1671648066944.png

 

Best,
Shahaf

Thanks @Shahaf 

OK for the fisrt issue

For the second, I still think everything that exists should be visible

 

Happy holidays!