In Preview: New UI design for desktop users

[Arthur_Rallu]

Hey everyone,

We’re excited to announce we are now previewing our new visual design for applications that are accessed on desktop browsers. 

Currently, your AppSheet applications tend to follow mobile design patterns even when your users have large screens and these patterns can be confusing to desktop users. The new design lets these desktop users navigate their apps more easily and access information in context, and provides an efficient way to create and update records without losing context. App creators can also present more information by leveraging the larger screens but still keep it organized.

Here are some before and after images that better illustrate the design changes.

Legacy Design - Screenshot #1: Sifting through a collection of records grouped by City and State after selecting a State (Deck View)

Legacy Design - Screenshot #2: Looking at a specific record after selecting that record in the screen above (Detail View)

Legacy Design - Screenshot #3: Editing an existing record/Creating a new record (Form View)

New Design - Screenshot #1: Seeing your data in context (Deck View + Detail View)

New Design - Screenshot #2: Focusing on a specific record (Detail View)

New Design - Screenshot #3: Editing in place an existing record

New Design - Screenshot #4: Creating a new record (Form View)

What’s next? Well, this is still a work in progress. We’ve been gathering feedback from a number of design partners, including some of you in the AppSheet Community, and we know there is more to do before it can properly support all of your applications. At this stage, we feel that it would be good to let you play with the new design and to give you an opportunity to share your feedback - what you like, what doesn't work, what you think could use some improvements. This represents a significant change and your feedback will help us guide our next steps. 

As this feature is in Preview, you may see visual changes in your apps as we work to improve the new desktop design in real-time. We don't recommend using the new desktop design in your production apps.

Thank you 

The AppSheet Team

FAQ

How do I get access to this new desktop design?

We are currently slowly ramping this new experience over the next week or so, so you may not see this option in the editor immediately.  

For each application, you can opt-in to use the new desktop design. You can toggle between the new and legacy desktop modes, as desired.

Follow these steps to enable the new design in your app:

1. Open the app in the app editor
2. Navigate to the UX > Options pane
3. Enable the Desktop mode (Preview) option - see screenshot below
4. Save the app in the Editor

All users of this application that access the app on a desktop browser will then see the new design after their next sync.

How do I configure the design of my app? I don’t see any new settings in the Editor!

There are minimal changes to the Editor for now. Mostly, the same settings are leveraged to specify the desktop and mobile designs. Let me give you an example.

Your apps have “primary views” and “menu views”. With the new desktop design, all of your views will be accessible from a side menu. That menu will list first the “primary views” and then the “secondary views”. In the future, we will adjust the configuration settings and in particular the language so that it makes sense for both mobile and desktop apps. For example, position values of "left most" and "right most" don't make sense for the new desktop design with its vertical menu structure.

We’ll be giving app creators more controls over some features that are currently set by default.

Is there some documentation or more information on what changed?
See Optimize the user experience using the new desktop design (Preview). We’ll update it over time.

Is there a list of functionalities that are known to not work with the new design?

Yes.
First, here is a list [as of July 31st] of (high-level) issues and requests that were reported to us and that still need fixes or assessments. Some of them are independent of the desktop mode, but we're still listing them here since people may want to know about them and so they don't need to report them unless it was reported for different app configurations :

General theme	Issues
Form View	Follow-up actions (reopen, next view, click-on-save action) do not get triggered or executed properly; sometimes it is dependent of the app configuration and sometimes it is not Delete and Done buttons are missing to delete new child row Some performance issue when there are many Enum value buttons and format rule(s)
Navigation expressions: LINKTOROW(), LINKTOFORM(), etc	When used in emails When used to go to Dashboard Views
Format rules	They don’t properly show up in a dropdown (for Enum, Ref, etc) They don't always show up in the group-by section They don’t show up new headers
Detail View UI	- In some configurations, showing the wrong display names in a Detail tab - Requests to show the image label in the Detail tab - Edit-in-place in Dashboard view - Sync gets the app user out of Editing mode in a Detail View
General UI	- Improvement requests on the subnav bar (e.g. larger text button, better responsiveness w.r.t. title, actions, text) - Clicking in grey area around onboarding view should not navigate the app in the background - Filtering on Dashboard - Tooltip for icon action buttons - Chart Views do not behave like other views
Localization of strings	Some strings are missing
CSV import/export	Error message when action was successful Export data based on what is visible to the user
Other app functionalities	- Missing Share, Feedback buttons - App Gallery behaving differently - Support of Amazon Cognito (missing account icon) - OCR not working on Desktop
Functionalities for app creators	“Preview as” is not available for the desktop emulator

Second, here is a list of some issues and feature requests that we know we are not going to tackle, at least for now.

