In Preview: New UI design for desktop users

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)

Arthur_Rallu_0-1659469291920.png

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

Arthur_Rallu_1-1659469291926.png

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

Arthur_Rallu_2-1659469291979.png

 

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

Arthur_Rallu_3-1659469291995.png

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

Arthur_Rallu_4-1659469292027.png

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

Arthur_Rallu_5-1659469291998.png

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

Arthur_Rallu_6-1659469292016.png

 

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

Arthur_Rallu_7-1659469291922.png

 

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
  1. 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
  2. Delete and Done buttons are missing to delete new child row
  3. Some performance issue when there are many Enum value buttons and format rule(s)
Navigation expressions: LINKTOROW(), LINKTOFORM(), etc
  1. When used in emails
  2. When used to go to Dashboard Views
Format rules
  1. They don’t properly show up in a dropdown (for Enum, Ref, etc)
  2. They don't always show up in the group-by section
  3. 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
  1. Error message when action was successful
  2. 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!

80 1,246 73.6K
1,246 REPLIES 1,246

Hi,

Reset on edit is unchecked for these columns. Yes, the first column is also behaving the same way. New video including AFTER tapping on Save is such:

Quick Edit Table including After Save 

@birikim @Peter-Google 

Definitely a bug!! 

 @Peter-Google , even in the video you provided there is some strange behavior in the editing of the table cells that should NOT be happening.  After, entering the value, the display shows the original value for a brief split-second and then switches to the new value.  This is typically indicative of some "additional unnecessary processing" on the Edit.  

In @birikim 's case, it could very well be that the "additional unnecessary processing" is encountering an error which prevents the old value be updated with the new.

Regardless, there is a bug and needs to be looked into.

@WillowMobileSys thanks for the reply. To recap, there are two topics:

1) The topic that the old value is shown briefly before the new value. We will need to revisit this later, since Table QuickEdit is a Beta feature separate from Desktop. We are prioritizing Desktop issues right now. While this is visually unpleasant, it still works in many cases now, so it is lower priority than other issues.

2) The topic @birikim raised, that in some cases, the new value doesn't show up, but still saves on clicking save. This issue has been assigned over to engineering to debug further and ascertain the cost of fixing.

Hi @birikim (also @WillowMobileSys), @Adam-google kindly looked at this and triaged it down to the link. Specifically, appending the "&quickedit=true" is not, as of right now, fully properly handled -- while it initiates quick edit, and saves correctly, it currently has that problem of not showing the new value. Initiating quick edit via just the button works as expected.

Here is a quick video in a separate small demo app to illustrate this:

For now, the workaround is to just not utilize "&quickedit=true" for the short term. Instead, users can just manually initiate quick edit via the button. We're looking into a fix to make "&quickedit=true" work as expected, but I don't have any timeline to communicate yet. Thanks.

Hi @birikim , (also @WillowMobileSys ), the fix was deployed earlier this week. I just retested on my sample app and "&quickedit=true" in links now works as expected. Please check as well, thanks.

Hello @Peter-Google There is an issue with quickedit in dashboard. I have an Inline table in a detail view inside a dashboard view. The quickedit is enabled for that table. 

1. It works when I use an action with &quickedit=true. Only when there is another table in dashboard that has quickedit enabled.

2. When I remove the table that has quickedit (Not the inline table in detail view). It just does not allow me to edit anymore.

 

It looks like format rules don't affect the tab names. Consider honoring at least any applicable format rule's "Uppercase" setting, as well as maybe others (e.g., Text color, Underline, Strikethrough). Some might have to remain ineligible (e.g., Text size).

Format rule:

dbaum_0-1682292903032.pngdbaum_1-1682292932024.png

App UI:

dbaum_2-1682293246315.png

Data source:

dbaum_3-1682293297879.png

 

Thanks @dbaum . Can you clarify, in what cases are you getting/utilizing tabs in desktop:

1) The desktop width is narrow, so you are getting tabs with even only 2 or 3 views open

2) You have a lot of views in the stack, so even on a wide-enough monitor you are still getting tabs

3) Some other case (pls explain).

Knowing about the use case for the tabs helps us contextualize this ask better. In many common cases on Desktop I don't get tabs, I just get the untabbed view headers. Thanks.

I only started exploring the new desktop UI in the last few days, so I'm not even familiar with the various scenarios and terminology in your reply. With that caveat, I think your #2 is probably the one that applies to the situation I observed. I was working in a browser window maximized to the width of my laptop.

  1. The app had a table view in the left pane, and I selected a row.
  2. That parent row's detail view then appeared in the right pane, including its inline table view for its own child rows. I then selected one of those inline child rows.
  3. That opened an additional tab ("GLARE" in my screenshot) within the right pane, with a detail view and, again, another inline table, from which I selected a child row.
  4. That opened yet another tab ("blade" in my screenshot) within the right pane.

