AppSheet apps are getting a material upgrade

[Arthur_Rallu]

Hi everyone,

As mentioned previously there, we’re adopting Material design and this is starting to get reflected in your apps. As mentioned by Mike, these changes are UI refinements and should not change how your apps behave. If you see a different behavior, please contact us preferably at support@appsheet.com.

We’ve already rolled out some of the changes (see screenshots below) to some of you for these views:

• Card View
• Map View
• Onboarding View
• About View

These are all the views that have been updated at this point, but it is possible that other views are affected as well. This is only transient. This happens because views share different components and we’ve already updated a component used in another view. We’ll continue our work to update all other views over the next couple of weeks and make them look consistent.

We’ll follow up with other posts starting next week and onward, to let you know changes you can expect to see soon or that have been deployed.

Thank you,
-The AppSheet Team

---

List card view on mobile:

List card view has a different layout now on desktop:

Map view on mobile

Map view on tablet and desktop now opens the selected record in a side panel on the right side

Onboarding view on mobile

Onboarding view on desktop

About view

[Fabian_Weller]

Hi @Cathal_Noone Yes I saw the same change. I also would like to see the background image. This helps to easily “divide” the cards from one another.

[Thiago_Calcagni]

Hi,

I have noticed in the Map View for desktop that the first picture is not appearing full sized.
Why is it different from the screen shot?
My picture is a Virtual Column that retrives a pic from another table.

This was my expectation (picture is edited ok?)

I would like to suggest an option in the Map View to choose if we would like to show the detail or not together the map. If we click in the X, the detail from the map closes, but if we choose another row, the detail automatically appears.
This because in the Interactive Dashboard view, sometimes it is interesting to see just the point being highligthed in the map, without showing the details. (see edited pic bellow)

And also which pic should be the main for the detail from the map. (see edited Pic bellow)

A problem on this new Map View with the detail is that the Overlay Buttons from detail view won’t be shown.

[Jonathan_S]

When Can I expect this upgrade to be rolled out to my account?

[Fabian_Weller]

Thiago_Calcagniti:

I have noticed in the Map View for desktop that the first picture is not appearing full sized.

This is because you have to edit the detail view for the slice “Disponiveis”.
AppSheet created it’s own detail view as you created the map view.
In this extra detail view you can set the “Main Image”.

[Sander_Devissch]

Can you re-enable the ability to repoll the location data e.a. press the pin icon!!
=> this is a breaking issue for our work

[Jonathan_S]

Hey any idea when my account is getting the material upgrade?? Cant wait!. Can you force?

[Thiago_Calcagni]

You are correct, thank you very much !

[Thiago_Calcagni]

Thiago_Calcagniti:

problem on this new Map View with the detail is that the Overlay Buttons from detail view won’t be shown.

Maybe the Overlay Buttons wont appearing in the detail view from Map should be considered as a feature request?

[Fabian_Weller]

Sander_Devisscher:

Can you re-enable the ability to repoll the location data e.a. press the pin icon!!
=> this is a breaking issue for our work

Sorry I don’t understand what you mean. Can you post a Screenshot please?

[Francios]

Hi @Arthur_Rallu @praveen any feedback on the rollout. We waiting on this game changing feature.

[Koichi_Tsuji]

Hi Arthur

After this improvement in new form view, the feature request I I made before is getting and making more sense

Input field - option to add placeholder Feature Requests

For HTML form, we are able to add placeholder as an attribute, so I wish to have the same capability for Appsheet form view. Sometime, the field name alone will not give user of the app reasonable guide as to what sort of data the user needs to enter into the field. We are able to add a description to add supplemental information, but place holder shown within the field box is more user friendly and not kill the space of the form. (Sample Image) [image]

Still with to have feature to get placeholder with the custom and arbitrary text to assist app users to guide what sort of data they are asked to enter to each field. Current “description” function is not useful, so I never used before.

Thank you

[Kirk_Masden]

Hi @Arthur_Rallu ! I hope it’s OK for me to add my own observations about AppSheet and material design. The links I’m pasting below are one’s I’ve already shared on another thread but I thought I’d share them here too for your reference:

Capitalization in material design Questions

