Can you create a support ticket so we can take a look at your use case in your app? Thanks!
1 Like
I love this future. Thanks!
Great to see that improvements are rolling out.
Making the desktop match the mobile format is important, I wish I knew about this on a roadmap though, as I had put a lot of custom work into making the desktop match the mobile format, so it will be back the drawing board for me.
I work in the disability sector and I’m wondering if disability and accessibilty needs have been baked into this redesign?
Cheers
1 Like
Wow Wow…will try it soon. I’m building some SaaS that are relied heavily on AppSheet and GPC. So it is right time for me.
Thanks you for working on continuously to improve the UX globally for AppSheet.
I quickly tested. Just three feedback for now.
-
“Linktoparentview” deeplink action seems to be not working on the new mobile UX. (likely a bug)
-
Display name for actions are ignored and not being respected in the tooltips for primary actions. The unique action names always shown (likely a bug)
-
New “Sync” experience. User need to hit and click “Sync” button to force the sync of app twice. I dont think it is not a good user experiences. Ideally, once the user hit SYNC button at the top right conner, then the sync operation naturally kicked off rather than hitting sync button one more time. Once again, far better user experience would be "hit sync at the upper right corner. Then sync would start while the bottom footer indicate the Sync Status. Once, the sync is finished, the user can closer the footer or the footer disappear once the user hit app anywhere else.
11 Likes
A small feedback here about related items: Related items display the “Display name” when using a Detail view type, while displaying the “Column description” when using a Form view type.
It has always been this way but it looks irrelevant when comparing detail and form view type: it is possible to make it consistent?
Thanks for considering
1 Like
This could be kinda of “feature request” not only for mobile view but for desktop view as well, but it is wise enough to take this up on this occasion while the dev teams are actively working on UX things.
For the “column name” especially for the mobile UX, the font size is far too tiny, and very much hard to read due to its tininess, especially for those of presbyopia like me. Ideally we need to have app global setting to fix the size of the column name with the details view, “Tiny, Small, Large” to change the size of column name more readable for the users.
With the desktop mode, the column name are more readable than mobile view for now, but font size with mobile phone is far too small.
Thank you for considering.
6 Likes
Description is just simply designed for the user to assist when they are on the form view to entry the data… It does not make sense to show Display name of that column in case of Form view.
1 Like
I get your point, but I disagree with that. A display name is a display name: if I want to guide the user, I can use the CONTEXT(“ViewType”).
Another bug I noticed while playing around.
“Freeze first column” (currently with preview mode) not working with new mobile UX, while it works with current mobile UX.
1 Like
I m sorry, but I disagree.
Then, how do you set up your app while you wish to have a particular “Guide” for user on Form view using “Description” option while you also have a need to display a display name for “Detail view”.
With your suggested settings, we get unable to set up to achieve our goal.
As clearly mentioned here, “Column description” is just an option for “Form View”, no more than that.
2 Likes
Not mentioned in the documentation for new mobile UX, but it is good enhancement to show “labeled” column as “view name” for detail view which is shown in header part. For this enhancement, I do have suggestion to make it more useful for users.
It is quite often that “label” column text length is bit long, therefore the view name in header part is truncated (partially visible) most of the times. For a suggestion, add “tooltips” for view name at the header. In other words, the user hit the view name (at the header) then the tooltip is make visible to show the full view name (=label or display name).
2 Likes
This change (highlighted in the docs below) make a thing worse and worser.
Add new row with the existing key value used to work as “UPSERT” operation both mobile and new desktop. However, once the new desktop was in place, then this was blocked by new desktop. So we have been requested for long time to address this but with new desktop. However, why do you make the function to be in line with bug? The important thing is to solve the bug for this with new desktop ux, rather than block the action for both new mobile and new desktop… Completely does not make sense.
In the meantime, with AppSheet API and invoke such action with Automation, we see the expected “UPSERT” operation without problem. Once again, this change would lose the consistency further.
2 Likes
Thank you for bringing this up @Koichi_Tsuji . We also need the function to “update” a row when the ID already exists. If the “Add a new row” action would be blocked, then some well working parts in our apps will no longer work.
3 Likes
@amyplin maybe you can consider the visual bug I mentioned in this post. This is still the case also with the new mobile framework.
1 Like
@amyplin It would be awesome if we could place navigation actions on the map view. Right now we have to use this workaround just for jumping to the current location.
2 Likes
@amyplin and please fix this years old bug 
1 Like
Indeed. Some high number of our apps will definitely be broken and need to re-construct…
Google teams need to re-recognize how large and massive magnitude negative impact this change is going to bring to the live apps… I would say it is surely larger than they expect.
I really don’t understand the way of thinking of Google team to ABSORB the bug to the platform…(x.x), rather than fixing an obvious bugs. We must be careful for the time being anyway.
2 Likes