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:
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 |
|
Navigation expressions: LINKTOROW(), LINKTOFORM(), etc |
|
Format rules |
|
Detail View UI |
- In some configurations, showing the wrong display names in a 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 |
|
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!
I was using this formula below and posting it in the body of the HTTP request for slack hook to link the slack message back to the appsheet page.
"https://www.appsheet.com/start/<<_APPID>><<LINKTOROW([camp id], "Campaign_Detail")>>
However, when I switched to the desktop view, the link goes to the legacy mode and automatically changes back to desktop view but not to the designated detail view but to the default dashboard view. Is there a way to set up a url so that it goes to the detail view in desktop mode?
It is kind of a bug, since the solution is not done yet. But it looks like they have a good plan for this. Here it the last update as far as I know:
The current state for this Preview is what you have seen: by default the Edit button in the app opens a Detail View that is editable; we have shared a way to bypass this (as shared by @SkrOYC ), but really it's only a temporary work-around.
At launch (where this desktop UI is officially available to all users), app creators will choose how they want their users to edit existing records: with a Form View or with the editable Detail View. We are working on this. The workaround has way too much friction and is not discoverable.
Hi,
A number of reported issues against the desktop UI have been addressed in the October 27, 2022 release, including the following:
Item | Description |
Bug | For desktop UI (preview), default to vertical scrolling for inline card views in dashboard views (instead of horizontal scrolling). |
Bug | For desktop UI (preview), fixed issue where button mode was not respected. |
Bug | For desktop UI (preview), fixed CONTEXT() in virtual columns in form views. |
Great. Good job!
Looking forward to address to autofill based on Google addresses as it does in "the old" desktop solution. Very usefull, since we're using that to get LatLong on a Google script and must make sure Address i 100% correct.
When the app is updated and synced, I need to "switching tabs" in desktop view to make it show the latest result or it will keep the status before updates.
Thank you.
I have been using the _ComputedAddress field to display an image in my app. I place it in a Detail view within the header (using the Card layout option). This works fine in the mobile design. However, when I switch to a Desktop Design I'm working on, the image no longer displays. Is this a bug? I'm unclear if it's because of the new Desktop Design being rolled out, or if it's related to images in the header (using a card layout) or _ComputedAddress in particular. Thank you for the help.
Relevant images can be seen here:
Hi everyone!
Im testing the Desktop Mode in a new app Im developing with my team and I realized that action on saved with type "LINKTOROW" is not working. The expected behavior in Legacy Mode is that once you click on Save in the form it navigates to its Details in a Dashboard View, and it works in Legacy Design, but not working in Desktop Mode.
I LOVE this beyond words!
BUT (of course there's a "but") found this unexpected behaviour:
I have a column [Product] (not a key) which has a validation formula to avoid duplicates:
NOT(IN([_THIS], SELECT(Articles[Product], TRUE)))
This works in non-desktop mode, when I edit the field (or enter a new row) and enter a value that's already present it gives me an error message as expected.
BUT in desktop mode the error message is permanently displayed and impedes ANY changes to the column, including new adds, since the app gives the same error message for ANY value I enter, pre-existing or not.
Note that the product is also somehow displayed as a non-editable input field in desktop mode.
I have a feeling this might be related to "Forms show incorrect values when computed from expressions"?
I have a feeling this might be related to "Forms show incorrect values when computed from expressions"?
Correct. We don't have a fix for this at the moment.
Hi,
The following issue reported against the desktop UI (preview) has been addressed in the November 1, 2022 release.
Item | Description |
Bug | Prompt user to save or discard changes when leaving a table view with unsaved changes Fixes a bug in the desktop UI (preview) where a user could navigate away from a table view with edits in progress without saving or discarding them. |
Thank you,
Liz
Ho
The following issue reported against the desktop UI (preview) has have been addressed in the November 2, 2022 release.
Item |
Description |
Bug |
For desktop UI (preview), fixed bug where force sync using LINKTO actions with "&at="&(NOW()+1) added to the expression was not working. |
Hi @Arthur_Rallu !
Thank you for this amazing new feature.
For EnumList Dropdown field, in case of filtered list:
Another thing (only a "nice to have", not a bug): the "clear" button is really close to "open" button. It's easy to misclick and clear all the selected records.
Thank you
@AleMagna wrote:
after selecting one record, the filter is removed
To be honest, I prefer this behaviour, and I'd like to see it on the Mobile Mode.
I guess there should be a setting on the column config in the future to decide it
@SkrOYC wrote:
To be honest, I prefer this behaviour, and I'd like to see it on the Mobile Mode.
For an Enum List? Surely you mis-understand the problem. Maybe you are thinking Enum?
The issue here is that you apply a search filter in a dropdown list of an EnumList type column. The user wants to select several items based on the filter BUT as soon as a single one is selected, the first one, the filter disappears and the list displays the entire dropdown list again. A user either has to:
Either way is very inefficient and NOT user friendly and I am certain is NOT the intended function.
Note that this is NOT the way it currently works for any search filtering. When a multi-selection action is possible, the user should be one to decide when they are done with the filter by searching with a different filter, tapping an "x" button or tapping off of the dropdown list/search feature.
**********
For a Enum, Ref or any other single selection dropdown, I agree that as soon as a selection is made, the control closes and returns to the normal view. This IS what currently happens for those type of controls.
Call me weird but I meant what I said, I guess I'm not an UX expert anyway
Weird! ๐
I guess not...
Thank you for this explanation.
It's exactly my point: It's not user friendly and for sure is not the intended function because on classic view is different.
Hello @Arthur_Rallu
Have this issue with navigation button when hitting the link to app. I made a dashboard/navigation app where the user will have more of custom landing app. But upon going to other app on desktop mode, Link to app(main) changes to "App Gallery" after reloading the page. On mobile view there is no problem. Ive attached a image for better understanding.
โ
@KON_TROLL wrote:
Is the fix for using form view for editing any where near a solution?
Take a look at older comments about it, there is a workaround given by the team while we wait for the editor to fully embrace the Desktop Mode
The workaround is pretty useless. @SkrOYC
Creating 50 new edit actions and hiding all the existing ones in every app is pretty pointless..... And when the new feature is in place, then doing it all over again reversing it!?
Is this discussion about workarounds just so you can continue testing the Desktop Mode?
Just eager to proceed in some of our apps. The new UX is just too good to leave alone. No critics, just a bit unpacient;) I did not ask for the workaround....
As mentioned by @WillowMobileSys, Desktop Mode is out there for testing, not everyday use if it doesn't meet your requirements. Desktop Mode is presented as is, and they will be making changes every week, but if it doesn't meet your requirements as is, don't use it.
That's what testing is all about @KON_TROLL
Correct, but there was also a comment earlier about an app creator who WAS interested in just testing and couldn't proceed because there were roadblocks at every avenue. My comment had two implied points:
1) Don't YET create live app workarounds for Desktop Mode. It is way to early and would be a waste of time.
2) If bugs are halting testing in a certain area, then that should be brought to AppSheet attention. It is in their best interest, and ours quite frankly, to remove roadblocks and leverage the willing community testers as much as possible.
One general comment for us ALL to recognize...
The Desktop Mode is extremely raw right now but a tremendous step in the right direction for Desktop apps. I don't know of ANY technical companies that open up forthcoming implementations this early! The whole intent is for us, citizen developers, to give feedback and help mold the direction and shape of the final product based on OUR needs - a carry-over from the original AppSheet company.
If we abuse this "gift" in a way that gives AppSheet a bad rep, it will be taken away. The more knowledgeable community users need to make sure we inform and educate the newer users who may not know about this preview process.
So true, but you know... when they let us taste the chocolate... we want more ๐
I still do not think asking for plan for update of different bugs is to "abuse this "gift" in a way that gives AppSheet a bad rep"
Exactly! @SkrOYC So that's why I asked for when a functional solution for this will be availeble....:) Not for a useless workaround.
@KON_TROLL wrote:
"abuse this "gift" in a way that gives AppSheet a bad rep"
Agreed and I wasn't implying that to be the case. I only mentioned that last part because there have been many regular Q&A posts that @Steve and I have responded to, reminding/inform them that Desktop Mode is in preview. Many of the newer users just don't know and I have seen a couple posts that were a bit nasty about the feature. And we all know how any social media can influence others - especially others not in the know!
I guess I wanted to remind us that we need to be careful how far down the "chocolate" path we allow ourselves to go. Basically, police ourselves!
@WillowMobileSys wrote:
there have been many regular Q&A posts that @Steve and I have responded to, reminding/inform them that Desktop Mode is in preview. Many of the newer users just don't know and I have seen a couple posts that were a bit nasty about the feature.
Same with AppSheet Databases
@KON_TROLL wrote:
a functional solution for this will be availeble....:) Not for a useless workaround
The thing is, the way it works right now is by design, it's not a bug, maybe a mistake based on who you ask, but they expected it to be the new editing experience of the Desktop Mode and figured out in the process that having a Detail view like experience for editing the fields was not always the best.
I remember when I talk about this on the private preview with @Summer1 and she said that they wanted to make a new and probably better experience to replace the old one (form view), but I guess it's just not an easy task to do and most of us are happy with a form view to edit fields, more so when there are more advance use cases as the ones I shared with her when detail view and form view doesn't even have the same fields.
The thing is, I can see a future where the form view is just available for adds and the edit view will be a separate view or default to either detail view fields or form view fields, instead of the expected form view (which was what the team wanted to do in the first place). But, as we all have mentioned before, we are still on the early stages of the Desktop Mode, something like a Beta waiting to be on staging/Release candidate, so we won't know until the developing process is complete
Hi,
The following enhancement and issues reported against the desktop UI (preview) have been addressed in the November 9, 2022 release.
Item | Description |
Enhancement | For desktop UI (preview), there is now a button next to the "phone" and "tablet" emulator icons to launch the desktop emulator in a separate tab. This enhancement will be rolled out gradually. |
Bug | For desktop UI (preview), fixed bug where the wrong actions were sometimes shown in the sub navigation. |
Bug | For desktop UI (preview), expanding detail views wouldn't always work properly. When users returned to dashboard views through the breadcrumb interface, sometimes detail panes would be empty. This behavior should now be fixed. |
Bug | For desktop UI (preview), groupBy views for the last groupBy column instead of showing them in the drill-down tree. |
Bug | For desktop UI (preview), fixed inconsistencies with filtering in dashboards. |
Thank you,
Liz
Well done! Keep it up:)
Hi Lizlym I wish appsheet update tree view for menu view assap.
Thanks
Hi @lizlynch,
I see showing the drill-down tree for group column as very useful for users on the new desktops, but I don't why Appsheet removed it for new update version?.
Hi @hien_nguyen
We did not remove the feature for grouping and filtering records. We modified it so that it is consistent with the experience you have on mobile.
To get back the display where all groupby columns show up in the drilldown tree, simply add the "_RowNumber" column at the end of the groupby list. See the note in https://support.google.com/appsheet/answer/10106698?hl=en
Well done on the updates. Working really well. I also noticed some new features to the editor. Very useful!
@lizlynch you guys are doing some good work!
I think a new bug arised after last update:
If you from dashboard enlarge/open a table view with groups after first having opened a group, you will not see the rows/data in the other groups. They do show as groups to the left with sum/total etc., but when clicking on them you just get an empty window with no rows... (the sum indicates of course that there should be rows there....)
Could it be related to the earlier issue of third breadcrumb...?