I understand that AppSheet is in the process of trying to improve its compliance with Google’s “material design” standards. In that regard, I’d like to point out a minor issue and ask if it has been considered. First, here’s the relevant information regarding capitalization: [Screen Shot 2021-01-23 at 18.27.31] [Screen Shot 2021-01-23 at 18.27.41] [Screen Shot 2021-01-23 at 18.27.46] And here’s what I have in my app: [Screen Shot 2021-01-23 at 18.28.24] In the text that I can control …

Is this Ok (I mean "OK")? Questions

I just noticed this “OK” button in the “About” menu of my app. “Ok” looks odd to me. Shouldn’t it be “OK”? I think we all have the same “Ok” buttons on our apps. If the default is not changed (or even if it is), it would be nice if we could change the appearance or wording with the localize feature (see UX menu). [Screen Shot 2021-01-23 at 17.54.12]

[Arthur_Rallu]

Hi all,

We’ve been ramping up the rollout of our various UI changes and recently one app creator, Randall, contacted us because they thought one of our changes was a mistake, and it was disrupting their users.

When an app user clicks on a record on a map view, the detail view used to open on the left. With our change, it opens on the right (see the post I’m replying to for some screenshots). They noted that we were departing from the familiar pattern found elsewhere and in particular in Google Maps. That pushed the team to revisit our original decision.

In this particular case, after thinking it through, we’ve decided not to revert back to the old configuration of the map view. Let me explain a little bit our rationale.

1. First of all, Google Maps and AppSheet differ in that Google Maps is an app in itself with a sovereign view while the AppSheet map view is one of multiple view types. That means we may have different constraints.
2. We are adopting a general master/detail pattern and we want to be consistent across all view types. App creators also tend to adopt that master/detail pattern when they create their own dashboards. The left part of the dashboard is for visualizing a collection of records, for example in a table view, while the right side is a detail view. When users click on a record of the table, they see the details of the record on the right.
3. One of our goals this year is to make improvements for desktop users. That includes having a persistent left-navigation menu in AppSheet apps on desktop. It’s a standard pattern. The AppSheet footer menu that is currently present for both mobile and desktop form factors is standard for mobile, but not for desktop. With a left-navigation menu, a user clicking on a record on a map view would suddenly see a detail view “pop-up” between the menu on the left and the map view on the right. This would break the standard pattern where you usually go from left to right as you drill down. Google Earth for instance is a desktop app. It has a left nav and it has the details of a selected spot on the right.

That feedback we got was useful. I personally had not thought that this would be an issue, but there was a concern and we needed to revisit that decision. In this case, we’re keeping the change, but thanks to Randall, we were forced to better articulate the pros and cons.

Thank you,
Arthur

[Josh_Klassen]

I find it very interesting that the column widths were okay before and now they are not. I have read through many community posts to see how to decrease the width and I have found many about how to increase column widths but nothing about narrowing them. Would you kindly link me to these posts you are referring to?

[Steve]

My impression is that the intention is to discourage the use of tables as navigation elements and encourage their use to display tabular data. To this end, table views have gained the ability to scroll horizontally. With horizontal scrolling, there’s (arguably) no reason to narrow columns in order to squeeze more columns in, as the “width” of the table display is no longer strictly constrained by the screen.

When horizontal scrolling was first introduced, you had to enable it in the app configuration. I can no longer find the option, so it appears you’re stuck with it.

[Adam-google]

It is the case now that horizontal scrolling is automatically applied in table views, and the option to disable it is no longer available. This thread gives more context. I can expand a bit on the rationale.

Before horizontal scrolling was supported, the view would automatically drop any columns that didn’t fit. This made it hard to predict exactly what data would be visible to whom since different device form factors and orientations would cut off different columns. It also made the views unstable and very sensitive to small changes in column widths - doing a “save and verify” (which recalculates column statistics that influence column widths) could have an unexpected side effect of removing columns from views where they had been visible before. We wanted to ensure any styling changes we make would not cause whole columns to disappear.

Our recommendation now is to use the column order option for cases where you do want to show only a small set of columns. Unlike the old behavior, you can be sure that any column you include there will be visible to the user regardless of device resolution (they may just need to scroll to see it).

We’re working now on providing finer-grained control over column widths for both app creators and end users.

[Grant_Stead]