Supporting multiple navigation actions in a grouped action	This is not something that we support. The team very intentionally did not want to support this. App creators should not rely on it and it won’t work in desktop mode.
Multiple requests to improve the Table View UI	We got requests to improve the Table View in general. The requests are valid, but that is out of scope for desktop mode. Changes we would be making would also impact the legacy UI and mobile apps.
LINKTOPARENTVIEW() not supported	For desktop users, there are better options to navigate back: the browser’s back button and the breadcrumbs.
Font size changes (via app settings) lead to layout issues	Generally, we recommend using the browser’s zoom which does a better job at resizing the app.
Background image

See also Limitations and known issues. 

How do I provide feedback?

Please share your feedback in this thread below this message!

[SkrOYC]

Well, my current use case considers that the Ref field is not in the detail view of the child record, so the only way to go to the parent record is by hitting the header, in the group by section. I also could make my current report-making workflows work way better if you even allow us to use any Inline Action in the header, so that we can create reports by adding a record to a helper table by using a linktoform in the header/inline action. It makes way less sense to create a report out of multiple records if this action is fired from within a single one, rather than using the header that's grouping them, for example.
I think that the way this was solved makes sense when you just use the default behaviour of showing all columns inside the detail view.
I also posted a question regarding the way an Inline Action to Open Ref made by the creator is not trated the same as the system genera..., and this decision seem to completely forget about that case. I'm 50% angry and 50% sad seing how this is being handled.

In general, I think that you may be going into a path that's more expected for a platform that doesn't require a creator to develop the final product. Since we are the creators, I think we should have full control of such behaviours so that we can make our apps work the way we need. The fact that we have such a limit/constraint is very weird, more considering that there are other parts of the platform that follow a different mentality and are creator's favourites, like Card view.
It is like you may be seeing AppSheet as a toy tool to play with that's inferior to coding options, and I cannot see how the team behind AppSheet could do such a thing, unless that's just the way upper management sees AppSheet.

I think I'm in no other position than start thinking about AppSheet as a less creator-friendly platform than I always thought it was and accept that now it's being tailored to more specific use cases, mainly those inside Workspace/GCC.

I really expected decisions like this to be handled listening to creators instead of a closed group of Googlers that, in the end, are not users of the platform nor make a living out if it

I will need some time out to process this, so many unsensible decisions lately

[Arthur_Rallu]

Thanks for clarifying your use case, Oscar. 

You do have a point with your use case (when the REF value is not shown in the Detail View). I'm going to repeat myself: the request makes sense. I agree and I'm not debating that. 
What I am saying is that enabling it in a fashion that works not only for your use cases but for at least most cases is not as straightforward as "putting it back". Every time we enable a functionality, we see app creators using it in a fashion that we did not anticipate. It's not bad, it actually shows how creative you all are, but it also means in some cases that it's harder for the product team to evolve these features afterwards or to build on top of them or to build something that might interact with the feature. So we're being very deliberate whenever we come at such cross-roads. 
Moving from a single screen to multiple screens for web browsers (with this desktop mode) gets us to lots of these cross-roads. And in the end, we have to prioritize which items we work on first. 

[lizlynch]

Hi,

The following issues were fixed in the August 17, 2023 release.

Item	Description
Bug	For desktop UI (preview), fixed a bug where some auth providers (such as, AWS Cognito) would show a random letter or number in the avatar circle.
Bug	For desktop UI (preview), clicking outside an onboarding view is now ignored.

[kvngo94]

Please check this bug : 

1. [Image] column

2. [Image Label] column

3. Mobile form view --> OK

4. Desktop form view --> Bug

    You see it shows [Image_Label] which must be hidden instead. And it also must show the [Image] instead

[kvngo94]

@Arthur_Rallu @lizlynch 

please help to check this

[Adam-google]

This is similar to the issue below - the screenshot shows the "edit in place" mode of the detail view (when using edit in place, the view type remains "detail" even while editing). If you want different behavior in depending on editing context, you can change the Edit action's desktop behavior mode to "open a form".

[Peter-Google]

Hi @kvngo94 did you try switching the setting from "edit in place" to "open a form"? As a reminder, this setting is on the relevant action settings:

[Peter-Google]

HI @kvngo94, please confirm if switching from "Edit in place" to "Open a form" fixed things for you, thanks.

[bolognesiedalla]

I don't know if anyone has already reported this bug.

In the desktop preview in a Form view when I want to edit a row, some fields to fill in disappear (which instead are present if I do the same editing action in the mobile version).
There are no conditions like CONTEXT(device) in these columns in the "show if" field.

mobile viewdesktop preview

