I need advice on how to make one of my dashbo

[fdmsaraiva]

I need advice on how to make one of my dashboards scalable.

I have a delivery tracking app. In it, I have an interactive dashboard with 3 views: - List of weeks - List of deliveries - Map of deliveries

This view currently loads ~600 deliveries spanning ~6 weeks.

At 600 place markers the map is already pretty laggy. The dashboard is interactive so I can filter the map by week, but this appears to be only aesthetic as the filter is pretty much instant and the map lags just the same, whether I have every delivery visible or just a given week’s worth.

Every week adds around 100 deliveries, so I know I’m just a few weeks away from the map becoming way too laggy, or worse, having deliveries start to go missing in the map.

This view is key as it gives admins a unique birds-eye view into the delivery side of the business.

So far as I can tell, the narrowest bottleneck is the map. Ideally - feature request time! - AppSheet would change the behaviour of map views in dashboards so that: - Map is redrawn with new pins when a filter is applied - Upwards of a certain pin amount, say 1000, map doesn’t render pins and a warning asks the user to further funnel down the data via interactive tables

As a last resort, and for this specific app, I know I can make slices of deliveries out of fixed intervals of weeks, keep adding these slices manually over time, and have separate dashboards for every slice, but this is also unscalable and cumbersome.

Thoughts?

[Buglouse]

I have the same issue. Rendering 600 icons on the map was laggy for field use. I have a custom filter for the areas we are focusing on at the time.

Create a table with your filters: Name, Type, Filter

Create an filter action on the filter table to render the result,

Behavior Condition=[Type]=“Zip” linktofilteredview(“Contracts”,and(in([Zip],split([_THISROW].[Filter],",")),[Inspection Date]>=[_THISUSER].[InspectionDate]))

Create a view for your filters so that you can click a filter, back, click another filter.

You can apply this logic to any constraint you have a value for; zip codes and dates (need to complete by), for my data. It is extensible for geolocation or, again, any value you have for your data.

What I had to overcome was creating separate actions for your filters, I have a few types and each type has a list and map action, for each type I create a custom filter. Once a type is specified, the filter can be modified within the app to show a different filtered result.

BTW I really like your view!

[fdmsaraiva]

@Buglouse Interesting workaround, thanks for sharing.

The benefit of that approach is that it is indeed scalable, and that’s quite a big benefit. Also, it’s a definite improvement over the last last resort I was thinking of, so that’s what I’ll do if I have to.

The downside though is that it really isn’t a dashboard any longer, as filtered states of the table and map views would load in a new screen that replaces the filter table, so I would have to go back and forth between screens to browse the data.

Anything I could do with an interactive dashboard map with a growing dataset to make it more scalable?

[pravse]

There is an option in UX -> Options to limit the number of map pins shown. Is that useful at all in this scenario? It shows pins that are closest to the current location, which I’m guessing is not what you want here?

Adding @Morgan_Dixon_AppShee and @Adam_Stone_AppSheet FYI

[Buglouse]

Well, I kind of like the idea so I gave it a try. UX > Map (Interactive Dashboard) with Contracts Map (Map) and Routes (Table). Routes > Route Map (Action) Route Map > Grouped: All Map, Zip Map, County Map (This is the draw back, unless I use a deck in the dashboard I’m only limited to one sub-set of actions; as I have Zip-Inspect, Zip-Inspect Fail, Zip-Inspected.) The Actions in the group have conditions that match Route[Type], so each should try but only the first match should succeed. This limits the click-on-row action to be only one, unless I can have an interactive condition… I could put Routes in a deck view so that all my actions are present.

Unfortunately this does not work exactly as I expect. Clicking the row with Interactive Off shows me the Contracts Map. Clicking the row with Interactive On does not change the view. Maybe I’m not understanding how interactive is intended to work. I would think that if a view is currently shown, clicking a row that results in that view changing would cause only that view reloading, keeping the rest of the dashboard intact. Does the Interactive mode change the display the row is on or can the row change an attached display ?

[fdmsaraiva]

Thanks @praveen. Pin rendering being weighted by proximity shouldn’t factor in because I have location mode set to none in the map view. The location of the user doesn’t really matter in this use case.

Also, I have that UX -> Options setting set to 5000 pins just to remove it as a bottleneck for the time being.

But at ~600 pins the dashboard already shows clear signs of performance degradation so I’m sure it’ll become unusable well before I hit 5000 pins.

So the question is how maps in interactive dashboards could be improved to keep up with steadily growing datasets, either by me, applying a technique I didn’t think of, or by you, changing the map view behaviour. What did you think of the features suggested in the initial post?

[pravse · Accepted solution]

@Filipe_Damaso_Saraiv, you could take @Buglouse’s idea but instead of having actions, you could enable quickedit. This idea is also desribed by some others in the community. It is a workaround in lieu of a true structured search view. The basic idea is:

*) have a Filter table

*) give it a single row – let’s say it has a key column with value 1.

*) in the dashboard, add a Details view for that table and enable quickedit for the columns

*) for the table you want to map, set up a slice that uses the row from the Filter table to appropriately filter the values. Something like this:

[ColumnA] = LOOKUP(1, FilterTable, FilterKeyColumn, ColumnAFilterValue)

*) add a map view over this slice to the dashboard

The purpose of the map pin limit is so that you never show several hundred pins on the map. So it is exactly what I think you were asking for in the original post.

[fdmsaraiva]

@praveen that workaround is great, it allows me to retain an interactive dashboard UX while avoiding loading the complete table upon entering the view, so I believe it solves my issue.

The map pin limit however, doesn’t seem to be what I was asking for, because the map performance doesn’t seem to improve much by lowering that limit. Performance can be pretty subjective and I may be making faulty assumptions, but it seems to me that the limit is mostly aesthetic, hiding items that have been loaded nonetheless. Eg: if you have a map drawing from a table with 5000 rows, then the map will lag and crawl even if you set the limit to 50, however, the map won’t crawl if it draws from a table that only has 50 rows.