I’m super excited to see more and more user defined things. Similar to rearranging the dashboard…

[Nicolás]

Hi Steve, in my case i need the narrow columns because this way i can have all the columns visible in a desktop view. Also the extended width that we have now seems an unnecesary use of space. I think it would be a good idea to mantain the narrow option like it was before.

[Nicolás]

Hi Adam, i was looking for this answer since the change was made i guess… I hope you guys can mantain the narrow option to stick to the minimum required or giving app creator more control over size and may be fix column option?
Thanks and keep up the good work

[Arthur_Rallu]

Hi @Nicolas_Cabello
We’re currently working on a feature where app users can choose the width of each column in a table view. The first iteration may not completely address your issue because it may not immediately save the chosen width (as if it were a user setting) and persist that, but this is the first step towards some user customization for the table view.

[Koichi_Tsuji]

Nice ! One step ahead is always important!

[Nicolás]

Thank you very much for your answer, may i sugest it would be great if fixed column would be aviable.

[Kirk_Masden]

Hi @Adam ! Hi @Arthur_Rallu !

I was interested to read about changes to and plans for horizontal scrolling. I wonder if either of you could confirm whether the issue of adding momentum (smooth movement that takes a little time to come to a stop) to horizontal scrolling is being considered:

Please enable/activate horizontal Momentum scrolling Feature Requests

For those who don’t know, Momentum scrolling is the ability to flick your finger on the screen and the view will scroll automatically - quickly at first and the gradually slow down to a stop, all without touching the screen again. Momentum scrolling is currently active vertically. It allows you to get top to bottom of a very long list of records quickly. Now that we can have scrollable tables in ours views and these tables can have a large number of columns, horizontal Momentum scrolling is…

As you can see, this was requested by @WillowMobileSystems and has gotten a good deal of support. @macastan was also kind enough to say that she thought it should be looked into:

Upcoming changes to the Table View - Horizontal Scrolling Feature Release Notes

This is definitely something we need to look into…Thank you for the suggestion, it will be such a big difference for phone scrolling!

I can image that this is not an easy ask but I wonder if anyone at AppSheet can give us an indication of whether or not it is on the “to do” list.

[takuya_miyai]

Hi @Arthur_Rallu

Will the material design of the form view be reflected in the Pro and Business plans in the future?
It seems that some users are wondering why the Form design of the Free and Pro plans are different.

[Arthur_Rallu]

Hi @Takuya_Miyai
Yes, apps from all plans will end up with the same form view (and any other views). We’ve been slow on the rollout. When we last increased the rollout, we hit customers with configurations that we did not anticipate and changed the way their apps looked (and not in a good way) and we had to fix that before we could continue on increasing the rollout to reach more customers.

We will be increasing the rollout in the next couple of days. Keep an eye out on your apps and on the feature release notes.

[takuya_miyai]

@Arthur_Rallu

Thank you.
I’ll keep an eye out for updates to the release notes!

[Arthur_Rallu]

We’re rolling back the change related to the width of the Detail View. See this.

[Markus_Malessa]

@Arthur_Rallu I have just recently been in a production application that I have not used in some time (last time was prior to the material upgrades). However I noticed something rather odd about the GPS Column ‘insert current location’ button. This behavior can be seen in the sample screenshots you posted in December 2020.

Specifically when a GPS column already has a value, the ‘insert current location’ button is displayed as an overlay inside the ‘miniature’ map view that is underneath the column input, whereas when no GPS value has been applied, this button is inside the input field on the right hand side. For consistency purposes, I believe that this button should be inside the input field under either circumstance, as the overlay inside the map could be confused as a map marker.

Please see my more detailed post about this here:

GPS Column 'Insert Current Location' Button Location Questions

When editing an existing row that already has a value in a GPS column, the button to ‘insert current location’ to overwrite the existing value is in a lets say odd location: [image] Whereas when creating a new row or editing an existing row that does not a value yet in the GPS column then the button to ‘insert current location’ is in a what I feel appropriate spot: [image] Is this an error on the Appsheet side by chance? Otherwise I guess anyone else experiencing the same and think that this…

[Rifad]

Here is a bug that’s actually bad Release notes: April 7, 2021 - #8 by Rifadm817