I've already contacted support who, after analyzing the problem with the specialists for about an hour, closed my chat saying that the desktop preview is still in beta testing and they advise against using it.

Plus it seems to cut off part of the view and you can't scroll the page much

I report it here hoping that the problem will be taken into consideration. Thank you

[SkrOYC]

Change it from "Edit in place" to "Open a form"
This is under the "Edit" action for that particular Table

[bolognesiedalla]

Thanks @SkrOYC , that actually works perfectly.
So do you advise me to change all the Edit actions to "open a form" to avoid these drawbacks?

[SkrOYC]

You should check which tables would actually benefit from it.
I tend to go this direction:

1. Simple table with no files or images: Edit in Place
2. Complex tables with files and images and show columns: Open a Form
3. Complex tables with files and images and no show columns: Edit in Place with INPUT() pop-ups for changing images and files (use when makes sense)

[Peter-Google]

Thanks @SkrOYC for helping @bolognesiedalla on this topic. I pasted it below, but I'll paste the screenshot here too for easy reference if other people find this post later on:

Remember, it's configured on the action, not the detail or form view.

[bolognesiedalla]

Browsing the desktop version of the app I'm creating, I realized that there is no back arrow to go back from the detail view to the main one (while it is present on the mobile version).

This arrow:

mobile version

desktop version

You can use the browser arrow but if you have just changed the record it does not go back to the main view but I reopen the form.

Has anyone else noticed this inconvenience? Have you managed to find a method to make it more comfortable?

[bolognesiedalla]

some news on this? @Arthur_Rallu 

[Peter-Google]

Hi @bolognesiedalla , I've made a note of this to be discussed internally. Thanks.

[Denzil_Snyman]

I have noticed same issue, at times user wants to step back with views using browser back arrow however if forms were used during session, the browser back button steps back into a form view it gets messy yes trying to get backwards.

[SkrOYC]

---

@JMPeterson wrote:

am I missing something?

---

As far as I know, we haven't been able to change which app that section links us to.

The app mentioned there, aside from AppSheet Gallery, will be the previous app you were after using a deeplink that takes you into another one.

I use this method to have one Hub app that serves as the "App Gallery" of a bigger thing, where each module is another app found inside this Hub. After entering the module/app, they can go back using the "App Gallery" button, which in their case is their corresponding Hub

[SkrOYC]

---

@Peter-Google wrote:

and not on the record rows grouped for that header.

---

Whether is shown in the records or not is decided by the creator, as always has been.

To be honest, I cannot get why it's so hard to understand that there is a behaviour that is even present in the mobile mode and someone thought that it was not a good one and just left the Inline action out of the group header for no valid or even apparent reason.

I'm sorry if I'm sounding harsh here, I appreciate the work behind the scenes, but I feel like this is not an issue we would have seen with the previous AppSheet team

[Ian_Fusi]

In the dashboard view, the graphics are very small, when we use desktop mode, there should be some way to lock the displayed size, like a true dashboard, have a minimum of responsiveness on this screen. another function it could have would be card, text, with the possibility of formulation, for example total price, total working time, number of employees, presenting it this way would be cool, creating a true BI

[Peter-Google]

Hi @Ian_Fusi , any way you can share a screenshot (without exposing customer or user info, for example w/ sample data), and can you confirm if you are talking about Desktop UI only?

We won't be making any more major changes to the layout options in dashboards before GA, but happy to hear the feedback for future consideration.

[ivanangel]

Hello everyone, please find the following topic I was not able to solve in another thread.

It's a specific problem for the desktop view, but it also pertains to some strange behaviors of the mobile view, especially regarding the cancel button in a form view...

https://www.googlecloudcommunity.com/gc/AppSheet-Q-A/hide-cancel-button-in-desktop-version/td-p/6412...

Thanks

[WillowMobileSys]

---

@ivanangel wrote:

Hello everyone, please find the following topic I was not able to solve in another thread.

---

As explained in the other thread, there is no solution - really nothing to solve.  It is not possible, at this time, to eliminate the Cancel button.  The real bug is that we are able to change the Cancel button label to blank when the real intent (by AppSheet) was to just be able to change the name.

[ivanangel]

Thank you Willow for the prompt reply (the same I received in other places these last days) but be careful that what you define as a "real bug" linked only to the desire to hide the button instead of deleting the "cancel" text is a much more important problem. In fact, if you use the form view to log in and the user presses the cancel button, they access the app without entering their credentials. If you have already found another way to allow secure access to the app acting directly from the app, please share it; otherwise, specify that the only way is to rely on a login tool external to AppSheet. Please let's try to be proactive. Thank you

[Marc_Dillon]