Thanks @dbaum for the clarification. I've filed this in our internal tracker as a potential future enhancement.

Tabs also don't support image columns designated as a table's label column. Instead, another column's value appears, but I don't know how AppSheet determines which column. It might be the table's first non-hidden, non-image column.

dbaum_0-1682724030135.png

And, both these issues (format rules; image values from label column) also apply to breadcrumbs.

dbaum_2-1682725362501.png

 

dbaum_1-1682724672741.png

 

Thanks @dbaum . Let me inquire internally on the behavior wrt "which tab string to use when the table's label column is an image."

@dbaum question - in your case, you are just using an image label and *no* text label right, can you confirm?

If you are using an image label and no text label for the row, [UPDATED 5/16] the code will try to use another text col if it exists, else falling back to _RowNumber.

I don't recall exactly how I had configured the columns since I have long since fixed the configuration to be more usable.

In some brief testing just now, it indeed seems like all your assumptions are accurate.

Hello there.

On the Desktop version, seems like filtering a Dashboard with multiple detail views with a LINKTOROW([ID], "Dashboard") has stopped working properly. I call this through an action that activates from clicking on a record on another Table view.

This was working about a week ago. I wonder why suddenly it´s not.

When we use a dashboard view to better display a record that has hundreds of columns or multiple variables, being able to filter the row becomes extremely important. I have read about "Filtering inside the dashboard view directly" workaround, and have applied it in other dashboard from my app, but this one way of doing is way less efficient.

Thanks.

On the other hand, it still works on mobile apps. For some reason.

UPDATE: I have entered my own app through "BlueStacks" Android emulator (yes, completely plausible), and it works just fine as inside the Appsheet editor. If you want to give your users a workaround for accessing a more stable version in a faster environment than the mobile app, meanwhile all of these preview problems remain unsolved, give this a try.

It may seem like not, but I am grateful for the Appsheet service existing. I just have dedicated so much time that it´s frustrating from time to time. But I do care. Thanks!

Thanks @thematgallery , we ll be investigating this.

Hi @thematgallery , thanks for your patience here, this should now be fixed, can you please test again in your app and let us know if you see any unexpected behavior.

I don't have a precise statement of the logic, but roughly speaking, LINKTOROW on a dashboard should succeed so long as the ID unambiguously matches one of the keys for one of the tables used by the Dashboard. This is a special case logic we ported from mobile to the new desktop experience since many people find this useful for their apps. Thanks.


@Arthur_Rallu wrote:

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

Yes, here is an initial updated list [as of Jan 6th] :

  • Forms show incorrect values when computed from expression [fix on its way]
  • Customized deep links not always directing the user to the proper page [fix on its way]
  • Slow performance when multiple actions are triggered at the same time or consecutively [working on it]
  • Form's "Event action" not supported 
  • Background images are currently not supported
  • Chart Views are not working properly
  • Form do not advance automatically
  • REF columns always show as dropdown (even if the app creator chose "button" option)
  • "All" button is not localizable
  • SNAPSHOT() not supported 
  • Record selected in an inline view is not highlighted

An update would be helpful @lizlynch @Arthur_Rallu 

Hi @SkrOYC , thanks for the list. When you say "Chart Views are not working properly", are you referring to another community thread that describes the issue in more detail? If so, can you paste the permalink for that thread? Thanks.

Hi @Peter-Google 

I was referencing the list of pending stuff from the OP

Let me check internally, regarding that list.

Hi, 

The following issue was fixed in the April 24, 2023 release:

tem Description
Bug For desktop UI (preview), a bug was fixed where enabling Edit in place on anonymous views opened the wrong record (a different record).


@WillowMobileSys wrote:

After, entering the value, the display shows the original value for a brief split-second and then switches to the new value.  This is typically indicative of some "additional unnecessary processing" on the Edit.  


I've seen this since a couple of weeks


@Peter-Google wrote:

We are prioritizing Desktop issues right now


In case it wasn't clear, these observed behaviors are in the new Desktop Mode ONLY.   

I use Table QuickEdits in a couple other apps daily without Desktop Mode Preview and I am seeing neither of these editing issues in that use case.

 

Apologies for that confusion. When I say "prioritizing Desktop", I mean the issues that are on the main path to getting Desktop ready for GA. Table QuickEdit is not on that path because it is a separate Beta feature, as the UI shows:

PeterGoogle_0-1682526552645.png

I understand this distinction is subtle, but it is the current prioritization scheme. Of course, where possible we will try to fix bugs like the one @birikim reported, but the prioritization will vary based on each precise issue. We are balancing competing prioritizations the best we can week-over-week and month-over-month.

Understood. 

This does highlight something I hope you can bring back to the team and place on their upcoming radar.  There are several items that have been listed as Beta for years now (most before Google acquired AppSheet).    They need to be finalized.

Thanks. @Arthur_Rallu and I are well aware of this phenomenon, we are trying to balance that against all the competing priorities. I don't have any major update now, but it is something we want to advance.

Aurelien
Google Developer Expert
Google Developer Expert

Hi @Arthur_Rallu 

Here is another thing that may be improved: format rule not fully being applied in a drop-down list (with type Ref)

from the app editor interface, mobile type:

Aurelien_0-1682577731382.png

 

From the desktop interface:

Aurelien_1-1682577787728.png

Many thanks for your consideration!

And thanks for the great work!

 

Thanks @Aurelien, I've added this to the queue of things for eng team to look at, no ETA yet.

[UPDATED 5/16] Just so other readers are clear, in the first screenshot, the dropdown items are being formatted as green or red per the format rules. In the second screenshot, the green/red formatting is not happening but is expected to.

To close the loop, this was fixed last summer, here is an example:

PeterGoogle_0-1707848875685.png

To explain this example, there are two tables, Offices and Site Leads, and each office references a lead. The orange format and icon are on the Offices table, to format the ref (via its presented label). The yellow format, icon and larger text are applied on the Site Leads table, to the name, when the name contains Lana.

If this feature is still in preview, why it is turned on by default for new apps?

In the new interface in April, some of the actions that previously worked correctly stopped working, in the old version they still work without problems.

App ID - Test application for demonstration:

 

7cbd7c2b-c5f5-47ed-a1ae-c37ad044f789

 

The problem occurs when calling an action from a third-party table

For clarity , a conditional scheme:

Схема.jpg

 

The essence of the actions is to add a new entry to the Print Task table from the Project table and further set parameters for printing via INPUT (set this row)

It probably makes no sense to describe in detail the structure of the tables and each action, because a test application has been prepared in which you can see everything.

Operation of actions in the new desktop mode:

App-Sheet-режим-нового-рабочего-стола-_печать_.gif

When launching actions in the "Project" table from the "Report" table, some of the actions are not performed and the INPUT window does not open

Operation of actions in the old interface:

App-Sheet-Старый-режим-_печать_3.gif

 

Everything works correctly in the old interface

How did you managed to print from appsheet without going to the print preview?

 

Good afternoon @Derinko20 !


Of course, this topic is not related to printing options from the application, but I will allow myself to answer your question.
What you see in the video is the tip of the iceberg. This is only the implementation of the first step in the AppSheet.
Analyzing and testing various printing options from the APPSHEET, I could identify several printing concepts:

Печать документов4.jpg

 All of them require the use of additional services or software.

You can also use the built-in software of thermal transfer printers to print barcodes by sending only text information that is encoded into the barcode by the printer itself.

==================================================================
As for the implementation in AppSheet, in this case it works as follows:

1. Tables - Printer || Templates/formats (e.g. A4) ||  Printing tasks
2. Setting up an action to add a print task to the Print Task table

3. Setting up an action to insert print parameters in the Print Task table using INPUT (number and printer selection)

4. Setting up a bot to monitor the addition and modification of records in the Print Task table

5. We send data from the App Sheet to an external printing system

This is a very conditional concept of necessary actions, in practice, of course, everything is much more complicated

Hi @Axel_Pro , thanks for the report, we're starting to look into this, no ETA yet but we'll keep you informed. Thanks.

Hi @Axel_Pro , this should be fixed as of approximately a week ago. I just tested again: go to report page, click on a project, from that project's details page click the print action, and you get the input dialog as expected to set the quantity and printer.

@Axel_Pro when you get a chance, can you check and confirm too? Thanks.

Hi,

The following issues were fixed in the April 27, 2023 release:

Item Description
Bug For desktop UI (preview), fixed a bug where the Finish View setting for form views was not working when the finish view type is a dashboard.
Bug For desktop UI (preview), fixed a bug where detail views with only a header card showing in a narrow column instead of ~700px min width.


@MiguelQ90 wrote:

having everything on the same platform like Appsheet seems very useful to me


Yes, I understand.  A one-stop shop is very attractive both in ease of use and cost.