---

@ivanangel wrote:

if you use the form view to log in and the user presses the cancel button, they access the app without entering their credentials.

---

You should NOT be doing that. If you need login for your app, you need to use a Secure app. You may in fact be breaking the TOS.

[WillowMobileSys]

---

@ivanangel wrote:

but be careful that what you define as a "real bug" linked only to the desire to hide the button instead of deleting the "cancel" text is a much more important problem

---

What I meant was that is was AppSheet's intent... for us App Creators to be able to change the Cancel button label.  Changing the label to blank implies "hiding" the button and that currently is NOT supported.   That is why I call it a bug.

---

@ivanangel wrote:

they access the app without entering their credentials.

---

You are trying to use the Form in a way that was not intended - as a login screen.  Login screens are external to any app and require additional functionality that an AppSheet Form View does not provide.

---

@ivanangel wrote:

If you have already found another way to allow secure access to the app acting directly from the app, please share it; otherwise, specify that the only way is to rely on a login tool external to AppSheet. Please let's try to be proactive. Thank you

---

Since this thread was about Desktop View, I only responded to the portion about the Cancel button - which should be the only concern on this thread.  I did provide a more proactive response about app access and security in your original thread.

[Wardaddy]

Reference actions "Data: execute an action on a set of rows" doesn't work correctly in detail desktop view. Action button open the reference table in mobile view, but it open the same table in desktop view. Any solution ?? Hopefully there's fix for this feature as it is very useful when viewing nested table.

UPDATE: After tried different method, changing the desktop behavior to "open in form" is the solution. 

[Skip2MiLu]

Hi @Arthur_Rallu 
Seems like the Card View within Desktop view breaks whenever you use grouping. 
I believe you do not have much choice but to move the Card View orientation to the same vertical layout in mobile view vs the hortizontal layout. 

See below comparison.

[Peter-Google]

Hi @Skip2MiLu , I can't find the previous post, but this was discussed sometime in the past few months. For now, only the 'list' layout type for inline card views scrolls vertically when inline; the rest scroll horizontally:

We have gotten previous feedback on the interest for more variations, such as vertical scrolling cards. The current approach will be used for GA and we'll consider other updates beyond GA.

[Skip2MiLu]

Thanks for the feedback @Peter-Google

I believe my point is less about having the option to choose between vertical and horizontal scrolling in a inline view. 

My main point is that there is a bug in the desktop view in that horizontal scrolling is not even possible within the large card inline view when using group columns. I. E. Scrolling does not work. 

Let me know if you are understanding the bug that I am reporting, otherwise I can share gif of the user experience. 

[Peter-Google]

Hi @Skip2MiLu , sorry for the confusion, thanks for clarifying. We'll need to take a look.

[baba_sawane]

Would be nice to be able to disable the 'foldable' menu button. So that we can restrict it to show the views names 100% of the time. 

[WillowMobileSys]

You can with a setting in the Theme & Brand section.  But, as many have complained previously (I agree with the complaints), this single setting hides BOTH the side menu and Search bar at the top. 

 

I hope this helps!

[baba_sawane]

Thanks for the answer.  I was talking specifically for the desktop view, I want to remove this button and keep the menu deployed so that we always see the menu headers in the UI.

[Peter-Google]

Hi @baba_sawane , thanks for the feedback. This is similar to this other request. I've added it to an internal list for further consideration, but for transparency, it's unlikely to happen before Desktop GA. Thanks.

[Peter-Google]

Hi @WillowMobileSys , on this point (hiding menu and search being coupled), I did find two older posts on this: here, and here. I'm going to add this to a list of future enhancements (decoupling those settings) to discuss. It probably won't until after Desktop GA though. Thanks for bringing it up again.

(To clarify, while this is the Desktop UI thread, this particular topic applies to Desktop and Mobile).

[lizlynch]

Hi,

The following issue has been fixed in the October 19 release:

Item	Description
Bug	For desktop UI (preview), LINKTOPARENTVIEW() is now supported.

[KON_TROLL]

Just want to give you credit @lizlynch  and @Arthur_Rallu 

The new UI for desktop is working really well for us (and our users) and you and your team has done a great job fixing and improving this for the last 10 months or so. Keep it up:) 

[Peter-Google]

Thanks @KON_TROLL for this note. Just so I'm clear, is the main benefit just being a dedicated desktop UI experience (vs a mobile-centric experience made larger on desktop), or is it more nuanced than that? Thanks, just trying to see what aspects of desktop resonate most with users.

[lizlynch]

@KON_TROLL Thank you, but I'm just the messenger. 🙂 @Arthur_Rallu and the AppSheet dev team deserve all the credit!